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.