But again, does this still happen when a white-list is applied with only one plant sensor, and adaptivescan is set to false and both intervals at heir default 55555 or something similar and scanduraction at 10000?
This would thelp to tell if the error happens during the actual scanning of all available devices or during the decoding of white-listed devices.
Oops - the :38 is what I should have looked up. That is a switchbot motion sensor that is about 60’ away. I’ll whitelist just one plant sensor after a fresh reinstall and erase of settings and report back shortly.
So also a W110150X then, so all three devices which caused the error were motion sensors - that’s a good start to know 
and with only one of them
6C: “uniq_id”: “5X2D3X6X5X6C-motion”
causing
W: Name too long, truncating
I don’t think it is the truncation which causes the issue, but more likely the setting to continuous passive/active scanning, which could be verified with a white-list and resetting all the settings to how I mentioned above.
BTW what kind of device is the 6C: “uniq_id”: “5X2D3X6X5X6C-motion”??
Then there should be no adaptive adjustment to continuous scanning, and hopefully no more rebooting, and it’ll give us a better idea where to investigate.
Ok - whitelisting just one plant sensor enables the gateway to stay online. Sorry, this has been a bit of a background project and I forgot that when I whitelisted one item the first time it was a QINGPING motion sensor.
I do not know what that other motion sensor is - it didn’t provide better intel on it via mqtt. I think I need to go out to my workspace and remove a bunch of batteries from undeployed devices. I would like to eventually deploy some motion sensors, although I’ve largely moved to zigbee for that.
Here are the default settings I get after resetting everything on first boot after setting up through the captive portal
N: No WebUI config to load
N: OpenMQTTGateway URL: http://NN2.NN8.0.NN6/
N: ZwebUI setup done
[NNNNNN][E][Preferences.cpp:NN] begin(): nvs_open failed: NOT_FOUND
N: Adaptive BLE scan: true
N: Active BLE scan interval: 55555
N: minrssi: -100
N: Presence Away Timer: 120000
N: Moving Timer: 60000
N: Force passive scan: false
N: Enabled BLE: true
N: ZgatewayBT multicore ESP32 setup done
N: Offline disabled
N: OpenMQTTGateway modules: ["WebUI","BT"]
N: ************** Setup OpenMQTTGateway end **************
N: Reconfiguring MQTT client...
N: Update check, free heap: NNNN0N: Using memory cert
[NNNNNN][E][ssl_client.cpp:NN] _handle_error(): [start_ssl_client():NN3]: (-NN) UNKNOWN ERROR CODE (NN4E)
[NNNNNN][E][WiFiClientSecure.cpp:NN4] connect(): start_ssl_client: -NN
E: Error on HTTP requestN: Update check done, free heap: NNNN6[NNNNNN][E][WiFiClient.cpp:NN2] connect(): connect on fd NN, errno: NN8, "Host is unreachable"
N: SYS json: {"uptime":NN7,"version":"v1.8.0","rgbb":NN,"mqtt":true,"serial":false,"disc":true,"ohdisc":false,"env":"theengs-bridge","freemem":NNNN0,"mqttp":"NNNN","mqtts":false,"mqttv":false,"msgprc":0,"msgblck":0,"msgrcv":0,"maxq":0,"cnt_index":0,"minmem":NNNN4,"tempc":NN.NN,"freestck":NNNN,"powermode":-1,"eth":false,"rssi":-NN,"SSID":"","BSSID":"EA:NN:DA:NN:NN:CB","ip":"0.0.0.0","mac":"NN:B7:NN:NN:NN:4C","modules":"'WebUI', 'BT'","origin":"/SYStoMQTT"}
W: MQTT not connected, aborting the publication
W: Network disconnected
N: Attempting Wifi connection with saved AP: 0
E (NNNNNN) wifi:sta is connecting, return error
[NNNNNN][E][WiFiSTA.cpp:NN7] begin(): connect failed! 0xNNNN
N: Attempting Wifi connection with saved AP: 1
E (NNNNNN) wifi:sta is connecting, return error
[NNNNNN][E][WiFiSTA.cpp:NN7] begin(): connect failed! 0xNNNN
N: Attempting Wifi connection with saved AP: 2
E (NNNNNN) esp_netif_handlers: invalid static ip
N: Attempting Wifi connection with saved AP: 3
E (NNNNNN) wifi:sta is connecting, return error
[NNNNNN][E][WiFiSTA.cpp:NN7] begin(): connect failed! 0xNNNN
W: MQTT not connected, aborting the publication
N: Connected to broker
N: [ OMG->MQTT ] topic: home/omg_wltest/LWT msg: online
N: [ OMG->MQTT ] topic: homeassistant/switch/NNBNNNNNNNNC-active_scan/config msg:
N: [ OMG->MQTT ] topic: homeassistant/number/NNBNNNNNNNNC-scanbcnct/config msg:
N: [ OMG->MQTT ] topic: homeassistant/switch/NNBNNNNNNNNC-restart/config msg:
N: [ OMG->MQTT ] topic: homeassistant/switch/NNBNNNNNNNNC-erase/config msg:
N: [ OMG->MQTT ] topic: homeassistant/switch/NNBNNNNNNNNC-force_scan/config msg:
N: [ OMG->MQTT ] topic: homeassistant/sensor/NNBNNNNNNNNC-interval/config msg:
N: [ OMG->MQTT ] topic: homeassistant/sensor/NNBNNNNNNNNC-scanbcnct/config msg:
N: [ OMG->MQTT ] topic: homeassistant/switch/NNBNNNNNNNNC-ohdiscovery/config msg:
N: [ OMG->MQTT ] topic: homeassistant/switch/NNBNNNNNNNNC-discovery/config msg:
N: [ OMG->MQTT ] topic: homeassistant/switch/NNBNNNNNNNNC-powermode/config msg:
N: [ OMG->MQTT ] topic: home/omg_wltest/WebUItoMQTT msg: {"displayMetric":true,"webUISecure":true,"displayQueue":0}
N: [ OMG->MQTT ] topic: homeassistant/binary_sensor/NNBNNNNNNNNC-connectivity/config msg: {"stat_t":"home/omg_wltest/LWT","avty_t":"home/omg_wltest/LWT","name":"SYS: Connectivity","uniq_id":"NNBNNNNNNNNC-
That is good to know, at least with the plant sensor(s), and very likely many other devices, white-listed all is fine.
So it definitely seems to be caused by motion/contact sensors, and likely these requesting continuous scanning when adaptivescan is on by default.
Needs to checked and verified on our side with such devices.
Thanks for the support - I can definitely work around this issue with WL for what I need to do, but I’m happy to contribute any testing that is helpful.
I am sure I pick up BT signals from at least 6 other families in close proximity to where I am - we live in/own a multi-family and the residences in our area are all tightly packed - so rogue devices causing crashing is likely something worth working out. I think every device I purchased was based on your known working list of products, and I may have backburnered this project/technology unknowingly due to this issue. Although maybe BT is not a great solution for motion/contacts?
Thanks for the details, I reproduce the issue. A development build will be available tomorrow here for testing:
can confirm that the development firmware, without any whitelisting, does not crash as it did previously.
Thanks for pointing this, new release published
