Bootloop when out of Nuki's bluetooth range

[harmptor]

First of all, thank you for this amazing component! It works really well when a connection to the lock is possible. Couldn't wish for more.

Now, I hope this finds you well rested after your summer vacation! Welcome back! It seems that if the bluetooth connection isn't available it makes the ESP fall in a bootloop. When I moved the Nuki out of reach of the ESP32, it bootlooped and eventually went into safemode. After bringing them closer together again and power cycling the ESP, it worked fine again. I don't have a clue whats really going on, so I'll just provide the logs and you can see for yourself.

I've seen two types of errors: This one in Log 1

[05:20:12][D][wifi:373]: Starting scan...
[05:20:12][D][esp32.preferences:114]: Saving preferences to flash...
[05:20:17]E (5956) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
[05:20:17]E (5956) task_wdt:  - loopTask (CPU 1)
[05:20:17]E (5956) task_wdt: Tasks currently running:
[05:20:17]E (5956) task_wdt: CPU 0: IDLE0
[05:20:17]E (5956) task_wdt: CPU 1: IDLE1
[05:20:17]E (5956) task_wdt: Aborting.
[05:20:17]abort() was called at PC 0x4015b0e8 on core 0
[05:20:17]
[05:20:17]ELF file SHA256: 0000000000000000
[05:20:17]
[05:20:17]Backtrace: [...truncated by me]
[05:20:17]
[05:20:17]Rebooting...
[05:20:17]ets Jun  8 2016 00:22:57

󠀡

and this one in Log 2

[12:32:32][D][esp32.preferences:114]: Saving preferences to flash...
[12:32:32]Guru Meditation Error: Core  0 panic'ed (IllegalInstruction). Exception was unhandled.
[12:32:32]Memory dump at 0x400f8200: ff0b0000 ffffffff ffffffff
[12:32:32]Core 0 register dump:
[12:32:32]PC      : 0x400f8204  PS      : 0x00060c30  A0      : 0x8012b9bc  A1      : 0x3ffb7830  
WARNING Decoded 0x400f8204: wifi_softap_stop
[12:32:32]A2      : 0x0000000b  A3      : 0x00000004  A4      : 0x00000000  A5      : 0x3ffbc040  
[12:32:32]A6      : 0x00000000  A7      : 0x3ffb6760  A8      : 0x8010c546  A9      : 0x80000020  
[12:32:32]A10     : 0x00000000  A11     : 0x3ffbc25c  A12     : 0x00000005  A13     : 0x00000020  
[12:32:32]A14     : 0x00000020  A15     : 0x00060023  SAR     : 0x00000000  EXCCAUSE: 0x00000000  
[12:32:32]EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0xffffffff  
[12:32:32]
[12:32:32]ELF file SHA256: 0000000000000000
[12:32:32]
[12:32:32]Backtrace:  [...truncated by me]
[12:32:33]
[12:32:33]Rebooting...
[12:32:33]ets Jun  8 2016 00:22:57

I'm using a NodeMCU and a Nuki 1.0 In Log 1, the Nuki has not yet been paired at first, as you can probably tell. Also note that these two logs derive from different esphome configs. In Log 1 the lock is called 'Nuki Lock' and in Log 2 it's called 'Hardware Nuki' (and I set up a template lock with the name 'Nuki') Let me know when you need more info or this is an issue for I-Connect/NukiBleEsp32

[uriyacovy]

Thanks @crixionz, good catch! I was able to reproduce the issue. Will have a look and update.

[leranp]

It can be related to my issue https://github.com/uriyacovy/ESPHome_nuki_lock/issues/3

I still have a reboots with an esp32-cam device

[uriyacovy]

Hi @crixionz, @leranp, Sorry it took much time, but I had to find the time to make some progress. In short, the root cause for the boots lies on the fact the NukiBLE library is using a synchronous bluetooth library (NimBLE-Arduino), while ESPHome is mostly async. It will not be easy to change this, so I had to work around this constraint by limiting the connection timeout (from 30 sec to 3) and disable connection retries (at the library level, not at the component level). I've also add Nuki connect sensor that would provide better description of the status. I'll be happy if you can build the following dev tree. Please note the changes required to the yaml:

esphome:
  libraries:
  - Preferences
  - https://github.com/uriyacovy/NukiBleEsp32#dev

esp32:
  board: esp32dev
  framework:
    type: arduino
    version: 2.0.3
    platform_version: 4.4.0

external_components:
  - source: github://uriyacovy/ESPHome_nuki_lock@dev

lock:
  - platform: nuki_lock
    name: Nuki Lock
    is_connected: 
      name: "Nuki Connected"
    is_paired: 
      name: "Nuki Paired"
    battery_critical:
      name: "Nuki Battery Critical"
    battery_level:
      name: "Nuki Battery Level"

2 more comments:

1. The dev tree also adds some debug printout when trying to connect to Nuki. Please upload them when reporting feedback.
2. If you encounter build problems, please try to build from scratch (in a new folder).
3. Since the underlying library is not async, I couldn't find a way to eliminate boots. Nevertheless, it should be much less frequent, but it also depends on the other components running on the esp32 (fewer the components, the higher stability).

Uri

[leranp]

Hi @crixionz, @leranp, Sorry it took much time, but I had to find the time to make some progress. In short, the root cause for the boots lies on the fact the NukiBLE library is using a synchronous bluetooth library (NimBLE-Arduino), while ESPHome is mostly async. It will not be easy to change this, so I had to work around this constraint by limiting the connection timeout (from 30 sec to 3) and disable connection retries (at the library level, not at the component level). I've also add Nuki connect sensor that would provide better description of the status. I'll be happy if you can build the following dev tree. Please note the changes required to the yaml:

esphome:
  libraries:
  - Preferences
  - https://github.com/uriyacovy/NukiBleEsp32#dev

esp32:
  board: esp32dev
  framework:
    type: arduino
    version: 2.0.3
    platform_version: 4.4.0

external_components:
  - source: github://uriyacovy/ESPHome_nuki_lock**@dev**

lock:
  - platform: nuki_lock
    name: Nuki Lock
    is_connected: 
      name: "Nuki Connected"
    is_paired: 
      name: "Nuki Paired"
    battery_critical:
      name: "Nuki Battery Critical"
    battery_level:
      name: "Nuki Battery Level"

2 more comments:

1. The dev tree also adds some debug printout when trying to connect to Nuki. Please upload them when reporting feedback.
2. If you encounter build problems, please try to build from scratch (in a new folder).
3. Since the underlying library is not async, I couldn't find a way to eliminate boots. Nevertheless, it should be much less frequent, but it also depends on the other components running on the esp32 (fewer the components, the higher stability).

Uri

Sorry, but i switched to the Nuki bridge, It is more stable for my needs. I can't help to debug the device with the dev version. Thank you for the great work 😊

[uriyacovy]

Sure, enjoy your new bridge 😊

[harmptor]

Hi @uriyacovy Sorry, I was on summer vacation too. Now I'm back and when trying to compile it says

