A Facebook post about a possible Home Assistant login attempt made me stop and think. I could not verify that report, so I did not treat it as evidence of an attack or a weakness in any particular remote-access method. It did, however, leave me with a question I could examine in my own setup: if somebody already had access to my Home Assistant account, how much could the data reveal about my routine?
I was not trying to simulate a break-in or prove how common account compromise is. I wanted to understand the information value of the history I had already collected for my own automations.
The question I wanted to test
My Home Assistant is connected to the ordinary signals that make a smart home useful: sensors, presence detectors, a door lock, and many more entities. Any one of those is mundane in isolation. A lock state tells me whether the door is locked; a presence sensor lets an automation decide whether a room is occupied.
I wanted to know what happened when those signals were read together over time. Could they reconstruct a broad daily routine? Could they distinguish working days from weekends? Would they suggest when the apartment was usually occupied or empty? And, if the data was good enough, would they point to recurring activities?
Those were deliberately questions about my own data. I did not want a tool to operate my home, and I did not give it permission to change anything.
How I ran the experiment
For the experiment, I used OpenCode with access to my Home Assistant through MCP. I gave it a read-only prompt and made the boundary explicit: it could inspect information from my own system, but it could not change states, configuration, or devices.
I have condensed and translated the reader-facing scope of my original prompt here. It is not a byte-for-byte copy:
Use the sensors, presence detectors, lock, and other available entities in my own Home Assistant to reconstruct broad routine patterns.
Differentiate between weekdays if the history supports it.
Read data only. Do not change states, configuration, or devices.That distinction mattered to me. The interesting part was not whether an AI could turn on a light. It was whether it could interpret a collection of data points that had already accumulated in a normal smart-home installation.
What it actually used
I started with the expectation that the system might need a lot of data. In the end, it did not use everything that was available.
The model initially identified eleven entities as useful for the analysis, then discarded three of them in an earlier response. Eight were enough for the final reconstruction. It looked back fourteen days in most cases; the room sensors only had seven days of history available.
The signals were not exotic. Presence, lock status, and a small number of motion or room signals carried much of the pattern. Other data was available in my setup — including a sleep analyser and more room-presence sensors — but it was not needed for this result.
That was one of the most revealing parts for me: the result did not depend on building a complete digital twin of my household. A small, ordinary subset was already enough to form a coherent picture.
What the redacted result showed
The output separated weekdays from weekends. On working days, it identified an early start, a recurring period away from home, and activity around the entrance and door lock when I returned. Weekends looked different: later starts, more time at home, and shorter individual trips rather than the longer recurring absence.
I removed exact times, locations, and other details before publishing the result. They were too private to reproduce. But I left the structure intact because that is the part that made the experiment useful: it was able to distinguish a regular working rhythm from a different weekend rhythm from the history alone.
I expected patterns to exist in principle. I was still surprised by how clear the summary was with only eight entities and a week or two of history. The striking part was not a single sensor value. It was the interpretation across several ordinary signals.
What this result can — and cannot — tell me
This was one read-only experiment in my own installation. It required an account that could already access the data, and it was not an attack demonstration or a measurement of how often accounts are compromised. I also cannot turn one redacted output into a universal claim about every Home Assistant installation.
What I can take from it is more concrete: a Home Assistant account can be access to a meaningful record of household routine, not merely a remote control for lights and switches. In my case, the sensitive part was not simply reading an individual entity. It was joining the history into a story about when the home was active, quiet, or empty.
That changed how I frame account security for my own setup.
The security habits I would prioritise
The current Home Assistant security guidance recommends a strong, unique password, multi-factor authentication, regular updates, and a secure method for remote access. Its authentication documentation also explains how to review account access and configure MFA.
Those are external recommendations, not outcomes of my experiment. They are the practical controls I would prioritise for a system that holds this kind of household data:
- Use a unique password stored in a password manager, rather than reusing one from another service. I use Bitwarden’s password generator for this.
- Enable multi-factor authentication for every account that can administer Home Assistant. I also keep my one-time codes in Bitwarden, so they are available when I sign in from my phone or computer.
- Keep Home Assistant current and review who has administrative access.
- Use an explicitly supported secure remote-access approach, rather than exposing an ad-hoc service to the internet.
I would also avoid treating arbitrary, scheduled password changes as the main defence. Current NIST guidance emphasises changing passwords when there is evidence of compromise rather than forcing routine changes without a reason. A unique password and MFA are more useful foundations.
What I learned from a small experiment
I did not need a dramatic breach scenario to make the privacy consequence concrete. Looking at my own ordinary smart-home history was enough.
The experiment made me pay closer attention to what an authorised account represents. It is not only permission to control devices. It can also be permission to interpret the habits those devices have recorded. That is why I now treat the protection of that account as part of protecting the privacy of my home.