I just want to add that since recently I experience exactly the same problem with one of my 4 “expire-configured” switches. All worked fine few months ago.
Three of them are working as designed and switch off after 5, 10 and 15 Minutes respectively. The forth one which is set to 30 Minutes works… only sometimes - I didn’t get the pattern yet, although I suppose that switching it ON - let’s say electronically - works fine, but doing so manually (the wall switch) doesn’t.
What I don’t get is the fact that I can see manual ON in the log, and yet it won’t expire.
Solution to #2: Adding association group in habmin
@Landstad All four of them lacked the association to controller (yet three of them worked fine). I just added the association for all of them. I’ll see what happens…
Yes, I did and it’s not. The manual (wall switch) “changed from OFF to ON” is the last occurrence of that item in the events.log.
I didn’t play with the verbosity of the log though, is it even possible? There are no rules for that switch, if it’s of any importance.
Edit:
I just checked today’s log and it seems the time to expire is actually defined as an “order of magnitude” than exact amount of time. 15 Minutes of my timer turned out to be about 28’30’’. I did not expect it to be exactly 15*60 seconds, but it almost doubled. Maybe it is working afterall, but much much slower than expected
Openhab (2.3.0) is running on Raspberry Pi3, do you think it can play some role?
It happened the same to me and I fix it adding a new item just for the expire time and a rule that changes the “real” item accordingly of what I wanted.
At certain time started to fail, 3 weeks ago approximately, with just one item with two channels. But when I splitted the channels worked again
Now my problem is, when I make use of the first Item as a regular basis, the second switch with expire binding come in. The obvious effect is, the light turn off when not desired.
I’m pretty sure it’s not really a technical issue but a personal comprhension difficulty problem
Yes. They’re both linked to the same channel, so naturally if you update A then B updates as well. (and the update starts ‘expire’).
One way round this is NOT to link the expiring Item to anything, so that way it’s state won’t change.
Then have a rule that listens for commands on the expiring Item, and passes those commands to the ‘real’ Item with the channel.
This won’t look very good in the sitemap (no state change when ‘real’ Item changes).
Do you care, if this is meant only to be used from rules e.g. motion detection?
Thanks, I think I’ve got the concept
So, If have a dedicated item device which is only “expirable”, like a bathroom fan, I can dedicate it a item with “expire” attribute in the item definition
Against, if I manage a (i.e.) lamp that can be addressed two way, my item definition (with channel referenced) need a second virtual item and a rule managing it. Right?
One thing not yet clear is how to pass the command between the two
Can you please, provide any example?
I certainly make use of this with a sensor/contact and motion detection but would like others cases too
You want the rule the other way around. You don’t want to send commands to the “timer” expiring Item, or you will start timer every time. You want the timer Item to pass commands to the real Item.
I don’t like resurrecting threads, but it makes no sense opening a new one. I have a binding which takes way longer to expire than set time. 30s as shown below took 12 minutes to expire (I had 10 minutes and after a few days it didn’t expire). It’s only one switch channel in the binding which gets no updates after being sent the ON command, what could be wrong?
You are right, it looks like the channel gets updates every 30s (precisely), although previously it wasn’t shown in the logs. I guess the only way is a separate item as shown above, right? I’m thinking it might need to be a little more complicated to be able to also have the status shown in the UI?!
Something like updating the separate_expire_item when sending a command using the switch (to trigger the expire timer) and then sending the expire=OFF command back to the switch? Or is that unnecessary?