Expire binding improvements?

I’have been looking into the timers as I intend to replace all my rules that use too long thread::sleep() waits.
And I’m surprised to find out that there is no easy way to have an timer that can have remaining time accessible/editable as the value to display/modify in rules.

While expire binding concept is excellent I’d love to be able access/check if the expire timer is running simply by the checking value of item.expiretimer and item.expirestatus that would return info if it is running or not (and maybe influence it by item.expirectl (start/stop/restart)

is that dooable?

You can already check to see if a timer is running by looking at its state. Normally, we use something like this: Switch … {expire=“20m,command=OFF”}. That means if the Switch’s state is ON, the timer is running.

On your other question, checking how much time left, I think it is doable, but it requires tracking additional state within the binding. E.g. in the example above, you might need to give it a name so that you can map another Number item to retrieve the remaining time. This is only my speculation as I haven’t looked at the binding source code. I have no need for such feature up to now. The nice thing about the expired binding right now is that it is dead simple, so any additional features should not require changes to existing item config.

1 Like

Not with the Expire binding as written and not in the way described.

The methods available on an Item in your rule is defined by the core of OH. A binding cannot add methods to the Item to call and I doubt it would be feasible to ever allow such a thing.

If one were to rewrite the Expire Binding as a 2.x version binding, then one could create a Thing with two channels, amount of time for the timer and amount of time remaining, or probably better the time when the timer will expire. But this approach will be orders of magnitude more complex to implement and to use and I’m not convinced the new capability is worth it.

While seems it cannot be done inside expire binding and I’d like to see these improvements as well (specifically the ability the cancel a running timer), I believe that in order to query the remaining time, you should be able to use persistence on the item and retrieve item.lastUpdate.

1 Like

Not having to define a Thing is a positive advantage for the expire binding in terms of speed/efficiency IMO.


There are ways, but certainly not easy

If the binding can’t add methods to the item maybe it can spawn automaticaly items with sufixes in names that could hold that required counter data. But stil that would not solve the problem of pausing, reseting the countdown timer that is so needed.

I think that was what the suggestion about additional Thing channels was about, so you could choose to link an extra Item to, say, a countdown channel, or perhaps a target datetime. Presumably you could send commands to that to zero it or reschedule it.

Given the architecture of OH, I think having bindings dynamically creating Items would not be accepted. The Item creation API is open so technically it’s possible, but the intent of Items is to be your model of your home automation. Having bindings creating Items dynamically would fly in the face of that. And as rossko57 indicates, that is what Things are for.

You can achieve these behaviors with Timers in Rules.

But getting current timer countdown time left is only possible by putting a time the counter was started into the helper variable. Am I right?

Or put the time when the timer expires and calculate how long it is from now to when it will go off.

var start = now
var end = now.plusMinutes(someMins)

// later on create the timer
timer = createTimer(end, [ |
    // do something

// later on to find how much time is left
var remaining = end.millis - start.millis
// do some math if necessary to convert millis to minutes and seconds.