ZWave binding updates

As per the other ticket, I didn’t see anything out of the ordinary in your log. The controller is still communicating after the problem at around 19:47, but I don’t see anything that indicates a problem.

ah, you mean it could be the battery itself and not the device? I did not think about this, shame on me… I’ll insert new ones and will report back…

Yes, the controller and/or the binding is constantly trying to poll z-wave devices, but there are no more incoming messages from nodes, and no messages ever get out to lights or thermostats after 19:49. All transactions abort or cancel.

One thing I see in the log is there’s an error saying that something takes too long - I don’t know if it’s related, but just after that the thread closes.

Is it now possible to define Things in the config file?

Yes - this was added to the development version a long time ago (early last year).

Thank you @chris for your quick reply!

1 Like

Hi @chris,

Thank you again and again for this nice binding !

I’ve removed my things, updated the binding (to the build #440), reincluded all the things.

All works well (and faster than before !) excepting my Node 2 and Node 16, that are two Aeotec Wallmote Quads ZW-130C, in spite of dozens of manual wake-ups. They were perfectly working before the update. They were included in secure mode (as all the other devices that are working fine).

I think the process went right to the middle of the interrogation process, but now each new wake-up seems to give this result :

15:46:45.463 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - NODE 2: Application Command Request (ALIVE:REQUEST_NIF)
15:46:45.464 [DEBUG] [ing.zwave.internal.protocol.ZWaveNode] - NODE 2: Decapsulating COMMAND_CLASS_SECURITY
15:46:45.464 [ERROR] [ommandclass.ZWaveSecurityCommandClass] - NODE 2: Error decapsulating security message
java.security.InvalidKeyException: No installed provider supports this key: (null)
at javax.crypto.Cipher.chooseProvider(Cipher.java:892) [?:?]
at javax.crypto.Cipher.init(Cipher.java:1248) [?:?]
at javax.crypto.Cipher.init(Cipher.java:1185) [?:?]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.generateMAC(ZWaveSecurityCommandClass.java:501) [224:org.openhab.binding.zwave:2.4.0.201810181356]
at org.openhab.binding.zwave.internal.protocol.commandclass.ZWaveSecurityCommandClass.getSecurityMessageDecapsulation(ZWaveSecurityCommandClass.java:303) [224:org.openhab.binding.zwave:2.4.0.201810181356]
at org.openhab.binding.zwave.internal.protocol.ZWaveNode.processCommand(ZWaveNode.java:1233) [224:org.openhab.binding.zwave:2.4.0.201810181356]
at org.openhab.binding.zwave.internal.protocol.ZWaveTransactionManager$ZWaveReceiveThread.run(ZWaveTransactionManager.java:485) [224:org.openhab.binding.zwave:2.4.0.201810181356]
15:46:45.465 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
15:46:45.466 [DEBUG] [rnal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

What could i do ?

Regards and thanks,

Romain

I have been following my Z-Wave binding and restarted it every time it crashed. Then suddenly it has stopped crashing. I have not done anything that could have helped it, but I am happy it has healed itself. Binding has been stable for the entire weekend.

One could always speculate that the newly included nightly network heal has actually healed something so that it now not any longer is triggering a potential bug.

ah, you mean it could be the battery itself and not the device? I did not think about this, shame on me… I’ll insert new ones and will report back…

Ok, so not much to be proud of, but there it is : Guess what? The 0% did indicate that batteries were actually empty, yes. How strange;-)

I did not expect it would have turned empty so quickly as it was more than half full (probably 60% at least) not so long ago, so I simply thought something else must had gone wrong…

1 Like

My Z-wave ventilation controller unit does not work any longer with OpenHAB 2.4 snapshot (updated today), the unit is this:

https://www.cd-jackson.com/index.php/zwave/zwave-device-database/zwave-device-list/devicesummary/430

and it will not accept any commands, nor do I get any items updated when I physically change settings on the ventilation engine unit.

Trying to adjust the fan speed from karaf results in the following in the log:

22:49:50.966 [INFO ] [smarthome.event.ItemCommandEvent     ] - Item 'Ventilasjon_FanSpeedSetting' received command 5
22:49:50.967 [INFO ] [arthome.event.ItemStatePredictedEvent] - Ventilasjon_FanSpeedSetting predicted to become 5
22:49:50.968 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 44: Command received zwave:device:ff1568d3:node44:thermostat_fanmode --> 5 [DecimalType]
22:49:50.968 [WARN ] [ss.ZWaveThermostatFanModeCommandClass] - NODE 44: requesting fan mode types, set request ignored (try again later)
22:49:50.969 [DEBUG] [erter.ZWaveThermostatFanModeConverter] - NODE 44: receiveCommand sending message null 
22:49:50.969 [WARN ] [erter.ZWaveThermostatFanModeConverter] - NODE 44: Generating message failed for command class = COMMAND_CLASS_THERMOSTAT_FAN_MODE, endpoint = 0
22:49:50.969 [DEBUG] [nding.zwave.handler.ZWaveThingHandler] - NODE 44: No messages returned from converter

There have been no changes to this device in the database for the better part of a year. You don’t say what you changed from? Were you previously on 2.3 or what?

I haven’t been active with openhab2 yet. How would I install the 2.4 snapshot binding?
In Openhab1 I could just download the jar and copy it to the addons-folder.
How would I do it in Openhab2?

How about reading the install docs ?
And the migration tutorial and all the rest of the docs volunteers have gone to great lengths to write down just for you ?

@mstormi: How about this does not answer my question.
I am asking how do install a snapshot binding with a stable openhab version as it was possible in openhab1.

I think you should read more of the docs to get yourself a little more up to speed with OH2 to not misunderstand things. There’s no such thing as a “snapshot binding” so your question was misleading.
There’s packages for snapshot releases of OH2 to include all bindings (i.e. their latest versions, which is probably what you’re looking for).
You can still copy jars to the addons folder BUT this is a deprecated approach because it isn’t guaranteed to work with the OH2 version that you have installed, and in this particular context (thread on zwave binding) there is no such jar for download (well not any more, i.e. none that you should use).

Imho this is still valid and not deprecated at all. How do you come to the understanding that this is deprecated?

This is why I was asking. I just wanted to use one experimental binding and not all of them.

I’m not sure I agree - there are bindings that are created regularly that are snapshots. They can be installed individually, or as a system.

It’s not deprecated - there are just other ways to do this in some cases. However, if you are using a specific version of the runtime (eg 2.3) and want to use a newer (snapshot) version of the binding, then the easiest (and I think only?) way to do this is to install the JAR manually. I think a lot of people still do this.

Of course there is a JAR. The Snapshot version is created regularly (every day or two normally) and you can download the JAR from the CI server. This used to be cloudbees, but is now ci.openhab.org. For example, if you want to download the latest snapshot of the ZWave binding, you can do so from here.

Because different versions of OH and binding are not guaranteed to work with each other.

Maybe I should not have used the term ‘deprecated’ but in fact it never was a recommended way to install bindings like that in general terms (i.e. as an advice to the average OH user). Also, you asked this in the context of the zwave binding.
We could start a (useless) argument on wording and scope of statements here, but that’s probably not a good thing to have 2 Germans do that on English terms, and it won’t get us anywhere.
Yes of course you can still download latest jars if you know where from, or you can extract them from packages, or or or. Dropping them into addons folder just happened to be (and yes, still is) the only way to install it in some cases (e.g. when the code was not yet merged into the master tree), but the recommended way is to go with the snapshot packages to ensure OH and its bindings are on the same level.
That’s eliminating at least a couple of potential error sources.
As I said you can still drop jars but then you’re well aware of what you’re doing and the implications that can have. This is for developers and beta testers but clearly not recommended to the average user.

Hi,

Could someone give me a hint ?

I’ve got the same messages with the build 441, and no more progress in spite of regular wake-ups.

Regards,

Romain