Presence Simulator: turning on lights at random to pretend that someone's home

I use the following script to simulate presence by turning lights on/off while I’m away. The “Away” state is determined, in my case, based on the Alarm_Armed status.

The script is implemented in JRuby OpenHAB Rules System

The probability of each item being turned on can be adjusted, so that eg. knowing that the Living room’s light is often turned on, we give it a higher probability vs e.g. the bathroom light.

Attach gPresenceSimulators group to lights that will be involved in the scheme

Group gPresenceSimulators

Switch LivingRoom_Light (gPresenceSimulators) {channel="xxxxx", probability="0.95"}
Switch FrontPorch_Light (gPresenceSimulators) {channel="xxx", probability="0.1"}
Switch BathRoom_Light (gPresenceSimulators) {channel="xxx"} // Use the default probability
require 'openhab'

rule 'Away: Presence Simulation' do
  every 20.minutes
  between '4pm'..'11pm'
  only_if Alarm_Armed
  not_if { Sun_Elevation.positive? }
  run do
    gPresenceSimulators.each do |item|
      if >= '11pm' # after 11pm, only turn off
        after(rand(19 * 60).seconds) { if Alarm_Armed.on? } if item.on?

      probability = item.meta['probability']&.to_f || 0.3
      after(rand(19 * 60).seconds) { item << (rand < probability ? ON : OFF) if Alarm_Armed.on? }

states = nil

rule 'Away: Leaving' do
  changed Alarm_Armed, to: ON
  run do
    states = store_states gPresenceSimulators # This can be an array containing all the items/groups to save

    # Turn off all lights, TVs, exhaust fans, and pause any google home devices that are playing
    gGoogleHomePlayers << PAUSE

rule 'Away: Return' do
  changed Alarm_Armed, from: ON, to: OFF
  run { states&.restore_changes }

The last two rules are to save the states of all lights when Alarm_Armed is just activated, and to restore the states of those lights when it’s deactivated, so all the lights will be as they were, and not randomly on / off here and there.

Thanks for sharing. Have you seen this new feature of openHAB and area of the forum?
Latest Add-on Marketplace/Rule Templates topics - openHAB Community

Not sure what is involved yet but should make sharing rules like yours much easier.

I have been wanting to do a similar thing for a while now except it is only in 1 room and the idea is to use a single RGB globe to emulate a TV being watched. This means low electricity usage as the light is low brightness and keeps changing in brightness levels and colour so anyone from outside the house sees a TV and assumes people are home.

WLED added an effect for doing this recently which I have not checked out yet called TV simulator. This should take the load off openHAB if a device can do all the random work and make it look realistic.

Effects and Palettes - WLED Project

Wow, I didn’t know about this! Cool!

The tricky thing is that sometimes a rule depends on many things, so it would need to be adjusted. I view my post as merely sharing ideas, and by doing so, hoping that I’d also learn from others’ feedback, suggestions, and criticisms.

That’s pretty cunning! :smiling_imp: I thought about playing a youtube playlist on a google home speaker to make some noise.

Cool! I have been meaning to check out / play with WLED! Thanks for sharing.

Of course, if the lights are already automated switching to a random pattern can itself be a signal that no one is home. Be careful of that.

An alternative approach I like to promote is to use persistence. Just playback what the light was doing seven days ago (or the time of your choice). That way it will be completely indistinguishable from you being present. In fact, that’s a easy one I can post to the marketplace for another example.

As for the marketplace, it currently only works with managed rules (i.e. those defined in the UI or through the REST API). That doesn’t mean that jRuby isn’t supported (though when I asked about that the jRuby developers didn’t see interested in ensuring that it does work in UI rules). I’d hope that UI rules with jRuby are possible.

The marketplace supports rule templates. You can create properties for the user to enter (which Item(s), Thing uids, thresholds, etc.) when they instantiate a rule from the template. So it is possible to make the rule flexible and give the user the ability to adjust those things that need to be adjusted via a simple form. Furthermore, once instantiated, the user can go in and modify the actual source code too. So it’s reasonably flexible on that front.

In your rule’s case I’d create a Group to hold the lights. The name of that Group would be a configuration property. The SunElevation Item could be an optional property, Alarm_Armed the same. The rand seed, time of day, and all that can be properties, some required and others optional that the user can set when instantiating the rule from the template.

It’s pretty manual at the moment. You need to create a rule through the UI. Then save the YAML from the code tab to a .yaml file. Alternatively, you can create the rule through the UI and pull the JSON from the REST API and save that to a .json file.

Then you need to replace the stuff before the “triggers” element with rule template information. For example, here’s the rule template stuff from my Alarm Clock template which is YAML.

uid: rules_tools:alarm_clock
label: Schedules a timer to run a script
description: This will trigger on an update to a DateTime Item and schedule a timer to call another script at the DateTime's state.
  - name: alarmTime
    type: TEXT
    context: item
      - name: type
        value: DateTime
    label: Alarm Time Item
    required: true
    description: Item that holds the date and time to run the script.
  - name: script
    type: TEXT
    context: rule
    label: Script to Call
    required: true
    description: The Script or Rule to call at the alarm time.
triggers: ...

