BREAK statement isn't working as expected

[csb0730]

Hello guys,
I'm trying to get following ruleset to work properly and have read all documentation I can find. But regardless what I'm doing I cannot get the BREAK working as expected (the following rules shouldn't be executed).

This is the ruleset:

Rule1
on Tele-DS18B20-1#Temperature DO event t1=%Value% endon
on event#t1 do ruletimer endon
on event#t1 do Backlog var5 %value%; mult5 0.75; <T1=%value%>; <T1_75=%var5%> endon
on event#t1<%mem1% do backlog var3 1; "rule1-3 T1 unter Schwellwert Pumpe immer EIN" break <=== break rule
on Tele-DS18B20-2#Temperature DO event t2=%Value% endon
on event#t2>%var5% DO backlog var3 0; "rule1-1 T2 > Grenzwert Pumpe AUS" endon <== this is executed in spite of break
on event#t2<%var5% DO backlog var3 1; "rule1-2 T2 < Grenzwert Pumpe EIN" endon

This is console output:

12:11:09.442 RUL: TELE-DS18B20-1#TEMPERATURE performs "backlog event t1=38.8"
12:11:09.456 RUL: TELE-DS18B20-2#TEMPERATURE performs "backlog event t2=34.7"
12:11:09.492 RSL: RESULT = {"Event":"Done"}
12:11:09.523 RUL: EVENT#T1 performs "ruletimer"
12:11:09.528 RSL: RESULT = {"T1":170,"T2":0,"T3":0,"T4":0,"T5":0,"T6":0,"T7":0,"T8":0}
12:11:09.542 RUL: EVENT#T1 performs "Backlog var5 38.8; mult5 0.75; <T1=38.8>; <T1_75=29.100>"
12:11:09.557 RUL: EVENT#T1<%MEM1% performs "backlog var3 1; "rule1-3 T1 unter Schwellwert Pumpe immer EIN""
12:11:09.600 RSL: RESULT = {"Event":"Done"}
==> This next rule should not be executed because of the BREAK in the rule before
12:11:09.640 RUL: EVENT#T2>%VAR5% performs "backlog var3 0; "rule1-1 T2 > Grenzwert Pumpe AUS"" <== NOK
12:11:09.659 RSL: RESULT = {"Var5":"38.8"}
12:11:09.909 RSL: RESULT = {"Mult5":"29.100"}
12:11:10.286 RSL: RESULT = {"Var3":"1"}
12:11:10.340 RUL: VAR3#STATE performs "backlog Power 1; "Rule 2 schaltet Ausgang auf 1""
12:11:10.400 RSL: RESULT = {"Var3":"0"}
12:11:10.449 RUL: VAR3#STATE performs "backlog Power 0; "Rule 2 schaltet Ausgang auf 0""
12:11:10.511 RSL: RESULT = {"POWER":"ON"}
12:11:10.514 RSL: POWER = ON
12:11:10.811 RSL: RESULT = {"POWER":"OFF"}
12:11:10.813 RSL: POWER = OFF

What can I do to get it work as expected? I mean to let break not execute any rule afterwards in a ruleset?
Am I doing something wrong?
Is there a relation between BREAK behaviour and event triggering after a break?

       Many thanks for any hint!

---

Background about device:

I'm using a Shelly 1.

Tasmota Version is 12.0.2
Version date and Time 2022.06.20 12:45:11
Core / SDK Version 2_7_4_9/2.2.2-dev(38a443e)

[barbudor]

Break is meant to be used with same trigger
Another trigger is another execution
Check again the examples

[csb0730]

That means when the second trigger fires (here: event#t2) then BREAK from (event#t1) does not have any effect?
Means ruleset execution goes on?

I'll check examples again. Many thanks so far.

[csb0730]

@barbudor
yes You're right. In all examples always the same trigger is used.

This is an excerpt from documentation about BREAK statement:

Using BREAK to simulate IF..ELSEIF..ELSE..ENDIF~

BREAK is an alternative to ENDON. BREAK will stop the execution for the triggers that follow. If a trigger that ends with BREAK fires, then the following triggers of that rule will not be executed. This allows to simulate IF..ELSEIF..ELSE..ENDIF

But the correct wording should be:

Using BREAK to simulate IF..ELSEIF..ELSE..ENDIF~

BREAK is an alternative to ENDON. BREAK will stop the execution for THE RULES OF THE SAME TRIGGER in a ruleset that follow. If a trigger that ends with BREAK fires, then the following RULES FOR THAT TRIGGER in the ruleset will not be executed. This allows to simulate IF..ELSEIF..ELSE..ENDIF

Is that correct?

[csb0730]

But when this is the behaviour of BREAK, how to stop execution of further rules in a ruleset by condition?
Is there a trick?
Is this impossible?

[barbudor]

1. Doc changes : looks good. You can make the edit using the pencil icon on the top right of the web page

2. I was not able to really understand what you want to achieve. Could you try to explain ? may be I could suggest a way

3. I see some strange things / error in your rules
   on event#t1 do ruletimer endon is missing the index of the timer and the duration
   <T1=%value%> this syntax is invalid, what are you trying to do ?

Those are also invalid, what are you trying to do ?
"rule1-3 T1 unter Schwellwert Pumpe immer EIN" break
"rule1-1 T2 > Grenzwert Pumpe AUS" endon
"rule1-2 T2 < Grenzwert Pumpe EIN" endon

[sfromis]

You need to be aware that rules are not some sort of programming sequence, each rule trigger is evaluated on it's own, and break can only work for the same trigger value, or for another value from the same JSON payload. Next JSON payload (including usage of the Event command) starts from the start. The thing is that a rule trigger is never a test of current value, but instead a test on the value from the event (not just the Event command) starting the rules engine. If no updating of the value occurs, triggers for that value are just not evaluated.

[csb0730]

Ok, I understand. Part by part it get's clear what happens :-)
That means that rule and event management is not exactly in sequence with source code. Not as simple as it looks in the first moment.

[csb0730]

@barbudor
as soon as it's completely clear what the behaviour is around BREAK I'll support for updating doc 👍

Regarding what I want to achieve I'll explain my code step by step:

Rule1
on Tele-DS18B20-1#Temperature DO event t1=%Value% endon

=> store temperature value in envent's t1 value for later use in several rules
teleperiod is 10s

on event#t1 do ruletimer endon

=> print ruletimer values in console for evaluation

on event#t1 do Backlog var5 %value%; mult5 0.75; <T1=%value%>; <T1_75=%var5%> endon

=> some preparations for later rules, <T1=%value%> and next statement <T1_75 ...> is for better format in console output

on event#t1<%mem1% do backlog var3 1; "rule1-3 T1 unter Schwellwert Pumpe immer EIN" break <== BREAK RULE

=> this rule should prevent further evaluation of this whole ruleset when temperature is too low
mem1 is 25, T1 is between 30 and 60 in standard operation, and < 25 when control should be off

on Tele-DS18B20-2#Temperature DO event t2=%Value% endon

=> this is for storing 2nd temperature value for control algorithm

on event#t2>%var5% DO backlog var3 0; "rule1-1 T2 > Grenzwert Pumpe AUS" endon <== this is executed in spite of break

=> decide whether to switch power ON or OFF by content of var3. This is done in rule2 ruleset by content of var3.
=> "rule1-1 T2 ...." is for print out good readable logging to console, the same for next rule

on event#t2<%var5% DO backlog var3 1; "rule1-2 T2 < Grenzwert Pumpe EIN" endon

=> same than before

My question is: Is it possible to achieve a real BREAK in a ruleset regardless if there are more triggers
behind the BREAK?

[barbudor]

store temperature value in envent's t1
Is meaningless
Event do not store values
If you want to store values you must use a variable

• mem is stored in flash and kept across reboot
• var is kept in ram and erase in case of reboot

When performing an event command the rules using the event as a trigger is executed right after. Event are often used for triggering rules from outide (mqtt command for example) or as some kind of 'subroutine' if you a multiple commands (backlog) that you want to be executed from different triggers

A "real break" means nothing for Rules that are trigger based. You may need to go for IF to prevent some executions.

I'll look more in details in your goal later today and may be able to suggest something

[sfromis]

When looking at rules, start by forgetting what you know about programming, the thinking is quite different with everything event-based, every trigger based on "something happening", never on "something being". If you want something more like "classic programming", look towards Berry with ESP32

[csb0730]

What do you mean with "Berry with ESP32"?

[sfromis]

Berry is a nice simple (but still decently modern) programming language which is included with Tasmota, when running on ESP32 chips instead of ESP8266.

[csb0730]

This looks nice, but I'm limited to ESP8266 ;-)

[csb0730]

When all is event driven and there is no real BREAK possible, I think the approach could be to move each control situation to a separate ruleset and activate rule1/2/3 as required.

My current approach was different:

Rule1 (on and off):

• collecting temperatures (only here), drive control algorithm, and feed VAR3 with result of control algorithm
• skip control algorithm with BREAK when temperature too low (this is not working now)

Rule2 (always on):

• provide a basic control interval (300s) and force power to 1 for a dedicated minimum time (70s)
• while power is forced to 1, disable Rule1
• set power by content of VAR3

Rule3 (always on):

• on boot set ruletimers to start values (300/70)

Algorithm should provide this behaviour of Power output:

  Rule2         Rule1            Rule2          Rule1
|1111111_----------------------|1111111_-++---+++---+++--------|

1 = Power on
+ = Power on
- = Power off
| = Limit of interval

I think when dispatching different jobs (the BREAK situation) to different rulesets this could provide a break-similar behaviour?

[barbudor]

In theory yes you can dynamically enable/disable rules
But everytime you do so, it will write the rule stats (on/off) to the flash so if that happens very often, that will help wearing the flash in shorter time.

I still can't figure out your algorithm
Would you be able to write it either in plain english, or in a pseudo-code, whatever is the most easy for you
We may find a way to move that to Rules

[csb0730]

Maybe I'll post all rulesets?

[csb0730]

My current version:

Rule1
on Tele-DS18B20-1#Temperature DO event t1=%Value% endon
on Tele-DS18B20-2#Temperature DO var2 %Value% endon
on event#t1 do ruletimer endon
on event#t1 do Backlog var5 %value%; mult5 0.75; <T1=%value%>; <T1_75=%var5%> endon
on event#t1<%mem1% do backlog var3 1; "rule1-3 T1 under min limit Power always ON" break
on var2#state>%var5% DO backlog var3 0; "rule1-1 T2 > threshold Power OFF" endon
on var2#state<%var5% DO backlog var3 1; "rule1-2 T2 < threshold Power ON" endon

Rule2
ON Rules#Timer=1 DO Backlog RuleTimer1 300; RuleTimer2 70; var4 1; rule1 0; <----- Rule2 Power ON------> ENDON
on rules#timer=2 do backlog var4 0; rule1 1; <-----Rule2 Power OFF------> endon
on var4#state=1 do var3 %var4% endon
ON var3#state DO backlog Power %var3%; "Rule 2 sets Power out to %var3%" ENDON

Rule3
on system#boot do backlog rule2 1; ruletimer1 3; <Systemstart SHELLY> endon

Rule2         Rule1            Rule2          Rule1
|1111111_----------------------|1111111_-++---+++---+++--------|

1 = Power on
+ = Power on
- = Power off
| = Limit of interval

I'll try to explain the goal of my code:

The code always has to switch on power if temperature 1 (T1) is lower than limit in MEM1.
If T1 is higher than MEM1 then control algorithm is working.
There is an interval of 300s.
In this interval power has to be switched ON for 70s.
If this 70s is over, control algorithm checks if 0.75*T1 > T2.
If yes power is switched ON
If no power is switched OFF
=> Teleperiod for control algorithm is 10s

[csb0730]

@barbudor
One next question which is not covered by doc: Is it mandatory to use the same trigger in a ruleset in one block or is it ok to mix them?

Example with my Rule1:

Rule1
on Tele-DS18B20-1#Temperature DO event t1=%Value% endon
on Tele-DS18B20-2#Temperature DO var2 %Value% endon
on event#t1 do ruletimer endon
on event#t1 do Backlog var5 %value%; mult5 0.75; <T1=%value%>; <T1_75=%var5%> endon
on event#t1<%mem1% do backlog var3 1; "rule1-3 T1 under min limit Power always ON" break
on var2#state>%var5% DO backlog var3 0; "rule1-1 T2 > threshold Power OFF" endon
on var2#state<%var5% DO backlog var3 1; "rule1-2 T2 < threshold Power ON" endon

equivalent with

Rule1
on Tele-DS18B20-1#Temperature DO event t1=%Value% endon
on Tele-DS18B20-2#Temperature DO var2 %Value% endon
on event#t1 do ruletimer endon
on event#t1 do Backlog var5 %value%; mult5 0.75; <T1=%value%>; <T1_75=%var5%> endon
on var2#state>%var5% DO backlog var3 0; "rule1-1 T2 > threshold Power OFF" endon
on var2#state<%var5% DO backlog var3 1; "rule1-2 T2 < threshold Power ON" endon
on event#t1<%mem1% do backlog var3 1; "rule1-3 T1 under min limit Power always ON" break    <== event#t1 triggered rule moved

Are they having the same result and command sequence? Or are all rules in a rule set depending from one trigger executed
in one block (independent from their position in rule set)?

[sfromis]

Outside of the effects of the options (like one-shot) for regulating behavior, and of course the cases break is designed to handle, each rule in a rule set is completely independent, without it mattering which rule set. Order only matters when the triggers reacts to the same event (like a sesnor payload) starting the rules engine. Note that your rules above has lots of highly invalid syntax - weird way of making comments?

[pkkrusty]

Also this ruleset depends on the readings from your two DS18B20 happening in the sequence 1->2 and the resulting triggers happening in a specific order. However, I'm not sure you'll get consistent behavior as is. I think var2 state might be evaluated before var5 gets set from the current reading of DS18B20-1. Since there is slightly more computation involved to set var5.

What is the purpose of on event#t1 do ruletimer endon? Debugging?

If I remember correctly, rules with same trigger are executed sequentially as written. But not sure if an entire backlog sequence would be completed before the next rule evaluates.

[csb0730]

Yes, rule on event#t1 do ruletimer endon is for debugging purpose.
Even the other possibly weird parts of the code like "rule1-1 T2 > threshold Power OFF" are for debugging.
Maybe there is a better method? Don't know but it works ;-)

[csb0730]

As I follow the discussion related this issue here I see that existing documentation related RULES is not as accurate as it needs to be to understand the real behavior!

It's mandatory to distinguish between PLC programming or any sequence like approach many programmers know.

The event driven mechanism, the three rule sets and their dependencies needs to have an own part in documentation!
This is non existent now!

[csb0730]

A call to the core maintainers: All which have this knowledge should assist !
=> What is executed when and how? This is the question. ==> Documentation!

[2Fblob]

@csb0730
Did you manage to find a way to break all the following rules in your code? I'm having the same issue where I want to disable a portion of rules whenever a switch is on, to gain some 'manual' control of execution.

I also agree the documentation is ambiguous and 3 years later this hasn't changed.
BREAK will stop the execution for the triggers that follow. If a trigger that ends with BREAK fires, then the following triggers of that rule will not be executed

It actually only applies to the next rule in the series, as you pointed!

Thanks

[sfromis]

Wrong. It applies to the whole rest of rules in the same rule set, but you need to be aware that it is only within each iteration of the rules engine, meaning only if all the trigger conditions are from the same event, like a sensor payload. It cannot work if using rules triggering on independent events, as each event will start the rules engine again, where old break are no longer in force.

Here's a demonstration test case for break really affecting the whole rest of the rule set

Rule1 on Event#test>5 do var9 5 break on Event#test>6 do var9 6 endon on Event#test>7 do var9 7 endon

Using the command Event test=10 would trigger all 3 rules if not using break after the first. If break only affected the next rule in the set, the third rule should fire with that command, but it does not. Hence, break works as documented, but you do have to remember the basic event-controlled principle of how rules work, and not treat it as "just" a way of doing if/else on independent variables.

And it is strictly speaking not about "same trigger", it can be different triggers on different fields from the same event, same JSON payload. A good case for this is sensors, where you can use break to reject based on one sensor, and only use other sensors from the same payload with following rule(s) if the first filtering rule passed.