Washing machine, living on its own?

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 :smile:

1 Like

wel, it’s not that I call my missis wasmeisje, I call the washing machine wasmeisje here :stuck_out_tongue:

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:

  1. Dummy Proof
  2. Wife Proof
  3. Fault Proof
  4. 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”. :crazy_face:

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…

image

:smiley:

1 Like

I’ll pass it on to my daughter, but she’ll not be amused…

2 Likes

At your own risk… :smiley: :smiley: :smiley:

1 Like

I see we can ask van Dale who does what chores:

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

The opinions expressed in your previous post suggest someone relatively new to Home Assistant’s style of scripting.

You have yet to explain why it is bad. Saying “the community decided long ago” (if there even is such a thing) is not an explanation. Can you point me to a HA directive? I explained my reasons, and have got only disdain in response. If you think that will make people listen to you, think again.

By the way: I avoid scripting in my answers as much as I can by design. If there is a GUI based way I will use it. If there’s not, I use simple scripting constructs. I’m not trying to teach programming skills. I’m trying to point to easy, well understandable ways that also people without programming experience can understand. I’m one of those deadful GUI people :wink:

And I hope that when I am no longer there to maintain Home Assistant, my daughter or son can understand what I left behind.

I could explain it but, based on past discussions, you aren’t receptive to suggestions, let alone explanations, that don’t conform to your own limited experience with Home Assistant. The discussion in this thread is yet another example of it.

Feel free to continue creating a multitude of single-trigger automations, that can enable/disable one another, and are limited to only the scripting features exposed in the Automation Editor. If that’s what your experience tells you is optimal and sustainable, I won’t waste time discouraging you from it.

  • I said single behavior, multiple trigger, not single trigger.
  • One behaviour can be complex behaviour too.
  • I said GUI if possible, not GUI only
  • I explain, you refuse to do with an insult to follow
  • Simple is not something I avoid because it makes me look stupid.