Home automation, UPS telemetry, and energy-aware scheduling

Three uninterruptible power supplies feeding live wattage into Home Assistant, real-time utility pricing imported and modeled, and an AI scheduler that defers heavy work when electricity is expensive.

reliability engineering sensor integration cost modeling energy-aware scheduling Home Assistant

My lab kept rebooting. I worked the software checklist first and found nothing that explained it. The cause was utility power flicker at the wall. The fix was three UPS units, a shutdown order so hosts go down after the hosts that depend on them, and live energy telemetry so the next anomaly would be visible instead of inferred. Since the UPS units went in, the reboots stopped, and the monitoring stayed because the data is useful beyond outage prevention.

Home Assistant OS runs as a VM on the Hyper-V host. It pulls in the house's lighting, plugs, air-quality sensors, filters, thermostat, vacuum, TV, and speakers, with the full list folded below. Custom dashboards cover home control, air quality with PM2.5 tiles and 24-hour trends, the built-in energy panel, a custom energy-detail dashboard, and a floor plan with state overlays. The camera pipeline that shares this house layer is on the cameras page.

UPS telemetry

Three UPS units feed power data into Home Assistant through three different read paths. The Ethernet ports on these units are surge pass-throughs, not management cards, so monitoring runs over USB or local REST only.

The Windows integration had a hidden snag. The USB driver install hangs silently on a driver-trust prompt unless the publisher certificate is pre-trusted in the machine stores, and the symptom reads as communication lost, which looks like a broken UPS connection. Pre-trusting the certificate resolves it.

The sensor chain

Per-UPS power feeds into a summed partial home power entity. One unit is measured directly in watts and one is derived from load percentage, which assumes the load's power factor matches the unit's capacity rating. When a host is missing, its contribution defaults to zero so the sum keeps updating, which under-reports the total while that host is down. That subtotal combines with a template sum of eight smart-bulb power estimates, brightness-scaled from rated wattages of 7 to 9.5 watts each, producing total tracked home power.

A Riemann-sum integration converts tracked watts into kilowatt-hours, calculated per UPS and in total, then feeds the Energy Dashboard. This chain tracks only UPS-connected loads and lights. No whole-home meter exists in the lab. The utility's actual import remains the ground truth for total usage and cost, and the sensors populate the tracked portion of a tracked-versus-untracked breakdown. The assumed light wattages are design values, not measured quantities.

Hourly pricing, cost accrual, and bill import

The utility publishes real-time hourly electricity prices that change each day. A script pulls the 24-hour price map: it seeds the site cookie and posts for the current day's rates, and the next day's prices publish in the late afternoon.

A template sensor reads the current hour's rate from that data. Three derived values follow: an instantaneous cost rate in dollars per hour, a running cumulative cost for the day, and a daily total that resets at midnight.

The utility portal's data token is session-bound and regenerates on every login. Importing my own historical usage from my own account requires authenticating fresh through headless browser automation on each run, instead of storing a hard-coded credential. A real-bill PDF pipeline parses the actual bills month to month, and a temperature-driven cost model accrues hourly estimates. The custom energy-detail dashboard hosts the bill breakdown and cost detail that the built-in panel cannot show.

Energy-aware scheduling

The lab orchestrator's scheduler places work by declared capability, memory headroom, and energy price, and the price is one of the gates an order passes through before it runs. Long deep-think runs for non-admin users are deferred when the current price is above a ceiling and retried when it drops. Heavy training and rendering orders target the cheapest four-hour window instead of reacting to the price ceiling moment by moment. The window is picked from the rest of today's published prices plus tomorrow's once they land. If a window would run into hours with no published price, the scheduler declines to claim it and waits. The gate fails closed: with no current price at all, deferrable work for non-admin users is deferred and no cheapest window is claimed, so a data gap never runs anything at peak by accident. An energy chip shows the current price when it is above the run ceiling, a quick signal to the operator that deferrable work is being held.

This is the same scheduler that decides which GPU in the fleet takes which order.