Proposal: Timed Command/Event/State Binding

[rlkoshak (Rich Koshak)]

Kai has made it clear that the Expire binding never should have been a binding in the first place. This feature should have been implemented as part of the core from the beginning. So another binding that does the same thing only more seems like the wrong path. It should be something that is implemented as part of the core.

@jluzonpr

Make a new binding that’s probably going to be similar to the expire binding. No idea on a good name yet. It will use a ScheduledThreadPoolExecutor and will hold on to the Future object returned to be used to do things like show when the event will trigger as well as be able to do things like cancel the event. The idea is to have a single things scheduled at a time per item, so if a new value is created, the old Future is cancelled and replaced with the new Future and thus a new event being scheduled.

Let’s assume this is built as a 2. version binding (please don’t even consider building a new 1.x version binding at this point). This means that we need to create Things and the Things will have Channels. This is good news as the Timer can exist as a single Thing and it will have Channels for triggering it, passing it the amount of time to run, seeing how long it left on it, etc.

I can see the following Channels, which would mirror what the Exec 2 binding does:

• Switch Run: Channel linked to a Switch Item. Send command ON will cause the Timer to become scheduled using the value stored in the Timeout Channel. Send command OFF will cause the Timer to cancel. Checking the state of this Channel will tell you whether there is a Timer scheduled or not.

• Number Timeout: Channel linked to a Number Item where you can define how long the timer is to be set for. It probably should be a Number:Time (or whatever the appropriate Unit of Measure is for duration). An open question is whether sending a command to this Channel triggers the timer to start

• Number Time Remaining: Channel linked to a Number Item that indicates how long until a Timer goes off. As above, it probably should be a Number:Time.

• Event: A trigger channel that activates when the Timer goes off. You would have a Rule triggered by this Channel which contains the code to execute.

There are some issues with the above approach, really, but like I said at the start. This isn’t something that should be a binding so it’s really kind of academic at this point.

This is something that has been discussed and I hope that support for Timers/Expire gets moved into the core for OH 3. Since the move from ESH I don’t know if the issue that David started to discuss this has made it over. But the ideas from that discussion have been included in his Next generation design: A Paper UI replacement proposal.