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
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)
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.
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.
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)
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).
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.
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?
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?
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.
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(),
.