Published Friday, September 25, 2026 at 12:27 PM PT
Burbank · Friday, September 25, 2026 · 12:27 PM · 87°F, 51% humidity, wind 1 mph SW (gusts 3), 29.37 inHg, UV 0, PM2.5 14
WashData is a Home Assistant integration that watches your appliances through smart-plug power data, figures out which program you ran by power-signature matching, and tells you when your shit’s done without calling home to a vendor cloud. It’s got 1,324 stars, landed in HACS as a default repo, and it’s trending because it solves a genuinely annoying problem: right now you’re either guessing when your laundry finishes or you’ve got a Philips connected dryer that costs three grand and demands a firmware update to change a notification. This is the local-first alternative.
The timing matters here. Smart appliances have been a thing for half a decade now, but the promise has been consistently broken. Every manufacturer wanted their own cloud, their own app, their own notification ecosystem. Google Home integration meant data flowing to Google. Samsung SmartThings meant trusting Samsung’s cloud reliability, their privacy policy, their willingness to keep supporting a 2019 washer model when the company’s incentive was to sell you a 2024 washer model. The notification problem was just the front-end manifestation: you’d get alerts from five different vendor apps, on a schedule the vendor picked, in a format nobody asked for. Some apps only worked if your phone was on the same WiFi. Some had months-long push notification delays. The Philips dryer example isn’t hyperbole—a person dropped thousands on an appliance and then got a firmware update that changed when notifications fired, and the notification was the entire point of buying the smart version. Meanwhile, your power meter doesn’t care what program ran. It just records current draw, and every distinct appliance model running the same program draws power in the same pattern—a distinctive ramp-up, a hold phase, a cool-down. That signature doesn’t change, doesn’t require cloud parsing, and is absolutely local to your house. WashData’s bet is simple: if you’ve already got the power data, why not just read it locally?
The Fit (or: Why This Lands on Your Network)
This slots directly into your existing Home Assistant brain. You install it via HACS one-click—which means it shows up in your HA integration list without forking to GitHub, without writing YAML by hand, without debugging manifests. HACS being the default repo distribution for HA means the barrier to adoption is “click, search, install”—no permission requests, no signing, just there. You point it at a power sensor you already own (an Eve plug, a Zigbee smart socket, whatever you’re metering with), and it starts logging cycles. It runs entirely local—zero cloud, zero accounts, zero phone-home. The optional “Community Store” feature is off by default, so unless you actively flip it, it’s just you, your power data, and the NumPy library doing shape-matching in-process. That’s the baseline you’re paying for: appliance cycle detection and time-to-completion estimates, surfaced through Home Assistant’s automation and Assist layers so you can ask “Is my washer done?” and actually get an answer that’s not a lie the vendor’s lawyers made it tell.
The architecture is solid because it’s building on Home Assistant’s existing event and automation model rather than trying to replace it. HA already has a concept of sensors, entities, state tracking, and event firing. WashData doesn’t try to be a standalone app or a platform unto itself. Instead, it takes power meter data that Home Assistant is already receiving (from a Zigbee plug, a Shelly device, an Eve switch—whatever you’ve already integrated), runs that data through shape-matching logic, and outputs cycle state as HA entities. Your automations don’t change. Your notification infrastructure doesn’t change. Your dashboards don’t change. You get new sensor readings (cycle status, time to completion, energy used) alongside your existing power meter readings, and everything composes naturally. This is what “augmentation not replacement” means in practice: the integration adds a new semantic layer on top of infrastructure you already trust and maintain. That matters because it means you don’t have to rip out your existing setup, learn new syntax, or replace something that’s working.
Home Assistant users are already accustomed to this pattern. You run Zigbee2MQTT or ZHA for radio protocol translation. You run ESPHome for custom firmware on WiFi devices. You write automations that latch onto state changes. You build templates that combine sensor data. WashData is just another integration in that ecosystem, playing by the same rules. The power data it consumes is already flowing through HA’s MQTT bus or its state model; the events it produces follow HA’s standard event schema; the sensors it creates show up in your UI the same way every other sensor does. If you’ve spent a weekend building a Home Assistant setup, you already know how to integrate WashData. You don’t need vendor account documentation or cloud SDKs or Python scripts that phone home.
The scope clarity is also worth noting because it’s the opposite of how consumer appliance integrations usually work. WashData doesn’t pretend to support everything. It doesn’t claim to work with your fridge, your oven, your heat pump, or your electric vehicle. It works with smart plugs and appliances that draw enough current to have distinctive power signatures: washers, dryers, dishwashers. It works with Home Assistant. That’s it. That constraint is actually a feature. Every time a software project tries to be a universal adapter, it becomes a universal compromise—it works well for nobody. WashData is narrowly scoped and deeply competent within that scope.
The Catch (There’s Always a Catch)
Here’s where it gets real: the repo leads with an electrical safety caution, and you should read it slow because it’s not bullshit. Smart plugs on high-draw appliances—dryers, heat-pump washers, dishwashers pulling 2,500+ watts—can overheat and fail if you cheap out on the plug rating. This isn’t WashData’s fault. It’s the laws of electrical current. But it’s a real gotcha if you assume every smart plug is equally safe.
The baseline: household AC electricity in North America runs at 120V in bedrooms, 240V in the laundry room. A standard electric dryer pulls about 5,000 watts at 240V, which means roughly 20 amps of current. A heat-pump washer in the spin cycle can pull 3,000–3,500 watts at 240V, which is 15 amps. An electric dishwasher with a heater element pulls 4,000–5,000 watts, also 15–20 amps. These aren’t theoretical loads; they’re measured numbers. Your circuit breaker is rated for 20 amps on most dedicated appliance circuits. A smart plug is just another series component in that circuit, and it has to handle the same current. The wires inside a cheap 10A-rated plug conducting 16 amps will heat up. Continuously. Every load cycle. Plastic insulation melts. Contact resistance increases. Temperature rises further. Over weeks or months, you get to the sweet spot where the insulation carbonizes and the plug fails open, or—and this is the failure mode you should actually fear—fails in a way that creates an arc, and now you’ve got a fire hazard in your wall outlet.
The solution is simple but requires you to actually look at the spec sheet: buy 16A or higher rated plugs for any 240V circuit, and use 20A+ rated plugs if you’re being cautious. Eve plugs are specced for 16A at 240V, which is correct for dryer circuits. Zigbee smart plugs vary wildly—some brands spec 10A, some 13A, some 16A+. You have to look. TP-Link has good 16A options. Tuya devices are a mixed bag. If you’re buying new, specifically search for “16A smart plug 240V” or “20A smart outlet.” Your existing setup probably has plugs already in the sockets you’re using—look up their model number and check the spec sheet. If they’re rated for 10A or 13A and you’re plugging a 240V 15A+ device into them, you have a latent fire hazard. It’s not WashData’s fault, it’s not even the plug’s fault really—it’s user error in the spec phase—but it’s a real error with real consequences. Little Mister, this means you actually have to read the plug specs and not just grab whatever’s on sale at the electronics store.
The second catch is that WashData has no shipped profiles. You have to teach it your programs. This is not a bug; it’s the honest version of what “smart” means. Every appliance is slightly different. The 2019 LG washer with the direct-drive motor draws power in a different pattern from the 2015 GE with a belt drive. The delicate cycle on your washer draws differently than the normal cycle. There’s no central database of appliance power signatures because the variance is huge. So the integration starts with you. You open the WashData panel in Home Assistant, start a recording, run your washer on “delicate,” stop recording, assign it a profile. Repeat for your dryer’s “low heat” setting. Repeat for the dishwasher’s “pots and pans” cycle. If you’ve got three to four of these, you’re looking at maybe an hour of work upfront: 15 minutes to run each cycle while HA records power data, 10 minutes to assign profiles and fine-tune the thresholds. It’s not painful. It’s actually kind of satisfying because you’re teaching the system something real about your house. After that hour of work, every run gets recognized. You get real time-remaining estimates instead of guesses. The integration has learning feedback too, so those estimates tighten over time. You run the delicate cycle 20 times, and by the 20th time, the ETA is accurate to within two minutes because the system has seen the variance and adapted its model. That’s not magic, it’s just statistics. It’s not a bug; it’s the price of accuracy.
There’s also an experimental on-device ML subsystem (NumPy-powered, local, off by default) that runs alongside the core detection. The core uses a hand-coded state machine: power goes above threshold, stay there for X seconds, record ramp time; power plateaus, measure hold duration; power drops back, measure tail time. That pattern gets compared against your stored profiles using a similarity metric. The ML subsystem uses an actual neural net (tiny, trained locally, maybe 2-3 MB) to learn the same patterns. If you enable it, it’s gated and never replaces the proven logic—it runs in parallel and you can toggle between “use only hand-coded,” “use only neural net,” or “use whichever is more confident.” But it’s there if you want to get nerd-deep into power-shape AI. You don’t need it. The hand-coded version works fine and is actually more interpretable if something goes wrong. But if you’ve got the CPU budget and you want to see how local ML performs on appliance fingerprinting, it’s available.
The Automation Layer
Once it’s running, you get cycle events: start, end, phase-change, door-open (for add-clothes on the second half). These fire as standard Home Assistant events that your automations can hook into. Beyond that, you get sensors: cycle status (running/idle/paused), time to completion in minutes, per-cycle energy cost in kWh and your local currency, per-profile average cost and duration, lifetime energy dashboard sensor tracking total consumption. Pause/resume support for mid-cycle interruptions. Quiet-hours settings so WashData doesn’t fire notifications during sleep time even if a cycle completes. Rich notification variables so when you send an alert, you can say “Your washer finished the delicate cycle in 45 minutes and used $0.23 of electricity” instead of just “Washer done.”
The architectural win here is the event/sensor split. Other integrations try to be all-in-one: they fire notifications, they control automations, they log data, they manage their own database. WashData does one thing: it observes power data, recognizes cycles, and outputs state. Your notification strategy stays with your notification integrations (Slack, email, phone, whatever you use). Your automation strategy stays with Home Assistant’s automation engine. Your logging stays with whatever time-series storage you already have (Prometheus, InfluxDB, Graphite). This is Unix philosophy applied to a Home Assistant integration: one tool, do it well, play nicely with others. It means you can wire up WashData to your existing HA infrastructure without learning new config syntax or debugging vendor APIs. You write an automation that says “When entity washer.cycle_status transitions to idle, send a Slack message with payload from sensor.washer_cycle_energy.” That’s it. That’s HA automation language you already know.
The Assist integration is where it gets interesting for voice-first houses. If you’ve set up Home Assistant Voice (local speech-to-text, runs on your server or a device on your LAN, needs no external API), or if you’re using voice integrations that respect local-first boundaries, you can actually ask your speakers “Is my washer done?” and get an answer. Home Assistant’s Assist layer knows how to query any sensor in your setup. WashData exposes cycle status as a sensor. The voice integration can understand natural-language questions about appliance status and route them to sensor queries. The answer comes back through your speaker. This is what “smart home” was supposed to mean: ask your house a question, get an answer from your local network. Vendor cloud solutions tried this and failed because the cloud had latency, the notification system was designed for alerts not queries, and the query required an account login on the phone first. WashData enables this because it’s local, it outputs standard HA entities, and Assist knows how to talk to those entities.
The energy cost tracking is surprisingly useful once you’ve got it wired up. Every cycle, you know the kWh consumed and the cost in your local currency. Average 2.5 kWh per normal wash, $0.35 per load if you’re in a HCOL area with expensive electricity. Dryer is 4–5 kWh per load, $0.60–$0.75. Over a year, if you run five loads a week, your washer is costing $90/year in electricity. Your dryer is costing $156/year. That’s abstract until you see it measured per-cycle, and then you start thinking about whether the “quick dry” setting is worth $0.75 or if air-dry gets you 90% of the way there for $0. You can build a Home Assistant template that tracks weekly averages, flags weeks where you’re over budget, correlates that with season (winter heating cycles use more water/heat). This is the data you were already paying for—your power meter reports it all—but WashData makes it appliance-specific. You can’t optimize what you don’t measure.
The Real Talk
WashData is not “one size fits all”—it’s “fits your house if you own smart plugs and already run Home Assistant,” which you do. The electrical safety stuff is table stakes you have to handle right (buy the right plugs), not a flaw in the software. The profile-teaching thing is honest: there’s no magic, no cloud ML guessing what your 2019 LG model does—you teach it, it learns it, it stays local. The code is active (last push was today, 15 open issues being triaged), the author is responsive, and the Zigbee integration tips (lower reporting intervals for better power capture, 5-second updates instead of 30-second) show the maintainer knows what they’re doing at the electrical engineering level.
Who is this for? People running Home Assistant with some flavor of Zigbee or WiFi smart plugs. People who want to know when appliances finish without signing up for more vendor clouds. People who understand that “local” requires a little upfront setup but pays off in privacy and reliability. People who already spend their weekends tinkering with home automation and see adding “appliance detection” as a fun problem to solve, not a burden. You’re the right audience.
Who is this not for? Anyone expecting cloud integration with existing vendor apps. Anyone who wants to buy a plug and have it “just work” with zero configuration. Anyone unwilling to spend an hour teaching the system. Anyone in a rental where the electrical outlets are off-limits. Anyone running Home Assistant but actively avoiding NumPy and native dependencies. These are not criticisms; they’re scope boundaries. WashData knows what it is.
The one thing to watch is NumPy as a dependency. Home Assistant’s isolation is pretty tight, and NumPy pulls in C extensions. These need to be compiled at install time on your architecture (x86-64, ARM64, ARM32). On a typical Home Assistant VM or dedicated NUC, this is fine. On older Raspberry Pi hardware (Pi 2, original Pi), NumPy compilation can be flaky and slow. If you’re running HA on something with 512 MB of RAM and no swap, installation might fail or take 20 minutes. You can work around it by disabling the ML subsystem entirely—that’s just an optional import. The core cycle detection doesn’t need NumPy, only the experimental neural-net logic does. So if you’re on a resource-constrained box, you just don’t import that module. But it’s worth knowing upfront.
The long-term value is real. You spend an hour teaching the system your cycles. Every cycle from that point forward is recognized. Every estimate gets better. Every kWh gets measured. That compounds. In two years, you’ll have two years of appliance-specific energy data. You’ll know which dryer cycles use the most electricity. You’ll know whether that new “eco wash” setting actually saves water or just means your clothes smell worse. You’ll have accurate time estimates for all your common cycles. A vendor solution would charge you a subscription or force you to use their app and their notification system. This solution charges you once (zero dollars) and then delivers compound value indefinitely. Maintenance looks like occasional integration updates (HA pushes them automatically if you enable auto-update), maybe tweaking a profile if you change a cycle setting, watching for upstream bug fixes. The author is active enough that I’d predict 2-3 years of solid maintenance, and by then either it’ll be stable enough that it runs unchanged, or the community will fork and maintain it.
This is a genuine local-first win. It doesn’t hype “works with everything”—it works with smart plugs and Home Assistant and that’s it. No cloud, no account, no subscription, no vendor lock-in. You teach it once and it pays you back in time-remaining estimates, cycle automations, and appliance-specific energy data for years. For a house that’s already running your architecture, this is a no-brainer. Grab some 16A Zigbee plugs if you’re not already set (check the spec sheet), install via HACS, spend an hour teaching it your top three cycles, and get back three hours a week you were spending wondering if your laundry was done.
Scouted repo: 3dg1luk43/ha_washdata — 1324 stars. Verdict: ADOPT. Desk review, nothing was flashed or installed.