That makes things much easier.
That makes things much easier.
I will try and do an update tonight to push these through.
I do not want to disturb you guys in any way but I don’t see the updated binding.
Last CI build is before your answer. Z-Wave build #14
Am I correct?
I’ve tried to install HomeAutomation. Their V3-BTZE device has 2 additional channels, some kind of Alarm state and report which is not present in current binding (I could not get more info of it). Might this be the root cause of NONCE errors? (Two separate channels updated by the lock but the binding only expects one channel to be reported and mixes NONCE IDs?) I way far from debuging any java source code (I only have some .NET experience) so ingore this if I’m totally wrong.
HE apparently did not have time to export the database. I verified by checking GitHub.
Thats ok, thank you!
Can I get the repo URL, to check it for myself later? Or is it a private one?
I check the date here. It goes here before the build picks it up.
I’ve just downloaded the latest CI build and the latest binding and I can confirm, the lock is reporting back. There is no NONCE security errors in the log, only I found four of <NODE 2: SECURITY_ERR No valid NONCE! null> error messages which does not affect the expected behaviour.
Thank you for your effort with this, and for the quick solution.
Best wishes and regards,
Sorry, I was too early.
I have a new security error: <SECURITY_ERR Failed authentication!> Displays 8 unmatched hexadecimal numbers. I continue the logs:
And again the UI failed to reflect the lock status change.
Well, if it fails authentication, then it won’t show the lock status.
Still got several NONCE ID invalid errors.
I don’t see any problem myself. Can you provide a short log that is actually causing you a problem.
The nonce issues that I see in the log are caused by packets being received twice, and not decoded the second time.
Hi @chris !
Sorry to resurrect the post but I still have some minor issues with my Danalock.
If I issue a command from the console to unlock/lock Danalock the item states are updated 3 times (ON->OFF->ON or vica versa depending on the initial status). This comes through the event bus to my rules and makes some hard time to figure out the current status of the lock. In real wolrd the lock only turns once.
I think the main cause is that the polling starts too soon and sees the status of the thing not started to turn yet and reports back the startup status too early. I attach the log of Z-Wave DEBUG and the relevant lines of the events.log.
Can you implement some wait code before the polling starts (I assume there is some devices with momentum and needs some time to reach the intended state)? Or any other method to correct this? Do I need to prepare my rules to handle this? (this may force my rules to be much more complex)
Please just change the command poll time to something longer to suite the needs of your device. This defaults to 1500ms (if I remember correctly) but can be set up to 15 seconds, and if set to 0 can be disabled all together.
I’ve tried to change it to 2500 ms than to 3000 ms on PaperUI but there is no effect. The log says it received a config update but the value defaults back to 1500. I tried it twice. And I noticed that the lifeline setting is lost as well. I’m on OH 2.5.5 release, Win Server Core 2019 and Zulu JDK 22.214.171.124 (8u242), 64-bit.
ZWave2.log (15.6 KB)
From the log, there was no change -:
NODE 2: Configuration update ignored binding_cmdrepollperiod to 1500 (BigDecimal)
I guess this is an issue with PaperUI? I’m not really sure, but for sure it seems that the binding is not receiving the new value.
I’ve managed to change this in jsondb and it is working right now.
Anyway I could not find anywhere the answer to this question: Is it possible to migrate a securely included lock to a .thing file? Or is it needed to be in the jsondb with previous secure inclusion made in PaperUI? Only this step keeps me to perform a full transition to thing/item files. Thank you for your help.
I don’t see why not - there’s nothing that needs configuring, so you can use the thing file if you want. Note that you can’t change any configuration of devices configured using things files.
I have the same issue with my danalock and found this:
NODE 16: Door-Lock config report - timeoutEnabled=false timeoutMinutes=254, timeoutSeconds=254
does this mean that controller ignores Node 16 (danalock) if there is a timeout and does ot try to reconnect?
I’m not sure what sort of “reconnect” you mean here?
This is a report from the lock - it’s nothing to do with the controller. I’d need to read the manual for your lock to know what features it supports, but I think this refers to an auto locking timer to automatically lock the door after some time. It might be disabled, or it might not be supported.
I just thought this could mean, that the lock will not update the controller if a time out happens.
In case the timeout setting is enabled, it might try to reconnect to the controller.
But that’s just a guess.
No - it’s nothing to do with the controller. It’s the configuration of the door-lock function only.