OpenHAB core rules - making rule fail if item state changes after rule starts running

Hope someone can help me out with this one :slight_smile:
Super simple setup, one presence sensor, and one light.
Sensor detects presence → light turns on.
Sensor stops detecting presence → light turns off.

Very basic and everything works fine, but the presence sensor is a little bit fidgety and will switch to off and back to on momentarily. I would like to add a …. Not delay…. But not sure what else to call it, where the despite the presence sensor being off, nothing happens for (example) 10 seconds. And it 10 seconds later the presence sensor item is ON, then the rule (turn light off) fails to run because, well there’s presence detected.

In my experiments I on the core rule engine (webui only, no scripts) I managed to delay the turn off, as if the state of the presence item is stored when the rule starts, and when the rule reaches the “but only if” condition (10 seconds later) it turns off the light despite the presence item stating ON because it does not check the current state of the item.

Couple questions:
Am I understanding the “but only if” field correctly?
Is there a simple way to do this in the webui ? (Without scripts)
Can anyone share a working example (even if with script) for me to tinker with? (I’ve tried ChatGPT with … erg varying degrees of failure )

Usually you’d do this with a timer (script)

Thank you! Yeah I assume in a script it would be easy work, but there I’m quite limited in my ability to code.
I would like to stay in the confines of the core rule engine only… let’s see…

Maybe you can come up with ideas of what to add to the UI rules (without scripting) that would make things easier.

Maybe some sort of delayed trigger, or enhanced trigger option similar to what jruby has could be useful. I’m not saying that you should use Ruby here, just trying to show what feature it has that might be (?) useful to bring to the UI.

Example:

rule "Execute rule when item is changed for specified duration" do
  changed Closet_Door, to: CLOSED, for: 10.seconds
  run do
    Closet_Light.off
  end
end
1 Like

Maybe you should try “debounce”, there are many posts on this topic.

2 Likes

Yes, but you need one extra item and two additional rules.

Any item can have an “expire” metadata added to it which gives the item a timer-like ability that when it’s state changes, after the configured expire time, it will automatically change (back) to a configured value. Most of the time this is applied to some sort of switch item which means you can set this switch item so that when something turns it ON, after X seconds, it will turn itself off again.

If you create exactly such a switch item (expire turns switch off after configured time) then with three rules you get exactly your desired behavior:

Rule 1) Sensor → ON then Light → ON
Rule 2) Sensor → OFF then Expire Switch to → ON
Rule 3) Expire switch → OFF then Light → OFF But only if Sensor == OFF

1 Like

Some posts which might help:… There are lots of approaches but most of them will require inline scripts.

This part is confusing.

A rule has three parts.

  • triggers: events that cause the rule to run
  • conditions (but only if…): what states all have to be true to run the script actions for a given trigger
  • actions: the stuff to run when triggered and the conditions are true

The rule reaches the “but only if” first. Where’s the delay coming from?

Indeed, the information about the event that caused the rule to trigger is saved at the time the some was triggered. But it’s not clear what you are testing here, the values in the event or the states of Items. And the timing doesn’t make sense either because the conditions will run right away. I know if no way to delay that. If you’ve added added a delay to the actions, that delay occurs after the conditions have already run.

I don’t think so. These define the states that must be true at the time the rule is triggered in order to run the actions.

sorry I’m on mobile with 8% battery struggling a little bit to type properly.

Then that is my problem, ok, at least now I understand the behavior. I need to make a note of this for future reference.

So long story short, my presence sensor sometimes will stop detecting presence for a split second. I am there but it switches off when I stand too still then turns back on quickly. The delay was a part of me trying to find a way to solve these split second change of state, where the presence switch turns off, but instead of the rule finishing then, it would wait ten seconds, to make sure that the presence really is off (aka person left) and not one of those split second state changes because I’m standing too still.

If the states are saved at the beginning of the rule starting, then yeah this is a bit of a limitation, because I need to check the state of the same item that triggered the rule a couple of seconds after the rule starts to check if the rule really should finish (aka turn off the lights) or if it should ignore it.

Was this easier to follow? I’m struggling with words :frowning:
I wonder if it would make sense to create a small change request?

I also need to review that debounce idea meanwhile, seems interesting.

Edit: Debounce profile does not appear available with switches… humm… starting to feel like maybe it would make sense to create the change request…

Debounce does exactly what you need. You just need to break out of the XY Problem. If you choose a solution that supports this, you only need to debounce OFF.

  1. A “raw” presence Item changes to ON
  2. the light turns ON
  3. “raw” presence Item changes to OFF
  4. a timer is created to check it again a little later
  5. the raw item changed to ON, timer is cancelled and nothing happened when it went to OFF
  6. the raw item changed to OFF
  7. timer is. created to check again a little later
  8. a little later passed, timer runs and turns the light OFF

You only turn off the light if presence remains OFF for a certain amount of time, ignoring those little blips.

This can be implemented with a profile, a rule template, expire, timers in rules, etc.

That’s not what’s happening though. The conditions are evaluated at the beginning if the rule. This is why you need a timer the action and the timer can check the conditions again or when conditions change cancel the timer.

OH already has a ton of ways to handle this, I don’t know we need yet another one.

The Debounce profile will work with any type of Item. But profiles only can be used on the link between a Channel and an Item.