ZWave binding updates

[dominicdesu (Dominic Lerbs)]

Hi,
this is the device: https://products.z-wavealliance.org/products/1086 (don’t know if you still maintain your own database, but on cd-jackson.com I am getting a 403).

[chris (Chris Jackson)]

@dominicdesu

don’t know if you still maintain your own database,

Yes - it is where all the openHAB database is derived.

@dominicdesu

but on cd-jackson.com I am getting a 403

I had to do a server restart - it should be back up in a couple of minutes.

[chris (Chris Jackson)]

I think the issue is that your device is configured to send the scene_activation command, rather than the central_scene command that the binding uses. The scene_activation is an old class and we use the newer one.

[evijf (Erik v)]

Is it just me or is it difficult to see when the fix is/will be merged with the OH?

Anyone got some pointer to navigate github or check the OH builds?

[sihui]

@evijf

Anyone got some pointer

If you are talking about

An error occurred while calling method 'EventSubscriber.receive()'

That is a ESH fix and you need to watch this page:

https://hudson.eclipse.org/smarthome/job/SmartHomeDistribution-Stable/changes

So as of now fix #6201 is not yet included in openHAB snapshot 2.4

[evijf (Erik v)]

Hi Sihui, Thanks for the link!
Any idea when this fix might get included?

[chris (Chris Jackson)]

@evijf

Any idea when this fix might get included?

Updates from ESH to OH are normally made every 1 to 2 weeks.

[dominicdesu (Dominic Lerbs)]

Hi @chris ,
I was able to change to central scene and now the messages are getting forwarded to the items, but all messages seem to be received twice by the binding:

2018-09-16 11:36:40.982 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0B 00 04 00 0A 05 5B 03 03 00 03 A7
2018-09-16 11:36:40.991 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=10, callback=0, payload=00 0A 05 5B 03 03 00 03
2018-09-16 11:36:40.996 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=10, callback=0, payload=00 0A 05 5B 03 03 00 03
2018-09-16 11:36:40.998 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-09-16 11:36:41.001 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 10: Application Command Request (ALIVE:REQUEST_NIF)
2018-09-16 11:36:41.004 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 10: Incoming command class COMMAND_CLASS_CENTRAL_SCENE, endpoint 0
2018-09-16 11:36:41.007 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 10: SECURITY not supported
2018-09-16 11:36:41.010 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 10: Received COMMAND_CLASS_CENTRAL_SCENE V1 CENTRAL_SCENE_NOTIFICATION
2018-09-16 11:36:41.013 [DEBUG] [dclass.ZWaveCentralSceneCommandClass] - NODE 10: Received scene 3 at key 0 [Single Press]
2018-09-16 11:36:41.016 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-09-16 11:36:41.019 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_CENTRAL_SCENE, value = 3.0
2018-09-16 11:36:41.022 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Updating channel state zwave:device:12345678-9012-3456-7890-123456789012:node10:scene_number to 3.0 [DecimalType]
2018-09-16 11:36:41.027 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 10: Commands processed 1.
2018-09-16 11:36:41.030 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 10: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@a67edb.
2018-09-16 11:36:41.032 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-09-16 11:36:41.035 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-09-16 11:36:41.037 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2018-09-16 11:36:41.039 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.
2018-09-16 11:36:41.049 [DEBUG] [WaveSerialHandler$ZWaveReceiveThread] - Receive Message = 01 0B 00 04 00 0A 05 5B 03 03 00 03 A7
2018-09-16 11:36:41.057 [DEBUG] [nal.protocol.ZWaveTransactionManager] - processReceiveMessage input 0<>128 : Message: class=ApplicationCommandHandler[4], type=Request[0], dest=10, callback=0, payload=00 0A 05 5B 03 03 00 03
2018-09-16 11:36:41.060 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Received msg (0): Message: class=ApplicationCommandHandler[4], type=Request[0], dest=10, callback=0, payload=00 0A 05 5B 03 03 00 03
2018-09-16 11:36:41.062 [DEBUG] [nal.protocol.ZWaveTransactionManager] - lastTransaction null
2018-09-16 11:36:41.064 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 10: Application Command Request (ALIVE:REQUEST_NIF)
2018-09-16 11:36:41.066 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 10: Incoming command class COMMAND_CLASS_CENTRAL_SCENE, endpoint 0
2018-09-16 11:36:41.068 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 10: SECURITY not supported
2018-09-16 11:36:41.070 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 10: Received COMMAND_CLASS_CENTRAL_SCENE V1 CENTRAL_SCENE_NOTIFICATION
2018-09-16 11:36:41.072 [DEBUG] [dclass.ZWaveCentralSceneCommandClass] - NODE 10: Received scene 3 at key 0 [Single Press]
2018-09-16 11:36:41.075 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got an event from Z-Wave network: ZWaveCommandClassValueEvent
2018-09-16 11:36:41.077 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Got a value event from Z-Wave network, endpoint = 0, command class = COMMAND_CLASS_CENTRAL_SCENE, value = 3.0
2018-09-16 11:36:41.080 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 10: Updating channel state zwave:device:12345678-9012-3456-7890-123456789012:node10:scene_number to 3.0 [DecimalType]
2018-09-16 11:36:41.083 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 10: Commands processed 1.
2018-09-16 11:36:41.085 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 10: Checking command org.openhab.binding.zwave.internal.protocol.ZWaveCommandClassPayload@d902a1.
2018-09-16 11:36:41.088 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-09-16 11:36:41.090 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction completed - outstandingTransactions 0
2018-09-16 11:36:41.091 [DEBUG] [nal.protocol.ZWaveTransactionManager] - ZWaveReceiveThread queue empty
2018-09-16 11:36:41.093 [DEBUG] [nal.protocol.ZWaveTransactionManager] - Transaction SendNextMessage 0 out at start. Holdoff false.

