Rule is triggering two times in a row

Hey,

i have 2 motion sensors in my hallway. When i walk through, one motion sensor gets triggered and after 1-2 seconds the second one gets triggered. So right so good. I have a rule, triggered by either of those 2 sensors. But after the rule ran through, it starts again. leading my lights to flicker for a bit before turning off completely.
The motion sensors are not sensing any motion after i went through the hallway (like 4 seconds after the first trigger)

Motion Sensor 1: ZigBee_Bewegungsmelder_Flur1_Bewegung
Motion Sensor 2: ZigBee_Bewegungsmelder_Flur2_Bewegung
Lights: Shelly_Licht_Flur

rule "ZigBee: Lichtsteuerung im Flur durch Bewegungsmelder"
when
    Item ZigBee_Bewegungsmelder_Flur1_Bewegung changed to ON or
    Item ZigBee_Bewegungsmelder_Flur2_Bewegung changed to ON
then
    logInfo("Debug", "Regel wird gestartet durch " + triggeringItemName)
    Shelly_Licht_Flur.sendCommand(ON)
    logInfo("Debug", "Licht wurde eingeschalten")
    while (ZigBee_Bewegungsmelder_Flur1_Bewegung.state == ON || ZigBee_Bewegungsmelder_Flur2_Bewegung.state == ON) {
        Thread::sleep(5000);
        logInfo("Debug", "Sleep 5000 in Schleife erfolgreich")            
    }
    Shelly_Licht_Flur.sendCommand(OFF)
    logInfo("Debug", "Licht wurde ausgeschalten durch " + triggeringItemName)
end
15:19:43.010 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'ZigBee_Bewegungsmelder_Flur2_Bewegung' changed from OFF to ON
15:19:43.017 [INFO ] [org.openhab.core.model.script.Debug  ] - Regel wird gestartet durch ZigBee_Bewegungsmelder_Flur2_Bewegung
15:19:43.132 [INFO ] [org.openhab.core.model.script.Debug  ] - Licht wurde eingeschalten
15:19:43.132 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'Shelly_Licht_Flur' received command ON
15:19:43.190 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Shelly_Licht_Flur' changed from 0 to 100
15:19:43.833 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'ZigBee_Bewegungsmelder_Flur1_Bewegung' changed from OFF to ON
15:19:48.155 [INFO ] [org.openhab.core.model.script.Debug  ] - Sleep 5000 in Schleife erfolgreich
15:19:53.171 [INFO ] [org.openhab.core.model.script.Debug  ] - Sleep 5000 in Schleife erfolgreich
15:19:57.288 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'ZigBee_Bewegungsmelder_Flur2_Bewegung' changed from ON to OFF
15:19:57.941 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'ZigBee_Bewegungsmelder_Flur1_Bewegung' changed from ON to OFF
15:19:58.186 [INFO ] [org.openhab.core.model.script.Debug  ] - Sleep 5000 in Schleife erfolgreich
15:19:58.207 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'Shelly_Licht_Flur' received command OFF
15:19:58.209 [INFO ] [org.openhab.core.model.script.Debug  ] - Licht wurde ausgeschalten durch ZigBee_Bewegungsmelder_Flur2_Bewegung

HERE THE RULE GETS TRIGGERED A SECOND TIME, TRIGGERED BY THE SECOND MOTION SENSOR WITHOUT ANYONE WALKING PAST THE SENSOR
15:19:58.230 [INFO ] [org.openhab.core.model.script.Debug  ] - Regel wird gestartet durch ZigBee_Bewegungsmelder_Flur1_Bewegung
15:19:58.262 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Shelly_Licht_Flur' changed from 100 to 0
15:19:58.353 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'Shelly_Licht_Flur' received command ON
15:19:58.354 [INFO ] [org.openhab.core.model.script.Debug  ] - Licht wurde eingeschalten
15:19:58.386 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Shelly_Licht_Flur' changed from 0 to 100
15:19:58.398 [INFO ] [org.openhab.core.model.script.Debug  ] - Licht wurde ausgeschalten durch ZigBee_Bewegungsmelder_Flur1_Bewegung
15:19:58.408 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'Shelly_Licht_Flur' received command OFF
15:19:58.448 [INFO ] [openhab.event.ItemStateChangedEvent  ] - Item 'Shelly_Licht_Flur' changed from 100 to 0


The rule runs twice because it’s triggered twice, by your two motion detectors.
So that’s expected behavior.

Well, i thought a bit different but found randomly an answer: Sleep in Openahb 3.0.0->Rules->Action->execute a given script

He says that triggered rules are being queued. Is there a way to stop queuing a rule?
@rlkoshak maybe you know something more?

No, and even if so that would be a wrong approach. Resolving concurrent access is a standard problem in computer sciences so use any of the well known solutions such as to use a run flag.

