Best way to control timer from more than one .rules file?

Setup, Configuration and Use Scripts & Rules
#1

I have not yet found a good solution for this. To simplify the issue:

  1. 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.
  2. 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.

#2

Yes, that’s it. Global Vars are only “global” to the rule-file they are in.
To get around that corner you could put those two rules into a single file

#3

I have read some things about the Expire binding. Could that be of use?

#4

As @rtvb suggests, the Expire binding is the perfect solution for this. You have your motion and contact rules continue to sendCommand(ON) for the light. Define the light with:

Switch MyLight { channel-"...", expire="5m,command=OFF" }

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.

#5

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.

#6

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.

#7

I know nothing of your rules situation but I will point you to the other design pattern postings and in particular the simple lambda example and the working with groups.

Based on what you describe above I suspect many if not all of these would help to greatly simplify and reduce the number of needed rules.