I have not yet found a good solution for this. To simplify the issue:
I have a motion.rules file that turns on a light for 5-minutes when motion is detected. If motion continues, the timer is extended.
I have a contact.rules file that turns on the same light for 5-minutes when a door is opened. As long as command or update is OPEN, the timer is extended.
The issue is that these rules are in different files, with different timers. Is there any good way to make one timer’s expiration not turn off the light when the second timer is still active? Is the only solution to use a large list of item DateTimes and Strings for tracking variables across different rule files? Doing so, I will not be able to make use of timers.
Five minutes after the last time MyLight receives an ON command the light will turn OFF. It doesn’t matter where the ON command comes from. And you don’t have to mess with Timers in your Rules at all.
The Expire binding really has become the best solution to this sort of problem.
However, it isn’t the only one. You can indeed handle this using Timers but you have to get a little clever. I’m suggesting this approach, the Expire binding is really the better solution.
Create a Rule that triggers when your light receives an ON command. this Rule can be in its own file if you wanted to. Create/reschedule/and cancel your Timer from this Rule. This approach would be an application of the Separation of Behaviors Design Pattern. Anytime you have cross-cutting logic like this (i.e. the same logic that you want to use across two or more different rule) this is a good way to handle that.
Thanks much for the direction guys! I will take a look at it this evening.
I didn’t want everything in one .rules file - I’m currently working on splitting them out into smaller files. Approaching 100 z-wave devices, and building more hacked z-wave nodes and custom microcontroller logic, the rules quickly grow in number. It’s a bit much for OpenHAB in general, and I’ve been contemplating using OpenHAB strictly as a HAL, due to “programming”/scripting limitations.
I used the following countdown technique. It is over-complicated, but illustrates what you can do with OH. It allows for different run times from different triggers and/or under different conditions e.g.day/night. It allows rules to inspect unexpired countdowns and decide whether to change or leave alone.
Not usually needed in a domestic setting.