I am trying to create a rule when if I have a virtual switch turned on that a set of actions will be perform every minute but if I turn off the switch then they will not.
It is globally disabling my presence detection.
rule "time to test"
when
Time cron "0 * * * * ?" and
Item presence.state == ON
then
logInfo("location.rule","Execute Location Service Script")
var String IphoneExec = executeCommandLine("sudo /opt/LocSrvcs.sh", 5000)
logInfo("presence.rule","Var1 = " + IphoneExec)
end
Can some please advise the correct way to achieve my goal.
Thanks
As I am trying to use state and Time conditions it is quite possible for the two to exist at the same time in the real world, as a state is being set for an indeterminable length of time and the time cron fires every minute.
An example of the if statement may well be useful here as I am struggling to see how I combine state item with a time cron in an IF syntax.
However after looking at the other thread and the complete concept even if I disagree with the statement the approach provided makes sense and works.
For anyone else interested this is what my rule looks like
rule "time to test"
when
Time cron "0 * * * * ?"
then
if (presence.state == ON) {
logInfo("location.rule","Execute Location Service Script")
var String phoneExec = executeCommandLine("sudo /opt/LocSrvcs.sh", 5000)
logInfo("presence.rule","Var1 = " + phoneExec)
}
end
I disagree with the âreal worldâ statement too although it doesnât apply to this specific question. Events occur simultaneously (to relativistic observers) in the âreal worldâ all the time. I assume when people are are making this claim they mean that openHAB rule engine canât detect simultaneous events. Even if it could, it would probably not be very useful.
The âwhenâ keyword is part of the problem. If it were named something like âtriggersâ, it would be less confusing. Iâm not sure, but I think the NG rule engine in OH2 uses that terminology instead. One could also argue that if would be better if the âwhenâ part of a rule could contain both triggers and conditions that constrain the triggering (like your original rule). The âthenâ part would then be more focussed on triggered actions rather than also being responsible for constraining the triggering behavior.
Ideally the triggers would not only be primitive event triggers, but advanced, derived ones. For example, a complex event trigger could be defined as something like the standard deviation of the exponential moving average of a sliding window of an itemâs state crossing a threshold (possibly derived from other item states). Another example (a variation of the âsimultaneous eventâ trigger would be something like if Item Aâ state changes (or doesnât change) with 5 seconds of a change to Item Bâs state then execute the action. There are certainly ways to work around not having having support for these kinds of triggers (with timers, periodic helper rules, etc.), but I believe it would be less error prone and more useful to nonprogrammers if they were supported in the rule language.
Donât quote me on this, but I believe the NG Rules Engine does indeed support conditions. There was another thread that mentioned that right now AND is the only supported boolean operator for triggers in NG rules triggers.
It does. It supports them as reusable âmodulesâ. One can also program conditions in a scripted action (or in a JSR223 rule).
You mean conditions, right? I think the triggers are still effectively an OR and the conditions (at least generic conditions) appear to only support AND (although I havenât seen that confirmed by @Kai).
I donât really know what I mean, honestly. Iâve zero experience with the new rules engine so I may have not followed that thread as closely a I should have.
Paul, rules are âfiredâ when something happens (changes or is updated) [trigger] on the eventbus (when-part of the rule). In the rule body you can check for current states of items, variable⊠by using âifâ clauses or âcaseâ⊠(Check for conditions).
So find your trigger and then check for conditions.