Here it is in JSON for one of my MQTT EventBus rule tempaltes.

    "label":"ONLINE Status Publisher",
    "description":"Publishes ONLINE as a retained message to the LWT topic.",
        "label":"MQTT Broker Thing",
        "description":"Select the MQTT Broker Thing used for the MQTT Event Bus",
        "label":"openHAB Instance Name",
        "description":"Name of this openHAB instance, used as the root of the topic structure.",
    "triggers": [...

The uid needs to be unique. Yannick and Kai use their names for the first part of the UID. I use “rules_tools” since I’ve already established that as a repo for my rules and will host my templates there. Everything else is pretty self explanatory.

The configDescriptions work the same as properties in custom UI widgets. So if you need an Item name for a field, you can specify that and the user will get the list of Items to select from.

You can post the yaml of json inline in your forum post or host it elsewhere (e.g. github) and provide a link to it.

Unfortunately, the only way to test it though is to publish it to the forum and set the “published” tag. The marketplace is currently the only way to install a rule template. But it’s just an initial testing release so we can’t expect it to be complete.

Another limitation is it currently only supports one template per post. So in cases like this with three rules there needs to be three postings (or figure out how to make one rule do all three jobs). I’ve already filed an issue on that because I suspect it’ll be rare that capabilities we post will be limited to one rule. In fact Yannick has an idea where maybe someday we can post whole comprehensive modules with a binding, rules libraries, rule templates, and UI widgets in one bundle on the marketplace. That’d be really powerful.

We sure can use some more rule template examples. I’m happy to help make this or anything else into a rule template.


Indeed, one needs to be careful about which lights to turn on/off and for how long, and when.

This is a great idea with caveat. Simply playing back N days ago isn’t going to work when you’re away for more than N days (e.g. away for 6 months+)… but yes, we can collect the data for a number of days (e.g. 5-10 days) and randomly cycle through different days so that the sequence isn’t the same day after day. This is certainly something that needs further refinement.

I think I can record a list of time_of_day + state changes into an array, and store them in metadata, and it can be replayed from there. This makes it much simpler to set up than persistence. So when NOT_AWAY, it would record, and when AWAY, it would replay. Great idea!

As for the marketplace, it sounds like I should wait until it’s more mature.

This is on the agenda and the main developer @broconne is aware of it.

I’m not sure it’s that big of a problem. Someone would have to be watching your house for at least 8 days and have a pretty good memory to discover a repeated pattern. And by then they will know you are not home even with the lights and other devices turning on and off because you will not have been see coming and going or through windows.

But you could do 14 days, 30 days, 60 days or what ever floats your boat. It doesn’t have to be hard coded.

The nice thing though on sticking to multiples of 7 is that the weekends behavior look like a weekend and the work day behavior looks like a workday. It’s a little bit extra verisimilitude.

I think that is the first time I’ve seen anyone claim Item metadata is easier than persistence, expeically given that openHAB 3 comes with rrd4j persistence installed and configured by default. I love Item metadata but I wouldn’t call it easier.


Hmm, I have never played with rrd4j, and wasn’t aware that it’s installed by default. Might have to look into that. I’m mainly using influxdb for graphing, and mapdb for simple persistence.

Working with metadata in jruby is extremely easy. It is just like working with a normal array / hash variable. I have used it to cache thousands of image urls from multiple photo albums for my Facebook photo frame display.

that is pretty slick!

yeah because my first question was going to be why not just turn on the tv? Obviously uses less juice. Great idea

Always been a fan of playing back switching from persisted values as Rich mentioned

1 Like

I’ve added a persistence driven presence simulation rule to the marketplace. It’s not super well tested but it’s also super simple so I don’t expect there to be any problems.

The Item that turns the simulation on/off, the Group containing the Items to play back, number of days to look back and how often to run the rule are all configurable.

Great idea, but for some houses we don’t have curtains in certain rooms so it would be pretty obvious what is going on when lights turn on in a room and no one walks in. It is normal for people to get sick and watch TV in bed and not move around the house like a normal routine, so a TV simulator is low cost to run and cheap to setup, suits my use case. I doubt someone will be watching a house with a clipboard in hand recording if your daily routine has changed, most likely it will be someone that is just walking down the street looking for a house with no cars, grass not mowed, letters still in the mail box, all lights turned off and no one answers when they knock on the door. The idea is to just to encourage the person to move to the next house and not choose your home.

If you have curtains, you could try setting up an old record player with a cardboard cut out on it casting a shadow on the curtain :wink:

@rlkoshak I’ve just had a look at your Persistence presence simulation. It does look very straight forward, and I agree that it is easier to do this approach using persistence instead of metadata, since all the states have been saved for you.

1 Like

Maybe a little late, but
I have implemented a Replay rule for this purpose. Initially in DSL now in jython.
It reads the events.log files and based on these entries generates events for all items which belong to a specific group (white listing items). It use the events 3 weeks back to generate a relativ realistic pattern. It can run forever with the caveat of a repeating pattern after 3 weeks. I can easily live with that. For a long time usage >2-3 month the daylight changing over this period is more crucial in my view.
Using persistence data instead of the events files looks interesting to me. I will have a look into it.My main question: How does it work after a restart of OH?

If you are interested in my Replay rule, Jython one, let me know and I will upload it.
It is tweaked for OH3.1 docker environment

I also have something similar in Python 3. But I turn on a single light only. After a random time, it is turned off, and another random light is turned on.

You can also simulate day night presence using an audio source such as Google Home and an external motion sensor. Play loud rock music for a random interval when the motion sensor is triggered :wink:

The same as before a restart. Persistence saves Item states to the database. That database is written out to disk. The whole point of persistence is that the data persists across OH restarts. If you are worried about differences in sunrise/sunset, one could go back 365 days and replay the events from last year if that is a concern with the persistence approach. Of course you’d have to have data that goes back that far and if using rrd4j there might be some weirdness caused by the compression rrd4j does to data as it ages.