The unglamorous half of home automation: appliances, consumables and upkeep. Individually these are trivial. Together they remove a surprising amount of low-level administration from daily life. None of it will impress a dinner guest, which is rather the point.
Appliances are the honest part of a home: they either work or they do not, and they do not care about your dashboards. Getting them to tell you which is the case, locally and without a subscription, turned out to be the difference between one manufacturer and another.
Measure what the appliance will not tell you
Plenty of appliances report status but not consumption. A dishwasher may expose an energy forecast per programme while having no meter at all. If it sits on a power-monitoring plug, you can have both: latch the plug's cumulative reading at the start of a cycle, read it again at the end, and the difference is the real figure.
The general technique, capture a baseline at the start of an event because afterwards it is too late, applies far beyond appliances.
Latch what the API clears
Many appliance integrations blank useful fields the moment a cycle ends. The programme name becomes unknown at exactly the moment you want to say “your cottons have finished”, the way a witness goes vague at the trial. Copy the value into your own storage while the cycle runs, and read the copy afterwards.
Two independent ways to know a machine is running
A vendor cloud gives you phases and programme names; a power-monitoring plug gives you a reliable running/not-running signal that works when the cloud is down. Use the cloud for detail and the plug for truth. When the integration disconnects mid-cycle, and it will, the automations keep working and only the cosmetic detail is missing.
Consumables should arrive as a list, not as interruptions
Printer toner, vacuum tanks and filters, water softener salt, batteries: each one alone is a notification you will act on eventually. Together, on a weekly digest, they are a shopping list. The test for whether something belongs in a digest rather than a push is on the alerting page: would this still be equally useful in eight hours?
Track what is on its way
Parcel tracking is a small thing that removes a recurring background worry. The two states worth a message are “delivered” and “ready for collection”, everything in between is noise you did not need. “It has reached the sorting facility” is a status with no verb in it for you.
Run services only when you need them
A heavyweight vendor controller that exists to push firmware updates does not need to run all day. Starting it in the small hours, enabling its integration, letting it do the work and shutting it down again reclaims memory on a constrained machine and reduces what is exposed the rest of the time. The controller wakes in the small hours, does its rounds, and is put away again like a ladder.
The same thinking applies to update policy generally: automatic updates for add-ons and integrations, but never unattended for the core platform or the operating system. Those deserve a human who is at home, awake, and able to roll back.
Keep records that outlive the database
Recorder retention should be short. Anything that must survive that (a household ledger, event history, incident notes) belongs in plain files you control, written atomically, and backed up separately. See the architecture page for the three retention tiers.
The dishwasher, it should be recorded, has never once lied to us. We cannot say that about anything with a Wi-Fi radio and a marketing department.