nuki_hub icon indicating copy to clipboard operation
nuki_hub copied to clipboard

Published 20 hours ago • verified publisher icon technyon

scan_evt timeout spammed in serial monitor

Open naice opened this issue 1 year ago • 7 comments

Hi,

first of thanks for your hard work! I let the hub run on my ESP32 over night PC was in deep sleep when i turned it on again this morning my serial monitor is spammed with "scan_evt timeout". image

already searched your source for it but couldn't find it, is this caused by the BLE library? I am just curious about the issue.

naice avatar Sep 12 '23 06:09 naice

Hi,

yes this comes from the BLE lib. If this causes issues for you (like the lock state not updating), consider to set "Restart if bluetooth beacons not received" to something like 60 seconds.

technyon avatar Sep 12 '23 10:09 technyon

I was thrilled already by the fact that the hub could connect to my front door as i am so far away (an entire floor level in my house), i just think thats because of an unstable signal.

But thx for the fast response, if i detect any issues i will try the setting.

naice avatar Sep 12 '23 10:09 naice

That would sure explain the timeout warnings ... if possible move the ESP closer.

technyon avatar Sep 12 '23 21:09 technyon

Hi. I am experiencing the same problem since I updated to 8.26. The issue occurs about once a day for me and results in the Nuki BLE connection being completely broken (only a manual restart helps). Before I was running on 8.22 which worked flawlessly for me with only one crash within 2 months. While I was investigating the issue I found espressif/arduino-esp32#5860 where bleScan->clearResults(); is suspected to be the root cause. This would make sense because it was introduced after version 8.22 to this project. I am currently running a custom build where I simply removed the clearResults() call again to see if that improves my situation. I understand there are certainly good reasons why this has been added, but at least for me it was working better without.

I will consider enabling "Restart if bluetooth beacons not received" as well but while this might mitigate the issue I would rather see this as a workaround and last resort than a fix.

jaynis avatar Sep 17 '23 15:09 jaynis

Thanks for looking into this. Yes, this would indeed explain it. The automatic restart option doesn't work for you?

technyon avatar Sep 18 '23 17:09 technyon

I havent tested the automatic restart option yet because before you mentioned it here I did not know it might be of help regarding my problem. But generally the automatic restart sounds a bit like symptom treatment rather than a fix of the root cause, what I am looking for.

jaynis avatar Sep 19 '23 18:09 jaynis

It is, and I'm not happy about having to resort to this. There are issues in the Espressif bluetooth stack, my guess is this is only one of them. Especially when using bluetooth and wifi at the same time, the stack sometimes silently dies. This is at least one hint at what's going on.

technyon avatar Sep 20 '23 09:09 technyon

It seems a fix for this problem has apparently been included in IDF 5.1.3 and up, see https://github.com/espressif/esp-idf/commit/74f99d267939674b7e67813aa12199d14ed1aa28, https://github.com/espressif/esp-idf/commit/56563f709229cbef07b79e1b5db48146f3b17e42 and https://github.com/espressif/esp-idf/commit/2ec5d6b0f2ed20fb179ccd854faac8fcf6e9a441.

So hopefully this will be fixed in Arduino Core 3.0 as this is based on IDF 5.1

iranl avatar May 21 '24 13:05 iranl