Simple Switch "dummy/mirrored" unexplained behaviour

Hello,
I ask you if you have an idea to help me fix these wired problem.

Basically the situation is the following:

  • I have some PIR HC-SR501 motion sensors on some rooms. The PIR is connected to some arduino or ESP. It send via MQTT the signal ON and OFF to OH4 on the raspberry.

  • The ON / OFF cycle of the PIR (Tx + Ti) is more or less a couple of seconds, achived regulating the Time potentiometer on the PIR :
    Waveform-of-Single-Trigger-Mode

  • To better manage a BAYES presence Switch like described in these topic I create a sort of “Copy” of the PIR switch in order to stay ON for longer time after a single “person is detected”. Indeed stay ON for 5 minutes instead of 2 seconds.
    (If, after passing in front of the PIR i did not move for some time on the SOFA, I’m inside the room but i’m only not moving for a while)

Here the two items in the MAIN UI

  • the link between these Items is made via a simple RULE like these:

Teoretically all seems very easy and smooth but something wired happends. I tought a lot but I’m not able to guess Why it happends:

Look here below:
PIR DIRECT CONTACT

BAYESIAN “DUMMY” SWITCH

As you can see, the items are not alligned as I expected. A lot of false ON is triggered…

Can you see a problem on these implementation ?
Is something that I miss?

Can I implement the same in a smarter or different way ???

Thank you for you valuable help.
Nicola

So you want [Deprecated] Design Pattern: Motion Sensor Timer which you can use Debounce [4.0.0.0;4.9.9.9] to implement.

Create a Group Item to put your motion sensor(s) into called Debounce. Add debounce metadata to those Items per the instructions. For example:

value="MotionSensorProxy"
config:
  states: "OFF"
  timeout: "PT2M"
  command: "true"

If that metadata is applied to MotionSensorRaw when the Item changes to ON that ON state will be commanded to MotionSensorProxy. However, MotionSensorRaw needs to remain OFF for two minutes before MotionSensorProxy will be commanded to OFF.

There’s no timer. As soon as your Item goes to OFF you simply command it to ON. Then the sensor changes to to OFF again and you command it back to ON. There’s no real filter here.

Note: Don’t post screen shots of code or logs. Always post the actual text in code fences.

```
code goes here
```
1 Like

Thank you very much. The explaination in the link are very near to my case.

To be honest I did not understand very well why the implementation with expiration time is deprecated but anycase I will try to use timers in rules.
I already manage a rule of a light ON/OFF that perform very well with timers.

Thank you very much.

Because every bit of functionality in that design pattern can be achieved though installing and instantiating the Debounce rule template and configuring the Items. No coding involved. I’m not going to maintain and keep up the examples and approaches in that post any more when I can maintain the rule template which can just be installed and used instead of needing to deal with helping people who attempted to copy/paste/edit and failed somehow. With the rule template I know exactly what code is running because it’s exactly the same code I’m running. And I’ve added way more diagnostics and error checking than anyone would do when copy/paste/editing a solution.

It’s less work for me. It’s less work for end users. Win win.

1 Like

@rlkoshak hello,
i’m sorry to come back to the argument but I’m missing something and I kindly ask your help to understand how to do…

I tried to implement the timers version of the story

1- I remove the metadatas from the items (Expiration from the “proxy” items for example)

2 - I modified the rules as follow, one for each of the 4 PIR i have with different timers (Timer_Bayes_1, Timer_Bayes_2 etc.)

rule "Bayesian PIR Bagno Grande"
when
    Item MQTTESP_PirBagnoG changed from OFF to ON
then
    if(Bayesian_Pir_BagnoG.state == OFF) {
		Bayesian_Pir_BagnoG.sendCommand(ON)
        Timer_Bayes_4 = createTimer(now.plusMinutes(timeoutMinutes)) [|
            Bayesian_Pir_BagnoG.sendCommand(OFF)
			Timer_Bayes_4.cancel
            Timer_Bayes_4 = null
        ]
    }
    else {
        Timer_Bayes_4.reschedule(now.plusMinutes(timeoutMinutes))
    }
end

In my implementation
PIR_itemname = Pir phisical sensor item linked to mqtt channel
Bayesian_PIR_itemname = Proxy item

please look at the graph. , these is a good example because i have two wired events very near in time, but seems to be full of the same kind of error. I can recognize it expecially during sleep time because the pir should stay OFF all the night…

A situation: How is possible that PIR sensor send ON command but Proxy did not follow the rule provided ???

B situation: How is possible that no-one command manually the PROXY item on but it goes on without the PIR sensor read noting???

C situation is what I expect every time to see

Do you have any Idea ?
Thank you very much

Your rule only triggers when MQTTESP_PirBadnoG changes from OFF to ON. When it changes from ON to OFF or any other transitions the rule doesn’t know.

If the Item was already ON, the rule won’t run, the timer won’t be scheduled nor will it be rescheduled.

You don’t show the events.log showing the events on these Items so :shrugging. How do you know that the PIR sensor read nothing? What’s the Timer doing? Add logging to find out.

Compare what events occur on the Items and add logging to the rule and compare those between the places where it works and where it doesn’t work.

You should use one rule to handle all your PIRs.