Closed ElksInNC closed 2 years ago
Please raise this issue with Tasmota, as this behavior showing a problem with tasmota. The original ESP8266 has a much weaker CPU and it works fine with the amount of queries from TDM on boot.
What you want to do is to much for the ESP32solo1 (single core cpu). Using BLE is already borderline additionaly a Berry script for BLE, well lucky it works! Trying to do another job which generates wifi traffic (polling infos via mqtt) is to much. Keep in mind BLE and Wifi shares the same hardware. So the cpu has to switch and manage this. In general using BLE with ESP32 and do "other" stuff has a high change for instability
ESP32 Solo1 running latest Tasmota (11.0.0.4) TDM 0.2.11 on M1 Mac
Conditions ESP32 Solo1 Wall Switch also running BLE scanner berry script (https://github.com/tony-fav/tasmota-blerry)
When TDM starts up - or when device reboots and TDM does its initial polling of the device, the volume and rapidity of the requests overwhelms the ESP and causes a crash.
Device will happily run BLERRY for days without issue. Device will happily respond to TDM on boot or anytime TDM starts without Blerry. Device will - most of the time - continue to run if Blerry is running and stable when TDM does its initial polling. (it seems that there are critical times in the blerry script cycle that can overload if the TDM requests happen at exactly the same time.) Device will consistently crash and frequently boot loop on start if TDM is already running .
Author of Blerry and I have both encountered this issue.
It appears that on boot, the berry scripting module loading followed by the blerry script loading combined with the high volume TDM requests at broker connect are just too much for the CPU.
We can mitigate the bootloop / startup crash by delaying the launch of blerry for a period of time after boot to allow for the chance that TDM will ask for all of its data a boot.
A more elegant solution that would let these two processes peacefully co-exist without making the Solo1 faint would be to provide some sort of pacing for all of the MQTT requests that TDM makes upon first contact with a device. TDM asks a lot of the device in the first 5 seconds or so after contact.
I can provide more detailed logs from a serial connection if needed (the below is weblog from a production switch - but I have others that can be set up in a testbench mode with serial logging.