AM43 controller keeps stopping

[Kite-Smurf]

AM43 controller keeps stopping when multiple clients are in range. (three at this time) log files available here: Download link

[buxtronix]

I'm seeing an exception and backtrace in the logs.

[17:51:42.296] - [COM4] - [>>] - abort() was called at PC 0x401b7267 on core 1
[17:51:42.303] - [COM4] - [>>] -
[17:51:42.303] - [COM4] - [>>] - Backtrace: 0x40091f40:0x3ffcec00 0x40092171:0x3ffcec20 0x401b7267:0x3ffcec40 0x401b72ae:0x3ffcec60 0x401
b61ff:0x3ffcec80 0x401b62f2:0x3ffceca0 0x401b62a9:0x3ffcecc0 0x400d5a2b:0x3ffcece0 0x400d44ce:0x3ffced20 0x400d32d6:0x3ffced40 0x400dc829
:0x3ffcedd0 0x4008e689:0x3ffcedf0

Could you help me by installing the ESP exception decoder in Arduino and running the backtrace through it? (you might have to recompile/upload once the decoder is installed).

https://github.com/me-no-dev/EspExceptionDecoder

[Kite-Smurf]

Hi Thanks for help! This is the translation of the backtrace: Decoding stack results 0x400943b0: invoke_abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c line 155 0x400945e1: abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c line 170 0x401bae77: __cxxabiv1::__terminate(void (*)()) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc line 47 0x401baebe: std::terminate() at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_terminate.cc line 57 0x401b9e0f: __cxxabiv1::__cxa_throw(void*, std::type_info*, void (*)(void*)) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/eh_throw.cc line 87 0x401b9f02: operator new(unsigned int) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_op.cc line 54 0x401b9eb9: operator new[](unsigned int) at /builds/idf/crosstool-NG/.build/src/gcc-5.2.0/libstdc++-v3/libsupc++/new_opv.cc line 32 0x400d5e5f: WiFiUDP::parsePacket() at C:\Users\otto.elter\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.4\libraries\WiFi\src\WiFiUdp.cpp line 210 0x400d4802: ArduinoOTAClass::handle() at C:\Users\otto.elter\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.4\libraries\ArduinoOTA\src\ArduinoOTA.cpp line 367 0x400d358a: loop() at C:\Users\otto.elter\Desktop\am43-client/am43-client.ino line 360 0x400dd5d9: loopTask(void*) at C:\Users\otto.elter\AppData\Local\Arduino15\packages\esp32\hardware\esp32\1.0.4\cores\esp32\main.cpp line 19 0x40090af9: vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c line 143 I hope this helps.

…

On Tue, Jun 16, 2020 at 12:02 AM buxtronix ***@***.***> wrote: I'm seeing an exception and backtrace in the logs. [17:51:42.296] - [COM4] - [>>] - abort() was called at PC 0x401b7267 on core 1 [17:51:42.303] - [COM4] - [>>] - [17:51:42.303] - [COM4] - [>>] - Backtrace: 0x40091f40:0x3ffcec00 0x40092171:0x3ffcec20 0x401b7267:0x3ffcec40 0x401b72ae:0x3ffcec60 0x401 b61ff:0x3ffcec80 0x401b62f2:0x3ffceca0 0x401b62a9:0x3ffcecc0 0x400d5a2b:0x3ffcece0 0x400d44ce:0x3ffced20 0x400d32d6:0x3ffced40 0x400dc829 :0x3ffcedd0 0x4008e689:0x3ffcedf0 Could you help me by installing the ESP exception decoder in Arduino and running the backtrace through it? (you might have to recompile/upload once the decoder is installed). https://github.com/me-no-dev/EspExceptionDecoder — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOECH4BEBGPGKYLOH463B3LRW2K7BANCNFSM4N6N5NOA> .

[Kite-Smurf]

What I also noticed that the controller crashes at: - Attempting to connect to: 02:cc:5a:a4:e2:76 (any of the addresses) and sometimes it is able to reboot automatically: Attempting to connect to: 02:87:4f:1d:a4:97 ...abort() was called at PC 0x40087969 on core 0 this happens also: - Attempting to connect to: 02:bd:8e:b0:58:b1 ...[02:87:4f:1d:a4:97] Got position: 100 - [02:87:4f:1d:a4:97] Disconnected then it crashes.

…

