Sorry, I’m new, I’ve tried to read as much as possible but it’s not clear to me how to properly setup a motion sensor. Should I set the item to be a switch or a contact or something else? So far I’ve configured mine as switches. But the PIR’s I own emit a trigger signal (movement detected) and then do not emit anything until they detect more movement. So if configured as a switch it sends an “ON” signal but never an “OFF” one…
Would appreciate any help on this issue.
I don’t have a PIR and not coded this yet, but I would probably set the item to be a Contact but trigger my rules on “received update” instead of “changed” or “received command”. That way even though it gets set to the same thing over and over it will still trigger the rule. To show it on the sitemap I would probably create a proxy Contract item that gets set to OPEN from the “received update” rule and a timer that sets the proxy back to CLOSED after a certain period of time without receiving an update. Then use the proxy item in your sitemap and anywhere else that wants to know whether the PIR has recently been activated.
Items:
Contact Pir_Sensor ...
Contact Pir_Proxy ...
Rule:
var timer = null
rule "Handle PIR Events"
when
Item Pir_Sensor received update
then
if(timer == null || timer.hasTerminated) {
Pir_Proxy.sendCommand(OPEN)
timer = createTimer(now.plusMinutes(5) |
Pir_Proxy.sendCommand(CLOSED)
timer = null
)
}
else {
timer.reschedule(now.plusMinutes(5))
}
end
Sitemap:
Text item=Pir_Proxy ...
NOTE: Obviously you need to replace the “…” with your parameters and binding stuff.
1 Like
I have multiple PIR’s.
Set as a CONTACT.
Motion sensors generally are in OPEN | CLOSED state. They also are not continuous sensors. Once they go to OPEN…there are not continuous updates on state. Most have a non-configurable timeout – when they change to OPEN, they are insensitive to additional movement during that timeout period. When the timeout expires, they switch to CLOSED state, but are again sensitive to motion.
1 Like
Thank you guys! Indeed, contact seems to work better, as @rlkoshak said listening to ‘received update’ is what’s needed, and it needs to be reset after some period of time (or the proxy) in order to use it in rules.
I have never tried to sendCommand to a motion sensor (or a proxy which passes thru to a motion sensor). Does this actually work ? I’m a big fan of PROXY’s for things which are manipulable (switches, dimmers) for intercepting state change commands at execution time. I don’t use them for sensors which are read-only.
Here’s what I mean…my PIR’s have a natural timeout of about 4 minutes, meaning they go OPEN when motion is detected, stay OPEN as long as there is relatively continuous motion, then after 4 minutes of no motion they go CLOSED. (The 4 minutes is not a configurable option.)
Here are my working rules for the relationship between the PIR motion sensor in my kitchen and the kitchen light.
(Note that there are other events in the house which can setup an OFF timer (t_03 in rules below) and they may do so with a much longer OFF timer setting. So there is some guard logic in these rules to allow for intercepting such things if motion is detected)
rule "MO_1: Events when motion in Kitchen trips"
when
Item mo_MOTION_Kitchen changed to OPEN
then
logInfo("KITCHEN","MO_1 : Kitchen Motion Sensor changed to OPEN ")
if (sw_LIGHT_Kitchen.state == OFF) {
/ /if light was off, turn cancel any extant timers and turn it on due due to motion
logDebug("KITCHEN","MO_1 : Turning Kitchen Light ON due to Motion Trigger")
t_02=createTimer(now.plusSeconds(1)) [|
sendCommand(sw_LIGHT_Kitchen_PROXY,ON) ]
logInfo("KITCHEN","MO_1: Motion Kitchen turning light ON")
} else {
logInfo("KITCHEN","MO_1 : LIGHT Kitchen is already ON")
}
if (t_03 != null) {
logInfo("KITCHEN","MO_1 : Extant Kitchen Light OFF timer being CANCELED...")
t_03.cancel()
t_03=null
} else {
logInfo("KITCHEN","MO_1 : [No Kitchen Light OFF Timer Available to Cancel]")
}
end
rule "MO_2 : events when mo_MOTION_Kitchen changed from OPEN to CLOSED"
when
Item mo_MOTION_Kitchen changed from OPEN to CLOSED or
Item mo_MOTION_Kitchen changed from Uninitialized to CLOSED
then
logDebug("KITCHEN","MO_2 : mo_MOTION_Kitchen has changed to CLOSED")
if (sw_LIGHT_Kitchen.state == ON) {
if (t_03 != null) {
logDebug("KITCHEN","MO_2 : Kitchen Light extant OFF timer being rescheduled....")
t_03.cancel()
t_03=null
} else {
logDebug("KITCHEN","MO_2 : Kitchen Light OFF timer being created....")
}
t_03=createTimer(now.plusSeconds(10)) [|
sendCommand(sw_LIGHT_Kitchen_PROXY, OFF) ]
} else {
//LIGHT IS OFF when motion sensor resets -- likely due to manual operation or initialization
if (t_03 != null) {
logDebug("KITCHEN","MO_2 : Kitchen Light extant OFF timer being cancelled because light is already OFF....")
t_03.cancel()
t_03=null
} else {
logDebug("KITCHEN","MO_2 : No Kitchen LIGHT timer OFF exists to cancel....")
}
//DO NOT CREATE A TIMER IF THE LIGHT IS OFF
}
end
My motion sensors are cheap rf 433 MHz and they only send info when triggered, there’s no ‘closed’ command. They can be tweaked with jumpers so that they will not emit a new trigger for 5s, 50s or 5m (saves battery). When you send a close command to the device, you’re actuating telling the openhab switch or contact to go back to closed state, the device will not be receiving anything. I guess using a proxy is “cleaner” because there will be no rf transmission. Again, I’m new to openhab and I may be wrong…
So your detector is powered up. Motion happens, it squirts a signal (which you trap as a contact OPEN event), then device is jumper-controlled as to next available time to squirt a signal IF motion is happening then, but it does not send a signal when that time has passed as a CLOSED event. And you are using the timer as an artificial signal for the CLOSED event, resettting the timer if it receives a new OPEN event before timing out.
This correct ?
In this case the Proxy Item is acting as a proxy for the data coming from the sensor. As far as I could tell there was no data going to the actual PIR. Perhaps the use of the name “proxy” for this sort of sensor as opposed to actuator is confusing but I can’t think of a better name right now. Open to suggestions…
That was my understanding of how his PIRs worked and was what drove my suggested approach. It basically implements the same behavior your PIRs have natively with the 4 minute timeout in a rule. So the Pir_Proxy converts all the OPEN signals into a nice smooth OPEN/CLOSED.
BTW, I’ve been using more proxy Items in my rule set after reading your previous posts. It makes certain thorny problems pretty clean.
There shouldn’t be any RF transmission if you skip using the Pir_Proxy and I suppose it is possible to implement this without the proxy item. At the time I wrote my suggestion it felt better to me to accumulate the Pir_Sensor state which could be receiving all sorts of updates based on your motion into a proxy for that item which only updated or changed to OPEN once until the timer triggered to set it back to CLOSED. My thinking was it might make other rules which depend on whether the sensor is OPEN or CLOSED a little easier to manage.
Though, after a night’s sleep I’m thinking that if you just use “Item Pir_Sensor changed” as the trigger instead of received update in the other rules you don’t need the Pir_Proxy.
That’s why I asked my question about his operations. While I don’t use proxies for sensors which report state changes in either direction (OPEN and CLOSED), if his sensor only reports the equivalent of an OPEN event, this might be a case where the PROXY is useful. Event (OPEN equivalent) happens - he traps it, sets the PROXY to OPEN, sets a timer for slightly longer that the device’s jumper configured minimum trigger interval and does whatever else he needs to do on the OPEN-event occurrence.
If the timer expires without another event, he post_Updates PROXY to CLOSED.
If another OPEN-equivalent occurs before the timer expires, he resets the timer. (or if you’re compulsive like me, you technically cancel and nullify the existing timer instance and make a new clean one.)
That’s it.
There shouldn’t be any RF transmission if you skip using the Pir_Proxy and I suppose it is possible to implement this without the proxy item.
My PIR signal is coming through a mosquitto broker, so I guess that if I send a closed command some kind of transmission will take place, but I’m not sure.
Though, after a night’s sleep I’m thinking that if you just use “Item Pir_Sensor changed” as the trigger instead of received update in the other rules you don’t need the Pir_Proxy.
Haven’t tried but unless I artificially reset the PIR_Sensor to closed state, I think a new trigger wouldn’t change the state. But again, if the state is reset to closed, that should work too.
If your mqtt binding config for the item starts like this { mqtt="<, that item can only receive MQTT messages. Outbound uses { mqtt=">. It is possible to have a single item do both inbound and outbound but you have to have two mqtt clauses in the curly brackets: { mqtt=">...,<..." }
So if it is set up to only receive changes made to its state in the rules will not cause a message to be transmitted. And even if it does send an MQTT message when it is closed, there has to be something on the other side of the broker subscribed to these messages or else they don’t go anywhere further than the broker.
If your mqtt binding config for the item starts like this { mqtt=“<, that item can only receive MQTT messages. Outbound uses { mqtt=”>. It is possible to have a single item do both inbound and outbound but you have to have two mqtt clauses in the curly brackets: { mqtt=“>…,<…” }
That’s right! So no message is sent.
Thx. Proxy use was one of those semi-epiphany moments as I "got the zen’ of this.
I am reading data from a database for the channels so how do I create a proxy item. In my case how do I create a proxy item.
A proxy item is just an Item without a binding that you put on your sitemap. The behavior that runs when you trigger the item gets implemented in a rule. So, for example, you can have a Switch Item that is a proxy for a light switch. You put the Proxy on your sitemap and create a rule triggered by that proxy Switch received command. In the rule you might do some extra work and tests (e.g. check the state of a motion sensor, check time of day, send a notification, etc.) and then sendCommand to the actual Switch bound to the light switch.
Hi federic. I too am trying to work with PIR motion sensor. On using
when
Item MotionSensor changed
then
sendCommand(RaspiLED, ON)
end
turns the LED on whenever i turn on the switch for my motion sensor and not when motion is detected by the sensor. Can you please share the rule that worked for you.
Hi,
Can you share your items’ file line for MotionSensor?
What do you mean by “when you turn on the switch for” your sensor, do you mean a physical switch on the sensor?
Switch MotionSensor{ gpio =“pin:18” }
i have created a switch for the motion sensor in openhab. when i turn the switch on from openhab, it turns the gpio pin to high the sensor starts working. but i want that when motion is detected my led should glow and not when the sensor is turned on