Understanding Motion Senor Timeout Functionality

JsChiSurf · January 27, 2016, 3:11pm

Hi All,

I have a “problem” that has vexed me for quite some time and and wondering if I am just “doing it wrong”.

I have 2 different z-wave motion sensors in the house used for similar, but different, purposes. Though they are different “brands”, I have a similar “problem” with both. One is a mono-price generic motion sensor, the other, an Ecolink.

One sensor turns a light on when motion detected during the nighttime, and then turns off when the device is “untripped” (trigger).

The other sensor is used simply to turn off a light when it too is “untripped”, as it is in my daughter’s room who never shuts off her light when leaving her room. So, it is only used to turn things off, but not on.

The problem I am having is that it would appear that each motion sensor gets untripped, based on when motion is initially detected, so that any additional / continued motion does not “extend” the trip time, and as such, the lights always turn off, it would appear, after the initial trip timeout occurs.

This, as you can imagine, drives my wife and daughter crazy, since the lights turn off of them even though they are up and active in the location where the motion sensors are present.

Is this “just the way it is”, or is there a different way to go about this, so that continued (not just initial) motion in a room continues to extend the timeout from the last motion detected, not, what it would appear, the initial?

Hope that makes sense.

Chrisfraser05 · January 27, 2016, 3:32pm

You need to have a look at the “blind time” on your devices parameters.
You can get this from your instruction manual.

I had a similar issue on one of my sensors.

I turned both the tripped time and blind time right down, so the device only stays tripped for 1 second and is blind for 5 seconds before it can trip again.

I then use a timer which retriggers (pleg) each time there is motion.
If no motion is detected after 30 mins my lights turn off

JsChiSurf · January 28, 2016, 12:05am

Thanks for the reply.

At least this confirms the behavior is as expected.

Unfortunately, my Ecolink (which the monorprice is also a clone of), does not allow you to modify the reset times as far as I can tell (http://forum.micasaverde.com/index.php?topic=27628.0).

Based on this understanding though, instead of turning the lights off on the “untripped” trigger, which always occurs after a fixed 4 minutes, I’ve switched to instead, querying the sensor for the last_tripped time, every X minutes via a scheduled job, and if the last tripped time exceeds, for example, 15 minutes, bank that the room is empty, and shut the lights off if they are on.

dawgbone · January 28, 2016, 6:25am

I tried the opposite with a scene of motion not detected, and with time restrictions…
As of now, it does not appear that time restrictions work… I’ve asked MiCasa about it over a week ago, and they have yet to get back to me…

And yes, EcoLink motion detectors are as good as 5 seconds for reset with test mode enabled(in which they work best, and have lasted years for me)…

I’ve used this borrowed code with “decent” results with my carport lights… and I’m somewhat happy with the results, and it doesn’t appear to cost battery life…

[code]local sensorDeviceNo = 118 – Motion Sensor device number
local lightDeviceNo = 108 – Light device number
local period = 75 – Seconds

local SS_SID = “urn:micasaverde-com:serviceId:SecuritySensor1” – Security Sensor Service ID
local SP_SID = “urn:upnp-org:serviceId:SwitchPower1” – Switch Power Service ID

function checkLastTrip()
local lastTrip = luup.variable_get (SS_SID, “LastTrip”, sensorDeviceNo) or os.time()
if (os.difftime (os.time(), tonumber (lastTrip)) >= period) then
luup.call_action (SP_SID, “SetTarget”, {[“newTargetValue”] = 0}, lightDeviceNo) – Turn off the light.
else
luup.call_delay (“checkLastTrip”, period) – Check when the sensor was last tripped every seconds.
end
end

luup.call_delay (“checkLastTrip”, period)

return true [/code]

The problem is, that if you read the EcoLink’s docs, there HAS to be “some” time(not defined) of zero motion, for it to reset, regardless… Which makes it pretty much useless for occupancy detection…
https://support.smartthings.com/hc/en-us/article_attachments/200698694/Ecolink-PIRZWAVE2-ECO_manual_rev1.pdf|

JsChiSurf · January 28, 2016, 1:23pm

[quote=“dawgbone, post:4, topic:190805”]I tried the opposite with a scene of motion not detected, and with time restrictions…
As of now, it does not appear that time restrictions work… I’ve asked MiCasa about it over a week ago, and they have yet to get back to me…

And yes, EcoLink motion detectors are as good as 5 seconds for reset with test mode enabled(in which they work best, and have lasted years for me)…

I’ve used this borrowed code with “decent” results with my carport lights… and I’m somewhat happy with the results, and it doesn’t appear to cost battery life…

[code]local sensorDeviceNo = 118 – Motion Sensor device number
local lightDeviceNo = 108 – Light device number
local period = 75 – Seconds

local SS_SID = “urn:micasaverde-com:serviceId:SecuritySensor1” – Security Sensor Service ID
local SP_SID = “urn:upnp-org:serviceId:SwitchPower1” – Switch Power Service ID

function checkLastTrip()
local lastTrip = luup.variable_get (SS_SID, “LastTrip”, sensorDeviceNo) or os.time()
if (os.difftime (os.time(), tonumber (lastTrip)) >= period) then
luup.call_action (SP_SID, “SetTarget”, {[“newTargetValue”] = 0}, lightDeviceNo) – Turn off the light.
else
luup.call_delay (“checkLastTrip”, period) – Check when the sensor was last tripped every seconds.
end
end

luup.call_delay (“checkLastTrip”, period)

return true [/code]

The problem is, that if you read the EcoLink’s docs, there HAS to be “some” time(not defined) of zero motion, for it to reset, regardless… Which makes it pretty much useless for occupancy detection…
https://support.smartthings.com/hc/en-us/article_attachments/200698694/Ecolink-PIRZWAVE2-ECO_manual_rev1.pdf|[/quote]
Yep, the above is essentially the same, in concept, for what I just converted (resorted) to, to have this behave as I want (desired in the first place). I’m glad I asked the question though, just to confirm I wasn’t crazy, though, I don’t necessarily like the answer

I had already written some basic scripts to loop through an array of all my motion sensors and tell me when the last tripped time was for them, and if any were within X minutes, I know if the house is occupied, etc (motion somewhere on some floor, etc), so I just adapted that code to use for the lights off when nobody there as well.

Of course, IMHO, none of this would be required if the motion sensor would just stay in the tripped state as long as motion continues to be detected.