Rule "ON System#Boot" not triggered in tasmota.bin with SetOption55 0 #7552

mphilipp · 2020-01-18T21:25:35Z

PROBLEM DESCRIPTION

It seems that the rule trigger System#Boot is no longer executed since I upgraded my Shelly to Tasmota 8.1. On another device that is still on Tasmota 6.6. the same rule is working as expected.

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

{"Rule1":"ON","Once":"OFF","StopOnError":"OFF","Free":465,"Rules":"ON System#Boot DO Backlog Var1 0; Var2 0 ENDON"}

Provide the output of this command: Status 0:
Provide the output of the Console log output when you experience your issue; if applicable:
(Please use weblog 4 for more debug information)

00:00:00 CFG: Loaded from flash at FB, Count 33
00:00:00 QPC: Flag 0E
00:00:00 SRC: Restart
00:00:00 Project tasmota Garage Version 8.1.0(tasmota)-2_6_1
00:00:00 WIF: Checking connection...
00:00:00 WIF: Attempting connection...
00:00:00 WIF: Connecting to AP1 XXXX in mode 11N as shelly-garage...
00:00:01 WIF: Checking connection...
00:00:01 WIF: Attempting connection...
00:00:02 WIF: Checking connection...
00:00:02 WIF: Attempting connection...
00:00:04 WIF: Checking connection...
00:00:04 WIF: Attempting connection...
00:00:05 WIF: Checking connection...
00:00:05 WIF: Connected
00:00:05 HTP: Web server active on shelly-garage with IP address 192.168.178.50
22:19:38 NTP: Drift 0, (UTC) Sat Jan 18 21:19:38 2020, (DST) Sun Mar 29 02:00:00 2020, (STD) Sun Oct 25 03:00:00 2020
22:19:38 QPC: Reset
22:19:40 APP: Boot Count 9
22:19:40 CFG: Saved to flash at FA, Count 34, Bytes 4096
22:19:57 WIF: Checking connection...
22:19:57 WIF: Connected
22:19:59 CMD: var1
22:19:59 SRC: WebConsole from 192.168.178.46
22:19:59 CMD: Group 0, Index 1, Command "VAR", Data ""
22:19:59 RSL: stat/tasmota/RESULT = {"Var1":""}

TO REPRODUCE

Rule1 ON System#Boot DO Backlog Var1 0; Var2 0 ENDON
Rule1 1
Restart 1
Var1

EXPECTED BEHAVIOUR

On Tasmota 6.6 this returns {"Var1":"0"} as expected. But on Tasmota 8.1. it returns {"Var1":""}. Also 6.6. prints the message RUL: SYSTEM#BOOT performs "Backlog Var1 0; Var2 0" on the web console but on 8.1 there is no such message.

The text was updated successfully, but these errors were encountered:

Jason2866 · 2020-01-19T08:48:24Z

Your example rule is executed at boot. Cannot reproduce the issue.


