So i have underfloor heating system, the heater is turned on or off based on the valves activity, if at least 1 valve is opened the heater will turn ON in 3 mins, is all valves are OFF the heater will turn off and cancel any delayed action.
analyzing the logs shows me that the event of switching the last valve OFF did not trigger the rule anymore, hence it didn't canceled the delay actions, hence my heater turned on even if all valves were off.
I'm pretty sure that is a bug and i'm not sure how to avoid it, the bug might have to do with the fact that sometimes all valves get turned off at once so because they change in a short period of the time they trigger the rule multiple times within few secs and somehow the last valve turning off fails to trigger the rule.
I think the issue is at 22:00:32.457 (Vana Liv + Camara) turns off, so that should re-trigger the rule and now they are all off and should cancel any cancellable delays.
Why do you have a delay on the cancel delay actions?
Try using two triggers, any turns on and another for any turns off. I haven't seen this in awhile but I have had issues with change triggers, but looking for a specific on or off would always work.
thanks, i thought as alternative to use a different trigger when all valves are off only but still i'd like to hear the opinion of a dev because it looks like a bug, I had to physically disable a valve and keep it open all the time as this is a dangerous bug for my heater, it makes it turn on basically with blocked water pipes so the pump can't circulate water forcing it and potentially damaging it.
The delay in cancel delay action was added as a potential fix to the bug as i thought maybe it didin't have time to read the last valve turning off but obviously didin't help, i removed it now.
Hard to say what's going on if the rule and logs you posted aren't set up the way you initially had the problem. The delay before cancelling actions is definitely a problem. You can see from the multiple On commands that there are multiple instances of the rule running.
I see both Off and off1() commands. What is the difference? Also the on is on1(). What is that?
Chasing down the issues with this specific rule may still not solve your issues. Rule Machine does not always work well with multiple triggers that can occur rapidly (usually within milliseconds). Even without intentionally adding that 3 second delay to the Cancel Delayed Actions, there is some time that elapses from the first trigger to the cancel action. Another trigger can occur in the interval.
There are a few options for this sort of automation:
Use the 'debounce contact' app that @bravenel wrote which you can find on this forum
Write a custom app
Use a different automation engine
I went with the last option. I use Node Red for automations with multiple triggers and delays since there are ways to 100% prevent multiple instances running at the same time.
If you're seeing this as a 'dangerous bug' then you shouldn't be using rule machine to control the situation. At a minimum you need other rules (preferably on other platforms like Node Red or a second hub) to monitor for the error condition and alert you when it occurs.
It's difficult to know what is really going on from these logs; if possible turn on descriptive text logging on the valves and include those devices in the log filter.
A race / timing issue would manifest this way.
This is good advice. One rule can Cancel Rule Timers on the other if needed.
Have you looked for a for-purpose device to automate the heater? If the equipment is expensive and the automation can damage it, there needs to be some kind of physical fail-safe in place (e.g. pressure or flow switch?).
"The delay before cancelling actions is definitely a problem"
there isn't any problem, all valves were turned off at the same time which were 3 or or 4 devices with no changes 1 hour beforehand so the canceling actions with 5 sec delay had plenty of time to cancel the 3 minutes delay from the heater.
You can clearly see the trigger is if a valve 'changes' and the last change that i circled in my screenshot did not triggered anything.
"I see both Off and off1() commands. What is the difference? Also the on is on1(). What is that?"
Is a double relay, to make sure the heater turns off I send the command on 1 channel then on both channels at once.
" At a minimum you need other rules "
I do, i have another rule which repeats the off signal to the heater several times when all valves are off and after 3 tries the heater is still reporting to be ON, i get a notification on my phone. The heater pump surely has a protection for overload as it worked before with a blocked circuit for few minutes but that doesn't mean I should force my luck.
I have adjusted my rule to this now and hopefully I'm avoiding the bug now.
You only issue the Cancel Delayed Action when all the trigger devices are Off. So every time one turns on, you get another instance of this rule running that is scheduling an On command for 3:30 in the future. Is that intentional? Why would you need to send another On 3:30 in the future if the heater is already on (or is already scheduled to be turned on)?
It's odd that the rule triggered 3 times from valves turning on at approximately 22:00:04, 22:00:08, and 22:00:09 (based on the On commands 3:30 later), but it only shows one of them is on at 22:00:09.187, the first line in the logs that shows us the device states.
Which devices turned on at 22:00:04 and 22:00:08? When did they turn off? The logs don't go back far enough to see if it was this one valve bouncing on/off, which would lead to the IF statement rapidly bouncing between true and false states. It would be very helpful to see the logs from 22:00:00 or earlier.
I see the missed trigger at 22:00:32, but it doesn't help that at the time of that trigger, there were at least three instances of this rule running, maybe more.
If I understand your rule logic, as others have suggested I'd try two rules:
__
Rule 1: Turn heater off
Trigger:
All valves off
Action:
Cancel delayed actions (prevents multiple Off commands if the last valve bounces closed/open/closed)
Cancel rule timers on rule 2 (prevents a previously scheduled On command from running later)
Delay 3 seconds (allows time for rule 2 to be canceled)
Turn off heater
__
Rule 2: Turn heater on
Required condition:
Heater is Off (cancel pending actions when required condition becomes false)
Trigger:
Any valve turns on
Actions:
Turn on heater, delayed 3:30
--
Rule 1 can only run when a valve is already on, since it is triggered by the change to off. So the heater should either be on or should be scheduled to be turned on within the next 3:30 when this rule runs.
The required condition for rule 2 ensures it will only run when the heater is not already on. This minimizes re-triggering of the rule every time another valve turns on. It will re-trigger when multiple valves are turned on within 3:30 of each other. Canceling pending actions when the required condition becomes false prevents sending an On command to the heater when it is already on and will clear out any instances of the rule that are still running when the heater turns on 3:30 after the first valve opened.
Hopefully others will double-check my logic here, but I think two rules like those would be much more reliable. It's still important to consider what the rules would do if a valve bounces rapidly from open to closed, triggering both rules in rapid succession. It think these rules will handle that, but I'm not 100% sure.
The new triggers you show will help reduce re-triggering since they only fire on any valve on or all valves off, but will still re-trigger when the 2nd or subsequent valve is turned on, and it can still bounce if the last On valve rapidly reports off/on (or off/on/off...). You would get an "any on" trigger, then an "all off" trigger, and then an "any on" trigger in that situation. I strongly suspect that's what happened in the example you posted above, but there is no way to tell without the logs starting from 22:00:00 that should show what was triggering the rule.
You haven't shown the other backup rule that you mentioned is also sending Off commands to the heater. If you can get the core rules running reliably, maybe that can be set up as a notification-only so you don't have another rule also sending Off commands to the heater and interacting with the first two rules.
I would even take it a step further and create a virtual switch device representing the "call for heat" state. One rule triggers on any valve on and turns on the virtual switch. A second rule turns off the virtual switch when all valves turn off. It won't matter how often individual valves turn on or off, the virtual switch will only create an off-to-on edge once (a single event) until they're all off again.
Then you can build other rules that react to the call for heat switch. One that triggers when the virtual switch turns on and stays for 3:30 (or whatever) then immediately turns on the heater. Another that triggers when the virtual switch turns off.
Even if you end up with more rules, I find this "separation of concerns" helps reduce the complexity of individual rules and makes things easier to troubleshoot. No need for delay cancellations, etc. You can also use this virtual switch in a conditional trigger or required expression if necessary/helpful.
thanks for the thorough answer , I will use your approach since is more optimized, I have the tendency to put as much as i can in 1 rule to avoid making more
But still that bug should be look into, I understand that the rule was triggered multiple times in a short period of the time but still that shouldn't happen
The heating algorithm got way more complex than I anticipated, that's why I try not to make too many rules to avoid confusing myself.
I have another rule for an external recirculation pump that is meant to turn on only when a certain number of water circuits are opened to help with the flow.
In my situation I had all four tire pressure sensors for my car updating within milliseconds of each other. The device driver would update and report all four values at once. When temperatures fell, all four might report low pressure and the notification rule would fire 4 times. Using a virtual switch did NOT prevent duplicate notifications. The switch was being turned on multiple times before the "on" status of the switch could be set. That prior discussion was here: Preventing double/concurrent activation - #6 by Alan_F
Multiple triggers within a few milliseconds may be an edge case for many automations, although in the case of my tire pressure rule it was pretty common. I've since moved that notification and anything else where I needed to deal with multiple rapid triggers to Node Red. In NR, a "trigger" node can ensure that only one message passes when multiple arrive, no matter how rapidly you fire messages at the input. In the case of the TPMS, I actually set it so all four tire pressures have to be received by a "join" node which then sends a single message containing all four values.
I suppose with as many devices as the OP has, it is theoretically possible for more than one to change state very close together and run into the same issue.
I can think of another possible solution - writing your own virtual switch driver and setting singleThreaded: true in the driver description section.
