(this is kind of minor but isn’t every minute excessive? you might also want to build in some hysteresis, so I feel the generic hygrostat might be solving all those nuances for you, thought I’ve never used it myself)
If you believe that then you have misunderstood how to use “event-based” triggers. The failure scenarios described in your first post can be mitigated by a proper combination of triggers. In other words, it should detect more than one “event” to make it more fault-tolerant. There’s no need to revert to periodic polling (which is an inefficient use of resources in an event-based system like Home Assistant).
Nevertheless, what you’re requesting is trivial to implement with the Generic Hygrostat integration and an automation that limits its operation to the desired hours. It provides the added benefit of allowing for the humidity level to be controllable via the UI.
Effectively, this is the same kind of request by users who attempt to create an automation to control a heater (the solution is to use the Generic Thermostat integration).
NOTE
You may wish to peruse the following topic which demonstrates how to make an automation more fault-tolerant.
Thanks. Prima facie, I find it impossible to predict what could go wrong, though I will attempt to study the issue further, when I can afford the time. For now, I will take the easy way out, and see how that goes.
Thanks again. I will have to devote some time to studying this Hygrostat integration.
I suggest your investment of time will provide you with better returns if you implement the Generic Hygrostat integration. After that, a simple automation can control when it is enabled/disabled.
I believe the generic hygrostat has the same bug as generic thermostat.
It will govern the humidity but not the device.
I noticed this when the room was warm and it allowed be to turn on the switch to the radiators, in my opinion the code should switch off the device in such cases.
I assume the hygrostat has the same issue since the code is probably based on each other.
@code-in-progress: Followed your instructions, and things work fine … except that the device does not get turned off @11PM. What am I doing wrong? Here’s the code:
In addition to what @Tinkerer said, I suspect it might be using the device id versus the entity id. I would try it with entity_id: <your entity> and see if that works. There is very little confidence that the device id is actually correct (I avoid using them at all and favor entities).
EDIT: Never respond to forum posts on a Monday morning before you’ve had coffee.
Thanks, guys, looks like @fantangelo’s solution might be what I need, as per this: leaving the before clause at 23:00:00, the automation will ignore the time_off event. By making it 23:00:01 I ensure that the time_off trigger is no longer ignored, hence the “Turn Off Dehumidifier” action gets performed. And that only happens once until 9:00 AM. Anyway, I will see what happens tonight, and report back.
Alright, guys, here I am reporting back: things work fine … except that once in a while the automation just does not go through, and here’s a screenshot of the trace:
It’s working exactly how you configured it. It triggers every minute and at 23:00:00. That means it attempts to trigger twice at the exact same time at 23:00:00. Which one of the two simultaneous trigger events is processed first may not always be the same. While the automation is busy processing the first trigger event, it blocks the second trigger event because the automation’s mode is single.
Changing the value of mode to queued will prevent blocking (meaning that while busy processing actions for the first trigger, it queues the second trigger) but it can potentially cause undesirable behavior. Here’s what I mean:
Imagine a scenario where the humidity is above 50 at 23:00:00 and then the Time Trigger is processed first and then immediately followed by the Time Pattern Trigger. The initial trigger results in turning off the humidifier. The subsequent trigger results in turning the humidifier back on. The humidifier is left on overnight.
I still recommend you use the Generic Hygrostat integration.
Thanks. Just to keep things simpler, I yanked out all that time_off trigger stuff, and made a separate automation that kills both basement dehumidifiers at 11:00 PM. It’s as simple as that. Now the state of both dehumidifiers is checked every minute between 9:00 AM and 11:00 PM and acted accordingly based on the humidity level, while the second independent automation simply turns them off at 11:00 PM.
And yes, I plan to look into the Generic Hygrostat asap.