Why most smart-home alerts get ignored

Most people who wire up smart-home notifications turn them off within a fortnight. Not because the sensors are wrong – the sensors are usually right – but because being told “the back door opened” forty times a day is the same as being told nothing.

The failure is in the rule, not the hardware. A sensor reports state. What you actually want to hear about is a situation, and the gap between those two is where good alerts are designed or lost.

Here is what we have learned building Spåna’s alert engine, and it applies whether you use us, Home Assistant, or something you wrote yourself.

An alert that fires on state is noise

“The door opened” is state. It is true dozens of times a day and almost never worth interrupting someone for.

“The door has been open for ten minutes” is a situation. It is true rarely, and when it is true you probably want to know.

The difference is a duration. It costs one parameter and it is the single highest-leverage thing you can add to a rule. Almost every alert that people eventually mute would have survived if it had a duration on it.

Our door rules come in exactly these two flavours for that reason: one fires the moment a door opens, the other only once it has stayed open past a threshold you set. The first is right for a front door when the house should be empty. The second is right for essentially everything else.

Pick a duration long enough to swallow normal behaviour. Ten minutes on a door ignores every ordinary coming and going and still catches the one that got left open. If you find yourself dismissing an alert as “that was fine”, the duration is too short.

Absence is harder than presence, and more useful

Presence is easy: something moved, fire an event. Absence has no event to hang off – nothing happens, and nothing continues to happen, and at some point that becomes the story.

This is the rule that matters most for checking in on someone living alone, and it cannot be event-driven. It has to be evaluated on a timer: every thirty seconds, ask whether the quiet has now gone on longer than it should have.

Two things make absence rules work in practice:

• Set the duration to the person, not the building. Three hours of stillness in the middle of a weekday is unremarkable for someone who naps and alarming for someone who never sits down.
• Give absence somewhere to hide. A trip out of the house looks exactly like a worrying silence unless you also watch the front door. Pairing an absence rule with a door sensor is what turns “no movement for four hours” from a false alarm into a real signal.

The same event means different things at different hours

Movement in a hallway at 3pm is someone getting a cup of tea. The identical sensor reading at 3am is worth knowing about.

No amount of tuning the motion rule fixes this, because the sensor data is identical. The rule needs to know what time it is. That is what quiet hours are for – you define the windows during which your home is normally still, and one specific rule consults them.

Two details that matter when you build this:

• Windows must cross midnight. A quiet period is almost always something like 23:00 to 06:00. If your implementation cannot express that, it is not useful.
• Allow more than one window. Night is the obvious one, but “while everyone is at work” is a second quiet period with completely different implications.

Thresholds should fire on the crossing, not on the reading

Here is a mistake that is easy to make and miserable to live with. You set an alert for “temperature below 10°C”, and your rule checks every incoming reading against the threshold. The room drops to 9.8°C and stays there overnight. Your sensor reports every few minutes. You wake up to two hundred notifications about the same cold room.

The rule should fire on the transition, not the state. Keep the last reading, compare it to the new one, and alert only when the value crossed the threshold going the direction you care about. One notification when the room gets cold, and nothing further until it warms up and gets cold again.

This is why our temperature rules are “drops below” and “rises above” rather than “is below” and “is above”. The verb is doing real work.

Repetition destroys trust faster than false positives

A single wrong alert is forgivable. The same alert five times in ten minutes teaches people to dismiss the whole channel without reading it, and once that habit forms you have lost the alert that actually mattered.

So the engine needs a cooldown. In ours, when a rule matches, we check whether an un-suppressed alert already exists for the same combination of name, room and area inside the cooldown window. If it does, the new alert is still recorded – you can see it in the history – but no push notification is sent.

That distinction is worth copying: record everything, notify sparingly. The history is for you when you go looking. The notification is an interruption, and interruptions have a budget.

A rule of thumb

After enough tuning, the test we keep coming back to is simple:

If you would not get up and walk to another room because of it, it should not be a push notification.

Everything else belongs in a feed you check when you feel like it. Most alerting setups fail because they push everything, and the genuinely important alert arrives in a stream the person has already stopped looking at.

Start with fewer rules than you think you want. Add a duration to every one of them. Then leave it alone for a week and count how many alerts you were glad to get – that number, not the number of sensors you own, is the thing to optimise.

Trying it without building it

Spåna ships eight rule kinds along these lines – arrival, continuous movement, absence, movement during quiet hours, door opened, door left open, and temperature crossing in either direction – on top of the IKEA DIRIGERA sensors you already have. Durations and thresholds are yours to set, and the cooldown is handled for you.

The beta is free. If you have opinions about what makes an alert worth reading, we would like to hear them.