ZWave light switch rule randomly triggered since update to OH 2.4


(David Masshardt) #21

I’ve already set my rule trigger to changed, but the problem is still that when I restart the OH server that the state of the switch is not initialized at startup. So I would have to press every switch once after the startup to synchronize it’s state with Openhab.

I’ve now enabled the trace log and filtered for one of the switch nodes: zwave.log (90.3 KB)

Can you see what the problem is that the state is not updated at startup? The polling seams to be started at startup, but it is not updated in the linked item. I’ve also tried sending a REFRESH with a startup rule, but that also did not synchronize the state at startup:

rule "System started"
	when
		System started
	then
		SW_ZWAVE_Kitchen_Light.sendCommand(RefreshType.REFRESH)
		SW_ZWAVE_PC_Light.sendCommand(RefreshType.REFRESH)
		SW_ZWAVE_Bedroom_Light.sendCommand(RefreshType.REFRESH)
		SW_ZWAVE_Living_Light_Left.sendCommand(RefreshType.REFRESH)
		SW_ZWAVE_Living_Light_Right.sendCommand(RefreshType.REFRESH)
		SW_ZWAVE_Bathroom_Light.sendCommand(RefreshType.REFRESH)
	end

(Chris Jackson) #22

Best is not to use TRACE - it just adds more noise that is not required 99% of the time. However, by filtering the log, you have removed the data that is needed so it’s not possible to use this file (with the ZWave log viewer) :frowning:


(David Masshardt) #23

Sorry, I’ve created a new log with DEBUG setting and uploaded it to my Dropbox: https://www.dropbox.com/s/4pb2h265jl0dd7c/zwave.log.zip?dl=0

Look e.g. for Node 34.


(Chris Jackson) #24

Can you post the XML file for this node? Then delete it, and restart the binding (to be precise, stop the binding, delete it, then restart). Please provide the log again from this restart.


(Ulrich) #25

You should setup persistence with restore on startup for those items you need to have initialized…


(Chris Jackson) #26

But this doesn’t mean that the state will be correct - just that it won’t be uninitialised any more.


(David Masshardt) #27

Done, here is the new log: https://www.dropbox.com/s/lyay9t41r72hwxf/zwave.log?dl=0
The XML before I deleted it: https://www.dropbox.com/s/8778qnutxygisp2/network_cd9d1ae4__node_34_before.xml?dl=0
And the new XML: https://www.dropbox.com/s/dxv5bkbj20eeb0k/network_cd9d1ae4__node_34_after.xml?dl=0


(Chris Jackson) #28

Thanks.

In the NIF, the device reports it supports SWITCH_BINARY -:

But when its version is requested, it reports version 0 -:

The standard states that if a device doesn’t support a command class when its version is requested, it should report version 0. So, the binding then removes this from the supported command classes.

I will update the database to force the version of the class to V1 and we can see if that helps.


(David Masshardt) #29

Ok, thanks. I guess I could test this in the next nightly build?


(Rossko57) #30

Forgive idle curiousity, I’m being nosey now.
Does that mean the binding thinks it cannot send commands to device? And hence why bootup/REFRESH is inoperative.

Presumably, once a day or whenever, the device sends a status unsolicited. (causing the ghost in the night effect)


(Chris Jackson) #31

Yes - I’ve made the database change, and will do a database update later. Assuming builds are working at the moment, it will be available tomorrow (I’m not sure if there are still problems with the builds since the ESH move).


(Chris Jackson) #32

Yes (but just for this command class) - this command class gets removed from the bindings view of the classes that the device supports, and it is therefore why the refresh is not working on startup (and maybe also why polling is not working on the device).

Forcing this command class to be implemented should solve this - I’m not sure if it will solve other issues discussed here though.


(David Masshardt) #33

I’ve compiled the development branch of the ZWave repository myself with the new XML you sent me, but the values are still not updated during startup. Do I have to delete the zwave file again?


(Chris Jackson) #34

I’m not sure what you mean - there is no development branch :confused:.

You will however need to delete the thing and add it back - the normal procedure when updating the thing types.


(David Masshardt) #35

I mean this branch here: https://github.com/openhab/org.openhab.binding.zwave/tree/development

I’ve deleted the Thing and restarted the server, but sadly the item still does not initialize the state.

Edit: After I re-added the thing it now completely stopped working. I’m not getting any updates from the switch anymore. Any Ideas why?


(Chris Jackson) #36

Well, this is a very old branch and I would not recommend using this. You should use the master branch.

Not without a log, but I would strongly suggest that you should just use the master version of the binding.


(David Masshardt) #37

I’ve compiled the addon again from the master branch and re-added the Thing, but the switch is still not working. When I push the button the node number does not appear in the log. Do you need a log from the start of the zwave addon or one when I actually push the button?


(Chris Jackson) #38

I need to see the initialisation, but there’s nothing to stop you pushing the button in the log as well :wink:


(David Masshardt) #39

Here is the new log: https://www.dropbox.com/s/kkc4bpdbgf2yvgl/zwave.log?dl=0

I only re-created the Thing for node 38 and I also pressed the button a few times. The Things from the other HAC01 switches I didn’t re-create yet and they are still working.


(Chris Jackson) #40

Please make sure that the correct version is running. In the log I see the following -:

org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.zwave [276]
  Another singleton bundle selected: osgi.identity; type="osgi.bundle"; version:Version="2.4.0.201902101535"; osgi.identity="org.openhab.binding.zwave"; singleton:="true"

this is indicative of two copies of the binding running and given that I don’t see the new information, I suspect you are still running the old binding. Either that, or the new binding is running, but the XML definition isn’t updated - either way, I don’t see the log entries saying that the version has been set.

                                logger.debug("NODE {}: Node advancer: VERSION - Set {} to Version {}", node.getNodeId(),