You could do something radical like begin the timing when the motion stops …
This isn’t hard folks, just requires logic.
Let me add a bit more detail;
When motion goes ON, turn the light ON.
You don’t need any timing here - if you got motion, you want the light on.
If the timer is running, cancel it.
That is possible with expire - you postUpdate your expiring Item to its “finished” value. There’s no off command, so your light-off rule is not triggered.
When motion goes OFF, now you want to begin timing by poking your expiring Item.
rule "Basement Motion Top"
when
Item basement_motion_top changed from OFF to ON
then
basement_light.sendCommand(ON)
// start or reset Timer
BasementTimer.sendCommand(ON)
end
rule "Basement Motion Bottom"
when
Item basement_motion_bottom changed from OFF to ON
then
basement_light.sendCommand(ON)
// start or reset Timer
BasementTimer.sendCommand(ON)
end
rule "Basement Motion Pap"
when
Item basement_motion_pap changed from OFF to ON
then
basement_light.sendCommand(ON)
// start or reset Timer
BasementTimer.sendCommand(ON)
end
rule "Basement Light Off"
when
Item BasementTimer changed from ON to OFF
then
basement_light.sendCommand(OFF)
end
I did one rule for each sensor because, to me, it seemed to be more consistent than putting all the sensors in the same rule.
So set that timer for the OFF command to 5 seconds, for instance. If you want to be precise, then set the timer for 55 seconds instead of a minute, to compensate.
rule "Sensor motion turns on light"
when
Item Swi_MSensor_Motion received command ON
then
Swi_Light.sendCommand(ON)
end
rule "Sensor motion turns on proxy/timer"
when
Item Swi_MSensor_Motion received command OFF
then
Swi_MSensor_Motion_Proxy.sendCommand(ON)
end
rule "Sensor proxy/timer turns on light"
when
Item Swi_MSensor_Motion_Proxy received command OFF
then
Swi_Light.sendCommand(OFF)
end
Cannot test yet but I’m guessing this should work now. I’ll report back later once I test. Thanks again everyone.
I doubt your motion sensor ever receives commands. You original rule did not trigger on commands.
If you fix the triggers, you will need to add to the light-on rule. “Cancel” your expire timer by postUpdating OFF to to the timer Item.
If you don’t do that, new motion detected during the timing period will not stop the timing from an earlier cycle.
EDIT - when you have it working, you can refine the light-on rule further by only issuing light-on command if light is not already on, saving traffic on your zwave network.
Not for expire. Setting it to ON resets it. From the documentation:
If another binding is repeatedly updating the state of the item to be the same state it already was, the expiration timer will continue to be reset into the future. Dedicating an item to the expiration function (so it doesn’t receive repeated updates from another binding) would avoid unwanted behavior, should it apply in your case
The following updated rule appears to be working as expected. I’ll know for sure in a few days.
rule "Sensor motion turns ON light (if OFF) and cancels expire"
when
Item Swi_MSensor_Motion changed from OFF to ON
then
if (Swi_Light.state != ON)
{
Swi_MSensor_Motion_Proxy.postUpdate(OFF)
Swi_Light.sendCommand(ON)
}
else
Swi_MSensor_Motion_Proxy.postUpdate(OFF)
end
rule "Sensor motion turns on proxy/timer"
when
Item Swi_MSensor_Motion changed from ON to OFF
then
Swi_MSensor_Motion_Proxy.sendCommand(ON)
end
rule "Sensor proxy/timer turns on light"
when
Item Swi_MSensor_Motion_Proxy received command OFF
then
Swi_Light.sendCommand(OFF)
end
The first rule could be simplified a little by moving the “cancel” outside the if().
Works the same, one less line.
A teeny tiny refinement, you can trigger from
xx changed to ON
Rather than
xx changed from OFF to ON
You don’t really care what it was beforehand, and this will take care of the rare case where the state might be NULL after a reboot etc.
The trouble that I’ve had with a setup like this is that the “smarts” are in both your motion sensor and the openhab rules. The smarts in the sensor make things more difficult.
The ideal setup is that the sensor only sends ON commands every time it senses motion. It sends an ON every x seconds as long as there is still motion. The rule receives that ON from the sensor and sends an ON command to the light. The light item is bound to both the zwave switch and the expire binding. You have the light set to expire after y seconds and send command OFF. y >x. With this setup, you only need 2 items (skip the proxy) and the following rule:
When
Item sensor receives command OR
Item sensor receives update
Then
light.sendCommand(ON)
end
I think only the command or update trigger, not both, is needed in the above rule. Check your events.log to see which ones are there.
Some motion sensors have a setting where they only send ON commands and not off. If that’s possible, I highly recommend using that setting and the above rule.
The trouble with the sensors that send ON and OFF is that if they keep sensing motion after they send the ON, it might be a long time before they send the OFF. So for this to work without ever turning off the lights while somebody is in the room, your expire number has to be bigger than the maximum time there could ever be between the sensor sending ON and OFF, whatever that is. That’s why the “smarts” in the sensors makes things more complicated.
I suggest to make this work you use my rule above and either get the sensor to send only ONs if possible, or crank the expire time up to something big like 10 minutes.
But this is not how the sensors work. It sends on when motion starts and off after x secs of no movement and it’s quite a good implementation.
It’s actually not a problem to write the timeout rules so that they respect this behavior but it won’t be a one-liner anymore and it’s a little bit harder.
Yeah, if that’s the case for this particular sensor then you could pretty much rely on the sensor for the on and off, maybe adding a little extra time in an openhab rule after the off sensor message if you want it to be a little more configurable.
I had one of those multisensors and I could never get it to do what I wanted reliably, so I’ve ended up switching to an esp8266 based sensor in one room and an insteon sensor in another room. Both of those allow just the ON messages to be sent. I know there are some configuration settings on the aeotec multisensors, but I don’t remember if that was one of the settings.
This is my simple rule, is doing what it should.
When Motion is dedected it sends an “ON” to the light and after the time defind in parameter 3 it sends an “OFF”.
rule "Licht Wintergarten AN"
when
Item PIR_Wintergarten changed to ON
then
if (Helligkeit_Wintergarten.state < 2) {
sendCommand(Licht_WG, ON)
}
end
rule "Licht Wintergarten AUS"
when
Item PIR_Wintergarten changed to OFF
then
if (Licht_WG.state == ON) {
sendCommand(Licht_WG, OFF)
}
end
I checked now also the timings of the motion sensor.
I found that the sensor sends no further “ON” in the time range defined in parameter 3, but still captures motion.
If there is no more motion the sensor sends an “OFF” after the time in parameter 3.
So if you have parameter 3 set to e.g. 1min it sends an “OFF” after 1min.
If there is still motion for e.g. 2min it will send “OFF” after 3min (2min motion + 1min).
I’ve now tested 3 different motion sensors for over a month, all with different rules depending on how they report:
Heiman motion sensor
Aeotec multisensor
Fibaro motion sensor
They have all worked flawlessly. With sensors that report both on and off I’ve had just as much success with using the expire binding as without.
Thanks everyone for your guidance and suggestions I now have a greater understanding of how sensors differ and what I can do to make them work as I wish.