On Tue, Jun 16, 2020 at 12:02 AM buxtronix ***@***.***> wrote: I'm seeing an exception and backtrace in the logs. [17:51:42.296] - [COM4] - [>>] - abort() was called at PC 0x401b7267 on core 1 [17:51:42.303] - [COM4] - [>>] - [17:51:42.303] - [COM4] - [>>] - Backtrace: 0x40091f40:0x3ffcec00 0x40092171:0x3ffcec20 0x401b7267:0x3ffcec40 0x401b72ae:0x3ffcec60 0x401 b61ff:0x3ffcec80 0x401b62f2:0x3ffceca0 0x401b62a9:0x3ffcecc0 0x400d5a2b:0x3ffcece0 0x400d44ce:0x3ffced20 0x400d32d6:0x3ffced40 0x400dc829 :0x3ffcedd0 0x4008e689:0x3ffcedf0 Could you help me by installing the ESP exception decoder in Arduino and running the backtrace through it? (you might have to recompile/upload once the decoder is installed). https://github.com/me-no-dev/EspExceptionDecoder — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOECH4BEBGPGKYLOH463B3LRW2K7BANCNFSM4N6N5NOA> .

[buxtronix]

I think this is caused by general instability in the way Arduino has configured the bluetooth stack.

After a lot of debugging, etc, I have managed to make significant improvements in the BLE
stack and two different BLE codebases i'm working on are running nearly rock-solid now.

The main fix is just to not have Arduino start the "Bluetooth classic" controller, but only run in BLE mode. Unfortunately most of this change is within the Arduino HAL, so needs to be patched yourself.

Please grab the latest version of this repo, and also see the updated manual patches in the README.

[ccmtozzi]

Hi, I'm having a similar issue! I did installed the last version and patch the BLE as suggested in the README. Not much used to Arduino but wanted to give it a try! It work for about a minute and stops! I do have 6 devices that are nearby, I was using another python script but liked the idea to move away from my RPI W to ESP32!!

log.txt

[buxtronix]

Attempting to connect to: 02:d1:ce:cd:e7:68 ...ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00

This suggests a power supply issue.

Also, the Arduino distribution has a limit of 3 devices it can connect to:

espressif/arduino-esp32#3283

Try testing with one of the motors turned off to see if that is a cause.

[ccmtozzi]

Thanks!! I will try to turn off 3 of the 6 and see if it works! I did test connected to my computer and in another USB power supply and same happened, probably it freezes when connecting to the 4th device. Since there is this 3 device limitation I wonder if would be possible to add to the code the devices it connects to instead of search for it, with that I could have 2 ESP32 that would connect to 3 devices each, maybe something around the code where you identify if the device has the service AND its one of the MAC in the list!! I wish my c++ was decent enough to try! :)

[buxtronix]

Yes, it seems reasonable to add a whitelist of mac addresses or names to connect to. Stay tuned!

[buxtronix]

I've restructured the repo as a library and also added whitelisting of addresses. Please check the readme for new insructions and give it a go.

[Kite-Smurf]

Thanks for updating the sketch.
The white list seems to be a very good option, however I'm unable to get it working with 3 motors. Leaving the white list empty would make the ESP32 connect to all three motors, but the controllers stops working soon. I do not see any backtrace issues anymore.
The controller stops usually at this line:

• Attempting to connect to: 02:cc:5a:a4:e2:76 ...[02:cc:5a:a4:e2:76] Disconnected
  and also would not restart automatically.

Using the white list makes the ESP32 to connect properly but only to two motors even if I whitelist 3 MAC addresses.
#define DEVICE_ALLOWLIST "02:cc:5a:a4:e2:76,02:bd:8e:b0:58:b1,02:87:4f:1d:a4:97"
I'm not sure why, but the MAC in the middle always get disregarded. The log says "not included in the white list"
The controller does not produce any disconnecting issues or crashes having only two MAC's in the white list.

[Kite-Smurf]

A few other questions regarding the Home Assistant side.

1. I found this remark in the sketch: * - am43/rssi - The current RSSI reported by the device.
   Is this still an option to use? I cannot seem to get any traffic on this topic.

2. the Covers and motor states keep showing offline states. ESP32 restart is needed to update the availability states. Is this caused by the controller or my Home Assistant setup?

3. If the AM43 controller goes offline, none of its related entities go in offline or unavailable state.

4. In case one of the motors go offline, its light and battery entities show online state. If the motor is powered on again, its state and its cover state would not update in Home Assistant as long as the ESP32 is not restarted.

5. Would it be possible to setup the ESP32 sketch so that we can make use of the Auto Discovery function of Home Assistant?

[buxtronix]

1. Allowlist should be fixed now, I had a bug in the list parsing code.

2. rssi is not yet implemented - the BLE library RSSI function seems unstable, I need to look into it further.

3. The offline states are due to a MQTT limitation of only one LWT topic per client - fixing these would require implementing a separate MQTT client per AM43 connection. May be feasible, I shall look into it.

4. Auto discovery looks interesting, it's something I can look into for sure.

[buxtronix]

Also, the persistent offline states are due to message retain settings. Rather than fix that in particular, I'll consider updating to one MQTT connection per AM43.

[buxtronix]

Please try the code in the 'mqtt-multiclient' branch. This uses a separate MQTT connection per AM43, allowing proper availability.

You can also copy the 'availability_state' from the cover entity over to the battery/light entities to get availability for them.

[buxtronix]

I've had good stability with this so merged the MQTT changes into master.