I have managed to install the latest openHAB docker on my QNAP and the z-wave binding (Aeotec) found the tilt sensor (ecolink TILT-ZWAVE2) just fine. The binary sensor state updates between open/close when I manually move the sensor. But after some time (i.e. hours) the state reports null again if I reload the paper ui control page. Manually moving the sensor updates the state, but shouldn’t it keep the last known state?
I see some posts about persistence after reboot, but my system has not gone through a restart. I have not created items or sitemaps yet, does that have any effect? The only other sensor I have added is a water sensor, both are old Z-wave. (not Plus)
The event logs show the state changes between open/close but not when it reverts to null:
Line 6917: 2020-05-12 22:32:24.495 [.ItemChannelLinkAddedEvent] - Link zwave_device_cffe5da8_node3_sensor_door-zwave:device:cffe5da8:node3:sensor_door' has been added.
Line 6921: 2020-05-12 22:32:58.492 [vent.ItemStateChangedEvent] - zwave_device_cffe5da8_node3_sensor_door changed from NULL to OPEN
Line 6923: 2020-05-12 22:33:06.377 [vent.ItemStateChangedEvent] - zwave_device_cffe5da8_node3_sensor_door changed from OPEN to CLOSED
Line 6925: 2020-05-12 22:33:10.227 [vent.ItemStateChangedEvent] - zwave_device_cffe5da8_node3_sensor_door changed from CLOSED to OPEN
Line 6928: 2020-05-12 22:33:14.327 [vent.ItemStateChangedEvent] - zwave_device_cffe5da8_node3_sensor_door changed from OPEN to CLOSED
Line 6967: 2020-05-12 22:34:41.004 [vent.ItemStateChangedEvent] - zwave_device_cffe5da8_node3_sensor_door changed from NULL to OPEN
Line 6969: 2020-05-12 22:34:45.378 [vent.ItemStateChangedEvent] - zwave_device_cffe5da8_node3_sensor_door changed from OPEN to CLOSED
Line 7000: 2020-05-12 22:39:42.427 [vent.ItemStateChangedEvent] - zwave_device_cffe5da8_node3_sensor_door changed from NULL to OPEN
Line 7969: 2020-05-13 02:38:32.896 [vent.ItemStateChangedEvent] - zwave_device_cffe5da8_node3_sensor_door changed from NULL to OPEN
Line 9782: 2020-05-13 09:50:13.135 [vent.ItemStateChangedEvent] - zwave_device_cffe5da8_node3_sensor_door changed from NULL to CLOSED
Firstly, the Paper UI is only meant for configuring openHAB, not for day-to-day operation.
Secondly, please follow the binding documentation for when things do not go as planned ant post unfiltered debug logs here, using code fences to make it more readable,
Have a look in your openhab.log around these times as well. There have been some issues where OH is restarting every minute. That might explain the behavior you see. However, most people had that on upgrades, not new installs. Worth a look anyway. A restart would not report a state change in the event log.
It is a fresh install but I’ll check the logs. But like Bruce said, I might be jumping the gun before defining items. I’m creating that right now. I’m just the type that likes to understand each layer before adding another and that can be pretty slow.
an automatically created one. You’ve got simple mode on … while this does give quick results, it soon becomes a royal pain as you want to do more sophisticated things like tailoring your system.
But that’s by the by.
Lifecycle of an Item. When initialized, like at system boot, it’s state is set to NULL. That doesn’t get logged, because it is normal initializing.
That’s the only way to set it to NULL.
We can of course initialize it “in flight”, for example by editing the Item, again no log is produced.
With 2.5 it has been observed that Things changing will cause certain parts of openHAB to reinitialize - rules, Items.
Your log will probably reveal a Thing change corresponding to a silent change to NULL, and that is what needs tracking down here.
This seems to be correct. The event log shows a Thing event roughly every 4 hours:
2020-05-13 18:50:36.295 [vent.ItemStateChangedEvent] - ecobee_thermostat_3a93abd6_411945229919_runtime_lastStatusModified changed from 2020-05-13T22:45:42.000-0400 to 2020-05-13T22:50:11.000-0400
2020-05-13 18:51:29.099 [vent.ItemStateChangedEvent] - network_pingdevice_192_168_10_81_lastseen changed from 2020-05-13T18:50:28.980-0400 to 2020-05-13T18:51:29.095-0400
2020-05-13 18:52:05.831 [vent.ItemStateChangedEvent] - zwave_serial_zstick_cffe5da8_serial_sof changed from 350 to 351
2020-05-13 18:52:05.913 [me.event.ThingUpdatedEvent] - Thing 'zwave:device:cffe5da8:node3' has been updated.
2020-05-13 18:52:06.833 [vent.ItemStateChangedEvent] - zwave_serial_zstick_cffe5da8_serial_ack changed from 269 to 270
2020-05-13 18:52:06.837 [vent.ItemStateChangedEvent] - zwave_serial_zstick_cffe5da8_serial_sof changed from 351 to 352
2020-05-13 18:52:06.909 [vent.ItemStateChangedEvent] - zwave_serial_zstick_cffe5da8_serial_sof changed from 352 to 353
I was manually checked the state on the controls page before and after the 18:52 mark in anticipation of this and it changed from reporting CLOSED to “-” (null). I also checked the openhab log and did not see any errors reported at that time. Next is to understand the update event above.
To be honest, that is what the binding documentation says to so when things do not go as planned I have found that the developer usually knows what he is writing about.
