ZWave binding updates

dominicdesu · September 16, 2018, 9:43am

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 · September 16, 2018, 9:47am

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 · September 16, 2018, 9:52am

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 · September 16, 2018, 11:27am

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:

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”
not able to include one node (investigating)
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 · September 16, 2018, 11:34am

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 · September 16, 2018, 11:43am

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:

Hope this helps,
Matt

chris · September 16, 2018, 11:44am

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 · September 16, 2018, 11:45am

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 · September 16, 2018, 11:46am

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

ariela · September 16, 2018, 11:47am

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

chris · September 16, 2018, 11:49am

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 · September 16, 2018, 2:17pm

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 · September 16, 2018, 2:33pm

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

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

and the controller is not in the list.

not understanding

chris · September 16, 2018, 2:34pm

Ok, this is not a ZWave Plus device, so doesn’t have a Lifeline group. The Controller update group is the same though, so make sure the controller is set to group 3.

ariela · September 16, 2018, 2:40pm

Understood thanks.

Short question: when I’ll have the new S5 (and I will put the S5 in the usb port instead of the old S2, so the S2 will be offline), do I need to exclude all zwave devices before? or simply I will include those in the new S5 controller? Simple search, or do I need to follow the manual inclusion (3 times the button in 3 secs)?

thanks for your support

Andrea

chris · September 16, 2018, 2:55pm

If you’re swapping controllers, then it’s probably easiest to exclude the devices, and reinclude them into the new network. It is possible to transfer the network over, but unless you have a large network, I (personally) think it’s better to reinitialise and have them join the new network.

ariela · September 16, 2018, 3:02pm

At the moment I have the new OH version, the old controller ONLINE, a new controller in Inbox (as the new zwave binding is ready), and all zwave devices in UNINITIALIZED status

So the steps should be:

ignore the new ZWave USB Dongle (CP2102 USB to UART Bridge Controller) (that is in facts the old controller)
remove all Things
remove the Zwave binding
reinstall the Zwave binding with S2 still in
at this moment I should have the old controller ONLINE, and all nodes to be added again
add all nodes, then exclude with HABmin

or simply:

remove S2 and put S5 in
remove all things
remove Zwave binding
reinstall the Zwave binding, and re-add all nodes

?? what I’m missing?

ariela · September 16, 2018, 11:02pm

For the records.
SOLVED with new S5. Everything is looking good for the moment. No issues at all. All devices seem reporting data correctly. Also some zwave+ devices

thanks
Andrea

marcelser · September 17, 2018, 6:16am

I did switch my openhab installation to snapshot and updated the binding as advised which is remove all things except controller, uninstall + reinstall binding. Then I had to reboot because serial port was not found but now my “sensative window strip” which is node 002 (which is correct) reports as “Unknown Device”.

Log shows:

2018-09-17 08:12:17.576 [arthome.event.BindingEvent] - org.openhab.binding.zwave.event.BindingEvent@ba8243

==> /var/log/openhab2/openhab.log <==

2018-09-17 08:12:19.599 [WARN ] [wave.discovery.ZWaveDiscoveryService] - NODE 2: Device discovery could not resolve to a thingType! Manufacturer data not known.

==> /var/log/openhab2/events.log <==

2018-09-17 08:12:19.619 [home.event.InboxAddedEvent] - Discovery Result with UID 'zwave:device:81ab7676:node2' has been added.

==> /var/log/openhab2/openhab.log <==

2018-09-17 08:12:19.617 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'zwave:device:81ab7676:node2' to inbox.

How to fix this?

DanielMalmgren · September 17, 2018, 6:38am

Sensative strips require some patience, it could take some while before they are fully synchronized. You could speed it up by waking it up (by placing the magnet near the rounded edge three times) though. Repeat that procedure a few times and see if it helps