I have an air quality sensor that measures VOCs and I want to trigger an action if the value is bigger than 200.
I made this rule:
Correct. Any change in that sensor will cause the rule to trigger (if the other conditions are also met of course). You want to do the actual comparison to 200 in the trigger..
I have a similar rule, maybe try to rearrange yours like this:
Also, if this is the Eurotronic Air Quality Sensor, you may want to change the reporting threshold.
Disable the ‘send POST’ command for a test.
What is listening on that IP?
So, firstly, not sure what you are trying to accomplish with the private boolean. If the goal is to prevent it from having multiple triggers, then you should have it as a required expression instead of within the body. When it is used, the FIRST action should be to set it false. The location you have it set at does nothing. It sets it false and then immediately sets it back to true.
Secondly, by the same nature, the time between statement would be more approprate in the required expression.
Required expressions prevent the rule from even running if the conditions aren't met.
So, required expression of Private Boolean = False AND your Time Between statement.
Then set your trigger. If changed is causing too much load, it might be more appropriate to put the level in the trigger.
First Action, Cancel timed actions and set Private boolean to true. This cancels any instances of the rule that might be already running and then prevents the rule from being retriggered until it has run and the boolean is changed back.
Then, complete the actions you actually want. i.e. Turn on the switch with the post command.
Not sure what you intended with the delay. But, the way it is written, you are waiting for 45 minutes for some reason. If that is a delay to turn it back off, you never told it to turn off. It looks like your whole if statement is delayed. And since there is no required expression to prevent multiple triggers, you are flooding the switch turn on action and the rest of the if block it is tied to. It might be better to use a similar condition as the trigger to turn off the switch. In this case it would be a "wait for" the value to drop below some value (that is below your trigger). Then, at the end of the rule, set the private boolean back to true so it can run again.
See a similar rule I did for turning on the fan in the bathroom when the humidity is too high. In mine, I require the light in the bathroom to be on (meaning someone has turned on the light and is likely in the room) along with the private boolean to prevent the rule from even running.
Then when humidity is too high, I have it check to make sure the light/fan switch is not already on. If it is not, then, it turns on the light/fan and sends a notification.
Then it waits for the humidity to return to a lower level, turns off the fan, resets the private boolean, and exits.
The POST triggers only the first time the VOC goes over 200. After POST it sets private boolean to false, after 45 minutes it sets it back to true. It worked well for about a month and yesterday it started to cause the heavy load problem.
Behind the IP is an Esphome device, if it gets a POST it will turn the ventilation device to maximum speed (for preset time).
Should not, at least not for a single rule, but the advice you got above (moving some conditions into required expression or trigger itself) is best practice.
However:
or turn on action logging to observe actions running and their timing. If for some reason that POST takes longer to complete (or time out) than it takes to get more events, you might end up with overlapping instances. Moving the set pb to false as the first action in your new rule should prevent this.
This makes perfect sense, I'll edit the rule according to the tips I got here.
Thanks!
Download the Hubitat app
