Bugs on Rules

[ascillato]

Describe the bug

A clear and concise description of what the bug is.

Hi, found 3 Bugs on rules. Described below.

Also, make sure these boxes are checked [x] before submitting your issue - Thank you!

• Searched the problem in issues and in the wiki
• Hardware used : NodeMCU
• Provide the output of command status 0 :

19:01:03 CMD: status 0
19:01:03 RSL: Topic Recibido /status, Tamaño de Datos 1, Datos 0
19:01:03 RSL: Grupo 0, Índice 1, Comando STATUS, Datos 0
19:01:03 RSL: stat/sonoff/STATUS = {"Status":{"Module":18,"FriendlyName":["Sonoff","Sonoff2"],"Topic":"sonoff","ButtonTopic":"0","Power":1,"PowerOnState":3,"LedState":1,"SaveData":1,"SaveState":1,"ButtonRetain":0,"PowerRetain":0}}
19:01:03 RSL: stat/sonoff/STATUS1 = {"StatusPRM":{"Baudrate":115200,"GroupTopic":"sonoffs","OtaUrl":"http://sonoff.maddox.co.uk/tasmota/sonoff.bin","RestartReason":"External System","Uptime":"0T00:06:35","StartupUTC":"2018-05-19T21:54:28","Sleep":0,"BootCount":26,"SaveCount":81,"SaveAddress":"3FB000"}}
19:01:03 RSL: stat/sonoff/STATUS2 = {"StatusFWR":{"Version":"5.14.0a","BuildDateTime":"2018-05-19T18:53:10","Boot":31,"Core":"2_3_0","SDK":"1.5.3(aec24ac9)"}}
19:01:03 RSL: stat/sonoff/STATUS3 = {"StatusLOG":{"SerialLog":4,"WebLog":4,"SysLog":0,"LogHost":"","LogPort":514,"SSId":["NetWireless","NetWireless"],"TelePeriod":300,"SetOption":["00808009","55818000"]}}
19:01:03 RSL: stat/sonoff/STATUS4 = {"StatusMEM":{"ProgramSize":516,"Free":2552,"Heap":13,"ProgramFlashSize":4096,"FlashSize":4096,"FlashMode":3,"Features":["00002C0A","1F90A984","0C000010","01021792","00000000"]}}
19:01:03 RSL: stat/sonoff/STATUS5 = {"StatusNET":{"Hostname":"sonoff-1757","IPAddress":"192.168.1.6","Gateway":"192.168.1.1","Subnetmask":"255.255.255.0","DNSServer":"192.168.1.1","Mac":"5C:CF:7F:F7:A6:DD","Webserver":2,"WifiConfig":5}}
19:01:03 RSL: stat/sonoff/STATUS6 = {"StatusMQT":{"MqttHost":"192.168.1.117","MqttPort":1883,"MqttClientMask":"DVES_%06X","MqttClient":"DVES_F7A6DD","MqttUser":"homeassistant","MqttType":2,"MAX_PACKET_SIZE":1000,"KEEPALIVE":15}}
19:01:03 RSL: stat/sonoff/STATUS7 = {"StatusTIM":{"UTC":"Sat May 19 22:01:03 2018","Local":"Sat May 19 19:01:03 2018","StartDST":"Sun Mar 25 02:00:00 2018","EndDST":"Sun Oct 28 03:00:00 2018","Timezone":-3,"Sunrise":"08:31","Sunset":"18:25"}}
19:01:03 RSL: stat/sonoff/STATUS10 = {"StatusSNS":{"Time":"2018-05-19T19:01:03"}}
19:01:03 RSL: stat/sonoff/STATUS11 = {"StatusSTS":{"Time":"2018-05-19T19:01:03","Uptime":"0T00:06:35","Vcc":2.784,"POWER1":"ON","POWER2":"OFF","Wifi":{"AP":1,"SSId":"NetWireless","RSSI":50,"APMac":"18:D6:C7:80:38:2C"}}}

