Rules, Timers, and RuleTimers

[Anil Garg]

I understand Rules a little bit.

I understand Timer with relay (on/off/Toggle).

Is there any place I can read about (1) Ruletimers  & (2) Timers with Rules trigger (as in the web GUI).

Thanks for the pointers.

Anil

[Anil Garg]

OK. It appears there are 8 rule timers:

17:53:52.831 CMD: ruletimer1
17:53:52.841 MQT: stat/tasmota_42226C/RESULT = {"T1":0,"T2":0,"T3":0,"T4":0,"T5":0,"T6":0,"T7":0,"T8":0}
17:53:53.595 MQT: tele/tasmota_42226C/STATE = {"Time":"2023-09-30T17:53:53","Uptime":"0T15:56:01","UptimeSec":57361,"Heap":113,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":3,"Berry":{"HeapUsed":4,"Objects":47},"POWER1":"OFF","POWER2":"OFF","POWER3":"OFF","POWER4":"OFF","POWER5":"OFF","POWER6":"OFF","POWER7":"OFF","POWER8":"ON","Wifi":{"AP":1,"SSId":"416OBP-IOT","BSSId":"B0:39:56:1C:CF:38","Channel":6,"Mode":"11n","RSSI":100,"Signal":-20,"LinkCount":3,"Downtime":"0T00:00:33"}}
17:55:02.648 CMD: ruletimer2
17:55:02.657 MQT: stat/tasmota_42226C/RESULT = {"T1":0,"T2":0,"T3":0,"T4":0,"T5":0,"T6":0,"T7":0,"T8":0}
17:55:18.115 CMD: ruletimer16
17:55:18.123 MQT: stat/tasmota_42226C/RESULT = {"Command":"Error"}
17:55:23.723 CMD: ruletimer10
17:55:23.730 MQT: stat/tasmota_42226C/RESULT = {"Command":"Error"}
17:55:29.075 CMD: ruletimer8
17:55:29.084 MQT: stat/tasmota_42226C/RESULT = {"T1":0,"T2":0,"T3":0,"T4":0,"T5":0,"T6":0,"T7":0,"T8":0}

[Anil Garg]

RuleTimer1 100 started a countdown from 100 does for 100 seconds.  At the end of the countdown there was no message on console.  However, I suspect, we can test for it value in a rule = or < or >  or similar.

[Andrew L]

ruletimer1 will trigger rules#timer=1 which can then perform actions.

So ruletimer1 700 will trigger rules#timer=1 after 10 minutes (700-100 seconds)

so then:

rule1

on rules#timer=1 do power1 1 endon

If you make a timer on the GUI with a Rule trigger, it will trigger on Clock#Timer=1 or Clock#Timer=2, etc...

rule1

on clock#timer=1 do power1 0 endon

[Andrew L]

Sorry, 700 is 700 seconds.  Got confused with pulsetime.

[Anil Garg]

I finally tested and put into operations.

Where we live in California, I wanted my variables to survive.  And, if I were to want to change start time, going into rules to edit on startup var values is more difficult.  So I decided to use mem on this device.  I do not know, at least at this time, when to use mem and when to use var.  Both have similar applications but mem survive their values after the power failure.

Here is what I implemented:

mem1    20            /*    minutes after midnight this schedule kicks in
mem2    2             /*    Starts the irrigation schedule from this number upto 8.
                            If mem2=4, it will irrigate 4,5,6, and 7

mem3    700           /*    600 seconds (its in 1/10 of second till 111 and {<n> minus 100} seconds from 112)

mem4    3600          /*    Watering spaced by 3600 seconds (1 hr) between stations
mem5    1 or 8        /*    Relay8 arms the valve and Relay1 is just an unused relay and so if Relay8 is off,
                            no actual irrigation will occur even if this schedule is executed

mem16   mem2          /*    Temporary scratchpad to retain the value on mem2


rule2
  on system#boot do backlog PowerOnState 0; interlock 2,3,4,5,6,7; calcres 0; Backlog0 Timezone 99; TimeStd 0,1,11,1,2,-480; TimeDst 0,2,3,1,2,-420 endon
  on time#minute=%mem1% do backlog calcres 0; mem16=%mem2%; power%mem5% 1; event t1=%mem4%; event t1=%mem2% endon
  on event#t1<8 do backlog pulsetime%value% %mem3%; power%mem2% 1; ruletimer1 %mem4%; mem2=mem2+1 endon
  on rules#timer=1 do backlog event t1=%mem2% endon
  on event#t1=8 do backlog mem2=%mem16% endon

I would love to hear any critiques or suggestions.

Thanks.

[Andrew L]

I don't think mem2=%mem2%+1 will do anything.  Rules are not like a programming language. You can't do normal math operations. Also can't use equal sign (=) except for event.

Need to use var1 to use add1 1, then assign to mem.  So you don't need the mem16 scratchpad. Just transfer mem2 to var2 and do your math operations. In case of power failure, you want the irrigation to continue where it left off? You need a trigger to check on system#boot where you're at in the schedule. But really, are power failures common? If you can count them on one hand, it's not worth worrying about.

When do you turn power8 off? Should be after power 7 has finished its cycle.

Your system#boot operations are mostly unecessary. You can do all those commands one time in console and they will persist.  See below:

mem1    20            /*    minutes after midnight this schedule kicks in
mem2    2             /*    Starts the irrigation schedule from this number upto 8.
                            If mem2=4, it will irrigate 4,5,6, and 7
mem3    700           /*    600 seconds (its in 1/10 of second till 111 and {<n> minus 100} seconds from 112)
mem4    3600          /*    Watering spaced by 3600 seconds (1 hr) between stations
mem5    1 or 8        /*    Relay8 arms the valve and Relay1 is just an unused relay and so if Relay8 is off,
                            no actual irrigation will occur even if this schedule is executed
mem16   mem2          /*    Temporary scratchpad to retain the value on mem2

backlog PowerOnState 0; interlock 2,3,4,5,6,7; calcres 0; Timezone 99; TimeStd 0,1,11,1,2,-480; TimeDst 0,2,3,1,2,-420, pulsetime 700

Rule2

  on time#minute=%mem1% do backlog var1 %mem2%; power%mem5% 1; event t1=%mem2% endon
  on event#t1<8 do backlog power%value% 1; ruletimer1 %mem4%; add1 1 endon
  on rules#timer=1 do backlog event t1=%var1% endon
  on event#t1=8 do backlog mem2 2; power7 0; power8 0 endon

(if you really want power failure robustness...)

  on var1#state>2 do backlog mem2 %var1%; power8 1; event t1=%mem2% endon

  on system#boot do var1 %mem2% endon

[Anil Garg]

I have tested it and I can confirm that it does.  It does not in console but does on the rule. 

[Andrew L]

You're right.  I did some testing and confirmed that it does work.  I have never seen it before, and it is not documented on the website. I'll bring it up on Discord to see if anyone knows when it was implemented.  Certainly makes variable manipulation easier.

[Justin Adie]

There is some mention of this syntax in the expressions in rules section of the manual (https://tasmota.github.io/docs/Rules/#conditional-rules).  So the parsing must have been in the core for some time.  I'm not aware of it being implemented outside of expressions though.

I'm torn about whether this is a "good thing".

--
You received this message because you are subscribed to the Google Groups "TasmotaUsers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonoffusers...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/sonoffusers/2d5b2cee-0493-4816-a320-4e8d79af408bn%40googlegroups.com.

[Andrew L]

Hm.  I think what we are seeing is the result of a build with

 #define USE_EXPRESSION // Add support for expression evaluation in rules (+3k2 code, +64 bytes mem)

Documentation seems to match what we are seeing. I haven't tested a build without that (all my builds include #define USE_EXPRESSION)