Please don’t ping people as per forum rules.

No. It’s by design and it solves a lot of problems.

Your rule in the first post means that your rule takes at least five seconds to run. If it’s triggered again, it has to wait up to five seconds before the second trigger will run the rule.

Each rule gets one thread. Only one instance of any given rule can run at a time.

In 2.5, that rule was really dangerous and not recommended. You could have starved out all of your rules. Now at most you could starve out just this one rule. But even so, sleeps are a bad idea.

Use a timer instead.

Off topic - please could you point me to this rule?

#15

1 Like

I am trying to use a timer instead. But i am not familiar with timers. I saw this post from you:

I am trying to implement a timerfunction that works, but i am not able to do so.

var timer = null

rule "ZigBee: Lichtsteuerung im Flur durch Bewegungsmelder"
when
    Item ZigBee_Bewegungsmelder_Flur1_Bewegung changed to ON or
    Item ZigBee_Bewegungsmelder_Flur2_Bewegung changed to ON
then
    Shelly_Licht_Flur.sendCommand(ON)
    timer = createTimer(now, [
        if (ZigBee_Bewegungsmelder_Flur1_Bewegung.state == ON || ZigBee_Bewegungsmelder_Flur2_Bewegung.state == ON) {
            timer.reschedule(now.plusMillis(100))
        }
        else {
            timer = null
            Shelly_Licht_Flur.sendCommand(OFF)
        }
    ])
end

I have no idea how the timers work. And my rule is not working either.

Well, the first place to look is the docs.

createTimer(AbstractInstant instant, Procedure procedure): schedules a block of code to execute at a future time

  • instant is usually a DateTime calculated using the built in variable now.
  • procedure is the block of code and is defined using lambda notation (i.e. square brackets)

It’s kind of pointless to schedule a timer for now. It will run immediately.

It’s very dangerous to reschedule a timer forever. What if those two Items never become go to OFF? the timer will never exit and run forever (which was a really really dangerous part of your original rule).

Why not skip most of this complexity? OH is an event based system. This is a standard [Deprecated] Design Pattern: Motion Sensor Timer problem. See that post for proper ways to implement something like this. Or even better, install a rule that does this from the marketplace: Open Reminder [3.3.0;3.4.9).

I really want to do it in an .rule file. I want to learn something and do it correctly.

My problem is following: I have 2 motion sensors. They have to turn one light on, when triggered ON and turn it off, when triggered OFF.
I dont want the rule to be queued a second time, while walking past both motion sensors.

When the first sensor triggers ON and after a few seconds the second sensor triggers ON, i dont want the rule to be executed a second time, while the first sensor is still having an ON-state and the first instance of the rule is still running.

Its hard for me to get it right. I would love to see you helping me with my problem. If not, it is okay. I dont want to waste your time. I just want to learn something new.

I think i understand how timers work, but i dont think they are helping my system to not queue the rule a second time, while the first one is running.

Try a different approach. Who cares if the rule runs a second time, there is no charge. But when it runs and the light is already on, don’t turn it on again. When it runs and the off-timer is already running, either do nothing or (probably smarter) reschedule the timer to extend the on-time (ypu’ve just detected someone, after all).

OK, so did you read that Motion Sensor Timer post? There are three different approaches in multiple languages presented there.

Then you can’t trigger the rule using both Items. Period. OH is event based. The rule will be triggered when the event occurs.

But that’s the point of all of this. The first rule should not still be running. That’s bad. Don’t do that. Figure out how to use the events and timers instead.

That’s because that can not happen. Forget about that. You can never make that work. It’s a bad approach. You need to change your over all approach.

You don’t want the rule to run when the second motion sensor triggers, don’t use that as a trigger to the rule. That’s your only choice.

Consider all the things available to you outside the rule.

  • Expire: does this light only get controlled by these motion sensors? If so, just set expire metadata on the light Item to turn off after five minutes. All your rule need to do is send command ON to the Light when one of these sensors triggers to ON. Couldn’t get simpler than that.

  • Group: does this light need to always turn off when both motion sensors go to OFF? Create a Group:Switch:AND(ON, OFF) and put both the sensors into this Group. Create one rule to trigger when a member of this Group changes to ON that turns on the light switch. Create a second rule to trigger when the Group itself goes to OFF to turn off the light switch. The Group will only change to OFF when both members are OFF.

If you insist on doing this in a rule, follow @rossko57’s approach (which is presented in the Motion Sensor Timer post as well).

Ohhhh, i think i had a big mistake in understanding timers.

I thought a timer would increase the time a rule is running. But instead the rule executes to the end and is then idle. It then can be executed a second time easily, while the timer from the first execution did not happen to that point in time.

For my understanding: If i am checking the timer state the moment the second rule executes, i can just

return

to end the rule immediately.

Thank you for your help. I will try a bit and then come back here with my solution.

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.