Using openHAB 2.4.0 Release Build and Expire binding 1.13.0 which is just great!
But, I have a z-wave wall socket that reports fine and has associations set and all …that has issues with the binding. When I set it to expire “2s, command=OFF” or 20m it just works. But 59m or 1h or more (longer intervals) it does not send command OFF it just keeps on going.
I have looked in the logs and could not find anything suggesting it is updated during this period of time.
Any tips ?
Events.log does not by default record updates to the same value.
But such updates will (correctly) restart expire’s timer.
You can satisfy yourself if your Item is getting updates with a simple rule triggered by received update.
I don’t known why this happens. A Workaround can be a proxy Item, maybe like this…
Switch proxy_wall_socket "Proxy Item for Wall Socket" { expire="1h,command=OFF" }
rule "Zwave Wall Socket OFF on Expire proxy_wall_socket"
when
Item proxy_wall_socket received command
then
if (proxy_wall_socket.state == OFF) zwave_wall_socket.sendCommand(OFF)
end
Ooh my. It looks like it does receive updates every 20 minutes. How about that.
How Do I go about finding out what and why, turning on DEBUG mode ? Scrolling through “difficult-to-understand” z-wave logs… ? I don’t have any rule or anything that performs something on this specific thing.
Well it’s not an unreasonable thing to do, and has its uses.
Alter your expire condition to expire="25m,state=UNDEF" and you can detect when the socket goes offline, useful if it is a portable type.
You can do your timing with rules. See the motion detector example using createTimer here, you would just substitute your rule trigger for zwave device ON and the timer end to action as zwave command OFF
Timing with rules and proxy items, fine, that I can understand.
But what is the purpose of altering the expire condition to expire="25m,state=UNDEF" ?
Should I read out something from this with my newly created rule that pushes me a notice when the thing receives an update ?
You don’t have to do that. It was a suggestion and illustration to exploit the capabilities of the expire binding and of your zwave socket’s regular 20 minute reporting.
rule "panic"
when
Item mySocket changed to UNDEF
then
logInfo("test", "Someone has stolen my socket!")
end
More usefully, if you have rules intending to control the socket, they can check to see if it is alive, and maybe do something different.
Ok, so on this particular device there is no possibility to make it stop updating (or change update interval) “whatever it is doing” so that I can make use of the ease of the Expire binding ?
May I ask what I’m doing to the device by setting it to "state=UNDEF" ?
I’ve no idea. It seems unwise to me, but of course it is your device. I’d make openHAB suit the device, not the other way round.
Bear in mind also that expire settings are not accessible from rules, so there is a limitation cost to the ease of use. You cannot have different day and night timings, for example.
Absolutely nothing. It just sets the state of the internal openHAB Item. Bindings don’t usually respond to Item state changes, only commands.
(Exceptionally bindings can be configured to act on state changes, but that’s not the case here)
As soon as a binding provides a new state, it will overwrite UNDEF with the new valid value. It’s just a tool for your convenience, if you want to use it.
Bindings will sometimes set state UNDEF themselves, e.g. to indicate lost or corrupt communication. zwave doesn’t usually do that, because many battery devices sleep for days and lost communication is not an abnormal event.