It should be the same 2 seconds that we also see in the 2.2 logs, so at least it should now be the same as before. If itās not 2 seconds, then let me know and Iāll take a look at the logsā¦
Yes, I grepped the logs since the beginning of the year for APP BUSY. Now that I have a good time frame to check, Iāll drill into the logs to see what was going on.
Iāll want to check the other Leviton devices for this then. And that Monoprice plugin.
Probably wise (and thanks). I guess if you check the XML, and if APPLICATION_STATUS isnāt in the NIF list, then the database will need to be updated to include this CC, with the ADD option.
It is about 8 seconds for 2 devices. Iāll test all my switches and let you know. It could be my network. Thank you so much again!
Hang on a secā¦ I think this is making sense now. There are retries after an APP BUSY, but only if the device supports APPLICATION_STATUS. So it is the APPLICATION_STATUS thatās actually reporting the APP BUSY, or that will be sent even without the CC?
Yes - the APPLICATION_STATUS CC is used to report the status of the application (various versions of BUSY).
Iām not sure I understand the question?
If the APPLICATION_STATUS is not supported, then the binding wonāt receive the BUSY, and the binding wonāt send the retry 2 seconds later.
He wasnāt getting them - that was the problem. Once I re-added this class, it works again.
Sorry, not trying to challenge you (and for wasting your time on this)ā¦ but his log shows that he was getting themā¦ 
Yes, but, the log shows that the device was sending the message - not that the binding was processing the message. The binding didnāt know about the CC due to the change with not adding unknown CCs. Therefore the binding didnāt process it and didnāt send the repoll.
1 Like
AH!!! Thank you!
1 Like
Just to make it easier for others
I started to go through this, but considering the other issues, the number of devices that would need to be updated, etc., could you just revert this change? IIRC, you didnāt think there should be any negative impact to having incorrect CCs in the XML, so all the change did was keep things tidy.
Some odd behaviour from the 22 July binding. It seizes up every so often with this in the log:
23-Jul-2018 14:13:15.488 [DEBUG] [rg.openhab.binding.zwave.handler.ZWaveThingHandler] - Controller handler not found. Cannot handle command without ZWave controller.
Dan
I have two kwikset 910 door locks and Iāve always had issues with the status showing as incorrect. From the logs, I can see the device is sending ALARM V1 messages upon manual lock/unlock. From searching this thread, is seems as ALARM V1 codes are non-standard and therefore not implemented in the binding?
Is anyone working on this? I would be happy to help with coding, testing, etc.
Thanks!
Dave
Alarm V1 is implemented. What is not implemented is conversion of these codes into something more meaningful, since there is no standard definition. However, the codes are available if you use the alarm_raw channel.
I have a simular issue with Danalock 3, its no longer updating the status if the door is manualy locked or unlocked.
If itās the same issue, and you are seeing the Alarm messages being received, then you probably need to add the alarm_raw channel to the database. Are you really sure itās the same though?
Its simular in the sense that the its no longer reporting updates like it used to ( When i had it all working on 2.2 with your secure version of the binding).
I dont see a alarm channel on danalock, it seems to have batteri and switch.
I went to checks its configuration, it did not have anything assined to ālifelineā, so im gonna qwant to what that is 
Thanks for clarifying. Do you happen to have an example of setting up the alarm_raw channel? When I saw channel, I thought of the Thingās Channel, but I the only alarm related channel there is alarm_number.
Perhaps I need to edit something in the db xml file?
My door lock uses the 914TRL xml file