To Reproduce
Steps to reproduce the behavior:

There are 3 Bugs on rules.

1 - When using backlog command, the value of the trigger event is not stored on var1.
Example rule:
rule on event#setvar1 do var1 endon <- works as expected
rule on event#setvar1 do backlog var1; power1 %value% endon <- var1 is not updated

2 - If it used %var1% without being set before, it is not replaced by zero.
Example rule:
rule on event#setvar1 do var1 endon on event#info do publish stat/sonoff/info %var1% endon
Console:

18:55:12 CMD: rule

18:55:12 RSL: Topic Recibido /rule, Tamaño de Datos 0, Datos 
18:55:12 RSL: Grupo 0, Índice 1, Comando RULE, Datos 
18:55:12 RSL: stat/sonoff/RESULT = {"Rule":"ON","Once":"OFF","Rules":"on event#setvar1 do var1 endon on event#info do publish stat/sonoff/info %var1% endon"}

18:55:21 CMD: event info

18:55:21 RSL: Topic Recibido /event, Tamaño de Datos 4, Datos info
18:55:21 RSL: Grupo 0, Índice 1, Comando EVENT, Datos info
18:55:21 RUL: EVENT#INFO performs "publish stat/sonoff/info %var1%"
18:55:21 RSL: Topic Recibido /publish, Tamaño de Datos 23, Datos stat/sonoff/info %var1%
18:55:21 RSL: Grupo 0, Índice 1, Comando PUBLISH, Datos stat/sonoff/info %var1%
18:55:21 RSL: stat/sonoff/info = %var1%
18:55:21 RSL: stat/sonoff/RESULT = {"Event":"Done"}

18:55:39 CMD: event setvar1=1

18:55:39 RSL: Topic Recibido /event, Tamaño de Datos 9, Datos setvar1=1
18:55:39 RSL: Grupo 0, Índice 1, Comando EVENT, Datos setvar1=1
18:55:39 RSL: stat/sonoff/RESULT = {"Event":"Done"}

18:55:43 CMD: event info

18:55:43 RSL: Topic Recibido /event, Tamaño de Datos 4, Datos info
18:55:43 RSL: Grupo 0, Índice 1, Comando EVENT, Datos info
18:55:43 RUL: EVENT#INFO performs "publish stat/sonoff/info 1"
18:55:43 RSL: Topic Recibido /publish, Tamaño de Datos 18, Datos stat/sonoff/info 1
18:55:43 RSL: Grupo 0, Índice 1, Comando PUBLISH, Datos stat/sonoff/info 1
18:55:43 RSL: stat/sonoff/info = 1
18:55:43 RSL: stat/sonoff/RESULT = {"Event":"Done"}

3 - If it called event inside a rule without backlog Tasmota crash.
Example rule:
rule on event#init do event outputs=0 endon on event#outputs do backlog power1 %value% power2 0 endon
Tasmota Crash when doing on the console: event init

rule on event#init do backlog event outputs=0 endon on event#outputs do backlog power1 %value% power2 0 endon
Works as expected when doing on the console: event init

Expected behavior
A clear and concise description of what you expected to happen.
1- VAR1 saved if using backlog
2- %var1% to be replaced by 0 if not set before.
3- Use event without backlog command

Screenshots
If applicable, add screenshots to help explain your problem.
Not needed.

Additional context
Add any other context about the problem here.
Given above

(Please, remember to close the issue when the problem has been addressed)

[arendst]

Thnx again. Will study...

[arendst]

There are bugs and there are features....

Once vars is made global these issues pop up for several reasons.
Originally vars was supposed to satisfy rules only during execution of the rules once.

Then vars were made global providing expectation that I didn't envision.

1. the varx command is not a real command but was supposed to be a rule local way of storing a value to a local var to be used in the next rule within the rule set. It is therefore only managed by the rule interpreter and not the command interpreter. This is why it won't work when using the backlog command as the varx command will not be recognized. It's not a bug but more a way of life.