I also tried to remove all things and the complete binding and reinstalled it again, same effect. Is this an issue of the device itself (it sends a duplicate message) or something with the binding?

[chris (Chris Jackson)]

@dominicdesu

all messages seem to be received twice by the binding:

This is not a problem with the binding, and will be an error with the way you have configured the device - it is normally caused by setting multiple associations.

[dominicdesu (Dominic Lerbs)]

You’re right! It was associated with node_1 which doesn’t even appear as an option in the list now anymore since I’ve remove it. Thanks for your help!

[ariela (Andrea Riela)]

Guys,

I’ve just updated to latest, found the new controller, set the new controller (ONLINE) as default controller, canceled the previous one, followed all steps before (canceledl things, … then added all things again).

But now I can see those issues:

1. mandatory to use on my openhabian vm the ttyUSB0 serial port. I was using a /dev/zwave_controller virtual port (to avoid the issue related to usb port changing sometimes), but there is maybe an issue there (when I start including the nodes, the controller is going offline saying “Serial Error: Port {0} does not exist”

2. not able to include one node (investigating)

3. worst issue, I can receive updates from by battery devices (danfoss thermostat valves), but not from my fibaro wall plugs (only switch on/off, not power in real time in W). I’ve tried changing the item from previous working configuration:

Number Fibaro_VMC_MeteredWallPlug_SensorPower "Power in real-time [%.1f W]" (gFF_Hallway, gPowerMeters, gChart, gHistory)

to

Number Fibaro_VMC_MeteredWallPlug_SensorPower "Power in real-time [%d]" (gFF_Hallway, gPowerMeters, gChart, gHistory)

but nothing …
Any suggestion? Here my debug log (example, node 10 is a fibaro wall plug, I’ve changed the power consumption but nothing, I’m not able to see differences)

https://pastebin.com/R6XtEteD
to understand better the log:

fibaro plugs: nodes 2,3,4,8,9,15,17,18
qubino plug: node 20 (node 21 is not yet included)
danfoss valves (battery): nodes 10,11,12,13,14

Any support will be much appreciated

Maybe start from previous backup again, but not using the new controller but the previous one?

thanks
Andrea

[chris (Chris Jackson)]

@ariela

Any support will be much appreciated

There don’t appear to be any reports from these devices in the logs. My first suggestion would be to exclude them, and add them back into the network so they are fully reinitialised. However, if that’s too much hassle, you could try setting the lifeline association group to see if that fixes it, as it is likely an association issue.

[mstehle (mattnl)]

Hi Andrea,

I don’t know if this is also your issue, but I ran into the same after I had updated to the testing binding quite some time ago. There seem to be different channels for power reporting for the Fibaro plugs. The meter_watts channel did not work for me. Check the channel you are using, and check this post:

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

Hi Norbert and Chris, I actually also just migrated my zwave network from the 1.9 binding to the latest development binding (dated 22-04-2018) and ran into the same issue with the Fibaro plugs not reporting power changes immediately. I had used the “meter_watts” channel. This did not work as expected. Then I have noticed that there is an additional channel “sensor_power” for the Fibaro plugs. This channel works as expected here - power changes are reported immediately Maybe you…

Hope this helps,
Matt

[chris (Chris Jackson)]

@mstehle

I don’t know if this is also your issue, but I ran into the same after I had updated to the testing binding quite some time ago. There seem to be different channels for power reporting for the Fibaro plugs.

This is not the issue here as there are no reports at all (but it is something that may later become an issue, and is part of the release notes that channels can change ).

[ariela (Andrea Riela)]

Interesting … but I was using the sensor_power channel already. Also in my previous configuration.

I’m now using the backup again, trying another way and see what happen

Andrea

[chris (Chris Jackson)]

@ariela

I’m now using the backup again

Did you try setting the lifeline before reverting to the backup?

[ariela (Andrea Riela)]

Yes but didn’t change anything. On the other hand, the lifetime was configured as before, and it was working in default configuration

[chris (Chris Jackson)]

@ariela

On the other hand, the lifetime was configured as before, and it was working in default configuration

Maybe, maybe not - it’s hard/impossible for you to tell easily I think… The associations are configured differently now - you may not see that, but this is a major change in this version of the binding to allow the system to work with the new association concepts that are now used in ZWave.

This is why I would suggest to completely reset the device. However, it may be something more fundamental as there are no reports at all in the log.

[ariela (Andrea Riela)]

Mmm … I have some issues with my old S2, I will try with a new S5 controller and a new installation from scratch.

I will let you know

thanks
Andrea

[ariela (Andrea Riela)]

@chris

lifeline association group

Sorry, what you mean? what is it exactly?
In the association groups of a Fibaro plug I can see:

1. Group 1 (on/off controlled devices)
2. Group 2 (measured load controlled devices)
3. Controller Updates

and the controller is not in the list.

not understanding