Activity

Nothing in light.kitchen being on says whether a person pressed a switch, an automation fired, a voice command asked, or brAIn did it.

That is the question behind most of what people actually want to ask their house — why did the hallway light come on at 3am? — and until the Activity tab it was unanswerable from every surface brAIn had.

The fourth kind of knowledge

Memory is what is true. A finding is what is broken. A guess is what brAIn might have wrong. Activity is what happened.

It is a record rather than a queue, so it has no badge. Nothing on it is waiting on you.

Where the cause comes from

Home Assistant’s logbook records a context for every state change — a chain saying what set it off. The Activity tab walks that chain and files each change under one of a closed set of causes:

Cause	What it means
Person	A named user did it, from the app or the UI
Automation	A rule fired
Script / Scene	Something ran
Voice	An assistant command — Home Assistant’s own Assist, or a brAIn voice agent
brAIn	brAIn changed it on its own — a fix you approved, a background run — see below
Unattributed	Nothing in the record says

Unattributed is an answer, in as many words

A wall switch and a device’s own integration reach Home Assistant identically. Naming either would be a guess, and a timeline that guesses is not evidence. So brAIn says unattributed rather than picking the likeliest.

Proximate and root cause are both recorded. An automation somebody started from the UI carries an automation and a user. Reporting only the user turns every automation into “you did this”; reporting only the automation loses the one fact that explains an unexpected run.

How brAIn knows what brAIn did

It wrote it down. The MCP server calls Home Assistant over REST with the Supervisor’s token exactly like every other integration, so a light brAIn turned on is indistinguishable in the context chain from a light anything else turned on — there is no id to match.

So every service call brAIn makes is appended to a ledger at the same chokepoint protected_entities is enforced at, and the reader joins the logbook against it. An area or device target is recorded and deliberately not resolved: resolving one needs the registries as they were at the time, and a wrong expansion would attribute somebody else’s change to brAIn — the one mistake the ledger exists to prevent.

What you ask brAIn to do is still yours. Each row in that ledger says which face asked — voice, the chat, the terminal, or a run nobody was watching — and the conversation it came from. A change you asked for through a brAIn voice agent is filed as Voice, and one you asked for in the chat or the terminal as Person, marked as made via brAIn. Only what brAIn did unattended is filed under brAIn. That matters below: “turn the hall light back on” said to brAIn is you overriding the motion rule, not brAIn and the rule fighting.

The ledger also records the state of each entity just before brAIn’s call, which is what lets a fix’s Put them back set things back the way they were.

Overrides ride above the list

An override is a person putting something back within a few minutes of an automation moving it. The automation ran, nothing errored, and the light is off — so no check that reads Home Assistant can see it, and it is the clearest signal a house gives that an automation is wrong for it.

These rules keep it honest:

• The state has to actually differ. Pressing “on” after a rule turned it on is agreement, and counting it would put the best-behaved automation in your house at the top of the list.
• One automation move is undone once. Nudging a dimmer three times is one disagreement.
• A person includes voice. Putting something back by asking Home Assistant’s Assist or a brAIn agent counts the same as pressing the switch.
• An automation undoing an automation is not an override. That is a conflict, and a different finding — two rules that disagree, where which one wins depends on the order two triggers happened to fire in.

Past three in a day, auto.overridden files it — with a denominator, because three undos of a rule that ran three times is a rule that is wrong for your house, and three undos of one that ran three hundred is an unusual Tuesday.

Nothing is cached

The tab is fetched every visit. A timeline showing the house as it was when you last looked is the one thing a timeline may not do — and a cache of a stream is a second copy of the logbook to keep true.

Asking about it

Claude can read this too. explain_change and get_activity are read-only tools on the analyst’s list, so you can ask “what turned the porch light on last night?” in the chat or on the ask bar and get the chain rather than a guess. A voice agent at the default Voice assistant level can’t read the house-wide activity — it only reaches what you expose to Assist.