[SOLVED] Only if rule

Hi,

I’ve got a rule that turns on a bedtime routine, and I’ve set it up so that it can be triggered in various ways, (Alexa command, cron, switch on peperUI), perfect.

The issue I’m now getting is that if I trigger via Alexa at say 7pm, the resultant switch item vEndOfDay gets turned ON. Now the cron is set to trigger at 8pm so seems, (unless someone can tell me otherwise), that the rule seems to then be re-triggered at 8pm…and as I have timers and music playlists associated they start again.

Is this correct?

Or as I have the rule running on ‘when item vEndOfDay changed’ that the cron will send it ON which it already is so nothing will happen?

Is there a neater way to do / avoid this or is it a non issue?

Is there a command that says ‘run this rule when item changed but only if the state being passed, (ON), doesn’t match the state it currently already is (ON)’

In order to give the correct answer/advise a look at your actual rule would help, why don’t yopu post it?
Without that we can only assume that you have all various ways to trigger the rule setup in the “when”-part of the rule, although other ways are possible.

Happy to, to be honest it doesn’t really give you any more info…

  1. Alexa trigger simply switches vEndofDay = ON when I say ‘Alexa its bedtime’

  2. Cron / Time of Day Rule Trigger

rule "Set aEndofDay = ON when vTimeOfDay = BED (between midnight and 6am)"
when
    Item vTimeOfDay changed
then
    if(vTimeOfDay.state.toString == "BED")
      {
      aEndofDay.sendCommand(ON)
      }
    else
      {
      aEndofDay.sendCommand(OFF)
      }
end
  1. Main Rule
rule "End of Day routine (Alexa / vTimeOfDay / Switch)"
when
	Item aEndofDay changed 
then
    if(aEndofDay.state == ON)
        {
        //do some stuff
        }
	else
        {
        // do some other stuff
        }
end   

This does what it says; triggers the rule when the state of the Item changes.

It does not trigger if the Item just receives a command (though a command may eventually cause a state change that might)
It does not trigger if the Item receives an update (whether from rule or binding) to the same state e.g. ON updated to ON

If this rule is triggering at unexpected times, your Item is getting changed and you’ll find the evidence in events.log

1 Like

Great, thanks for confirming…that’s what I thought but something random is / was going on with the rule…maybe I’ve got something else running interfereing with it…or perhaps I fiddled with the rule and reset the variable at some point…

Think I’ll keep my hands off OH for a couple of days, let it run itself and observe…

Editing rules and items file causes Items to be reset to NULL and System started rules to run. If a rule or binding then comes along with an update, obviously that would trip a changed trigger.

It’s quite common to have to adapt rules to deal with that situation. Time-of-day workings is a good example - when suddenly resetting things in flight, you may need to recalculate/repopulate current conditions. Which might trigger changes etc.

Sometimes cunning use of triggers will do. For some simple day/night item, triggering from
when DayNight changed from ON to OFF
will avoid triggering when changing from NULL to on or off.
Unfortunately there isn’t an “anything but NULL” condition which would be useful :smiley:

Sometimes it is just easier to reboot OH.

Yes, that’s what I’m thinking. I fell foul of the system started rules a while back when I was trying to set up a presence rule and everytime I thought it was running fine it would stop, or worse, start up when I was home…which meant constant moaning from the wife as the cameras would start pinging and alarms would fire out the speakers!

I like the idea of the ‘anything but NULL’…perhaps that could be a feature request for OH 2.6???

Well, there is a workaround.
Every rule with a changed trigger has an implicit variable previousState (not to be confused with someItem.previousState involving persistence) so you could do it like so …

when
   Item someItem changed
then
   if ( previousState != NULL ) {
       // do stuff
   }
1 Like

Big fan of that! That’s solved a heap of annoying actions from my tinkering!

Just a little heads up;

previousState is only there if the rule has at least one changed trigger.
In any other rule it will fail like an unknown variable.

It only gets populated if an Item was involved in the trigger.
Example

when
   System started or
   Item myItem changed
then

When this rule gets triggered by System started, previousState exists but has null content. (what value could it take?)

Obviously when previousState does have content it’s only about the Item that did the changed triggering.
You cannot cheat round that association

when
   Item thisItem changed or
   Item thatItem updated
then

If this rule is triggered by thatItem updating, previousState would exist (because the rule has a changed trigger) but will be null (because the triggering Item is not part of the changed trigger)

It just takes a little care constructing rules and triggers, and if necessary testing if things are null before trying to use them.