Motion Sensors / restarts / special rules

Setup, Configuration and Use Beginners
1

I am running openhab2 and trying to setup some rules around my motion sensors. Here is what I am thinking.

Using some design patterns and virtual switches I am looking at the following concept.

Group gMotionSensors
Group gMotionSensors_raw
Group gMotionSensors_LastUpdate

Switch LivingroomMotionSensor_raw <input from motion sensors>
Switch LivingroomMotionSensor (gMotionSensors) 
DateTime LivingroomMotionSensor_LastUpdate (gMotionSensors_LastUpdate) "Livingroom   [%1$ta %1$tR]" <clock>

So when the motionsensor triggers it updates the state of _raw, updates the item for the lastupdate timestamp, updates the virtual switch

rule "Raw Motion Sensor State Changed"
when
    Item gMotionSensors_raw changed from OFF to ON
then

        gMotionSensors_raw.members.forEach[motionsensor |

        val dtStr = motionsensor.name + "_LastUpdate"
        val nameParts = motionsensor.name.split("_")
        val virtName = nameParts[0]
        
        val DateTimeItem assocDT = gMotionSensors_LastUpdate.members.filter[dt|dt.name == dtStr].head as DateTimeItem
       
        
        assocDT.postUpdate(new DateTimeType(motionsensor.lastUpdate))
        val SwitchItem virtNamer = virtName as SwitchItem 
        virtNamer.send(ON)
        
    ]
end

So at this point, the raw sensor would trigger only when the trigger is updated to “ON”. it will ignore the motion sensors “OFF” trigger because I am not as concerned with that as I am handling off via code.

When it triggers to “ON” it will turn on the virtual switch and update the “_LastUpdate” item (i know, this is also handled in persistance, but I want to be able to display this info later on a sitemap)

Next I want to put a rule that will allow the motion sensors to still be triggered off even through a reboot. This is why i am not using expire binding.

rule "Motion Sensor Done"
when
    Time cron "0 0/1 * * * ?"
then
     gMotionSensors.members.forEach[motionsensor |
     
         if (motionsensor.state == ON) {
             if (!motionsensor.updatedSince(now.minusMinutes(Settings_MotionSensorTimeout.state))) {
                  #the motion sensor is on, and it was updated more than X minutes so it's time to turn it off 
                  motionsensor.send("OFF")
              }
          }
    ]
end

So that is my concept so far. I have not implemented it because I am looking at one other feature and have a couple routes I could go.

Basically what I want to do is compensate for this scenario. My wife likes to read. So she will sit down with her kindle and barely move. Because of the pets the sensitivity is set a little lenient to compensate. So what i would like to do is if the light turns off because she didn’t move, if she triggers it again to turn on, but it triggered with in say 30 seconds of when it turned off, to add say 10 minutes to the default timeout. if it happens again, maybe add 15. Since i don’t think variables are persistent through triggering of rules, the only thing i can think of is to add something like this.


Number LivingroomMotionSensor_triggercount
DateTime LivingroomMotionSensor_shutofftime

and then do something with the rule to look at the shutofftime instead of lastupdated. Then in the triggering rule for turning on, check the lastupdate time and what that state was. If lastupdate < 30 seconds ago, set shutofftime = + (TriggerCount * 5). If lastupdate > 30 seconds. proceed as normal and set triggercount = 1

so if it default time is 10 minutes, then first motion detect will set the lights to turn off after 10 minutes and set trigger count = 1. if the lights turn off and turn back on with in 30 seconds, timeout is set to + (TriggerCount = 1 * 5) so now it’s 15 minutes. Update trigger account to 2. Repeat.

Any thoughts on this? Or does it seem feasible enough to say, do it and see what happens? :slight_smile:

Thanks! any feedback is appreciated.

2

Hum, well if you declare a variable outside of rules, at the top of your rules file, it exists/persists outside of the rules, and is visible to all of the rules in that file.
“Global variable” - it might be useful.

Will not persist through a system or rules file reload.

Taking it a step further, the global variable can be a global timer, started by one rule and checked to see if its running by another rule.

3

I think OP’s concern is persisting through an OH restart/rules reload. Items with persistence is the best way to achieve that.

@crankycoder, given your requirements your proposal seems reasonable. If you ease up on the requirements just atad and let the timer completely start over on a reboot/reload (e.g if you have a 10 minute timer and if oh restarts you reschedule the timer for 10 minutes, ignoring the time that has already passed) then this can be done with Expire binding timers.

Persist the timer objects and have a System started Rule send command to all your timers that were ON before the restart.

Since OH restarts and reloads are rare events, in my system this was a good compromise. I have a gExpireTimers group and add all my timers that I want rescheduled after a restart to that group.

4

Absolutely, this was about the secondary function of creating a “retrigger window” that extended the run time, which necessitates another set of timers somehow. Those won’t need persisting since they’re only needed after something else happens.

Having said that, the desire to have a variable run time does clobber the expiring Items method for the runtime timers.

1 Like
5

Ah, nice idea. I may have to play with that concept. This would also help compensate for when a node fails over too. My big thing is if a light turns on and then someone leaves the room and something happens (reboot, restart, failover) i don’t want that light to be left on. Mainly because i am also working on moving the house over to running on battery/solar then grid, i would like to try to keep some effeciencies in place :slight_smile: I do like the expire binding, so restoring time state with expire may work.

6

Thanks for some feedback on this. It definitely gives me some more ideas to play with :slight_smile:

This is why I love the OH forum. lots of ideas

7

I deal with that exceptional occurrence by having a ‘System started’ rule check for lights ON and begin the timeout process for them.
Don’t care about old timer value as (a) rare occurrence (b) who knows how long system was offline anyway

1 Like
8

Would you happen to have that start up rule somewhere? I am proceeding with this now that the holidays are over finally :slight_smile:

9

My timers for sure don’t work like yours, but its just a case of

rule "startup check"
when
    System started
then
    // check to see if light currently ON
    // if so, do whatever you do to set an off time
    // and so that any motion etc.will still restart your timer

Depending on how quickly your lighting technology updates OH, you may need to delay checking.

1 Like
10

oh i thought it was something crazy elaborate haha Ill see what i come up with :slight_smile: