Here’s something simple that you can experiment with and enhance.
- alias: example 1
trigger:
- platform: numeric_state
entity_id: sensor.washingmachinepower
above: 500
for: "00:01:00"
action:
- wait_for_trigger:
- platform: state
entity_id: sensor.washingmachinepower
to: 0
for: "00:00:05"
- service: persistent_notification.create
data:
title: "{{ now().timestamp() | timestamp_local() }}"
message: "Washing is done."
How it works:
-
It uses a Numeric State Trigger to trigger when power exceeds 500 and remains above 500 for a duration of at least a minute. You can adjust the duration to suit your needs. The point of using
for:is to ensure it doesn’t trigger due to a spurious, momentary power spike. -
After it triggers, it proceeds to execute
action:where it waits for another trigger, a State Trigger, when the power drops to 0 and remains 0 for a duration of 5 seconds (adjust to suit your needs or even eliminate it if you feel it’s not needed). -
Finally, it calls the persistent_notification service to post a message in the UI consisting of the current date and time and a brief description (change this to whatever service you prefer).
You can enhance wait_for_trigger with a wait_timeout to protect from waiting forever should, for some unexpected reason, the power never return to 0.
Washer Monitor
If you’re interested, I’m currently doing something a bit more sophisticated for my washing machine. Based on its power consumption characteristics over an entire washing cycle, I’m inferring what it’s doing.
I gathered data for five wash cycles and discovered that I could not determine the difference between power consumed during washing and rinsing because their respective power ranges overlapped (i.e. the same power consumption is reported for washing and rinsing).
Here’s a sample waveform of the stop/fill/wash/spin/drain phases followed by fill/wait phases (the trough) and then the rinse/spin/drain/stop phases.
The resulting Template Sensor can report:
- stop (no power consumed)
- fill (filling water for either washing or rinsing)
- run (agitation for either washing or rinsing phase)
- pulse (representing the power spike when the spin cycle begins after washing or rinsing)
- wait (short waiting period before the rinse cycle begins)
However it can’t differentiate between run being a wash or a rinse purely on power consumption (or fill or pulse).
The solution is an automation, triggered by changes to the Template Sensor, that steps through the discrete phases of a normal wash cycle:
- 'stop'
- 'wash fill'
- 'wash'
- 'wash spin'
- 'wash drain'
- 'rinse fill'
- 'rinse wait'
- 'rinse'
- 'rinse spin'
- 'rinse drain'
- 'unknown'
The phase are stored in an input_select and the automation steps through them based on the Template Sensor’s previous state and current state. In other words, if the Template Sensor changes from stop to fill, the automation is triggered and sets the input_select to wash fill. When it changes from fill to run, the input_select is set to wash. From run to pulse, sets it to wash spin and so on and so on.
This blog post by Phil Hawthorne inspired me to use an automation and input_select to report the washer’s current operating phase. I simply adapted it to use a Template Sensor because of the inability to distinguish between washing and rinsing phases directly from the current power consumption.
NOTE
The associated Template Sensor and automation are posted below.
