I have a strange problem since the update to Openhab 2.4. I’am using the Hue binding to control my lights with Openhab and I also have some InWall ZWave switch detectors that are turning the lights in a room on and off using a rule.
Since the update to 2.4 all the lights in a room sometimes turn on by themself without pressing the ZWave button. I’ve added some debug logs and enabled the event logging and what I found out it that the rule of the InWall switch was executed, but in the event log I don’t find an entry that the switch item has changed at this time. Here is one of my light rules:
rule "Light switch kitchen"
when
Item SW_ZWAVE_Kitchen_Light received update
then
if (G_SW_HUE_Kitchen_All.state == ON) {
G_SW_HUE_Kitchen_All.sendCommand(OFF)
} else {
G_COLOR_HUE_Kitchen_All.send(HSBType::valueOf("82,55,100"))
}
end
My guess is that maybe the ZWave items are receiving a postUpdate e.g. from polling, even when the state has not changed and that triggers the rule. This would explain why this happens in every room at random times.
I’ve already tried to change the rule to “received command”, but that does’t work at all. Do I maybe have to change the rule to “changed” because of a different behaviour in Openhab 2.4 or is there a way to get the “received command” Trigger to work with ZWave switch items?
And in events.log updates are not listed. I suspect if you put the eventbus logger into debug or trace logging you can get the updates to show up there too.
Thanks for the hint. I’ve now observed this for some time and it seams that every room switches the lights by itself only once per 24 hours. And the polling period of the ZWave switches is exactly 1 day. I did read the post about the multiple big and small changes to the ZWave bundle. I guess something must have been changed regading the polling that causes items to update. I’ve now changed the rule triggers to “changed” and I will observe this for another 24 hours.
Any ideas what could habe been changed that could cause this change in behaviour from 2.3 to 2.4?
The difference between 2.3 and 2.4 are HUGE. It could be almost anything. But I suspect the newer binding updates Items on a poll because that is the correct behavior. When the binding gets a new value for an Item, it should update that Item, even if the value is the same.
Changed or received command are probably more appropriate Rule triggers anyway.
I have some more infos about this problem. After I set the trigger of every rule to “changed” I also restarted Openhab. After that the lights in two rooms did light up anyway during the night and caused me to wake up. In the event log I now found this line at the time the light switched on:
SW_ZWAVE_Living_Light changed from NULL to OFF
The problem was that I didn’t use the light switch in those two rooms since the Openhab restart and because of this the value didn’t get initialized. This confirms that there seems to be some new kind of polling that initialized the value after a few hours and this triggered the rule.
The problem is that I cannot use “received command” as a trigger because the ZWave binding doesn’t seam to send commands. I could add the switches to the mapdb persistence that the values are initialized at startup, but maybe the values could still be different after a restart.
Is there maybe a better way to ignore those polling updates in the rule?
That would be normal. The Item’s state would be NULL from last boot/editing, and eventually gets set to a “real” value when the binding gets a periodic update from the device.
Some would say “use persistence, and restore on startup” to avoid NULL states. That’s not always sensible (a) because remembered last value may no longer valid (b) editing doesn’t trigger the restore.
Better I would say to deal with it your rules, there a number of ways.
You could check in the body of the rule for previousState to have been NULL before deciding what to do.
Or you can change the rule trigger. As this is just a swtch, you can check for changes on->off or off->on, which would ignore changes NULL->xxx.
The problem is that if I would simply ignore the Null to something state I would also have the problem that I either need to press every button once to initialize the value after a restart of Openhab or I would have to add the button to the persistence system.
As far as I know there is no way of knowing if a rule was triggered by an actual action from a device or an internal polling update if the binding does not use commands instead of updates to make this difference clear. Or is there maybe something new that can be used with those channel based event triggers?
Have you actually tried this from a reboot? I thought part of the OH boot issued REFRESH to each Item, which in the case of mains powered zwave device should result in update to a non-NULL state before your rules get started.
I think there is a little confusion over the roles of command and update within openHAB. Commands generally originate in UI or rules, and flow “outwards” via bindings to real devices. Status from devices, whether unsolicited or polled, flows inwards as updates.
You did follow the advice to recreate zwave Things after the 2.4 update, because of the nature of some changes? That’s not explicit yet.
Yes, I rebooted my Openhab server yesterday and the ZWave switches were only initialized hours later which caused the light rule to trigger and this woke me up in the middle of the night. And even when the devices would be initialized at startup, would this not also trigger the rules and switch the lights at every startup?
And yes I had to re-add every Thing after the update. They didn’t work at all after the update.
I think in this case it would be the best option if I could just deactivate the polling update for those devices (or the individual channels) completely. I don’t really care if the switch detector state is currenty ON or OFF. I also control the lights via the app and other remotes, so the state of the lamps and the switch is almost always different. I just want the event that the button was pressed and then I check the current state of the lamps and switch them on or off accordingly. But there seams to be no option to disable the polling completely using paper ui. Is there maybe a hidden way to do this?
It’s an interesting conundrum. Requiring to detect any change coupled with an unhelpfully delayed ‘refresh/recovery’ is tricky.
I’m sure it ought to work out of the box, and refresh the Item state at boot up. (Should complete before your rules become live, same as restore-on-startup). I do not know the subtleties of zwave configuring, though.
Perhaps you should reveal your Item and Thing definitions, someone might help with this part…
But having said that, you would run into the same issue if it were a sleeping battery device.
The heart of the matter is not caring about the state of the switch, only changes. When used conventionally, looking for meaning in on or off instead, this would all “come out in the wash”, that’s to say it’d sort itself out.
I can think of some sticking plaster rules to improve things -
rule "sticking plaster"
when
System started
then
if (zwaveItem.state == NULL) {
zwaveItem.sendCommand(REFRESH)
}
// not convinced this will work
// so far as I can see, this should happen anyway at boot
end
rule "the real action"
when
Item zwaveItem changed
then
if (previousState != NULL && previousState != UNDEF) {
// here do your usual stuff
}
// drawback, first operation after bootup
// but before some 'refresh', will be ignored.
// better than ghosts in the night?
end
The device I’m having this problems with is the Everspring HAC01. The device has only one switch channel and no other options to configure. With the battery powered remotes and wall switches I don’t have this problem because they cannot be polled. Battery powered ZWave devices only wake up once per day and and there is no way to poll values from them. When a button is pressed they simply wake up for a short tim, send this one value and go to sleep again.
I don’t know this REFRESH command yet and if it would work on ZWave devices.
@chris: Didi you encounter any problems like this yet and what would be the best way to create a rule that only reacts to actual switching of mains powered wall switch detectors like this in OH 2.4?
There shouldn’t be any issue with using the REFRESH command - this just does a poll in exactly the same way as has been done for a long time (ie it’s not new in 2.4). The REFRESH command has also been there a long time.
It will of course update the value though - again, this is the same as always. Any data received from a device will be sent to OH - even if it has not changed state.
Thanks for the quick reply, I will try if the suggestion from @rossko57 with this REFRESH command works. If the values of the ZWave switches would be synchronized with this startup script there should only be changed events after that when the switch is actually triggered. I will report back if this solution worked for me.
To explain, I don’t need the ON of OFF state of my wall switches. I only need to know if a switch has been pushed. But with the new polling in Openhab 2.4 my rule with “received update” did trigger on every poll update too and this would then switch my lights randomly.
I don’t know exactly. I just know that in OH 2.3 I never had problems with the “received update” rules of my Everspring HAC01 wall switches. I OH 2.3 those rules would only trigger if I actually pressed the button. Since the update to OH 2.4 this event is triggered randomly because the items were updated and my guess is that this has to do with the pooling. Maybe the polling of those devices simply did not work in the previous version because of a bug that has been fixed now.
I’m currently testing if the devices are actually polled and updated at startup. Last time I restarted my Openhab server the switch items were still “undefined” after startup.
Edit: I just restarted my Openhab server and the switch values are all set to null. I will restart again with ZWave debug log enabled to see what is happening.
Do you actually have logs to show what the problem is, as I’m not really sure what you are reporting. Polling hasn’t changed, but the command repoll has been added so maybe this is your issue (although this is only done immediately after a command has been sent).
Maybe your rule should use the changed trigger as it will always run during polling - but this will not have changed from 2.3. This is a simple switch, and I’m pretty confident that polling has always worked otherwise many devices would simply never have worked.
To clarify, OP problem is that after boot, switch Item state remains at NULL for very long period, eventually updating to ON or OFF.
It’s not possible to distinguish if this late change is prompted by action at the device or just a routine poll. So he can’t tell at OH if action is needed or it’s routine.
Ok, thanks. That’s certainly not clear from the original post which doesn’t mention startup at all
If this is the case, then the logs should be looked at to see what is happening. The ZWave binding has always had a mechanism to poll all channels on startup (the so call dynamic initialisation phase). It should be obvious from the ZWave debug logs what is happening.
