And now say sorry to wife!
En nu gauw excuses aanbieden bij je vrouw!
I would however not use the wait but use a separate flow. A wash cycle can take quite long, and if you reboot or reload automations in the mean time the finished message will not happen. If you are worried the message flow will start without the start action taking place you can always make sure the end flow is only turned on when the washer starts, and turned off by the message itself.
1 Like
Ze mag blij zijn !! 5 minuten langer blijven zitten 
How to do so Edwin ? Looks promising
alias: '[Voice] - Washing Machine Lifecycle start'
trigger:
- platform: numeric_state
entity_id: sensor.power_38
above: 500
for: '00:01:00'
action:
- service: automation.turn_on
target:
entity_id: automation.voice_washing_machine_lifecycle_done
mode: single
alias: '[Voice] - Washing Machine Lifecycle done'
description: ''
trigger:
- platform: numeric_state
entity_id: sensor.power_38
for: '00:05:00'
below: 5
condition: []
action:
- service: tts.google_translate_say
data:
language: nl
entity_id: group.broadcast
message: De wasmachine is klaar. Je mag de was eruit halen
- service: notify.mobile_app_sm_g998b
data:
title: '{{ now().timestamp() | timestamp_local() }}'
message: Washing is done.
- service: automation.turn_off
target:
entity_id: automation.voice_washing_machine_lifecycle_done
mode: single
I use this:
a input select helper:
automation for the state:
alias: Wasdroger
description: ''
trigger:
- platform: numeric_state
entity_id: sensor.qubino_wasdroger_electric_consumption_w
for:
hours: 0
minutes: 0
seconds: 10
id: washing_was
above: '5'
- platform: numeric_state
entity_id: sensor.qubino_wasdroger_electric_consumption_w
for:
hours: 0
minutes: 2
seconds: 0
id: finished_was
above: '0.5'
below: '5'
- platform: numeric_state
entity_id: sensor.qubino_wasdroger_electric_consumption_w
for:
hours: 0
minutes: 2
seconds: 0
id: offstate_was
below: '0.5'
condition: []
action:
- choose:
- conditions:
- condition: trigger
id: washing_was
sequence:
- service: input_select.select_option
target:
entity_id: input_select.wasdroger
data:
option: Wassen
- conditions:
- condition: trigger
id: finished_was
sequence:
- service: input_select.select_option
target:
entity_id: input_select.wasdroger
data:
option: Klaar
- conditions:
- condition: trigger
id: offstate_was
sequence:
- service: input_select.select_option
target:
entity_id: input_select.wasdroger
data:
option: Uit
default: []
mode: single
automation for message:
alias: Was klaar
description: ''
trigger:
- platform: state
entity_id: input_select.wasdroger
to: Klaar
condition: []
action:
- service: notify.mobile_app_in2013
data:
message: Hallo, hier je wasmeisje. Ik ben klaar met mijn zware klus ;-)
- service: notify.mobile_app_zerkoefs_iphone
data:
message: Wasdroger is klaar
mode: single
This works even after a HA restart during the laundry
That is nice too, but my daughter would object to “wasmeisje” as being too sterotypical 
1 Like
wel, it’s not that I call my missis wasmeisje, I call the washing machine wasmeisje here
Thanks both (@Edwin_D @BebeMischa ), that would require a little more time… I’ll spend this week some to see if I can make it:
- Dummy Proof
- Wife Proof
- Fault Proof
- Discrimination Proof
You helped a lot !
Kr;
Bart
2 Likes
I get that, but a washer would probably feel non-binary, so might be want to called a “washen”. 
EDIT: oh my god, If you’d want to create a sensor for it, would that need to be a non_binary_sensor too? I’m not going to be able to handle that…
2 Likes
I asked my washer, how it feels. Did not get any answer.
So I looked up the dictionary, and our dear van Dale said: it’s a girl. I can’t help it…
1 Like
I’ll pass it on to my daughter, but she’ll not be amused…
2 Likes
At your own risk…
1 Like
Maybe my interpretation could be of use to any of you Using power consumption to show information (status, elapsed time, count) of cycles on a dish washer - #2 by hebom
This is a nice approach too. I was trying to keep as close as possible to the original approach to best illustrate possible improvements.
But maybe you should adjust the filters in your example because of the now required default. For expample the float filter should now be something like float(0). If you do not, the templates will produce errors on startup.
I would also consider adding an availability template to the sensor.
1 Like
Suggestion:
Instead of automations enabling/disabling one another (which the community has long concluded to be an anti-pattern) make the first automation set a flag, like an input_boolean, which is checked by the second automation’s condition and subsequently reset by it as well.
In fact, by employing a flag, the two automations can even be consolidated into one.
But it is silly to introduce a flag that does exactly the same as the state of the automation. If you disable the automation you decrease the workload for HA. Also you can easily see which automations are active. Why would disabling an automation be an antipattern if you don’t want the automation to do anything? Hiding that the automation is inactive inside the automation is worse i.m.o.
But it does depend on the reason, you shouldn’t do it for changes in the state of ‘normal’ entities such as temperature changes, lights being on or off, etc. Just don’t create a binary sensor to say “This automation is disabled”, and then not disable the automation. That is introducing confusion.
What I consider to be an antipattern is to put two separate triggers in one automation, only to then require if statements to make each trigger do something entirely different. Only because you think it is nice to have them grouped together? The name can group them too. The cleanest way is one behaviour per automation, together with all the triggers that may invoke that behaviour.
Your opinions on what’s purportedly “silly”, and how automations ought to work, are contrary to years of tried and true expertise established by the community. However, you are certainly free to express them, just know they reflect a lack of experience with Home Assistant.
So you are saying, because “The hammer” is a clearly established antipattern, you should never use hammers again? The point of antipatterns is to know when to avoid them. Not to be rigid.
I also explained why I think it is “silly” in this case - that is avoid having two mechanisms do the same thing. Maybe I should have avoided the word silly, sorry for that.
And this is not the first time you accuse me of being inexperienced, so by now you must know that is not the case.
1 Like