Hello @chris
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.
Do you understand what happens ?
And… thank you for this nice binding 
Regards,
Romain
From what version?
Hum… good question ! How can I find this information ?
I just install the updates when aptitude tells me to do that and I use the stable releases. So I imagine from 2.5.3 ?
So it was likely from a 2.5.x release. That means there should have been minimal binding changes.
That database entry was last updated in March 1. If your last update was before then you could try to delete the Thing from OH (NOT exclude) and re-discover & add to get the new settings.
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).
There have not been any change in the binding, so if it was working ok previously, then it should still be ok.
Looking at the log it seems that the binding no longer requesting the data using security - likely due to something the device has returned. Again though nothing has changed between 2.5.3 and 2.5.4.
Thank you @chris for your answer.
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.
Yes - everything is possible
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 !
Hi @chris,
Hope you are well. Did you had a chance to find some time to investigate this topic ? I am at your disposal if you want me to try and report about a snapshot or whatever else.
Regards,
romain
Sorry - I forgot to look at this.
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 think it initialised correctly juste once : when I put in prod the binding version I customized to “quick-and-dirtyly” force security without taking care of the device willingness (what I related here about the physical device we are talking about )
When you say reinitialise, do you mean exclude and include again from the zwave network ? if it’s only excluding from the binding and scanning again, I’ve already done that before starting this topic.
Thank you again for your support
No - there is a reinitialise button (or configuration parameter in PaperUI) that can be used, but exclude/include also does this (and more).
I have added an option to the database to work around the issue I saw in the log above with the security - hopefully that will help.
Thank you ! How long should I wait to be sure it is included in the binding snapshot before I test ?
It will be a few days. If I get time I’ll do it tomorrow, otherwise my normal routine of late has been to do the database export to the binding on a Sunday night.
You then need to wait for a snapshot built with those changes.
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 
Romain
