Motion sensor items

Tags: #<Tag:0x00007f2fb26d1670>

I have been working on my motion sensor rules. I have found a small conflict and wanted to see how everyone else is setup.

my motion sensor (build using mysensors) is done in such a way that it only sends a “motion detected” message to openhab when it goes from 0 to 1.

Using the design patterns that means my expire timer starts when motion is detected and 10 minutes later it turns the lights off. However, if someone has been moving around the whole time, the PIR motion sensor is still at high/1 and hasn’t changed. So now, there is motion and the lights are off.

So my question, are the motion sensors everyone else is using constantly republishing their state? How frequently?

Or are you starting the timer when the motionsensor itself turns off?

PS. fixing this will have a very high WAF lol

I can relate! I have a similar struggle now.
I have a sensor set up. I used the expire binding to set up a timer. If motion is detected within that time, the timer gets reset.

Item:
Switch MyTimer { expire="5m,command=OFF" }
Rules:

rule "Papillon Motion On"
when
    Item Papillon_Motion changed from OFF to ON
then
    Papillon_Light.sendCommand(ON)
    // start Timer
    MyTimer.sendCommand(ON)
end

rule "Papillon Motion Off"
when
    Item MyTimer changed from ON to OFF
then
    Papillon_Light.sendCommand(OFF)
end

Does your keep sending the ON state? Mine isn’t. I think that is my problem. So I have a new firmware i modified ready to go on that mysensors module to send the current state every 30 seconds or so. Just not sure if that’s how every one elses is doing it.

My zwave sensor is configurable. I think I have it check once a minute after motion is detected.

1 Like

That’s what i was wondering :slight_smile:

Im guessing that’s how alot of them are done.

So I have 2 options,

  1. leave it like it is, and have it start the timer when the PIR goes low.
    Pro - less communication back and forth and only really sending updates on state change
    Con - have to rewrite my rules a bit

  2. have it send regular state
    Pro - will just work with current rules setup
    Con - will be sending the same status update over the RF every 30 seconds instead of on state change

Any thoughts?

Most commercial motion sensors activate for just a few seconds on detection, then deactivate. They might retrigger quickly afterwards, if motion is still present. Or they might not - sometimes there is an adjustable “blanking time” to prevent re-triggers for a period.

But there’s nothing wrong with having a sensor like you have, that sends “trigger” and then stays that way until motion stops.
If you configure your rules properly to handle that e.g.
When triggered - turn on light without timer.
When trigger stops, begin the off-timer
If triggers while timer running, cancel timer.
If timer runs to end, light off.

The only “useless” (for this purpose) kind of sensor would be one that sends only a “trigger start event” i.e. either no “trigger stopped” or “still triggered” events.

1 Like

I may end up doing 2 design patterns. Because I can actually see a useful need for both. If there is a motion sensor that is battery powered. Only sending on state change would extend the life of the battery. Where as full time powered ones might not be as much of a concern.

Atleast I know now what was causing some of my issues.

Hi,

I use the expire binding for the time delay. ( 5 min in my case ). And send a post.update (off) to the motion sensor direct after trigger. So a new motion will always trigger my rule again, even when the motion is all the time.

Hmmm with some testing i think that is how i am going to have to go.

Right now I have it triggering the timer when no motion is detected. However, if you walk back in the room, motion is detected again, but the timer is still going. so if you keep moving, the motion detector doesn’t send a “no motion” again so the timer just keeps counting down and will turn off.

So I think i need to go back to working on triggering when motion is detected and resetting regularly.

Thanks for the feedback!

Jason
First, I’m glad that you realized sending a state update every 30 seconds will kill battery powered devices. Second, let me ask a question. Are you using timers or the expire binding? The expire binding automatically resets the timer every time it receives any command other then OFF. I think timers can do the same thing but not without some fiddly coding.
With you sensors, I think starting the timer when ever motion stops is the way to go because when motion stops is when you really want to wait for a few more minutes and if no motion has occurred, turn off the lights. But with the expire binding, sending the switch (which is configured with expire binding) anything other then OFF resets the timer, even ones or zeros should restart it.

