Rule triggering when Item changed from anything but

Hi
I’ve got a working rule that triggers when “Item changed to 7”. Now I want to change the rule though so that it does not trigger if the Item value changes from 0. Essentially I’d want to put “Item changed from anything but 0 to 7” but that’s not valid. Obviously I could do a lot of or’s here (“item changed from 1 to 7 or Item changed from 2 to 7 etc…”), just wondering if there’s a better way?

After some searching I guess another way would be to look at the previousState the first thing I do in the rule. I am not using persistence though, I understand that would be needed?

previousState is an implicit variable. You don’t need persistence for it since v2.2

rule "Nothing but 0 to 7"
when
    MyItem changed
then
    if (previousState >= 0 && previousState <= 7) return; //Exit the rule
    // Do what you want
end

Don’t forget the ; after return

2 Likes

Ah, great! Guess I missed when that changed :slight_smile:

In fact, previousState was available for ages (I used it in OH1 since ~1.1?), but it’s only available in rules triggered by changed and only for the triggering Item :slight_smile:

And of course previousState could be NULL, which should be incorporated.

1 Like

That’s perfectly enough for me :wink:

I’ll add an extra check for NULL as well, had completely forgotten to do that…

So there is a ‘previousState’ for Item “changed”, but how about the case of Item “received update”? In the latter case there is no previousState? Seems like the answer is no based on the wording on this page under Implicit Variables: https://www.openhab.org/docs/configuration/rules-dsl.html#scripts - you get the triggeringItem for a status update or change, but you only get the previousState for a status change.

I’ll have to scrub my rules for this - I didn’t realize this was true. I’ve been using received update and changed almost interchangeably.

Implicit Variables inside the Execution Block:

received update will trigger even if the value has not changed whereas changed is self explanatory.

Thanks for clarifying - that makes sense. What doesn’t make sense to me is that ‘update’ doesn’t give you the implicit ‘previousState’. I think it should, even if it could be the same - it could also be different. I will be much more careful in the future in my rules regarding this - thanks again to both you and Udo.

If it is the same there there is not previousState. Previous implies a change.

I would just like to agree with @jswim788 here. It would be easier writing the rules if there would be a previousState in update rules as well. Then you could also compare the current and previous states and do different stuff if they’re the same compared to if they’re not.

If you guys feel strongly about it, please add a feature request in github:

1 Like