Ah, thanks, now it's clear.
This ^^^
2 Likes
Have you looked at the False Motion Reduction zone type?
That's what I suggested, but he evidently only has one sensor in each room.
1 Like
All correct. One sensor per room prevents me from using the option specifically named for what I want to do. I.e reduce false motion alerts.
I guess I can buy new sensors. It's just annoying since this change seems like it would be a small change to ignore the initial trigger device for say 20 seconds.
I'm assuming a real intruder would go to more than one room
One key point which I feel has not been mentioned.
When a motion sensor detects motion, it becomes active.
It changes from active to not active, (assuming there has been no more motion), in X seconds, where X is motion sensor dependent. If the subject has gone from room a to room b in less than X seconds, then you won't get motion sensor in room a to be active for more than X seconds.
With some (very sophisticated) sensors, you can vary X is (e.g. the Aeotec Multisensor 6, with the right driver).
Perhaps this will help in your analysis.
That is also what I was trying to achieve by having Zone Motion setups for each sensor, so you could control the X value, regardless of the physical sensor options. But that didn't solve the requirement for an initial sensor firing and their being a timeout where another sensor needed to fire, where the trigger sensor could be any one in the group.
Thanks @sburke781 and @jtmpush18 for the comments! I appreciate the discussion.
- I'm not worried about the "trigger" sensor being triggered again during this whole "Zone Activated" green time frame
- As @sburke781 mentions, a key here is "the trigger sensor could be any one in the group"
- programmatically, in the app it should be easy to know which device was the trigger device in the group and ignore it (either for the entire "Zone Activated" green timeframe, or for some number of seconds)
- the key for a home intrusion detection using motion sensors in my opinion is seeing more than one trigger in say 5 minutes.
- I think many people would like to avoid having 2 sensors per small area/room to save $$
- PIR (passive IR) falses aren't necessarily just "cheap" sensors. Just search "does PIR false" and see the examples like Five Causes of PIR False Alarms - ACT Meters (UK) Ltd
@mike.maxwell is there someone from Hubitat here that can comment about adding this option to "ignore trigger device" can be added to the built in app? I'd be happy to be a Beta tester. 
i guess i don't get it, isn't ignore trigger device effectively the same as not including the sensor in the zone in the first place?
I guess I'm not following the use case.
1 Like
/on soapbox
Above is the root cause of your issues, IMHO, and should be reason enough to replace your existing sensors, or at least augment them w/additional sensors that are reliable. Especially if your key use is home security (which is not really a recommended use for HE, it is not a purpose-built Home Security system). But if you want to use HE that way, investing in sensors that are reliable should be your first step, not adding work-arounds to SW to try to fix HW problems.
/off soapbox
You can get reliable Third Reality sensors, really long battery life, well loved by users here, for $16. Cheap as chips...
https://www.amazon.com/THIRDREALITY-Friendly-Required-SmartThings-Devices/dp/B08RRRWK6B/ref=sr_1_2
2 Likes
Hi @mike.maxwell, thanks for the quick reply. Let me try to outline the use case:
- setup hubitat built in app for home intrusion, using motion sensors and contact sensors
- motion sensors are at most 1 per room, say Garage, Kitchen,Basement,Bedroom
- Since the owner isn't sure where the intrusion will start to occur, all 4 motion sensors are in the "Trigger Device" set
- Since there are not redundant sensors in each of those 4 areas (i.e. 8 sensors) the current app has no way to avoid a single false trigger of a single motion sensor (because it is the "trigger" and then a motion sensor in the zone motion sensors)
- PIR has a false event (we can discuss this later @danabw) due to some dust/bug/sunlight in the Kitchen
- This is the only false PIR firing that day/week, no intruder was in the house
- Owner is alerted by the built in app and has to check, cancel alerts, etc (annoying or worse)
The issue is per the earlier chart:
if the trigger is ALSO a motion sensor (say "motion 1") then when the trigger enables the green zone to happen, then motion 1 is already active and triggers the alert.
I would like to understand if it's as trivial as I am thinking to adjust the app, to just ignore the trigger device in the green zone alert time window.
@danabw thank you for the soapbox open and close. I do agree that we must always question everything in the whole system. And many times there are different solutions to a problem with different trade offs. In this case, IMHO, it feels like a simple solution in the software that can help all users, regardless of the sensor quality they bought
It might be an easy change but HE would need to prioritize it over other work. That can be a tough call when there are already plenty of proritized/planned new features and existing defect fixes to deal with.
At the risk of coming off maybe a bit pedantic/didactic 
, I still think that using sensors that are known to be unreliable in a security application seems like starting off on the wrong foot. I do get it that we all have our own patience/budgets for adding or replacing devices in our home.
Maybe Mike will see it your way.
1 Like
Ok, I decided to just write this myself. Here is an early version that I need to beta test now.
TLDR: it only uses the activate events from motion sensors, and therefore the motion sensor that ends up triggering the "activation window" to start does not INSTANTLY also trigger the "activity" state which is a virtual contact sensor.
This app should give me what I was looking for:
- can use any number of PIR motion sensors
- can use any quality of sensors
- can use <= 1 sensor per room
- can adjust the "activation window" timing in minutes
- can adjust the timeout (in minutes) on the end result "flag" (virtual contact sensor) that would be used in the built in hubitat intrusion alarm app
Note: this app replaces the "zone motion controller" app completely for me.
I will send any updates/bug fixes here after I do enough beta testing.
Thanks all for the great discussion and help!!
(And thanks to my offline friend John G. for a quick IM chat that prompted this approach)
definition(
name: "Prevent False Motion Alerts",
namespace: "hubitat",
author: "Justin Eltoft",
description: "Require multiple motion sensor events in specified time before alerting of intrusion",
category: "Security",
iconUrl: "",
iconX2Url: "")
preferences {
page(name: "mainPage")
}
def mainPage() {
dynamicPage(name: "mainPage", title: "Prevent False Motion Alerts (ver:0.13)", install: true, uninstall: true) {
section {
input "thisName", "text", title: "Name this Alert", submitOnChange: true, defaultValue: "Prevent False Motion Alerts"
if(thisName) app.updateLabel("$thisName")
input "motionSensors", "capability.motionSensor", title: "Select Motion Sensors", submitOnChange: true, required: true, multiple: true
input "alarmSensor", "capability.contactSensor", title: "Select Virtual Contact Sensor as Intrustion Alarm Flag", submitOnChange: true, required: true, multiple: false
input "activityTimeoutMinutes", "number", title: "Activity Timeout (Minutes):", defaultValue: 5, submitOnChange: true, required: true
input "activationWindowMinutes", "number", title: "Activation Window (Minutes):", defaultValue: 15, submitOnChange: true, required: true
}
section("Debug") {
input "debugLog", "bool", title: "Enable Debug Logging:", defaultValue: false, submitOnChange: true
}
}
}
def installed() {
initialize()
}
def updated() {
unsubscribe()
initialize()
}
def uninstalled() {
unsubscribe()
deleteChildDevice("PreventFalseMotionAlerts_${app.id}")
}
def initialize() {
state.activityTimeout = 0
state.activationWindowTimeout = 0
def multipleMotionDev = getChildDevice("PreventFalseMotionAlerts_${app.id}")
if(!multipleMotionDev) multipleMotionDev = addChildDevice("hubitat", "Virtual Contact Sensor", "PreventFalseMotionAlerts_${app.id}", null, [label: thisName, name: thisName])
multipleMotionDev.close()
if (debugLog) log.debug "PFMA: ---------------------------------------"
subscribe(motionSensors, "motion", handlerMotion)
}
def handlerMotion(evt) {
//if (debugLog) log.debug "PFMA: motion event $evt.device $evt.value"
if (evt.value == "active") {
handleMotionEvent(evt)
}
}
def handleMotionEvent(evt) {
def multipleMotionDev = getChildDevice("PreventFalseMotionAlerts_${app.id}")
// check if we're already activated for multiple motion
if(state.activityTimeout != 0) {
if (debugLog) log.debug "PFMA: motion when active : ${evt.device}"
// set flag for any motion in triggered state
multipleMotionDev.open()
// reset the timeout
state.activityTimeout = now() + (activityTimeoutMinutes * 60 * 1000)
// set timer to check if activity timeout passed
runIn(60 * activityTimeoutMinutes, timerHandler)
} else if ((state.activationWindowTimeout != 0) && (now() <= state.activationWindowTimeout)){
if (debugLog) log.debug "PFMA: motion during activation window : ${evt.device}"
// set "flag" that multiple motion events seen during activity window
multipleMotionDev.open()
// reset activation window now that we're activated
state.activationWindowTimeout = 0
// enter activity timeout period
state.activityTimeout = now() + (activityTimeoutMinutes * 60 * 1000)
// set timer to check if timeout passed
runIn(60 * activityTimeoutMinutes, timerHandler)
} else {
if (debugLog && evt != null) log.debug "PFMA: motion to enter activation window : ${evt.device}"
state.activationWindowTimeout = now() + (activationWindowMinutes * 60 * 1000)
// close the flag (should be already) since we weren't already triggered
multipleMotionDev.close()
}
}
def timerHandler() {
def multipleMotionDev = getChildDevice("PreventFalseMotionAlerts_${app.id}")
if (state.activityTimeout != 0) {
if (debugLog) log.debug "PFMA: timer handler (activity timeout)"
if (now() > state.activityTimeout){
if (debugLog) log.debug "PFMA: activity timed out"
state.activityTimeout = 0
state.activationWindowTimeout = 0
multipleMotionDev.close()
}
} else if (state.activationWindowTimeout != 0) {
if (debugLog) log.debug "PFMA: timer handler (activation window timeout)"
if (now() > state.activationWindowTimeout){
if (debugLog) log.debug "PFMA: activation window timed out"
state.activityTimeout = 0
state.activationWindowTimeout = 0
multipleMotionDev.close()
}
} else {
// all zero, set "flag" closed just in case
if (debugLog) log.debug "PFMA: timer event with no timeouts"
multipleMotionDev.close()
}
}
I may add the ability to name how many sensors are required to activate this. I think 2 (as this does) is probably the safest to use though.
1 Like
Yes. Motion can be a trigger. I have two zones , bothe use only motion sensors. This works very well.
If you want it to.
Thanks @lcw731 but the second question was my main problem which has now been solved by writing a custom app (see above). So far testing seems good.
1 Like
Just tested this for the first time from being away for 2 days and it worked as expected. I can see the laundry room sensor triggered 7 times (one of those times there were two close enough to reach the second stage of this app) during this period, sometimes at night. Unless that was a headlight ambient light trigger this sensor seems to just fire randomly sometimes. I'll have to design a test to determine that later.
For now though, the above app worked as expected. Here below is the one time it entered the second stage, where the first motion entered the activation window. The second motion then triggered the virtual switch that flags the app as ready to alert, and then there were no more motion for the next 5 minutes so that second stage alert timed out.
See
- 2023-09-01 09:48:13.825 PM debug PFMA: motion to enter activation window : Motion laundry
- 2023-09-01 09:52:38.311 PM debug PFMA: motion during activation window : Motion laundry
- 2023-09-01 09:52:38.324 PM info Prevent False Motion Alerts was opened
- 2023-09-01 09:53:27.880 PM info Motion laundry is inactive
- 2023-09-01 09:57:38.562 PM info Prevent False Motion Alerts was closed
So this requires at least three sensor random events to happen within 5 min for the first 2 and then the third within the 15 min for the last one. (or whatever you set those two values to instead of the defaults)
Just came to say:
-
Good on you for working up a solution
-
Your use case and initial feature request is totally valid
There are security system and device manufacturers that have explicitly addressed the case you outlined. Visonic is one where in fact you can adjust sensitivity right onboard the motion sensor through a dip switch or jumper.
For the sake of cost many Home Automation device manufacturers overlook these "real world" features that make a significant difference to reliability and usability.
Often it is NOT merely a "cheap sensor" that is the problem. It could be an expensive sensor in a challenging environment; (case in point - no other mounting location besides where the sun hits once a day for an hour or so).
While we can say HA and HE is not for Security, increasingly HA in general IS serving roles in this mission.....AND EVEN IF....we aren't talking security it is without a doubt that many of us push the limits of some of these sensors in environments or use cases where a simple "ignore this device's initial triggering until/unless x, y, or accompanied by z" would be VERY helpful to manage "false-ings".
Furthermore, "adding another sensor" to said environment to create a zone might not be desired (there's enough batteries to change as it is) or practical. A software feature allowing for the desired outcome is indeed logical.
Just wanted to validate your initial request. Like many things in the HE space others will eventually encounter a need for it....and it wouldn't surprise me in the least to see the functionality built-in sometime in the next couple of years... despite the contention exhibited.
1 Like
