Actually, it should be easier than that. Instead of making a separate automation, you could use one of the custom actions to call a script.
In that case, it would look something like this:
# This is your script
alias: Washing Machine Notifications
sequence:
- device_id: xxxxxx
domain: mobile_app
type: notify
title: Alert!
message: The washing machine is finished. Time to flip clothes to the dryer.
- service: script.turn_on
target:
entity_id: script.google_home_resume
data:
variables:
action:
- service: tts.cloud_say
data:
entity_id: media_player.speakers
message: >-
The washing machine is finished. Time to flip clothes to the
dryer.
cache: true
mode: single
icon: mdi:washing-machine
Then in your main automation, you just have to call the script in the according section āWhen a job cycle is finishedā:
# This goes into your configured automation
actions_job_cycle_ends:
- service: script.washing_machine_notifications
data: {}
Why services
Calling an external script unbundles the main automation from the services it calls. This way, even if your actions take a long time to execute, they should work just fine. Once a script is called, the main automation ādoesnāt careā about how long it takes to complete. To my understanding, services work like independent asynchronous blocks (this is why we have multiple modes of execution - Scripts - Home Assistant).
The behavior would instead be different if you placed time-consuming login in the actions section. In that case, the automation would synchronously try to execute everything in that block of Actions, and thatās not granted to happen since ASM is stateless and is free to stop/reboot whenever necessary.
Your solution likely doesnāt work because you have to indicate the state you are coming from:. In the near future, Iād likely make some sort of sub-blueprint that is tested and simplifies that kind of implementation.
Yes! I was thinking about this the other day. The automaton still works if you fake the switch by replacing it with a helper, but Iād like to have the option to disable that requirement.
Itāll ship in the next version, but these days have been crazy and development is taking longer than I expected
If I could have one wish, is that this blueprint will include also āDelayed Job Started durationā so that a job would be counted as started if the power consumption is over over a threshold for a set period of time, that would allow me to prevent false positive in my washing machine cycle, see my power consumption:
@chicknlil25 Nice to hear that your initial problem was solved.
It looks like you need to fine-tune your automation. The procedure can differ a lot from appliance to appliance, and most of the time this step is not even necessary (this is why Iām still trying to document this process and make it easier).
It looks like your appliance intermittently uses less power than the finishing power threshold causing the behavior you described.
You should use the āDelayed Job Completion durationā (delayed_job_completion_duration) option. I would set it to 10 seconds and see if the problem is solved.
Iām suggesting 10 seconds because it looks like that, on average, your ājob_completedā periods (the ones in light blue) last for approximately 6 seconds. Please be mindful that mine itās just an estimate! I had to count the pixels of your graphs for that
Feel free to change this value to something different if you want to, but read the warning, and consider that a smaller value is better.
Hello,
i have started using this Blueprint shortly and its been working great for a washing machine. However for dyer its misfires.
As you see from the image. Dryer at some point stops heating the drum and just spins it from time to time for an hour. During this period status periodically changes from ongoing to complete to idle to ongoingā¦ and so on.
Is there a cure for this? Which parameter should I adjust to make job complete recognition more reliable?
Yes, there is a fix! The problem seems to be the same as @chicknlil25 (here), and the solution proposed (here) should work for you as well. However, youāll likely have to set āDelayed Job Completion durationā (delayed_job_completion_duration) option to about 140 seconds.
Feel free to ask for help if this doesnāt solve your problem.
@leofabri I have just done one more washing cycle and noticed that there was not transition job_ongoing ā job_complete it just went str8 to idle. Which didnāt trigger notification automation.
It looks like that part of the problem is now gone!
I believe the automation is skipping the job_completed state because your power sensor is issuing power readings quite frequently, and the automation gets triggered immediately after the finishing power threshold is reached and the job is done. If my theory is correct, thereās a chance that the transition job_ongoing ā job_completed will happen sometimes, but itās completely unpredictable and it breaks the execution of the custom action you are trying to use.
Iāve addressed this issue in V3, but sadly, it has not been released yet. The next version will include some more timers, one of which will allow you to say for how long you want the job_completed state to persist before allowing the state machine to enter idle.
Here are your options:
A little hack: Slow down the polling rate of your smart socket. Look for an option that allows you to receive new power reads slower, and if you find one, set it to 60 seconds. Note that not all sockets allow you to set the polling interval.
Easier, temporary, but less elegant fix: Create an additional automation that detects when thereās a transition from job_completed ā idle.
Make a new automation. Copy and paste the following while in Edit YAML mode:
alias: "Washing Machine - Job Completed detection - Temporary Fix"
description: "This is a temporary fix. V3.0.0 will solve the issue."
mode: single
trigger:
- platform: state
entity_id:
- input_select.washing_machine_state_machine
from: job_ongoing
to: idle
id: job_done_trigger
condition:
- condition: trigger
id: job_done_trigger
action:
# Put your custom actions here
Add your actions, as you would in your custom action section in the main automation.
If you feel adventurous and you think you can make it, you could update straight to V3.0.0-dev.
a. Replace the existing blueprint with V3-dev by issuing this command in your VSCode terminal:
cd /config/blueprints/automation/leofabri && curl -sSL https://raw.githubusercontent.com/leofabri/hassio_appliance-status-monitor/release/v3.0.0-dev/appliance-status-monitor.yaml -O
b. Now we need to create the helpers (yes, there are a few more compared to V2.1.1). First, find your washing machine package (should be inside of /config/packages) and delete it. Now, open the terminal in your VSCode and execute the following command
You should see that a new package is created inside the washing_machine folder.
c. Verify/Reboot Home Assistant
d. Open your existing Washing Machine Automation ā Edit in YAML ā Copy and save the content you see on your PC because we are going to replace it entirely.
f. Remember to set the following values appliance_socket, appliance_power_sensor, appliance_starting_power_threshold, appliance_finishing_power_threshold. You can also use the visual mode to do this. The values of these variables should match the ones of the old yaml you saved in step d.
g. Save and perform step c. once more.
h. From now on, if you need to configure more appliances, please refer to the new V3 guide here.
Iāll do my best to release V3 as soon as possible.
hello, friend! I have my laundry running right now as I type this. Mostly succes thus far. It did alert once, relatively early in the process (and oops, just for a second time as Iām typing this!) but that had been it so far. Should I stretch out the 10 seconds to longer for next week? 12 or 15 seconds?
I think weāre muuuuuch closer to complete success though, which Iām extremely grateful for!
Any chance we can change the power consumption input to accept both watts and amps? the reason i ask is because the amp readings, at least on my setup seem to be significantly more steady than the watt readings:
Hey @leofabri - it went off 9 times in total. Iāve yet to be able to figure out a good way to get a solid, zoomed in view of a āshortā history (a la a washing machineās run time), so Iām not sure about how long that delay should be. This was definitely much better than previous runs though!
