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

Could you please summarize the logic that you used for determining whether a node is dead? About half of my nodes are being marked dead, but I do not see any consistency in which are dead between restarts. The nodes come right back up after manually using them. I’m guessing there’s a timeout somewhere that needs to be extended.

I also have installed the test binding, seems to be working well. No problems observed so far :slight_smile:

It should be the same as the current master binding - if a device fails to respond after 3 retries, it’s marked DEAD. DEAD nodes will still have messages sent, but until they respond there will be no retries.

Interesting… I’ve watched a block of ~10 nodes all be marked as dead simultaneously. The mains powered devices seem to come back on their own eventually. The battery devices are probably waiting for their next wakeup though (1h). I’m letting it rest for a bit and see were they’re at, then restart and get some logs. But doubt they would help… it sounds like my network is just congested enough (120 devices) to cause some drops, especially after a restart.

What would be the down side of increasing the number of retries?

Slowing down the network (each retry blocks the network for 5 seconds!). If something hasn’t responded in 9 attempts, then there’s something wrong.

I wouldn’t expect 10 nodes to be marked dead at exactly the same time - It’s quite possible there’s a bug in the code so if you have a log I’ll be happy to take a look.

Has anything changed recently in command version handling? For one of my older Qubino dimmers ZMNHDA I got version 0 for three of the commands. One of them is ASSOCIATION and for this reason lifeline is not associated with the controller, as the command is removed from the list of supported commands. IMO this worked well in March version of the binding, but now I am not 100% sure.
Is there any way to fix/workaruond this? I saw there is some option to override command versions using properties, but have never done such thing before. Does it work?

Okey, so maybe it worked long time ago, lifeline assoc. set in then has been working till last Friday, when I had to reinclude the device, so it lost associations and stopped working. New version could not add it back, as the device reports version 0 for assocations command class.
Anyway a hint how to workaround this would be helpful.

I’m not sure I understand the problem, so can’t comment on a workaround. Can you post a log or something to explain the issue?

The problem is in version of some command classes that the device reports back to the binding - it reports version “0” which I assume is invalid. Here is the log:

2018-06-03 16:18:56.089 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=36, callback=0, payload=00 24 04 86 14 85 00
2018-06-03 16:18:56.092 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 36: Application Command Request (ALIVE:VERSION)
2018-06-03 16:18:56.094 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 36: Incoming command class COMMAND_CLASS_VERSION, endpoint 0
2018-06-03 16:18:56.098 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 36: Received COMMAND_CLASS_VERSION V1 VERSION_COMMAND_CLASS_REPORT
2018-06-03 16:18:56.099 [DEBUG] [ommandclass.ZWaveVersionCommandClass] - NODE 36: Process Version Command Class Report
2018-06-03 16:18:56.104 [DEBUG] [ommandclass.ZWaveVersionCommandClass] - NODE 36: Requested Command Class = COMMAND_CLASS_ASSOCIATION, Version = 0
2018-06-03 16:18:56.105 [INFO ] [ommandclass.ZWaveVersionCommandClass] - NODE 36: Command Class COMMAND_CLASS_ASSOCIATION has version 0!
2018-06-03 16:18:56.106 [DEBUG] [ommandclass.ZWaveVersionCommandClass] - NODE 36: Removed Command Class COMMAND_CLASS_ASSOCIATION

After removing this command class I guess setting any association is not possible.

Is there a way to override command class version by setting a property or in any other way?

No - it is valid. It means that the command class is not supported. This is why the binding removes it from the list of command classes.

The standard states -:

If the requested Command Class is not supported or controlled, a responding node MUST set the Command Class Version field to 0x00.

I’m not sure that we can override this. It is possible to add command classes, but if the device requests it to be removed, then it will still likely be removed.

None of this is new though (I just checked, and the last time this code was touched was Feb 2017!), so why has it just started happening?

As I wrote in my second post, this device is one of my older devices and it has been initialized/configured long time ago (years). Perhaps it worked in a different way in OH1.x. When I reincluded this device recently it lost associations configuration and now it is not possible to configure them again. This is what I suspect, but will take a closer look again when I am back home.
I have 2 such devices and the second one is working well, but it hasn’t been touched since the beginning.
By “working well” I mean sending reports to the controller, as I can controll both of them without any problems.

By this do you mean the Thing was never deleted and rediscovered when upgrading to the dev version of the binding? This is a necessary step. Also, my Leviton dimmers and switches tend to stop reporting status after any updates to the binding, so I usually do a bulk delete of Things when there is an update. Have you tried deleting them (not excluding) and rediscovering?

The thing has been deleted and discovered several times, but the device hasn’t been reincluded, so lifeline configuration has not been touched since then. I added this device to OH1.x first time, then migrated to OH2 etc, but from the controller perspective nothing has changed, maybe some config params, but not associations.

OK. Just wanted to be sure you didn’t miss that step in the upgrade. Have you tried deleting and rediscovering since you last updated the binding? This works for me with my dimmers and switches.

4 days later: all is good

Things stay Online in PaperUI and report data as scheduled.
I removed the battery from one Z-Wave node on purpose and it got reported as Offline after a while (same behavior as the master branch).

1 Like

I don’t think this is relevant, just this one device I reincluded stopped sending reports, also in .xml file association map is empty and after analyzing log it shows that there is a problem with command class version.
Additionaly after reincluding the device got discovered as a new one with new node ID, so it is a new thing anyway.

Quick question on the last update for the development version of the zwave binding 04th June:

Is there still a difference between the “test” version of the binding mentioned here or are they the same now?

They are different - the version at the top of this thread uses the same concept for dead nodes as it always has…

Just to add - I decided to keep them separate to avoid everyone changing concepts while I/we were still testing :wink: .

1 Like

Makes sense :rofl:
BTW, test version is running now for a few days without any issues. :+1:

1 Like

Hello,

Is the zwave 2.3.0 stable binding buggy ?

I was using 2.3.0 SNAPSHOT dev version of the zwave binding that was fully fonctional before the stable release of 2.3.0 and all was going right.

I then updated to 2.3.0 stable for both openhab and the zwave binding. Everything runs fine excepting the zwave binding. I find in particular in the logs “… nonce that is unknown to us”.

Everything is allright again if I use the last zwave snapshot (june 2018, on top of this topic).

Wouldn’t it be nice to provide a fully functional stable binding in the 2.3.0 stable release ?

Regards,

Romain