[FR] Support for additional sensors to improve cycle detection accuracy

[Machaeon]

Before You Submit

• I have searched the existing issues and this feature has not already been requested.
• This request is specifically about WashData, not Home Assistant core or a third-party integration.

Problem or Motivation

Currently, ha_washdata relies solely on power consumption patterns from smart plugs to detect and classify appliance cycles. While the existing shape-correlation matching algorithm is sophisticated, adding support for additional physical sensors would significantly improve detection accuracy, especially for distinguishing between similar cycles and identifying specific phases within a cycle.

Proposed Solution

Additional sensor types to complement the power consumption data:
Vibration sensors for washing machines:

• Detect spin cycles with high precision
• Distinguish between wash and spin phases
• Improve detection of pause periods (soaking)

Humidity sensors for dryers:

• Direct measurement of drying progress
• Precise detection of cycle completion
• Eliminate false "end detections" during cooling phases

Temperature sensors for both appliances:

• Track heating phases
• Improve energy consumption correlation
• Better distinguish between similar programs

Related Device Type

General / Not device-specific

Device Brand & Model (if device-specific)

No response

Alternatives Considered

No response

Additional Context

No response

[3dg1luk43]

I'm wondering how would you use temperature and humidity sensors with appliances. Let's say temperature makes sense a bit if you stick the sensor on front door, isolate it properly so ambient temperature does not poison data and wash 60 or 90 degrees. But Humidity? How would you setup device to monitor humidity?

[Machaeon]

For example, I’m currently using a temperature and humidity sensor located inside the dryer’s filter housing.

[AlexHunterCodes]

Since temperature and humidity sensors can be very slow to react and run on batteries (and therefore don't update very frequently), I don't know how useful or reliable they would be as sensors for profile matching. They'd have to be permanently powered to be practical, but also kept dry (or waterproof). It's wading into "bespoke WashData-specific ESPHome device" territory, and how many users will go to those kind of lengths to add more sensors for an unknown benefit?

Vibration might be viable, but it would again be very coarse and probably too low resolution. I know my washing machine's spin cycle would shake the sensor at too high a frequency for something like a Third Reality zigbee vibration sensor to handle. It wouldn't be able to update HA often enough for WashData to sample accurately. Something like a laser (or magnetic) tachometer looking through the front window would be a lot easier, and it would return a frequency in Hz instead of a raw sine wave that would need to be sampled; but I've never some across such a sensor suitable for home automation use. (or a motor encoder inside the machine somehow)

One use for vibration sensors might be to track specific events in the cycle, since they can detect one-off jolts and clunks that signify a new phase. For example, sticking them on the water inlet and drain hose to loosely detect when flow starts and stops.

Home Assistant has growing support for water meters and flow sensors. I think they would be far more practical for WashData as they can update at similar frequencies to smart plugs and track usage (optionally cost too). Manufacturers usually state how much water each profile should use in their manuals (at least they do in the EU for compliance reasons) and these values could be added to each profile by the user for WashData to compare against, just like it already does for cycle length.

Water meters would also allow for easier detection of standard phases like wash/rinse/drain, but also added phases like pre-wash or program variances due to load size or level of soiling.

[3dg1luk43]

@AlexHunterCodes thanks, strong +1 on the general direction, especially the idea of using extra sensors as phase anchors rather than trying to match against them directly.

Thinking about it a bit more, I'm less sold on water flow as a parallel matching channel than I was when I first read your comment. A washer only pulls water when it actually needs it (initial fill, then refills per rinse), so the flow signal isn't a smooth curve like power, it's a few bursts separated by long zero-flow stretches. That's not really something correlation/DTW can chew on the same way it does the power trace.

Where I do think water flow is useful:

• Total litres per program as a Stage-1 fast-reject gate, next to duration and energy. Cheap, no shape matching involved.
• Fill and drain events as phase markers (pre-wash starting, rinse ending, etc.), feeding into phase_assignment to sharpen phase boundaries and time-remaining.

Same goes for vibration: probably not a matching input, but great as a "spin started / spin ended" event.

Temperature and humidity are the ones I'm most skeptical about. Both are inherently slow to react, and most readily available HA sensors update on the order of minutes, not seconds. Even @Machaeon's filter-housing humidity placement (which is clever) is probably more of a coarse "drying is finishing" hint than something we can sample densely. At best they end up as binary flags ("heating active", "cool-down reached"), and the power trace already gives us the heating one for free.

If anyone here already has flow or humidity logged alongside their power data for a few cycles and is willing to share, that'd help me figure out which of these is actually worth a config-surface slot before I build anything.

[AlexHunterCodes]

"Phase anchors" is definitely a better term for what I was trying to say.

I'm less sold on water flow as a parallel matching channel than I was when I first read your comment. A washer only pulls water when it actually needs it (initial fill, then refills per rinse), so the flow signal isn't a smooth curve like power, it's a few bursts separated by long zero-flow stretches.

Yeah, it's a long shot. Watching my machine on its eco mode, it looks like it draws a different amount of water depending how heavy the load is, and will then draw a different amount of energy (draw max power for longer) to heat it depending on the temperature setting / profile. That in turn changes the total runtime and throws off matching until much later on in the run. The total quantities and the start/end are more useful than the rates, but the time those steps take might still be helpful.

So power and water consumption together could estimate the load and temp near the beginning of the cycle and hopefully create more accurate time estimates for variable profiles.

[AlexHunterCodes]

Had another idea: photodiodes or LED blink sensors like the ones for utility meters.

My washing machine's time delay mode is surprisingly spiky on the power graph. It sits drawing nothing for a while and checks its timer periodically as you'd expect, but it primes a lot more of the machine's electronics during those checks than it probably should. It's a 2s spike of 30-60W, so I think it gets as far as charging up capacitors and motor coils before it realises it has to wait some more and goes back to sleep.

That's more power than it consumes at the very start of a normal cycle, so it's enough to set off WashData prematurely even with the new config options.

Sensors stuck to the machine's status LEDs could directly read the machine's state with perfect accuracy:

• time delay or pause LED blinking = ignore spiky false starts until it stops blinking
• provide true phase anchors
• intercept pauses from the machine and pause detection/recording if initiated by the user, alert the user if the pause is unexpected (a fault) or if the profile has been configured to expect a pause (add softener/sanitiser, remove delicates, etc.)
• trigger a definitive force end event when the "done" LED turns on or the "door locked" LED turns off at the end of a run (instead of when the user manually opens the door later on).

Status LEDs could be solid on/off or blink, so they would need debouncing or some timer logic to translate flashes to meaningful states.