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.
My solution was made for at least 4 reasons:
- 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.