Anti burglary presence simulation


(M) #1

Task
Simulate presence when not at home to prevent burglary

Solution
To simulate credible presence there is nothing easier to use the data you do have of your real behavior. So I restore the previous week’s status of certain lights when not at home:

rule "Periodically check auto lights"
when
    Time cron "0 */10 * * * ?"
then
	logInfo("LightsAuto", "Auto Light Check")
	// If nobody is home and lights away mode is auto or if mode is on
	if( (Presence.state == OFF && Lights_away_auto.state == "Auto" ) || (Lights_away_auto.state == "On") ){
		gLights_auto.members.forEach[lamp|
			lamp.sendCommand( lamp.historicState(now.minusDays(7)).state )
		]
	}
end

Error during rule execution (maybe due to sendCommand)
Help with a loop (Runs too fast / Ignores timers)
Help with a loop (Runs too fast / Ignores timers)
( ) #2

Amazing @Mpower! Such a clever idea and shorter than any other inferior solution :smiley:


(Patrickse) #3

So easy. I’ve used the the Caldav approach for this. But that’s really smart. :thumbsup:


(Stefaan Bolle) #4

What persistence service do you use to retrieve the historical items of gLights_auto?


(Oggerschummer) #5

Very cool approach.
Some ideas that could improve the solution:

  • Store the date when the auto-lighting has been activated.
  • Get the historic value from the stored date -7 + (days since then mod 7)
  • Add probabilty factor when switching on the lights (e.g. switch on by 90% only).
  • Switch-off time should vary as well, but it needs to be ensured by a rule the at a certain point in time (e.g. midnight) lights will be set to OFF so no light burns forever.

This would ensure that

  1. the pattern never repeats 100% (which it currently does). If you are away for more than a few days this will make things even more realistic.
  2. we avoid that the changed pattern results in shifting the switching time after some days to someting unrealistic.

Pretty sure I missed some scenarios but the basic idea should be clear.

Regards,
Oggerschummer


(Angelos) #6

I like it ! :tada:

Already implemented it in my OH2 rules :slight_smile: Thanx!


(M) #7

I use influx db, but i Think it doesnt latter which one you use


(Dirk Wissmann) #8

Wow, a cool and simple solution.

Just for my understanding, since I just started using a MySQL database together with OpenHAB 2, and the state(s) some light switches are placed into the database. I use the strategy “everyChange”.

Now if I use these rules shown here, the periodic check is done every 10 minutes.

In case, e.g. I go into the bath room, turn on the light, stay there for about 2 minutes, and then leave it and turn the light off again, this won’t be replayed, as the check is done only every 10 minutes, right?

Would it make sence, to do the periodic check every 1 minute, if not present? Would this lead to a more accurate presence simulation? Or would this be too much for my little raspi 3? In Addition, I would’t log the check, as this leads to a real full log then.

I think reducing the interval to 1 minute would really replay the “real life”.

What’s your opinion about that?

And now for beginners like me: where would I implement this rule? Up to now, I only used the PaperUI on OpenHAB with Raspi 3. Where could I store the values for Presence and Lights_away_auto?


(Lucky) #9

I have my trigger at 5 minutes on an rPi3. Works fine, although Im not using the code above. I do mine differently. I also never toggle the simulation, it’s automatic. I have several rules to determine human presence based on door/window contacts, my indoor camera motion etc. If no human presence is detected for a configurable amount of time, then human simulation begins:

Random lights

  • max 2 hours each light
  • max 2 lights on at a time
  • max 20 minutes of ‘no’ light turned on
  • lights only turn on based on astro sunset time

During day time

  • I randomly play 2 radios, 1 upstairs, 1 downstairs.
  • Both chromecast audios
  • Random play uri/stations
  • Max 2 hours each per continuous play
  • Max 20 minutes of silence (both off)

when simulation has started, it does not rely on cron to determine the next ‘tick’ but I rely on a timer. Once timer has ended, a new timer starts with the new random duration.


(Chris) #10

Visual Studio Code shows error warning: Type mismatch, cannot convert from State to command.

Have things changed since 2017? Must I explicitly typecast/transform/convert State so it is accepted as command?

Thanks!


(Vincent Regaud) #11

Does it work, though? Despite the VS code warning?


(Chris) #12

Actually I didn’t try, I’m used that warnings like that would cause runtime exceptions (I’m new to openHAB) and I wouldn’t know where those would be logged


(Vincent Regaud) #13

They would be logged in /var/log/openhab2/openhab.log and /var/log/openhab2/events.log


(Chris) #14

Nothing showing up about that (nor about “logInfo(“LightsAuto”, “Auto Light Check”)”) in either file


(Dominik) #15

The correct syntax should be

lamp.sendCommand( lamp.historicState(now.minusDays(7)).state.toString )

(Chris) #16

Thanks, it works now!
Hint for newbies (note to self…): It won’t work if you put a group that only contains other groups as “gLights_auto”
It will iterate over the groups and will be unable to access their historic state etc. You want to iterate over a group of Lamps (or Things for that matter).


(Dominik) #17

Give a try with

gLights_auto.allMembers

instead of

gLights_auto.members

Then all items should be touched in the nested groups, but I am not sure then about the state.


(Martin) #18

Great idea and I’m just about to implement it.
One general question about the behaviour of persistence:
I’m using influx with a „onChange“ strategy. When I turn a light on persistence will insert the state with timestamp into the influxdb. So far so good. Let‘s say I turn on a light 7 days ago at exactly 7pm. The presence simulation queries the state of that light at 7:05pm. There won’t be an entry in the influx db with timestamp 7:05. I guess the persistence service will return the „last known“ state which is the State with timestamp 7pm, right?