# Presence Simulation: replaying your own history while you are away > presence_simulation is a Home Assistant custom integration that reads the recorder history of your lights, switches and covers and replays it, so a house that is empty does not look empty. It suits someone who wants a cheap presence trick without hardware, and it depends entirely on the recorder database holding enough history to replay. **slashback100/presence_simulation** — Home Assistant Presence Simulation - Repository: https://github.com/slashback100/presence_simulation - Stars: 1,091 · Forks: 40 - Language: Python - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/slashback100-presence-simulation ## Replay, not prediction The presence_simulation integration does one thing: it makes your house look occupied while you are away by turning lights, switches and covers on and off based on your history. The how it works section is short and precise, and it is the whole mechanism. The component looks in the database for the states history of all the entities configured for it, over a period corresponding to a delta variable, and it applies to those entities the same state, and some attributes such as brightness and rgb_color, that they had delta days ago. So this is replay, not prediction. There is no model of your habits, no learning, and no attempt to look realistic. The schedule you get is the schedule you had a week or two ago, which is precisely the point: an observer watching the house sees a pattern consistent with the past, and the integration is the mechanism rather than a coincidence. The supported entity domains are listed. There is light, cover, media_player and input_select, plus all domains for which entities have an on or off status and that can be turned on and off with the homeassistant.turn_on and homeassistant.turn_off services, which covers automation, switch and group among others. There is one behaviour worth noting because it is not obvious from the name. If the service runs for longer than the number of days defined as the delta, the component is simply reset and starts over, and it keeps doing that until the stop service is called. A simulation left running for a month will loop through the same window repeatedly rather than drifting into nonsense, which is a sensible failure mode. ## The recorder has to hold more history than the delta The pre-requisites are short but they are the ones that decide whether the integration works at all. The history integration must be activated, and the readme notes that it is by default. The period kept in the database should be bigger than the delta used in the simulation, and the default number of days kept is 10, which is configurable through the recorder integration. That is the whole dependency. This is a replay tool, and a replay tool is only as good as the recording it replays, so the recording window is the constraint that matters. If you set a delta of 14 days and the recorder keeps 10, you are asking for a week of history that does not exist. The light attributes section adds the other half. To simulate light brightness changes and colour temperature changes, attribute data has to be stored in the recorder database. Without those attributes, the integration only simulates the action of turning lights on and off, so a light comes back at whatever brightness it happened to be left at rather than at the brightness it was set to. The readme points at a companion component, Light Reilluminator, which can be installed alongside to store light attributes, and says it enables the simulation to turn lights on at their previous brightness and colour temperature values and to update them as they change. The licence is MIT, with the licence file at the top of the repository named LICENCE. The repository is a HACS default integration, with a hacs.json at the top level, and it also carries a blueprints/ directory for automations and an examples/ directory with a lovelace folder. ## Three installation routes, HACS first The readme gives three options and recommends the first. Option 1 is HACS. You need HACS installed, which allows you to easily manage and track updates, and then you search for Presence Simulation in HACS or use the linked repository badge, click Install below the found integration, and restart Home Assistant. The readme adds a note that it can also be added as a custom repository if you have an issue with the procedure above. Option 2 is manual. In your Home Assistant configuration directory, ~/.homeassistant for instance, create a directory custom_components/presence_simulation and put the code in it, then restart Home Assistant. Option 3 is a git clone into the same place. ```bash git clone https://github.com/slashback100/presence_simulation.git ``` That creates the directory custom_components/presence_simulation, and again you restart Home Assistant afterwards. All three routes end the same way, which is worth knowing because the restart is not optional: the integration is loaded as a custom component at startup, and until Home Assistant restarts there is no switch entity and no services. The repository layout explains where things live. custom_components/ holds the integration itself, hacs.json is the HACS manifest, and the blueprints/ directory holds ready made automation blueprints. ## The config flow builds the simulation, not a YAML file Configuration happens through the UI config flow, and the readme gives a fallback for when the config flow link does not work. You go to Configuration, then Integration, click the + button, search for Presence Simulation and confirm. The config flow then asks for the settings, and the readme walks through them one at a time. The first setting is the entities, or group of entities, to be used in the simulation. It can be a group of lights, switches, covers, light groups, media_player, or any component that can be turned on and off with homeassistant.turn_on and homeassistant.turn_off, and you can set up several entities. If you use a group, the simulation will act on each entity of the group independently, which is a detail that matters for how you group things. The second is the delta, the number of days of history the simulation will use. The third is the poll interval in seconds, which determines how quickly the simulation notices that it has been requested to stop, and it defaults to 30 seconds. The readme warns that the smaller the number, the more computing process the component takes, which is a real trade-off since a short interval is what makes the stop responsive. The remaining options are behavioural. You choose whether to restore the states as they were before the start of the simulation. You can randomize the activation and deactivation of your entities, where 0 disables the behaviour and a positive number, representing a number of seconds, adds or subtracts a random number of seconds from the time the entity was actually switched on or off in your historical data. You can choose to treat Unavailable states as Off, which is needed for some devices that report unavailable instead of off. And you can set a default brightness for lights, a number between 1 and 100, where 0 means the brightness will not be set during the simulation and lights keep their last brightness value. Every one of these can be changed later through Options on the integration screen. New in version 4.0, you can create several presence simulation switches, associate them with different configurations such as different entities and the random feature, and turn them on and off independently. ## A switch entity and three services The component creates an entity whose name is computed from the name you chose, switch.presence_simulation for example, and the entity is set to on when the simulation is running and off otherwise. That single entity is the primary control surface, and it means the simulation can be driven from a dashboard, an automation or a script without touching the integration's internals. There are two ways to launch the simulation. Toggling the switch toggles the presence simulation. And there are three services available. The service presence_simulation.start starts the simulation and sets the referenced presence simulation switch entity to on. From version 4, the parameter switch_id is mandatory if you have several switches, and it should be the name of the switch you want to turn on. The service also optionally accepts a list of entities, a delta, a choice to restore the states, and a random offset. The switch_id requirement is a direct consequence of the version 4.0 change that allowed several independent simulations. Before that there was one switch, so there was nothing to disambiguate. After it, each simulation has its own entity, and a service call that did not name one would be ambiguous. The readme marks this with a warning symbol, which is fair, since the failure mode is a service call that does nothing rather than an error. ## Where presence_simulation is the wrong tool Three cases argue against it. The first is a real occupancy system. This replays history. A house that is genuinely occupied by a pet sitter, a cleaner, or someone who works from home, and a house that is being simulated, produce the same signal to a burglar looking for signs of life, and this integration does nothing about that. A hardware presence sensor or a phone geofence solves the actual problem, and the readme points at Light Reilluminator as a companion for attribute storage, which is the direction this category of tool usually goes, toward combining signals rather than synthesising one. The second case is a system with a short recorder window. The default retention is 10 days, and if your delta is larger than that, the simulation is replaying from history that is not there. The tool is not wrong in that situation, the configuration is, but it is a configuration that is easy to get wrong on a large installation where the recorder has been trimmed to save space, and the readme gives you no diagnostic for it. The third case is a household with genuinely variable routines. If your lights are on every evening at eight, the simulation is perfect. If your schedule has changed substantially in the last month, replaying the older delta is actively misleading, and no amount of configuration fixes it because the tool has no notion of which history is representative. The randomisation option is worth reading carefully, because it is the only mitigation on offer. A positive number of seconds is added to or subtracted from the time an entity was switched in the historical data, so the replay is not a verbatim repeat. It is a jitter, not a model, and it changes when the lights come on without changing which lights come on. On maintenance, the release history shows a fairly steady line, with v5.3 in May 2026, then v6.0 and v6.1 in September 2026, and the last push on 2026-10-12. The two September releases came a day apart and v6.1 was a config validation fix, which is a sign of a component that is being adjusted against real installations rather than developed in isolation. ## Conclusion presence_simulation suits a Home Assistant user who wants their house to look occupied while they travel, who already keeps a long enough recorder history, and who is happy with a heuristic that replays states rather than a real occupancy model. It does not suit a setup where the recorder is trimmed to a few days, since the replay has nothing to draw on, and it does not suit anyone who needs the simulation to be indistinguishable from genuine occupancy. Before you install it, check how many days your recorder keeps, confirm your delta is smaller than that, and note that the last push was on 2026-10-12 with the newest release v6.1 from 2026-09-25. ## FAQ ### How do I install presence_simulation in Home Assistant? The recommended route is HACS, searching for Presence Simulation, clicking Install and restarting Home Assistant. Alternatives are creating a custom_components/presence_simulation directory in the configuration directory with the code in it, or cloning the GitHub repository into that same location, and restarting Home Assistant in both cases. ### What does the delta option do in presence_simulation? The delta is the number of days of history the simulation uses, so the entities are set to the state they had delta days ago. The period kept by the recorder has to be larger than that delta, and the default retention is 10 days. ### Can presence_simulation restore the previous state of my lights? Yes, there is a configuration option to restore the states as they were before the start of the simulation. The readme also notes that if the service runs longer than the delta, the component is reset and starts over until the stop service is called. ### Why are my simulated lights coming back at the wrong brightness? Simulating brightness and colour temperature changes requires attribute data to be stored in the recorder database, and without those attributes the integration only simulates turning lights on and off. The readme points at the Light Reilluminator component as a way to store those attributes. ## Sources - [Issues](https://github.com/slashback100/presence_simulation/issues) - [License: MIT](https://github.com/slashback100/presence_simulation/blob/main/LICENSE) - [README](https://github.com/slashback100/presence_simulation/blob/main/README.md) - [Releases](https://github.com/slashback100/presence_simulation/releases) - [slashback100/presence_simulation on GitHub](https://github.com/slashback100/presence_simulation) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/slashback100-presence-simulation