Too aggressive settings for bluetooth proxies with WiFi + BT support
emontnemery opened this issue · 10 comments
PR #6 set very aggressive settings for BT proxies, without explaining why:
scan_parameters:
interval: 1100ms
window: 1100msWith these settings, I can't get a bluetooth proxy with WiFi + BT support to successfully connect and stay connected to my WLAN.
For reference, the default settings are:
DEFAULT_INTERVAL_MS = 320
DEFAULT_WINDOW_MS = 30
With the default settings, a bluetooth proxy with WiFi + BT support connects and stays connected to the WLAN.
If the settings are changed, the documentation should also be updated: https://esphome.io/components/bluetooth_proxy.html#complete-sample-recommended-configuration
+1, why was interval = 1100ms chosen?
I do see this number referenced in home assistant community forums a lot, but I don't see any explanation.
I can understand increasing window to match interval, but why change interval away from the default 320ms?
Why is 320ms the default and not some other value? This was asked also several times, and nobody knew the answer...
1100 was chosen to match closer the passive ble advertisment intervals of various sensors, in order to catch as many of them as possible.
It was tested thoroughly when bluetooth proxy was introduced, and based on results achieved, this seemed the most appropriate value at that time.
1100 was chosen to match closer the passive ble advertisment intervals of various sensors, in order to catch as many of them as possible.
Shouldn't the interval be set to something which is not at all very close to the interval of the sensor? If the channel hopping interval is close to the sensor's interval there must be a high risk that the proxy is consistently on the wrong channel when the sensor updates, causing long outages?
Do you agree setting window to match interval is not suitable for proxies with WiFi + BT support?
In my experiments, having window = interval brought the highest density of reading from the sensors (using 10 Xiaomi sensors spread around the house). As per BLE advertisment specs, the broadcasts happen every 2500ms so having it set to something close to half of it bought very good results (not only with Bluetooth Proxy, but also with ESPHome's native Xiaomi integrations).
Didn't notice any kind of WiFi connectivity issues with window = interval, (I'm using 4 UniFi APs for proper coverage).
Stable connectivity depends on many factors, not just how window and interval are set. If you find yours operate better with different values, just use those, ymmv.
Please try with more value pairs, I'd start with something around 300ms. Let it run for a few horus and gather data in HA, compare density - and post results let's see how it performs in your environment. What board do you use and advertisments of how many sensors do you want to catch?
I only have a couple of devices which I want to connect to, so I unfortunately can't make a good test tracking sensors.
My WiFi setup is similar to yours; I have 3 UniFi APs.
The SSID I configured the ESP home devices to connect to is shared among the UniFi APs.
With 1100/1100, it was a 100% failure to connect to WiFi.
If you think the 1100ms interval is good considering the BLE advertisement interval, I'll stick with that and try different window lengths.
Should I run some WiFi test, maybe try pinging the devices or something like that?
I agree with @nagyrobi 's reasoning for setting window=interval.
Seems like we are making a tradeoff between detecting BLE signals vs OTA updatability over WiFi. I prefer bluetooth proxies functioning at their "max performance" since that leads to better data. Optimize for the common case :) OTA updates rarely happen, so no need to sacrifice device performance for them.
@emontnemery I'm surprised you are using WiFi bluetooth proxies. WiFi and bluetooth interfere a lot. Ideally you use ethernet instead.
But FYI you can probably workaround this issue by using ESPHome safe mode.
button:
- platform: safe_mode
name: Safe Mode Boot
entity_category: diagnosticWhen you wish to do an OTA update, press the safe mode button in Home Assistant. This will reboot your ESP with BLE scanning completely disabled. Then you can do OTA update via ESPHome with no interference.
With this safe mode setup, you can keep window=interval for max BLE scanning performance.
I think all of the above discussion is missing the critical piece of information of what hardware each user is using. Having aggressive BLE settings will cause more power draw to the ESP. If the hardware itself does not have the power available for this type of setup, of course you will have unstable connections.
I personally have not had much luck with 1100/1100 working well on an M5 Atom Lite, but it's entirely possible for the same settings to work fine on supporting hardware with more power bandwidth and perhaps a less crowded 2.4GHz area.
The 1100ms settings make sense for Ethernet but its a problem for Wi-Fi coexistence.
The HA issue queue has reports of frequent drops with the 1100ms setting which goes away when returned to the defaults. I keep having to tell users to adjust their settings back to the defaults for stable operation. I think we should adjust the Wi-Fi ones back to the defaults and leave the Ethernet ones with 1100ms
What is the DTIM set to for the Wi-Fi network that has this issue?
setting it to 1 seems to make it more stable but I still get drops
With Ethernet I had good results even with double advert interval: 5000ms.
Note: I experimented all the above with passive mode, and PR #6 was made when active mode wasn't even known it's possible... I agree that active mode may need totally other values, however, I only have passive sensors to experiment with, and these work reliably with 1100ms in my environment. I do heating control relying on them.