Most home automation is about the present: is the light on, is anyone home. The data you already collect can usually answer a more valuable question: what is about to need attention? Your appliances have been politely announcing their own funerals for years, in units nobody graphs.
Things wear out. Filters clog, batteries fade, motors develop opinions, and limescale accumulates with the patience of geology. A household discovers each of these at the worst available moment, which is why this page is about noticing them a fortnight earlier, when the discovery is merely inconvenient.
Batteries: forecast instead of react
The standard low-battery alert arrives as an interruption, usually when you do not have that cell type in the drawer. Everything needed for something better is already in the system: a percentage per device, the cell type, often a "last replaced" date. Fit a line through each device's recent history, extrapolate to a floor (not zero; devices die well before that), and aggregate what falls due in the next month into a shopping list by cell type. One order instead of five surprises.
Auditing the sleepers without waking them
Battery devices spend their lives asleep, which makes "is it dead?" a surprisingly rude question: the obvious check wakes the device, and enough scheduled politeness will flatten the battery you were trying to protect. It also fails anyway, because a sleeping sensor that ignores you is indistinguishable from a dead one. So the audit is passive by rule: mains-powered devices get probed, battery devices are judged only on what they volunteer, when they last reported and what their voltage was when they did. Nothing sleepy is ever woken to be asked how it slept.
Heating elements: watch energy per cycle
Scale on a water heater's element does not reduce the power it draws, and to first order the same energy still ends up in the water, so thin scale is invisible in these numbers. The trend is fishing for the later stages: an element insulated enough to overheat starts tripping its cutout and duty-cycling, cycles stretch, standby losses grow, and energy-per-cycle finally creeps. A lateish warning, honest only as a trend, and still much cheaper than the element choosing its own day to burn out.
Derive cycles from the power trace, not the switch: the socket can be on while the thermostat has already cut the element. Hysteresis (on above one threshold, off below a lower one), discard anything too short to be real, and never trust a single cycle, which depends entirely on how much hot water somebody drew. Only a rising median across weeks is a signal, and below a decent sample count the sensor declines to give a verdict.
Motors: watch the power factor, not the watts
A washing machine and a dishwasher each contain a motor that will eventually fail, and their power consumption says almost nothing until the day it does. The classic early signal is the power factor: a drying-out run capacitor makes an induction motor pull more reactive power for the same real work, and the ratio sags months ahead. Two caveats, learned from review: a worn bearing moves the numbers the other way (that failure lives in the energy-per-cycle trend), and an inverter-driven machine shows the wall its rectifier rather than its motor, so what is really tracked is an electrical fingerprint per programme, and drift in it says "something changed" without naming the part. It was being measured anyway, so it is free.
The trap that makes the naive version useless
Averaging the power factor over a whole cycle produces a number that mostly tracks which programme you chose: both machines spend most of a cycle running a heating element, which is purely resistive, so a hot wash looks healthier than a cold one and the trend you end up watching is your own laundry habits.
Why not just ask the appliance?
Both machines have integrations that report state, phase and programme, and for cycle boundaries they are a trap. The washer's cloud has reported Off while the drum was turning: it disconnects and keeps serving the last known state as current. The dishwasher's local link can go half-dead in the long drying tail, and one cycle spent seven hours officially 75 % done. Current draw cannot lie about whether a machine is running, so power stays the spine and the integrations are joined on as context, which matters more than the boundaries would have: spin speed is a large confounder (1200 rpm and a 30-degree tumble are different operating points), so the trend is computed within the largest programme class and says so when it has to pool.
A string that means "no value" is still a value
The washer's phase sensor reports the literal text Unavailable, a string in a
perfectly available entity, which every "does this have a value?" check passes happily. Its load
sensor reports 65535, the firmware's way of saying it does not know. Charted, that
is a 65-tonne wash. Any join from a vendor integration needs an explicit list of placeholders to
discard, or you get a well-populated column recording a programme called "Unavailable". And check
what each plug exposes: one of these reports apparent power, the other only volts and amps, so
its apparent power is computed as the product. A product line is not consistent with itself.
Refusing to give a verdict
Every cycle goes to a file (duration, energy, peak draw, motor-band power factor, and how many samples supported it) and the detector offers no opinion below eight usable cycles. Above that it compares the median of the newest third against the oldest and reports a relative fall. The thresholds are uncalibrated, because nobody has a failing motor to hand, so they are set to be quiet and the log is the real product. A detector that admits it is still learning beats one that produces a confident number from four data points.
The mundane one that pays off constantly
Washing machines smell because the door is left shut on a damp drum. The data to prevent that is trivial, a finished cycle and a door state, and no appliance does it for you. A gentle reminder two hours after the cycle, only if the door is still closed, only if somebody is home, and read from the power trace so that it works when the vendor cloud is down, is one of the highest satisfaction-per-line automations you can write.
Consumables, and the same shape everywhere
Once you notice the pattern it repeats: filters, tanks, brushes, cleaning cycles. Find the quantity that trends rather than the one that alarms; project it forward crudely, since order-of-magnitude is enough to act on; batch the output into a single list rather than a series of interruptions.
None of it is dramatic. That is the point. Drama is what you get when you skip this page.