Preventing False Positives using Rules

[hardyh (Hardy Haase)]

I wasn’t really able to find anything specific, perhaps using the term false positive in the title will make it easier in case others are looking for an answer too. My PIR motion sensors tie into the system using a rule I found somewhere in here, and everything works well except that the PIR occasionally has a false positive and signals the lights on when they aren’t needed. That’s not a big deal in the basement but I would like to add similar setups in more sensitive areas of the house where random light activity would be less acceptable. Any suggestions on how to filter out the false positive - like only responding to the second motion sensed within a certain time span? Any suggestions would be appreciated.

Here is my current motion sensor rule

rule "basement light motion"
when
Item Motion2 changed from 0 to 1
then

    if (basement_timer != null)
    {
        basement_timer.reschedule(now.plusMinutes(basement_timeout))
        logInfo("basement","basement timer rescheduled for " + basement_timeout + " minutes")

	{
		sendCommand(StartCountdown,ON)
		
		
    }

    }
    else
    {
				
				sendCommand(Light_Hue_9,ON)
				sendCommand(Light_Hue_10,ON)


				logInfo("basement","basement timer create with " + basement_timeout + " minutes")
        basement_timer = createTimer(now.plusMinutes(basement_timeout))
        [|
            if (Motion2.state ==  1)
            {
                basement_timer.reschedule(now.plusMinutes(basement_timeout))
                logInfo("basement","basement timer triggered, but rescheduled again for " + basement_timeout + " minutes")
            }
            else
            {

				sendCommand(Light_Hue_9,OFF)
				sendCommand(Light_Hue_10,OFF)



                basement_timer = null
            }
        ]
    }
	
	
end

[lipp_markus]

Not sure that will be an easy solution to this. You could look into the following options:

1. test a few other brands of PIR to find one that delivers more reliabel results
2. add a second PIR and only trigger if you get signals from both
3. only trigger if you get a second signal within a preset time(your proposal)

In general, all systems will show false positive (system triggers, without movement) and false negative signals (system does not trigger despite bonafide movement).

Option 1 above does not guarantee results and can take quite some time, but maybe a good way to go about if you are willing to spend the time and money.

Option 2 obviously doubles the costs/number of sensors; and you will have to place both sensors carefully to avoid situation where only one sensor picks up movement (and the other for example is too far away).

Option 3, slows the response of your system, depending on how long you wait for the confirmatory signal; if it is milliseconds, you may not notice, if it is seconds you will notice. You would need to perform quite some testing on your system to capture its behaviour, for example, how does the false positive signal look like, one spike, several spikes, how long does the signal last. How does your sensor indicate real movements? One signal, bursts of signals…how long does your signal last and when is your sensor ready to send out another signal (which would determine the wait time). Where do you put the sensor and how sensitive is your sensor to pick up slow movements etc.

It will likely require some experimentation to determine what works best for you, to limit the times where it goes on without movement (false positives) and at the same time the equally annoying effect of the system not triggering (or too slowly triggering) when you want it to switch on lights.

If you go with option 3, you may want to look at posts that deal with debouncing switches, timers and latches. For example here:

Design Pattern: Rule Latching

This design pattern is not my own but I cannot find the original post that describes it to give credit to the right person. Problem Statement Sometimes one wants to make sure that only one instance of a Rule is running at a given time. For example, when a rule is triggered by a Group Item’s receiving updates, the Rule gets triggered more than once per event. Another use is if one needs to implement debouncing. Concept Use a ReentrantLock and require the Rule to acquire the lock before runnin…

if you search for debouncing you will find a several approaches.

Or just a timestamp technique, for example here:

This is also called “debounce” and if you search the forum for that you will find lots of other posts. There are a ton of ways to implement it besides ReentrantLocks. For your use case I would probably recommend just using a timestamp. var lastRing = now rule "Doorbell" when Item Doorbell received command then if(lastRing.isBefore(now.minusSeconds(30)) { // make the doorbell sound/alert lastRing = now } end This way doesn’t depend on finiky locks nor does it req…

[hardyh (Hardy Haase)]

Thanks, I have seen some posts about debouncing and wasn’t sure if that was appropriate for this situation - I got the impression they we’re for avoiding activation of the same rule twice not so much double checking that the rule should actually be activated in the first place. I will give those suggestions a try first! I think for now having the sensors only affect change on secondary lighting during the normal sleep hours might be a good start.