Once a system has a few hundred moving parts, the interesting question stops being "is this entity ok?" and becomes "is anything wrong that I have not thought to look at?". Dashboards are bad at that, because they only show what you already decided to display. What you need at that point is not another dashboard but a colleague who reads them all overnight and cannot be offended by what it finds.
A house that announces things is a smoke alarm. A house that explains things is a colleague. The difference is one clause: not 'the light is on' but 'the light is on because the room got dark while the floor lamp was tricking the sensor'. It is more work to write and vastly less work to live with.
Explain the event, do not just announce it
When an alarm trips, the useful message is not "alarm". It is the evidence a person would gather before deciding whether to worry: which sensor fired first, what the neighbouring sensors did in the seconds around it, whether anything else in the home was moving, whether a door had been opened recently, what the weather was doing.
Assembling that automatically turns a startling notification into a judgement you can make from your phone. Most trips have an innocent explanation, and the difference between a system that says "alarm" and one that says "alarm, and here is why it was probably the wind" is the difference between panic and a shrug.
A nightly review of the evidence
The most valuable reporting mechanism here runs once a night: collect twenty-four hours of evidence (lights, alerts, doors, air, media, which automations fired and which did not) and have a language model review it against the house rules, then write a short report. What living with that colleague is like has its own page.
It looks for four things:
- Anomalies, behaviour that does not match the rules
- Suspicious silence, something that should have fired and did not
- Waste, heating or cooling with nobody home, lights in empty rooms
- System errors, with a judgement about which are actionable
Give it the state its rules depend on
A rule that says "lights cycling with no motion is expected while the home is in holiday mode" is useless if the evidence pack never includes whether holiday mode is on. The reviewer will say so, and being told "I could not check this" is itself a useful output.
Whenever you add a rule that keys off some state, add that state to the evidence in the same edit. Here that same-edit rule is enforced by habit; the mechanical version is a check that fails the change when the automations move and the rules block does not.
Label your evidence honestly
A subtle failure: an incident log written by several different automations, described to the reviewer as if every line came from one. It read a routine informational line as a critical event and reported a problem that did not exist. Ambiguous input produces confident wrong conclusions, from a model exactly as it would from a person.
Digests instead of interruptions
Not everything deserves a push at the moment it happens. Things that are true for days (devices offline, batteries getting low, config that references entities which no longer exist) belong in a daily or weekly digest. The test is simple: if I read this eight hours from now, is it still equally useful? If yes, it is a digest item, not an alert.
Watch the config, not just the devices
Automations accumulate references to entities that were renamed or removed. Nothing fails loudly; the automation just silently never matches again. A config auditor that lists references to non-existent entities catches a class of decay that no runtime check will.
Give it the same treatment as every other auditor: teach it to ignore entities that are missing on purpose, or it will cry wolf and you will stop reading it.
The nightly review is the part we would keep if we could keep only one thing. It is the house reading its own diary and occasionally wincing.