Most automations here are conveniences. A handful are not: they cut power to appliances, they decide whether an alarm may be interrupted, and they are the reason nobody comes home to a flooded kitchen. Those get written differently, and the differences are worth spelling out. They must keep working at three in the morning, during a power cut, while you are two countries away, conditions in which optimism is not an engineering material.
A handful of automations here can cut power, silence an alarm, or leave a heater on. They are held to a different standard from the ones that change lamp colours, because a lamp that is wrong is a joke and a heater that is wrong is a story you tell the insurer.
Rule one: the safe default has a direction, and it is not always “do nothing”
The received wisdom is that when data is missing, an automation should do nothing. That is right about half the time.
- A command that starts something (heating, cooling, a pump) must do nothing when unsure. The cost of a false positive is a machine running unattended.
- A command that stops something dangerous must lean the other way. If the leak sensor is unreachable, "do nothing" is not neutral; it is choosing to keep the appliance running.
This installation learned the point the expensive way, in the first category: an “off” command sent to an air conditioner turned out to be a power toggle, so the failure mode of guessing was not "nothing happens" but "the air conditioning starts, in an empty room, for four hours". That story has its own page. The generalisation is that you cannot pick a safe default until you know which way the harm points.
Rule two: gate on the real state, never on a mirror of it
It is convenient to mirror an alarm panel into a simple on/off helper and let automations read that. It is also how you get an alert firing during an actual alarm.
The panel has more states than anyone remembers, disarmed, arming, several armed modes, pending, triggered. The mirror has two. Every state that does not map cleanly gets rounded to whichever value the mirror last held, and the rounding happens silently. Worse, the mirror can drift: anything that sets it directly, or any reload that restores it from disk, and it now disagrees with the panel it claims to represent.
So the gate reads the panel itself, and is written as state != triggered rather
than as a list of permitted states. New states added by a future update fall on the permissive side
of a condition that is only about one specific thing, instead of silently disabling the gate.
One scope note, added after review: that fail-permissive shape is for gates that suppress an alert, where an unknown state failing toward "alert anyway" is the safe direction. Anything that reduces protection (disarming, unlocking, cutting a safety device) wants the opposite: a positive list of explicit states, where unknown fails toward "do not".
Rule three: an automatic remedy needs a list of things it may never touch
There is a circuit breaker here that watches the error rate per logger and, above a measured threshold, switches off the offending automation. It exists because a self-feeding loop once wrote 6.4 GB overnight and filled the disk.
An automatic remedy that disables automations is itself dangerous. So it carries a protect list, and after review the list is keyed on the platform's label registry rather than name substrings: anything labelled critical, alarms, leaks, smoke, gas, heating, is never disabled automatically, no matter how loudly it is failing. Those get a shout and a human. The substring version is the cautionary tale: it once protected a hallway dimmer while leaving a water heater exposed, purely by accident of naming.
And audit the converse. A protect list proves that protection exists; it says nothing about whether the protected set is the right set. Running the reverse query here, every automation whose name smells of safety, minus everything protected, found the boiler's last-resort cutoff hanging on a single substring and a severe-weather warning protected by nothing at all ("meteoalarm" does not contain "alarmo"; the ambience automation, by accident of naming, enjoyed better protection than the boiler).
A deliberate pass over the full list, no name patterns, found nine more, among them the external heartbeat and the watchdogs' watchdogs. The criterion worth writing down before the pass, so it cannot drift during it: would this automation's silent auto-disable be dangerous, not does it sound safety-adjacent.
Six rules, each learned by watching it get broken. Rules acquired any other way tend not to stick.
Rule four: suppression must never reach the top tier
Air-quality alerts here can be suppressed, deliberately, when the system has positively identified a benign cause, such as cooking. Without that, the flat would alarm every time someone fried something, and the alarm would be trained out of usefulness within a fortnight.
But the suppression is scoped. The top tier (smoke levels consistent with a fire, or readings beyond any plausible domestic activity) is never suppressed by any identification, however confident. Detection can lower a warning; it can never silence the one that matters. If your alert tiers all share one suppression path, you have one tier.
Rule five: the safety automation must verify, not assume
Anything one-way (infrared, a fire-and-forget command, a webhook into something you do not control) gives no acknowledgement. A safety automation built on such a channel must be paired with an independent check that the world actually changed: a thermometer, a current reading, a contact sensor.
And that check must be level-triggered, a loop that keeps asking for as long as the dangerous condition could be true, not a single confirmation a few seconds after the command. Sending is optimistic and happens once. Verification is skeptical and has to keep going.
Rule six: the alert path must not run inside the thing it protects
Covered at length in the dead man's switch, but it belongs in any list like this one. If the notification channel is a component of the system being watched, then the failure of that system is the one event it can never report. Something outside has to be expecting a signal, so that silence becomes the alarm.