Expire-bindings never expire

you’ve checked the events log to make sure it’s not getting regular updates?

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 :wink:
Openhab (2.3.0) is running on Raspberry Pi3, do you think it can play some role?

Hi all.

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

Cheers

Sergi

Hi, having the same issue but, my fault, I dont full understand what adding a new express item means
I got the following in my configuration files

item

Switch	Cucina_Stato  "Luce On/Off"	(AllKitchen) {channel="espmilighthub:rgb_cct:001:0x156C1:level, espmilighthub:rgb_cct:001:0x44F98:level"}

From which I derived the following item

Switch	Cucina_Tempo "Luce On/Off"	{channel="espmilighthub:rgb_cct:001:0x156C1:level, espmilighthub:rgb_cct:001:0x44F98:level", expire="1m,command=OFF"}

Sitemap
a simple switch

 Switch item=Cucina_Tempo label="Prova temporizzatore"```

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

It’s quite straightforward

rule "pass commands"
when
   Item thisItem received command
then
   thatItem.sendCommand(receivedCommand)
end
1 Like

So the scenario would be

Switch	Cucina_Stato            "Luce On/Off"		(AllKitchen) {channel="espmilighthub:rgb_cct:001:0x156C1:level, espmilighthub:rgb_cct:001:0x44F98:level"}
Switch Cucina_Tempo { expire="15s,command=OFF")

And the subsequent rule

when Item Cucina_Tempo received command
then Cucina_Stato.sendCommand(receivedCommand)

I got it
Thank you Sir
I hope this example can help some other noobs like me

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.

1 Like

It’s obviously like you remark
It was a typing error, now I have corrected the post

Thank you, just ran across this post which solves my issue easily. I assumed it was part of the OH core.

Best, Jay