00:00:00 CFG: Loaded from flash at F6, Count 65
00:00:00 Project sonoff GPS Version 8.1.0.4(tasmota)-STAGE
00:00:00 SNS: Hardware Serial
00:00:00 RSL: tele/sonoff-6111ED/SENSOR = {"Time":"1970-01-01T00:00:00","GPS":{"fil":0,"int":1},"FLOG":{"rec":0,"mode":0,"sec":0}}
00:00:00 WIF: Connecting to AP2 Jason_Home_WLAN in mode 11N as sonoff-6111ED-4589...
00:00:05 WIF: Connected
00:00:05 HTP: Web server active on sonoff-6111ED-4589 with IP address 192.168.2.134
09:47:02 MQT: Attempting connection...
09:47:05 MQT: Connected
09:47:05 MQT: tele/sonoff-6111ED/LWT = Online (retained)
09:47:05 MQT: cmnd/sonoff-6111ED/POWER = 
09:47:05 MQT: tele/sonoff-6111ED/INFO1 = {"Module":"Generic","Version":"8.1.0.4(tasmota)","FallbackTopic":"cmnd/sonoff-6111ED_fb/","GroupTopic":"cmnd/sonoffs/"}
09:47:05 MQT: tele/sonoff-6111ED/INFO2 = {"WebServerMode":"Admin","Hostname":"sonoff-6111ED-4589","IPAddress":"192.168.2.134"}
09:47:05 MQT: tele/sonoff-6111ED/INFO3 = {"RestartReason":"Software/System restart"}
09:47:05 RUL: SYSTEM#BOOT performs "Backlog Var1 0; Var2 0"
09:47:05 MQT: stat/sonoff-6111ED/RESULT = {"Var1":"0"}
09:47:05 MQT: stat/sonoff-6111ED/RESULT = {"Var2":"0"}
09:47:09 MQT: tele/sonoff-6111ED/STATE = {"Time":"2020-01-19T09:47:09","Uptime":"0T00:00:15","UptimeSec":15,"Vcc":3.078,"Heap":24,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Wifi":{"AP":2,"SSId":"Jason_Home_WLAN","BSSId":"00:A0:57:2A:BD:19","Channel":13,"RSSI":94,"Signal":-53,"LinkCount":1,"Downtime":"0T00:00:06"}}
09:47:09 MQT: tele/sonoff-6111ED/SENSOR = {"Time":"2020-01-19T09:47:09","GPS":{"lat":0.0000000,"lon":0.0000000,"alt":0.000,"hAcc":0.000,"vAcc":0.000},"FLOG":{"rec":0,"mode":0,"sec":0}}
09:47:17 CMD: Var1
09:47:17 MQT: stat/sonoff-6111ED/RESULT = {"Var1":"0"}

mphilipp · 2020-01-19T12:41:31Z

Thank you for looking into this!

Your observation left me quite puzzled. Therefore I completely reset the Shelly via esptool and flashed various firmware versions via serial.
It turned out that I was previously using sonoff-basic.bin. Apparently I missed that this has been renamed to tasmota-lite.bin and therefore accidentally flashed tasmota.bin during OTA upgrade.
When using tasmota-lite.bin v8.1.0 the System#Boot rule trigger is working again.

I do not fully understand how using the wrong binary can lead to this strange symptom while everything else works fine.
I'm thinking about how to prevent that this happens again.
Would it be possible to issue a warning during the OTA update process if the binary name is changed?
Or could the default OTA URL be changed to contain the binary name that is currently installed?

Regards,
Matthias

ascillato2 · 2020-01-19T15:01:49Z

Closing this issue as it has been answered.

Support Information (Guide)

See Wiki for more information.
See FAQ for common questions/answers and links if none of your question is in the list.
See Chat for more user experience.
See Community for forum.
See Code of Conduct

mphilipp · 2020-01-24T20:31:58Z

@ascillato2 could you please re-open this issue?

I did some debugging and it turned out that the the "on system#boot" rule is never triggered if you use the recommended release binary with its default settings and don't configure MQTT.

The reason is this code in MqttReconnect() in xdrv_02_mqtt.ino

#ifdef USE_DISCOVERY
#ifdef MQTT_HOST_DISCOVERY
        if (!strlen(SettingsText(SET_MQTT_HOST)) && !Wifi.mdns_begun) { return; }
#endif  // MQTT_HOST_DISCOVERY
#endif  // USE_DISCOVERY

For some reason, the system boot event is generated by the MQTT driver in MqttConnected().
The binary tasmota.bin is compiled with USE_DISCOVERY enabled, while tasmota-lite.bin is compiled without this #define.
If you do not set an MQTT host and mDNS is disabled, the function MqttConnected() never gets called and hence the "on system#boot" rule is not triggered.
Unfortunately the default settings after a fresh install of tasmota.bin match this condition and the function returns before generating the the system boot event.

I think the solution would be to make the system boot event independent from MQTT. Please have another look and comment.

Thanks and regards,
Matthias

ascillato · 2020-01-24T21:13:57Z

As designed. SYSTEM#BOOT only triggers if mqtt is on. If you want a trigger for an earlier event prior all the initialization, you can use ON POWER1#BOOT DO ....

ascillato · 2020-01-24T21:17:38Z

Nevertheless, @arendst what do you think of @mphilipp proposal?

arendst · 2020-01-25T11:03:12Z

I'll make sure there will be a SYSTEM#BOOT trigger when no MQTT is enabled.

arendst · 2020-01-25T11:45:56Z

Been looking over the code and I found the code part you mention:

The reason is this code in MqttReconnect() in xdrv_02_mqtt.ino
#ifdef USE_DISCOVERY #ifdef MQTT_HOST_DISCOVERY if (!strlen(SettingsText(SET_MQTT_HOST)) && !Wifi.mdns_begun) { return; } #endif // MQTT_HOST_DISCOVERY #endif // USE_DISCOVERY

It's not in MqttReconnect() but the more obvious MqttCheck().

And still it does trigger the SYSTEM#BOOT on a restart as can be seen here:

00:00:00 SRC: Restart
00:00:00 Project tasmota Wemos4 Version 8.1.0.4(tasmota)-STAGE
00:00:00 WIF: Attempting connection...
00:00:01 WIF: Network (re)scan started...
00:00:01 WIF: Attempting connection...
00:00:02 WIF: Attempting connection...
00:00:03 WIF: Attempting connection...
00:00:04 WIF: Network 0, AP1, SSId indebuurt, Channel 1, BSSId 74:83:C2:2A:F1:AC, RSSI -80, Encryption 1
00:00:04 WIF: Network 1, AP1, SSId indebuurt, Channel 11, BSSId 18:E8:29:CA:17:C1, RSSI -34, Encryption 1
00:00:04 WIF: Connecting to AP1 indebuurt in mode 11N as wemos4...
00:00:04 WIF: Attempting connection...
00:00:05 WIF: Attempting connection...
00:00:06 QPC: Reset
00:00:06 WIF: Attempting connection...
00:00:07 WIF: Connected
00:00:07 HTP: Web server active on wemos4 with IP address 192.168.2.223
12:41:30 NTP: Drift 0, (UTC) Sat Jan 25 11:41:29 2020, (DST) Sun Mar 29 02:00:00 2020, (STD) Sun Oct 25 03:00:00 2020
12:41:30 RSL: INFO1 = {"Module":"Generic","Version":"8.1.0.4(tasmota)","FallbackTopic":"cmnd/DVES_83BB10_fb/","GroupTopic":"cmnd/tasmotas/"}
12:41:30 RSL: INFO2 = {"WebServerMode":"Admin","Hostname":"wemos4","IPAddress":"192.168.2.223"}
12:41:30 RSL: INFO3 = {"RestartReason":"External System"}
12:41:30 RUL: SYSTEM#BOOT performs "Backlog Var1 0; Var2 0"
12:41:30 SRC: Rule
12:41:30 CMD: Group 0, Index 1, Command "BACKLOG", Data "Var1 0; Var2 0"
12:41:30 SRC: Backlog
12:41:30 CMD: Group 0, Index 1, Command "VAR", Data "0"
12:41:30 RSL: VAR = {"Var1":"0"}
12:41:30 APP: Boot Count 149
12:41:30 SRC: Backlog
12:41:30 CMD: Group 0, Index 2, Command "VAR", Data "0"
12:41:30 RSL: VAR = {"Var2":"0"}
12:41:31 CFG: Saved to flash at FA, Count 399, Bytes 4096

In the above case the mqqthost is set none and SetOption3 disabled mqtt all together.

So although the top code in MqttCheck() does not execute function MqttConnected is executed once anyway by the bottom part of MqttCheck() at a restart which will also execute the SYSTEM#BOOT trigger.

EDIT: I see where it goes wrong: When SetOption55 is OFF mdns will never work and an empty mqtthost will complete the lack of SYSTEM#BOOT trigger.

Will redesign mdns...

Fix trigger SYSTEM#BOOT when mdns is disabled an no mqqthost is set (#7552)

ascillato2 · 2020-01-25T18:03:51Z

@mphilipp

Hi, Theo has fixed this bug. Please test it. Thanks.

mphilipp · 2020-01-26T11:40:41Z

Thank you very much, Theo and Adrian! Now it works as expected.

barbudor · 2023-03-13T18:56:06Z

Your question as nothing to do with that closed issue
Please open a new Discussion (and not an Issue)
Thanks

ascillato2 closed this as completed Jan 19, 2020

ascillato2 added the troubleshooting Type - Troubleshooting label Jan 19, 2020

mphilipp changed the title ~~Rule "ON System#Boot" no longer working in 8.1~~ Rule "ON System#Boot" not triggered in tasmota.bin with default settings Jan 24, 2020

arendst reopened this Jan 25, 2020

arendst self-assigned this Jan 25, 2020

arendst added enhancement Type - Enhancement that will be worked on and removed troubleshooting Type - Troubleshooting labels Jan 25, 2020

arendst added troubleshooting Type - Troubleshooting enhancement Type - Enhancement that will be worked on and removed enhancement Type - Enhancement that will be worked on troubleshooting Type - Troubleshooting labels Jan 25, 2020

arendst added a commit that referenced this issue Jan 25, 2020

Fix trigger SYSTEM#BOOT

53e9321

Fix trigger SYSTEM#BOOT when mdns is disabled an no mqqthost is set (#7552)

arendst added the fixed Result - The work on the issue has ended label Jan 25, 2020

arendst changed the title ~~Rule "ON System#Boot" not triggered in tasmota.bin with default settings~~ Rule "ON System#Boot" not triggered in tasmota.bin with SetOption55 0 Jan 25, 2020

ascillato2 closed this as completed Jan 25, 2020

toszczyp mentioned this issue Jan 2, 2024

Rule not executed when no connection to configured MQTT. #20371

Closed

14 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Rule "ON System#Boot" not triggered in tasmota.bin with SetOption55 0 #7552

Rule "ON System#Boot" not triggered in tasmota.bin with SetOption55 0 #7552

mphilipp commented Jan 18, 2020

Jason2866 commented Jan 19, 2020 •

edited

mphilipp commented Jan 19, 2020

ascillato2 commented Jan 19, 2020

mphilipp commented Jan 24, 2020

ascillato commented Jan 24, 2020

ascillato commented Jan 24, 2020

arendst commented Jan 25, 2020

arendst commented Jan 25, 2020 •

edited

ascillato2 commented Jan 25, 2020

mphilipp commented Jan 26, 2020

barbudor commented Mar 13, 2023 •

edited

Rule "ON System#Boot" not triggered in tasmota.bin with SetOption55 0 #7552

Rule "ON System#Boot" not triggered in tasmota.bin with SetOption55 0 #7552

Comments

mphilipp commented Jan 18, 2020

PROBLEM DESCRIPTION

REQUESTED INFORMATION

TO REPRODUCE

EXPECTED BEHAVIOUR

Jason2866 commented Jan 19, 2020 • edited

mphilipp commented Jan 19, 2020

ascillato2 commented Jan 19, 2020

Support Information (Guide)

mphilipp commented Jan 24, 2020

ascillato commented Jan 24, 2020

ascillato commented Jan 24, 2020

arendst commented Jan 25, 2020

arendst commented Jan 25, 2020 • edited

ascillato2 commented Jan 25, 2020

mphilipp commented Jan 26, 2020

barbudor commented Mar 13, 2023 • edited

Jason2866 commented Jan 19, 2020 •

edited

arendst commented Jan 25, 2020 •

edited

barbudor commented Mar 13, 2023 •

edited