I have a ZWave light switch. I can turn it on and off from the Point screen, so I know the commands are working fine. Also, when I turn on the switch using the physical switch, the state updates in the point screen, so that part is working.
Here is the problem: I set the Metadata “Expiration Delay” to 0h0m15s,command=OFF. I expected that the light would turn off 15 seconds after I turn it on. Problem is, it never turns off.
What am I misunderstanding about Expiration Delay? Goes without saying, I am on OH3.
Read about syntax in the Expire binding docs in OH2, this became the metadata feature in OH3.
Note whenever there’s an update to the switch item, timer will restart.
Thanks. I read the OH2 doc, as you suggested, and the syntax looks right to me. Also, the reason I kept the expiry so short (15 secs) was to avoid the repeated commands problem.
Thanks, rikoshak. When I tail the events.log file, all I see is entries like
item XXXX changed from OFF to ON
when I switch it on manually. Then it just sits there, no further action takes place on Expiry.
I tried using the Console to manually send the OFF command, and that works fine. Just to be sure I am not doing something stupid, here is the screenshot of my Metadata section for the thing. Can somebody please tell me if this looks OK?
Nothing needs to be done to enable it in OH 3. Unless you messed with the Code tab, the syntax for the expire config can’t be wrong. That that leaves either there is a bug or there is something else going on with that specific Item.
The first and easiest place to see most of what is happening with an Item are the lines in events.log. So care to post those lines? When one of us says “what do you see in x.log” we don’t want a description, we want you to literally post the relevant lines from that log. Please use code fences.
```
code goes here
```
Don’t hold information back from us. Doing so just makes it take longer to help you and tends to make us grumpy.
I switched the light switch ON, waited over a full minute, and then switched it OFF. Here is what I got in the events.log:
2021-08-12 15:03:53.659 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ClosetLightSwitch_Switch' changed from OFF to ON
2021-08-12 15:05:08.659 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'ClosetLightSwitch_Switch' changed from ON to OFF
OK, that confirms that the Item is flapping around or anything like that.
Open the Developer Sidebar (alt-shift-d).
Open the Event Monitor (second tab).
Click on the small blue circle icon to create a filter. Enter *ClosetLightSwitch_Switch* as the filter (note the *, those are wildcards).
Click “String Events”.
Wait a small amount of time so see if any events occur. If they do get a rough count for how far apart the vents occur. If they don’t, sendCommand ON to the Switch, continuing to monitor the events. After the command, changed, and update events occur wait for the 15 seconds. Did any additional events occur in those 15 seconds?
I’m also remembering from a long long time ago when Expire was an add-on instead of built in that it couldn’t handle expires that are too short. Maybe try one minute and see if that makes a difference. If so open an issue on openhab-core to have Expire handle shorter expire times.
Thank you! That was the key debug tool I needed to figure out the problem.
The issue is that I am trying to detect when the switch is turned on manually (using the physical wall switch, not via OH), and then turn it off some time later. To do this, I have to set the poll interval rather short so I know when the light turns on. Thus, I had set the poll interval to 15 seconds as well.
However, the poll response itself is an event that resets the expiry timer, so it never kicks in.
So, I need to find a different solution using JS or whatever, is the conclusion I am drawing from all this…
OK, if I set the polling interval to the default (very large value), I never get an ON status when I turn on the switch manually, using the physical wall switch. Is this not expected? How do I debug that situation if that is not the expectation?
Not really, if we are talking about a zwave device. We can’t see what you’re poking at.
There is debug advice in the docs, but first I would look at some of the dozens of threads on the topic. Very often it’s about configuring the ‘lifeline’ on the device.
Frequent polling is bad practice because the traffic clags up your zwave network, it’s not intended to work that way,it’s event driven.
Yes, confirming it is a ZWave device, as mentioned in the opening post. OK, I will set the polling back to the default large interval, and see about how to solve that problem. Lots of stuff to learn, I guess.
I did a bunch of research on “lifeline” which seems to be related to “associations”. Most of the posts I uncovered talk about HABmin as the tool to use to examine and set associations. However, I believe HABmin has been deprecated completely as of OH3. Can you point me to a way that I can use to set and examine associations? Thanks.
FWIW, when the “re-initialization” is performed, I captured and analyzed the Debug log - it does appear that this process sets the Association and Lifeline, as can be seen from the screen cap attached. However, no joy in receiving status updates from the device with no polls.
Some Zwave devices simply do not report back when they’ve been manually switched. For example I’ve an old Linear wall switch that simply does not report manual triggers.
As rossko said, rapid polling on the Zwave network will cause lots of problems so it is not recommended.
If your device supports reporting manual changes in it’s state you will find an Association Groups section in the Things options. Set that to Controller.
If you don’t see this then it might be that this device simply won’t be able to work the way you need it to and you might need to find an alternative device.
