Hello all, I’ve got about 11 or so radiators using the Stella-Z units, with the pre-recent-update z-wave binding these would report back their data when it changed, I then used to use the valve opening levels to decide whether to switch on the boiler or not, but since the new update, these values are no longer being reported back.
I set up each device entry to poll these values, 11 devices being polled once every 10 minutes, but my openhab system became very unresponsive and all the radiator devices kept showing as offline, with the polled values no longer being returned.
As the radiator devices do not appear to have any association groups (I don’t recall if they did before, but they did used to report back values regularly), is there any way to get them to pass back changes as they happen? Is polling now the only way?
I assume you use a recent 2.4 snapshot ?
Did you properly delete and redefine your things as explained here ?
Not sure what you mean by
I don’t know these devices but assume they’re battery operated.
You mustn’t poll these. Effectively you cannot anyway. They’ll either report when there’s a change (if they support this functionality to report on changes) or you will have to wait for them to wakeup to send a reply.
Wakeup interval is determined by zwave parameter on the device.
Binding will take care of polling all by itself anyway, so no need to even issue a single poll query.
Your “poll” action (I assume by that you refer to send a REFRESH) will end up in a queue of un-answered messages, eventually slowing down OH as you noticed yourself.
I suggest you enable ZWave debugging to see what’s going on.
And I had to make three assumptions on information required to understand your problem (not sure I did). Please try to be more specific when asking next time.
It was a fairly generic question, basically if there was any difference between the old and new zwave binding but it sounds like it’s supposed to work the same way. I may have managed to get the radiators to work so I’m parking that for now, there’s a lot of strange things going on with the rest of the setup, so I’ll be immersing myself in figuring all this out. I’ve got about 50 z-wave devices and some of them are doing some very strange things, e.g. two of my lamps have reversed their sense, so when I turn them on in software, the devices turn off and vice-versa… All very odd, I can see myself losing another day on getting this to function again!
Hmm I wonder if this could have something to do with it… It seems OpenHab has lost configuration on nodes, certainly I’m finding that the record of a device’s configuration doesn’t seem to match the device itself and also when I set a new config, this is not reflected in the UI. For example a motion control device that according to openhab is set to trigger then timeout after 10 seconds doesn’t do so, but setting it to timeout after 11 seconds then back to 10 again makes it timeout after 10 seconds.
Hmm… The “network number” also appears to be wrong, the device is supposed to be on “zwave:device:214d29fb:node17”.
2018-09-27 11:10:23.436 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Configuration update received
2018-09-27 11:10:23.436 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Configuration update set action_reinit to true (Boolean)
2018-09-27 11:10:23.437 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Re-initialising node!
2018-09-27 11:10:23.447 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Got an event from Z-Wave network: ZWaveInitializationStateEvent
2018-09-27 11:10:23.450 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 17: Init node thread start
2018-09-27 11:10:23.454 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 17: Serializing from file /var/lib/openhab2/zwave/network_d2122d61__node_17.xml
2018-09-27 11:10:23.455 [DEBUG] [l.initialization.ZWaveNodeSerializer] - NODE 17: Error serializing from file: file does not exist.
2018-09-27 11:10:23.455 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 17: Starting initialisation from EMPTYNODE
2018-09-27 11:10:23.460 [DEBUG] [ve.internal.protocol.ZWaveController] - NODE 17: Init node thread finished
2018-09-27 11:10:23.460 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 17: Node advancer - advancing to IDENTIFY_NODE
2018-09-27 11:10:23.461 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Got an event from Z-Wave network: ZWaveInitializationStateEvent
2018-09-27 11:10:23.461 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 17: Node advancer: Initialisation starting
2018-09-27 11:10:23.467 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 17: ProtocolInfo
2018-09-27 11:10:23.467 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 17: Listening = false
2018-09-27 11:10:23.467 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 17: Routing = true
2018-09-27 11:10:23.467 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 17: Beaming = true
2018-09-27 11:10:23.467 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 17: Version = 4
2018-09-27 11:10:23.467 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 17: FLIRS = false
2018-09-27 11:10:23.467 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 17: Security = false
2018-09-27 11:10:23.468 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 17: Max Baud = 40000
2018-09-27 11:10:23.468 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 17: Basic = BASIC_TYPE_ROUTING_SLAVE
2018-09-27 11:10:23.468 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 17: Generic = GENERIC_TYPE_THERMOSTAT
2018-09-27 11:10:23.468 [DEBUG] [rialmessage.IdentifyNodeMessageClass] - NODE 17: Specific = SPECIFIC_TYPE_THERMOSTAT_GENERAL_V2
2018-09-27 11:10:23.468 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 17: Creating new instance of command class COMMAND_CLASS_NO_OPERATION
2018-09-27 11:10:23.468 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 17: Command class COMMAND_CLASS_NO_OPERATION, endpoint 0 created
2018-09-27 11:10:23.468 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 17: Version = 1, version set. Enabling extra functionality.
2018-09-27 11:10:23.468 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: Adding command class COMMAND_CLASS_NO_OPERATION to the list of supported command classes.
2018-09-27 11:10:23.469 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 17: Creating new instance of command class COMMAND_CLASS_BASIC
2018-09-27 11:10:23.469 [DEBUG] [tocol.commandclass.ZWaveCommandClass] - NODE 17: Command class COMMAND_CLASS_BASIC, endpoint 0 created
2018-09-27 11:10:23.469 [DEBUG] [ng.zwave.internal.protocol.ZWaveNode] - NODE 17: Adding command class COMMAND_CLASS_BASIC to the list of supported command classes.
2018-09-27 11:10:23.470 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 17: Node Init response (0) org.openhab.binding.zwave.internal.protocol.ZWaveTransactionResponse@5cf8f701
2018-09-27 11:10:23.470 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 17: Node Init transaction completed with response COMPLETE
2018-09-27 11:10:23.470 [DEBUG] [alization.ZWaveNodeInitStageAdvancer] - NODE 17: Node advancer - advancing to REQUEST_NIF
2018-09-27 11:10:23.470 [DEBUG] [ding.zwave.handler.ZWaveThingHandler] - NODE 17: Got an event from Z-Wave network: ZWaveInitializationStateEvent
2018-09-27 11:10:23.471 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 17: sendTransaction org.openhab.binding.zwave.internal.protocol.ZWaveSerialPayload@58c76846
2018-09-27 11:10:23.471 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 17: Bump transaction 21413 priority from Controller to Immediate
2018-09-27 11:10:23.471 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 17: Adding to device queue
2018-09-27 11:10:23.471 [DEBUG] [nal.protocol.ZWaveTransactionManager] - NODE 17: Added to queue - size 20
It looks like the real serial z-wave controller has been ignored and a “new” one set up. Although bafflingly despite this, much of my house is working so it can’t really have lost connection, and the controller is listed as “online” despite having a blank port in its config. Certainly neither Habmin or PaperUI can even detect the /dev/ttyACM0 port despite the openhab user being in the dialout group. This was working fine previously. I’ll keep investigating.
I’ve rebooted the box, I can see two-way z-wave traffic and I can control nodes, e.g. the lamp beside me can be turned on and off. The radiator next to me has the right ID “zwave:device:214d29fb:node20” while the ID of the z-wave stick is “zwave:serial_zstick:214d29fb” which looks fine. The z-wave stick is on /dev/ttyACM0 with group read-write for dialout, and the openhab user is in the dialout group. Communication with z-wave is going fine, as seen by being able to turn lamps on and off and getting alerts from devices like the motion sensor above my head.
Openhab version is 2.4.0~20180924031502-1
In Habmin and paperui, the z-wave stick “port” config entry is empty, with the drop-down only offering /dev/ttyS0 as a choice. I am ignoring that as there’s just a console port on that. Despite this, z-wave communication works fine.
I’m just waiting for the network to settle down a bit before I try to re-init a device and see if this spurious ID crops up again.
No, it’s not the node (thing) ID of the controller, It’s your home ZWave network ID stored and used in that controller.
Read the thread I linked to plus eventually parts of the big (now closed) one that it in turn links to.
All of the differences and migration are discussed there.
OK I’ll have a skim read of the 4,000 comment “Refactoring and security” thread later… Much later!
I did read the original migration thread, followed the procedure and didn’t originally have any real problems, there is certainly a problem with habmin and paperui not picking up the right port device in the UI but it’s not affecting my setup at the moment so I’ll park that and it isn’t a z-wave issue anyway (or I wouldn’t have thought so).
I have about 7 movement sensors, three work fine, four are having problems, I’m going to have to reconfigure those completely as both habmin and paperui no longer reflect their current configuration, so I have to get the UIs back into sync with the devices, so far I’ve needed to change a value, e.g. alarm timeout, write it, then modify it back to the original value before the device’s behaviour matched the configuration that OpenHab thought was already present.
As for the radiators, last time I checked before the latest reboot they were waking up as intended every 10 minutes but there was no z-wave traffic other than the wakeup, I’ll play around some more with that later, I can’t afford to spend another day on this right now.
Sadly it seems the radiators don’t support reporting on wakeup, so I’ve had to resort to polling them every 30 minutes. They wake every 10 minutes so hopefully there won’t be too much traffic. From the look of my pre-new-binding config, I was polling before without knowing it, looks like it was set to poll every half hour by default with this in almost every device’s config area;
“binding_pollperiod”: 1800
Marking this one “solved” as effectively it’s a dead query.
