Closed dgtal1 closed 4 years ago
The issue is related to BLE (and does not match the symptoms fo #816).
Probably related to https://github.com/esphome/issues/issues/735. Please try different scan parameters for the BLE tracker and/or test if the same symptoms appear without BLE.
The issue is related to BLE (and does not match the symptoms fo #816).
Probably related to #735. Please try different scan parameters for the BLE tracker and/or test if the same symptoms appear without BLE.
Just to confirm: you want me to play with "scan_parameters" parameters: interval, window, duration, active? In my config I did not set them and left the defaults. I read in #735 that the defaults changed. What were they in 1.13.6? I could try their previous values as they used to work just fine
Correct.
The old defaults were:
interval: 512 ms
window: 48 ms
I disabled BLE tracker completely in the current setup and will observe the switch during the day and then will enable it before I go to sleep with the old default values and will also see tomorrow how it behaved overnight. WiIl come back when I have some input.
Regarding the issue - if I understood 735 - there won't be any code fix, but the solution for such issues will be to change the values of the BLE tracker, right?
Correct, there seems to be a balance of "stable WiFi connection" and "BLE getting many packets". I hoped with recent esp-idf versions it would tip towards the latter, but apparently not. Then the question will be which ones should be the default.
One more remark from my side: why is that so that all esp sensors tracked by the tracker send their values constantly and only something that is not a sensor in fact is shown as unavailable for hours? Is it that some TCP 'ping' packet related to this entity is lost? If so - it must have been lost all the time (every time it's sent by ESP32) as the unavailable status lasts for long hours.
@grzeg8102 - can i please ask what you mean by 'the solution for such issues will be to change the values of the BLE tracker, right?'.. also, did this work for you?
thanks
@mikkaat Set scan parameters in ble tracker to the defaults of v1.13.6:
esp32_ble_tracker:
scan_parameters:
interval: 320ms
window: 30ms
I can say that changing the parameters to:
interval: 512ms
window: 48ms
did solve the problem for me. I mean it sometimes changes to unavailable for a few seconds, but as noted above - this happens to me even without the BLE tracker enabled. I perceive the software with the above settings as stable as 13.6. So it's good enough for me.
@OttoWinter which numbers provided by you in this thread were defaults in 1.13.6? 512/48 you gave me or 320/30 you gave to @mikkaat ?
@grzeg8102 I rechecked and it's 320/30. But it's mostly the ratio between the two that counts, which is the same for both.
I experience the similar symptoms. My config has ble scanner. It’s important, that esphome config has home assistant sensors, which work well and update correctly. At the same time neither esphome sensors nor esp32 in general are visible in HA. So it looks like one direction working integration instead of bi-directions as should be.
@mikkaat Set scan parameters in ble tracker to the defaults of v1.13.6:
esp32_ble_tracker: scan_parameters: interval: 320ms window: 30ms
Hi All,
I have been running 1.14.2 with the following settings for the last 3 hours and have not seen any drops..
esp32_ble_tracker:
scan_parameters:
interval: 512ms
window: 48ms
Thanks @OttoWinter thanks @grzeg8102
Thanks @OttoWinter this fixed my issue.. Now working perfectly and i have flashed all my Esp32s
I did, also the changes interval: 320ms window: 30ms
After that, there are not drops, but the OTA update is still not working with esp32_ble_tracker.
19:16:21][C][web_server:121]: Address: 192.168.2.33:80 [19:16:21][C][ota:029]: Over-The-Air Updates: [19:16:21][C][ota:030]: Address: 192.168.2.33:3232 [19:16:21][C][api:095]: API Server: [19:16:21][C][api:096]: Address: 192.168.2.33:6053 [19:16:57][D][ota:072]: Starting OTA Update from 192.168.2.5... [19:16:57][D][ota:243]: OTA in progress: 0.1% [19:16:58][D][ota:243]: OTA in progress: 4.5% [19:16:59][D][ota:243]: OTA in progress: 5.5% [19:17:00][D][ota:243]: OTA in progress: 9.9% [19:17:09][W][ota:309]: Error client disconnected while receiving data! [19:17:09][W][ota:276]: Update end failed! Error: No Error [19:17:09] [19:17:09][W][wifi_esp32:329]: Event: Disconnected ssid='XXXXXX' bssid=XX:XX:XX:XX:XX:XX reason=Beacon Timeout[W][wifi:094]: WiFi Connection lost... Reconnecting... [19:17:09] [19:17:09][W][wifi:482]: Restarting WiFi adapter... [19:17:09][D][xiaomi_ble:158]: Got Xiaomi LYWSDCGQ (XX:XX:XX:XX:XX:XX): [19:17:09][D][xiaomi_ble:161]: Temperature: 20.3°C [19:17:09][D][xiaomi_ble:164]: Humidity: 54.9% [19:17:09][D][sensor:092]: 'swicth02_192_168_2_33_temperature': Sending state 20.30000 °C with 1 decimals of accuracy [19:17:09][D][sensor:092]: 'swicth02_192_168_2_33_humidity': Sending state 54.90000 % with 1 decimals of accuracy [19:17:14][D][wifi:298]: Starting scan... [19:17:14][D][esp-idf:000]: E (57944) wifi: esp_wifi_scan_start 1245 wifi not start
Operating environment/Installation (Hass.io/Docker/pip/etc.):
Esphome in docker. Home Assistant 101.1 ESP (ESP32/ESP8266, Board/Sonoff):
ESP32, DEVKIT V1 Affected component:
switch
Description of problem: Since I upgraded to 1.14 on Saturday I'm getting my restart switch shown in HA as unavailable. upgrade to 1.14.2 yesterday didn't fix this. On 1.14.0 the switch randomly changed its status from off to unavailable. Since 1.14.2 it become not available after a couple of hours after upgrade and stayed as unavailable. See attached image:
All other entities related to my ESP32 - mostly sensors - are shown as normal with a valid status and values. I'm sure this only started with 1.14 as I observe these entities every day.
I think this has something to do with general stability of the new software. After checking the logs I noticed that esphome could not connect to my ESP32 node initially and required 4 retries to connect to it. I'm sure this didn't happen before and esphome was always capable of connecting at the first time. Could be related to mDNS?
Problem-relevant YAML-configuration entries:
Logs (if applicable):
Additional information and things you've tried: