OH2 Z-Wave refactoring and testing... and SECURITY


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.

Hmmm… how would @r27 have gotten them without APPLICATION_STATUS?

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… :confused:

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.


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.


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 :slight_smile:

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