I’ve updated to the latest stable 2.5.4 and since this update my Aeotec ZW121 (led strip) color feature does not work any more. The other features (on/off, warm/cold light, auto colored animations) are all right.
Here is a debug log - I played with the color picker around 18h42 on node 4. And I tried to reinitialize the device around 19:00 - shows that something hangs during initialization.
Sorry, I forgot to mention I’ve already tried to delete and add the Thing before sending my first post.
I’m not sure but I suspect that the initialization sequence has been complicated around “STATIC_VALUES” step. It hanged and I had to restart the binding to make it complete. But trying a second time did the same thing (I’ve updated my first post to provide a log of reinitialisation).
I think I have luck from time to time about this device : at each new stable release of openhab, I have to tweak, restart, reinitialize lots of time… to get this device working totally with openhab.
When you say : “it seems that the binding no longer requesting the data using security”, would it be possible to add an option to force requesting with security ?
As a workaround for this particular case, but also because it seems to me that if I want security to be enabled, I don’t want the binding to decide by itself it won’t require any more security.
But… it’s not so simple since you can’t just add an option to secure everything as it needs to be compatible with what the device wants secured - otherwise we have the opposite problem where the binding secures stuff and the device doesn’t want it secured. It should work correctly by polling the device to find out what it supports.
But this is how it should work - the binding should decide, along with the device, what is secured. Otherwise this can become quite complex.
OK, I understand Thank you for keeping explaining to newbies like me !
So… an option to have a retry with the other option (clear / secured) in case of failure ?
instead of the loop of retries continually failing I see on this $-#/! device - it’s curious, aeotec never released updates for this particular device contrary to the other ones
I will try and find some time to take another look at this later. From the log, the device has stated that is should secure the color command class so I’ll have another look to see if I can see why the binding isn’t using security.
If it may help, after a restart of the binding, it was showing something I have not seen for two years :
ERROR] [mmandclass.ZWaveSecurityCommandClass] - NODE 4: Error encapsulating security message
java.security.InvalidKeyException: No installed provider supports this key: (null)
at javax.crypto.Cipher.chooseProvider(Cipher.java:930) ~[?:?]
at javax.crypto.Cipher.init(Cipher.java:1433) ~[?:?]
at javax.crypto.Cipher.init(Cipher.java:1364) ~[?:?]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.getSecurityMessageEncapsulation(ZWaveSecurityCommandClass.java:377) [bundleFile:?]
at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager.sendNextMessage(ZWaveTransactionManager.java:903) [bundleFile:?]
at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager.access$3(ZWaveTransactionManager.java:845) [bundleFile:?]
at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager$ZWaveReceiveThread.run(ZWaveTransactionManager.java:457) [bundleFile:?]
Also, I tried to revert to the 2.5.1 jar : exactly same problem.
I think the time I had a fully featured initialization/serialization was when I tried to modify the binding source code to basically force the secured communication.
It’s what I related here
Then I reverted to the official binding, and I can’t explain why it kept working til this update…
Obviously, I do not say it is the solution I just try to help investigating.
Anyway, I greatly appreciate your help. Thank you !
The reason for the security stopping is that the device reports that it supports security command class version 0. This is interpreted by the binding as the command class is not supported, so the binding removes support for this command class (as per the ZWave specification).
This causes the binding to stop using security and I guess the device doesn’t like this. This is not new though - it’s been in the binding for many years.
I could guess that this was an error - ZWave error detection is quite poor, and given that the device has clearly initialised in the past, I assume that it did not always report version=0 or it would never work. I would therefore suggest to try and reinitialise - if it still returns version 0, then we can add a workaround in the binding.
Looking more at the time you reported that the colour command doesn’t work (18h42), it looks like it’s working fine -:
Here we see the binding send the colour command, and the binding acks this command. All is sent securely and I don’t really see any issue. There are a number of these colour commands sent around this time, and while I’ve not checked every single one, they do look like they are working ok (by which I mean the command looks ok, and the device acks the command).
I’ve also contacted aeotec support for getting a firmware update. After I insisted to get an update newer than the standard three years old one they gave me initially, they have been kind enough to generate a 1.03 version.
Using BOTH chris snapshot binding version and the new firmware solved my problem of inclusion. But it does not solve the stability after two days, the device becomes unresponsive and I have to power off and on to make it work again for a couple of days, before becoming again unresponsive