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!_
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 <- var1is 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 eventinside a rule without backlogTasmota 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- VAR1saved if using backlog
2- %var1% to be replaced by 0 if not set before.
3- Use eventwithout backlogcommand
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)
Thnx again. Will study...
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.
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.
Thanks :smile:
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.
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 ;-).
Thanks a lot! Very happy with the rules feature
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.
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.
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 :+1:
Closing...