[Reactor] Bug when sending MQTT boolean payloads

[therealdb]

I have a rule that's driving my pool heater to match the solar excess. In the previous iteration, I checked for the status every minute, but I wanted something different and smarter. The logic is basically:

• run continuously from 9:15 to 18:15
• check for conditions, and
  • if there's solar excess, use the power to turn on the heater, then wait 1 minute to check again
  • turn off the heater, then wait 5 minutes to prevent frequent on/off cycles

I thought that this could be very similar to Reactor-Ex machina's logic, so I crafted a rule that's basically doing the same: an infinite loop from 9:15 to 18:15 that's checking for status and has a delay based on the heater's condition.

All went well, but after a couple of hours, I got this:

Reaction task "49683" failed due to an exception. Please see the log.
rule-liy7z3gf:S (Pool-Heater-Solar) step 0: Error: Task has run too much! Runaway?

and the rule was reset (and the heater was left on). Is that by design and I should adopt another strategy? What are others doing when they have a state machine?

With the EV charger I did two groups of condition, each triggering every x minutes based on the charger status, but this seems less smarter and very rudimental. Any suggestion is appreciated. Thanks.

[tunnus]

You could utilize pulse with repeat to control your heater. Not sure why you would want to run continuously, or do you assume there’s always excess during that time?

”Delay reset / sustained for” are good tools to increase hysteresis, to avoid too frequent changes

[Crille]

I'm combining global expressions and a rule to handle my pool heater. I monitor my electric meter and get real time values every 8-10 seconds.
I'm allowing it to run a little bit even on bought electricity and have an expression triggered by MQTT to manually override the rule with another rule.

Global Expressions:

Rule:

I use Sustained for and Delay reset to prevent flapping. I also handle manual and automatic triggers different. Automatic with sustained/delayed and manual no delays. The Set reaction starts the heater, sets the poolHeatTrigger to "auto" and sends a notification (if automatic start), the Reset reaction turns it off (with notification if started by auto logic).

That's my approach, hope it gives you some new ideas.

[therealdb]

@tunnus said in Long-running task in MSR:

You could utilize pulse with repeat to control your heater. Not sure why you would want to run continuously, or do you assume there’s always excess during that time?

Yes, I mostly have solar excess during the day, unless I'm charging the car. I have an 8.2kWp system, soon to be expanded to 12kWp. House is fully electric, but all is new, so consumption is moderate.
That's what I'm doing with my EV charger rule. Two groups, one to check for charging, the other for idle, with different timeouts. I was searching for something more sequentially, maybe. I don't know.

@Crille said in Long-running task in MSR:

I also handle manual and automatic triggers different. Automatic with sustained/delayed and manual no delays.

yep, I have a virtual device with modes. It's selectable from a dashboard (and via our bot), and you'd choose from:

• solar
• always on
• always off

Solar mode has conditions for pump, temperature threshold based on hour, rain, and exporting power, to give the EV charger the space to still charge the car at minimum, if necessary.

Thanks for the head-ups. Back to the drawing board

[therealdb]

I ended up using the same approach as in my rule for solar mode of the EV charger:

I left 4 seconds for the rule to reset, so it could "pulse" again in 4 secs and re-evaluate the conditions.