Carlton, you write, if I understand correctly, that you left the starting and finishing thresholds to the defaults, and thatās why theyāre not showing up in the generated yaml. If youād changed them, they would show up as starting_hysteresis, starting_threshold, finishing_hysteresis, finishing_threshold, a bit like this:
Thank you for the information.
I thought that I would try it with the defaults listed but now I know they need to be changed.
Will try it and see what happens.
Thanks
I think that would easily and finally make automations based on this blueprint work if
a) automations have been reloaded
b) HA has been restarted
Both cases/events rendered my automations based on this blueprint useless during the last years, cause they āforgotā their starting_threshold and starting_hysterisis have been crossed already (the automation has been triggered already and is/was running). In short: currently this blueprint is not able to survive reloading automations. Possibly those additional triggers will fix this (and make my additional āfailsafe automationā useless).
I primarily use this blueprint to make my working desk power plug been switched off automatically after system has been shutdown/hibernated/removed.
Thank you. While I basically donāt like the approach of āoutsourced configuration dataā (by using helper entities as config parameters instead of handling all inside the blueprint/automation which is much more tidy and centralized) I will have a look at your blueprint. It looks like a very very VERY powerful one. Interesting is the external āonly Italianā HA Power Control part I donāt even get what it does, will probably head over to Google Translate to do the IT/EN or IT/DE job
Iām really quite happy with @Sbyx ones blueprint here, actually it works perfectā¦ as soon as the bug/optimization noted here has been fixed/implemented
@e-raser Well, I am working on a translation myself
Iād then ask HA Power Controlās author to approve that. Iām like 90% done, but thatās still unfinished.
I answered a question about that specifically, it should explain what it does:
Honestly, even if I do like this blueprint, the problem that you mention, that ācurrently this blueprint is not able to survive reloading automationsā is a big deal to me.
I actually doubt that adding the automation_reloaded and the start triggers would make a big difference. What theyād do instead is execute the pre_actions (Actions when starting threshold is crossed) and nothing more. Therefore, unless the appliance is still running and the power consumption is not steady (exactly 0.0W, indefinitely) the waiting for the trigger finishing_threshold would never end/happen.
The problem with state triggers that wait for some time to be valid is that they are completely nullified after home assistant reboots, and thereās no way of getting around this, if not using some āhelperā variables and possibly a state machine that can ārememberā what was happening before the blueprint was reloaded.
To me, it seems like this blueprint is conceptually made to work this way. Maybe itās just because itās very āunlikelyā that HA or the automations get reloaded during an applianceās cycle, or maybe because it wasnāt as meaningful to the author as it would have overcomplicated things. However, this happened many times already and deserves attention.
I wanted it to work even after Home Assistant reboots or automations get reloaded, so I made the raw logic as stateless as possible.
I wanted to be able to perform custom actions not just when the appliance finishes.
I wanted it to be more responsive to changes in power consumption and chose not to wait for some time to pass. I thought that this would be useful to measure how long a cycle takes to complete.
I wanted to make the appliance āawareā of being the cause of an overload.
Obviously, this solution needs 4 of those helper entities but, in my opinion, the trade-off is worth it.
Please note that pt. 4 is optional! In the sense that: when you configure my blueprint, you can leave the āAppliance Suspended entityā empty, and it should still work.
The only difference is that youāll never see the detached_overload state ever happen (you still have to put it in the state machine though).
Iāll update my documentation and mention it there as well.
* meaning: restarting HA as well as reloading automations (which might happen A LOT sometimes) donāt break automations based on this blueprint anymore. Only ādownsideā is of cause they get triggered and are constantly (shown as) running (attribute current: 1) until the numeric_state condition is met - which is therefore just a cosmetic issue I warmly buy for the mentioned benefits.
In my case I use a Zooz Z-Wave Plus Power Switch ZEN15 to report power consumption on my washing machine. I was planning to use this automation to get notified when the spin cycle is finished, since thatās usually a few minutes from the end of the full washer load.
During the spin cycle the power consumption can get as high as 400W, but occasionally the washer takes a pause during the spin such that the wattage falls back down to very nearly the idle wattage.
Bottom line: spin cycle instantaneous power consumption is not guaranteed to remain above a reasonably high threshold for even 10 seconds, even though the moving average is definitely above 100W for 5+ minutes.
So maybe detecting onset of the spin cycle is not the point, and I should just trigger āstartedā by the washer being something like 2x the idle wattage for X minutes, and āstoppedā at a later point when itās back to idle wattage for Y minutes, and pray that the pauses in the spin cycle donāt approach the idle wattage.
Anybody else with a ZEN15 and a washing machine in the same camp as me?
I came up with the 4 minutes because the āTumblefreshā option of the washer spins once every 5 minutes, if enabled. I hadnāt enabled it in this particular cycle, though. Making the finishing hysteresis longer than 5 minutes would cause the finish action never to be executed if I had turned on that option in the washer, which I usually do, but forgot this time.