Rich has a Design Pattern somewhere made for this exact situation

And maybe you already know about the expire binding but if not go here

I am using that design pattern and the expire binding :slight_smile:

I did not realize that it was that easy to reset. But I am guessing no way to cancel it without actually flipping that switch to off.

Why should you cancel it`?

No no Jason cancelling the expire binding is as easy as postUpdate OFF to the switch item
easy

Wow, maybe that should be made more clear in the doco

sending the expire binding anything OTHER THEN OFF restarts the timer
sending the expire binding OFF kills timer

Kim
What if some other operation turned the light off already? Like the switch was flipped manually. What if your presence detection just triggered because you walked out the door? What about cascading timers that trigger other timers? What about a hundred other scenarios, the power of the expire binding is it’s utilitarian simplicity

Yes. You need to change your rule structure. Have a rule triggered on “motion begins” that looks to see if the off-timer is running, and if it is then cancel it.

This is the way to go for minimum transmissions from your sensor; just “begin” and “end” needed. Your rules take different actions on each of those.

If you use something like expire=“5m, command=OFF” then you can’t cancel it without turning the light off (or the Item supposedly representing the light. at least)
You can reset/restart it by sending ON. For that to work here you would need periodic motion triggers.

1 Like

First, I would suspect the presence detection acting as it´s suppose to, and the timer is sat for its purpose as well. Then I fail to see why anyone would cancel it.
On my motion detection timers, I´ll just let it run out. It is their purpose. I do not have a switch to turn off lights which is controlled by a timer.
I do however have a switch to turn on the light manually, (without the timer on), in case I need light longer than the timer is set to, without having to run infront the the motion sensor all the time. Thats in my garage. It´s a simple switch which just turn on the light without a timer. (Logic is inside my IHC controller though, but the principal is the same, and should be easy to do with openhab as well).
Another way is to have more motion sensors covering the different part of the area, and triggering the same light and timer.

You probably want to postUpdate so your cancelling the expire binding doesn’t also turn off the device or something. That’s how the design pattern does it. Expire is configured to send command OFF and to cancel use postUpdate.

1 Like

good catch Rich, that is what I meant to but dumb
Thanks updated my post in case folks find this thread later

1 Like

That right there may have been the key :slight_smile:

I have actually found (for my use) timers on lights only work in a few situations.
Typical situation where it works good:
in a closet or other room where you don’t actually spend time. Example, I go in my closet, motion sensor triggers light, I’m in there for a minute or two and a minute or two later, timer shuts it off. This is especially cool because the closet light is always a prime example of a light that often gets left on mistakenly (wasting electricity) or left on for longer then needed. Bathroom lights sort of fit this description as well but with a twist. If I get up in the middle of the night and go in there, and the light comes on automatically (very dim so it doesn’t blind me) it is nice to be able to see without having to grope for the switch in the dark. It stays on long enough to help me find my way back to bed. But when I go in to take a shower, I turn on a light manually so it doesn’t go out while I’m showering. Laundry room, pretty good but I found a door switch better, open door, light goes on, close door, light goes off. This works because for me the only time I need a light on in there, the door is open. When I walk out, I close the door unlike the closet and bathroom door which often are left open
What I have found in main rooms where I spend time, timers are less useful. If you set the timer to a long enough time where you aren’t going to have it shut off on you because you are sitting still, reading, watching the tube, whatever, the timer is so long it takes way to long to go off after you have actually left the area (went to bed)

That is actually good advise and I do the same, in larger areas, more sensors help.
What works for me is good presence detection. I use the wasp in box method If I am home and it is dark (night) leave the lights on and if the system detects I have left or go to bed (motion sensor in bedroom picks me up) shut off the lights.