I have a plug that monitors power going to the hot tub. I want to be notified if it has been using power for several hours and then stops (i.e. heated up to temperature over the course of X hours) but not when it does its little cycles of power to top up the heat.
So in this graph…
I only want to be alerted after the large peak at the beginning, but not the smaller ones.
What is the syntax for this? I’ve tried various permutations.
There are probably more elegant ways, but I would do this in two automations. It would make use of a new helper you would add that flags the long heating event.
The first automation checks for the long heating event - trigger looks for power > 1000w, for 6 hours (make this longer than any of the other shorter cycles you would see, so it doesnt false trigger. The action would be to set the helper flag to ON.
The second automation checks for the falling edge transition of the power. The trigger would be power < 1000w, with an AND condition that the helper flag is ON. In the actions of the automation, be sure to reset the helper flag.
Should be easy to do in one automation.
Trigger on high power for xx hours, whatever the power and length threshold is.
Then in the actions part, do a “wait for event” waiting for the power to drop. Then do the action you want.
Am currently on mobile. If you need a sample code holler. Can send when on a keyboard.
yeah, a sample would be good. I’m failing to see what goes in what section on the Automation builder.
you didn’t say anything about your entities, so i threw together this sample.
description: ""
mode: single
trigger:
- platform: numeric_state
entity_id:
- input_number.test_number
for:
hours: 6
above: 50
condition: []
action:
- wait_for_trigger:
- platform: numeric_state
entity_id:
- input_number.test_number
below: 20
timeout:
hours: 6
- service: script.debugmsg
data:
debugtrace: hottub
title: come to temp
message: hottub has come to temperature... i think...
it triggers when my entity (input_number.test_number) goes above 50 for 6 hours. then waits for it to drop below 20 (and times out if it doesn’t do so for another 6 hours… just to make sure it doesn’t wait forever). after that it sends me a message.
is that what you want? some edge cases and stuff to pretty it up, but those are the bones.
Be advised that long durations like this are more susceptible to termination by a restart.
for:
hours: 6
timeout:
hours: 6
true point. the second one (timeout) was safety to ensure it doesn’t wait forever…so a restart is fine.
the first one is vulnerable to a restart, as is using timers and other similar. @craigmcfly, if it’s super important to you that it works even across reboots, then it gets more involved than my one straight forward automation… but certainly can be done…
The timeout is part of a wait_for_trigger which will be terminated by a restart.
right, but my point is that the purpose of that timeout is simply to protect against some error case (e.g. if the entity goes offline) so that the automation doesn’t wait forever… so a reboot actually is fine in that case.
still, point still holds… op needs to decide how important it is to survive reboots. if that’s critical, then it definitely gets more complex.
A reboot (or merely a restart of Home Assistant) terminates all automations that are busy executing their actions, like your example’s wait_for_trigger (that waits for up to 6 hours for the entity’s value to drop below 20).
Any automation that lingers in its action section (due to the use of wait_template, wait_for_trigger, delay, repeat, etc with long processing times) is vulnerable to being aborted by a restart (thereby failing to execute some or all of its actions). The longer the waiting/delay/number of iterations, the larger the 'window of opportunity ’ for termination.
An aborted automation that relies on a Numeric State Trigger is at a greater disadvantage owing to how the trigger operates (entity’s value crosses the threshold value). It may take a long time for the monitored entity to revert to the state needed to cause triggering again.
hi, thanks @armedad for the simple automation example. Learning something new every time I play with HA, and having fun at the same time!
@123 , thanks for the insight that long delays in automations expose the risk of missed / incomplete automations (due to restarts). That makes sense, and I think armedad was clear that his example was simplicity over those known risks.
I suppose the automatons could use time thresholds (to armedad’s point, all depends if the OP wants the automation to survive a reset). An automation could use the power rising transition trigger to get the time of the ‘ON’ transition (set the time of a Time/Date helper to now() ). A 2nd automaton, triggered by the falling edge transition, could check if the duration since the last ON transition is longer than the preconfigured limit (6hrs). If true, then perform an action.
actually easier than that. a timer can be configured to restore after a system restart:
so it’s not hard, but it does mean multiple automations and a timer helper. but haven’t heard back from op, so dunno if that’s important to them…
Thanks to everyone who’s commented. I’ll try some things out and comment with what worked.
I can’t see how I’d incorporate a timer into this, but I appreciate the link so I’ll have a read.
timer method.
automation 1)
when ever the entity hits your threshold, start the timer
automation 2)
whenever the entity falls below your threshold, stop the timer
automation 3) if the timer fires (ie, it’s been 6 hours where it hasn’t gotten stopped), do your thing.
(you can, of course, combine the 3 above into one, but logically it’s 3)
step 4: in configuration.yaml set restore: true for your timer to make sure it gets restored.
that’s the basic idea. you then also probably need to decide how you want to deal with what happens if home assistant is down/rebooting and while it’s doing that, the power threshold hits… so you might have another automation to fire on homeassistant_started and then check to see the current power state and handle that. or you can adjust the 3 automations to recognize the state (e.g. if the timer fires check to see if the temp fell below the threshold… meaning the “stop” event was missed.)
need to decide how important it is to be resilient… being resilient to a quick reboot doesn’t require that last bit of complexity if you’re ok betting that it’d be rare and not catestrophic for the power threshold to hit during the reboot. being resiient to sustained downtime, as you can see, is more involved.
Well, that worked nicely!
alias: "Hot tub up to temperature "
description: ""
trigger:
- platform: numeric_state
entity_id:
- sensor.plug_power
for:
hours: 2
minutes: 0
seconds: 0
above: 1800
condition: []
action:
- wait_for_trigger:
- platform: numeric_state
entity_id:
- sensor.plug_power
below: 50
- service: notify.my_mobile
metadata: {}
data:
message: "Hot tub is up to temperature "
mode: single
nice job! Only comment I would have is your trigger thresholds seem to be very close to the ON/OFF values in your chart. If these values were to fluctuate over time for any reason, the automation may not trigger. An ON and OFF threshold of 1500 might be more robust, based on the chart.
Also, you may want to test any other available functions in the hot tub like ‘pump with no heat’, just to be sure you don’t get false triggers.
Good point about the upper level. I’ll drop that down a bit.
Pump with no heat hits at about 100w, so I could in theory bring that one up a bit, too.
I’ll tinker with it over time, but for now I’m happy 