A working solution would be:
rule on event#setvar1 do var1 endon on event#setvar1 do power %var1% endon

2. if the var is not initialised it has a string length of 0 and will not be replaced with any value other than it's name. Changing it to 0 is a feature request not a bug.

3. calling an event within a rule will start a loop as the event will start the rule again and again while the initial rule has not yet finished. Using backlog makes the rule finish first before executing the next event from the rule. Using backlog is a workaround. Simple solution is to add a backlog command when an events is in the rule. Difficult solution is programming recursive rules leading to major memory use which the device won't handle.

All items have workarounds. Some items have inherited results. They are all explainable fro some reason.

Solutions:

1. as designed.
2. I'll change it to return an empty string if a variable has not been initialised as it is a safer solution in case of power command using a non-initialised variable resulting in just a status message.
3. I'll add the backlog command always when an event command is present in the command string.

[arendst]

Reconsidering!

I'll make the var (and mem) options a command making handling a lot easier and more versatile. A command like var1 would show it's value.

[ascillato]

Thanks 😄

[arendst]

Right.

So the following changes have been made:

1. using backlog the value will be stored now but the correct syntax is (and has always been (your solution where %value% was not entered worked but is now not supported anymore)):
   rule on event#setvar1 do var1 %value% endon
rule on event#setvar1 do backlog var1 %value%; power1 %value% endon
2. un-initialised vars and mems are now "empty" strings
3. if and event is used within a rule it will always be executed from the backlog to solve rule loops.

[arendst]

Also note that the following won't work:
rule on event#setvar1 do backlog var1 %value%; power1 %var1% endon

Well at least not as you probably would expect. The var1 value used by the power1 command will be the value present before the backlog command is executed. This is so because the rule will replace %var1% BEFORE the backlog commands are put in the backlog-log ;-).

[ascillato]

Thanks a lot! Very happy with the rules feature

[ascillato]

Hi @arendst ,

There is a bug with:

on event#test do power1 1 endon

Doing the command: event test, Tasmota crash.

If doing instead the rule with backlog:

on event#test do backlog power1 1 endon

It works as expected.

[arendst]

I cannot reproduce:

rule on event#test do power1 1 endon
16:56:09 CMD: rule on event#test do power1 1 endon
16:56:09 RSL: Group 0, Index 1, Command RULE, Data on event#test do power1 1 endon
16:56:09 MQT: stat/wemos6/RESULT = {"Rule":"ON","Once":"OFF","Rules":"on event#test do power1 1 endon"}
16:56:10 CFG: Saved to flash at F4, Count 258, Bytes 2560
power
16:56:17 CMD: power
16:56:17 RSL: Group 0, Index 1, Command POWER, Data 
16:56:17 MQT: stat/wemos6/RESULT = {"POWER":"OFF"}
16:56:17 MQT: stat/wemos6/POWER = OFF
event test
16:56:24 CMD: event test
16:56:24 RSL: Group 0, Index 1, Command EVENT, Data test
16:56:24 RUL: EVENT#TEST performs "power1 1"
16:56:24 RSL: Group 0, Index 1, Command POWER, Data 1
16:56:24 MQT: stat/wemos6/RESULT = {"POWER":"ON"}
16:56:24 MQT: stat/wemos6/POWER = ON
16:56:24 MQT: stat/wemos6/RESULT = {"Event":"Done"}
16:56:25 CFG: Saved to flash at FB, Count 259, Bytes 2560

There were problems before as noted in another issue (I can't find just now) but by moving the power handling to a sub-process that issue and the issue you encounter were gone...

Is it reproducable in your case? Does it always fail? I could think of a scenario where it would fail when the event command is executed just before 0.1 second moment the power sub-process is started.

[ascillato]

Hi,

I reflash with last version and works as expected. So may be I was testing on a device with old firmware. Sorry.

Everything is working now. Thanks 👍

Closing...