PS Microsoft.PowerShell.Core\FileSystem::\\192.168.0.222\config\esphome> esphome run .\cora.yaml
?[32mINFO Reading configuration .\cora.yaml...?[0m
?[33mWARNING The selected Arduino framework version is not the recommended one. If there are connectivity or build issues please remove the manual version.?[0m
?[33mWARNING The selected Arduino framework version is not the recommended one. If there are connectivity or build issues please remove the manual version.?[0m
?[32mINFO Generating C++ source...?[0m
?[32mINFO Compiling app...?[0m
*********************************************************************************************************************************************************************************************************************

Obsolete PIO Core v5.2.5 is used (previous was 6.0.2)
Please remove multiple PIO Cores from a system:

https://docs.platformio.org/page/faq.html#multiple-platformio-cores-in-a-system
*********************************************************************************************************************************************************************************************************************

Processing cora (board: esp32dev; framework: arduino; platform: platformio/espressif32 @ 4.4.0)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Platform Manager: Installing platformio/espressif32 @ 4.4.0
Downloading  [####################################]  100%
Unpacking  [####################################]  100%
Platform Manager: espressif32 @ 4.4.0 has been installed!
Error: Unknown development platform 'espressif32'

I tried esphome clean, deleting \.esphome\build\cora and also deleting \.esphome\external_components\* but that didn't help. How should I proceed?

[uriyacovy]

Hi @crixionz,

Did you update to the latest ESPHome version? Also, if this does not work, try to delete your user.platformio folder. This happens probably due to a conflict with platformio environment (ESPhome uses espressif 3.5 while NukiBleEsp32 moved to 4.3).

[harmptor]

Thanks, updating ESPHome to 2022.8.3 helped, yet gave me a different issue. Log here: https://dpaste.org/K263Y Could that be because of the changes merged in #8 ?

[uriyacovy]

The changes in #8 were not merged yet. Could you post your full yaml? My guess is that you didn't update the NukiBleEsp32 to the dev branch as well (https://github.com/uriyacovy/NukiBleEsp32#dev)

[harmptor]

Oh okay! I did exactly as you said (I could directly copy-paste from here because I'm using packages hehe, so there's no way I mess up the code) My yaml: https://dpaste.org/2QOXW

[uriyacovy]

@crixionz, I see two things:

1. My mistake - I tried to put the dev branch in bold (**), but the mark-up did not work. In any case, use:

external_components:
  - source: github://uriyacovy/ESPHome_nuki_lock@dev

2. You have 2 esp32 sections. I am not sure how this should work. Maybe it's better to combine them.

[harmptor]

Ahh damn, I thought these asterisks looked a little sus, but I rolled with it because, yea... :D Okay, changing rn. The two esp sections should be fine coz ESPHome automatically merges everything in the package with the main yaml for me. Edit: Update: Compiled successfully!

[uriyacovy]

Great. Please update how it runs and if the module is more stable.

[harmptor]

Okay, thank you! It seems more stable now. I think. I have two logs for you again, Log 1 where everything is fine and Log 2 where I moved the node further away from the Nuki.

Regarding the tested hardware, I should mention that I'm using a Nuki 1.0 and it works fine. I obv didn't add the door sensors to my yaml so I don't know whats up with that, but I can test if needed 👍

[uriyacovy]

Hi @crixionz, Seems like there's a reset in log 2 (23:50:10). As I wrote here https://github.com/uriyacovy/ESPHome_nuki_lock/issues/6#issuecomment-1240270276, this is somewhat expected since the underlying Nuki BT library is blocking (not async). This development was meant to overcome issues of momentary disconnections, which are now reported via the 'Nuki connected' sensor. Obviously, if the esp cannot connect to the Nuki, there's not much that can be done.

[harmptor]

Oh I just realised, Log 2 wasn't even over serial... dummy Should I get the logs of scenario 2 over serial?

Okay, I think I somewhat understand(a little), and to me it looks like this version retries the connection way more often before rebooting, which is good. So thank you very much!

1: Do you need more logs/testing/etc? 2: When do you think this change will be in the main branch? (3: How do we not need nkohylban's library anymore?)

[uriyacovy]

1. I don't think more logs would help at this stage, since I'm not sure that much more can be done.
2. Yes, after some stability tests, I'll pull it (+additional changes) to the main branch. But you can work with dev without issues I believe.
3. nkohylban's library is included in the update arduino framework (4.4.0)

[harmptor]

Okay, glad to hear! Thank you so much for all the work and for all the help and answers!! Should I close the issue, now that not much more can be done? Or you can just close whenever... 🙂 Again, thank you!

[uriyacovy]

I'll close the issue for now. Please reopen if you still encounter boot loops.