[WiFi] Simplify credentials management#3473
Conversation
This may lead to lots of unneeded log spamming when processing rules.
N.B. the 'stage' build does NOT work with LAN.
…it#3463) See also letscontrolit#3463 Still not finished as I discovered a logic error in the connection process when the initial scan may still be active when `prepareWiFi()` is called which changes WiFi mode.
Management of the credentials for WiFi networks had become way too complex. This introduces a list of good candidates for connecting to, based on scan result and found RSSI values.
|
I made a quick test build: Please realize this is absolutely not finished yet, but I wonder if it already makes a difference with some notorious nodes like some Sonoff Basic units that experience perfect responsiveness on one build and dreadfully slow on other builds for no known reason. |
|
Made a new test build (still not finished, but Setup will now be usable again :) ) |
|
Created a new build: Main changes:
N.B. most of the ESP32 builds failed, but that will be fixed in a next build. |
|
Tried these: ESP_Easy_mega_20210124_normal_ESP8266_4M1M_VCC.bin : Worked OK, WiFi is fine (-45 dBm) |
|
I plan on making the "hidden" SSID connection optional or at least more dynamic. A SSID of an access point can be set "hidden", which means it doesn't broadcast its SSID. We can connect to a hidden SSID by just giving the SSID and a password, but then you don't know which one it will connect as it connects to the first one that's successful. If you have hidden SSIDs in the neighborhood, you may end up trying those too. So I want to add a flag later to ignore hidden SSIDs if you know your AP isn't hidden. What it does now:
As soon as this list is empty, a new scan will be performed and the loop repeats. Things still to add:
|
Think you skipped one: (saw this: // FIXME TD-er: Must make this a setting.)
|
Ah glad someone is reading my changes too 👍 I even have more things on my todo list, but not sure if those will be included in this PR, or maybe for later as I don't want to stick on this one adding features. Things on my mind:
|
Also force WiFi scan if reconnect to last used AP was unsuccessful. Add checkbox to allow connecting to hidden SSID (also from setup page)
|
Added:
Still to do:
Documentation on the new TX power settings: WiFi TX Power(Added: 2021-01-26) The default TX power of an ESP unit is:
For some units it can help to reduce the TX power of the WiFi. As of now the exact reason why this may improve stability is a bit unclear. For example, the power supply may be slightly underdimensioned, or the antenna impedance isn’t perfect. (can be affected by a lot of factors) The effect of a reduction in TX power is of course lower energy consumption, but also a reduction in WiFi range as the received signal strength on the access point will be lower. The unit for WiFi TX power is expressed in dBm, which makes it very easy to calculate the effect. The relation between TX power in dBm and Watt:
Every 10 dBm lower is a factor 10 less energy sent from the antenna. N.B. Since most ESP boards use a linear voltage regulator from 5V to 3.3V, the power reduction can be as high as 0.15 Watt. See also “WiFi Sensitivity Margin” For example the AP does receive the signal from your ESP node with an RSSI of -60 dBm. If we lower the TX power from 20 dBm to 10 dBm, the access point will receive our signal with an RSSI of -70 dBm. Lowering the TX power can also be useful to make it more likely a node will connect to an access point close to the node in a setup with a number of access points using the same SSID. Most access points will disconnect a node if its signal drops below a certain RSSI value. (some brands of access points allow to set this threshold) WiFi Sensitivity Margin(Added: 2021-01-26) See also WiFi TX Power. The ESP boards have a RX sensitivity depending on the used WiFi connection protocol:
These are the numbers for an ESP8266. N.B. The ESP32 is more sensitive for lower bit rates, but we use these more conservative ones. Our dynamic WiFi TX power strategy is based on the following assumptions: Without any changes in TX power on both the ESP as the access point (AP), we can assume the signal strength attenuates the same from the AP to the ESP as the return path from the ESP to the AP. Meaning if we see the signal from an AP has an RSSI value of -60 dBm, we can assume the AP receiving our signal has a similar signal strength with an RSSI of -60 dBm. An access point usually has a better RX sensitivity than an ESP board. With these assumptions in mind, we can lower our WiFi TX power. Let’s assume the ESP is connected to an access point using 802.11N and we see an RSSI of -60 dBm. Without lowering TX power on the ESP, the access point will receive the ESP with an RSSI of -60 dBm. When the TX power on this ESP is lowered from 14 dBm to 4 dBm, the access point will receive the ESP with an RSSI of -70 dBm. This is still within the stated -72 dBm RX sensitivity. However for improved stability, it is wise to add some margin. For example a margin of 5 dBm. When applying this margin of +5 dBm, the ESP must try to match its output power to make sure the access point will receive the ESP with an RSSI of at least - 67 dBm. The set TX output power will then be (-60 dBm - -67 dBm =) +7 dBm, which is still a significant improvement in power consumption. This margin can also be used to compensate for an access point which is set to a non default TX power. For example, it is good practice to lower the TX power of an access point to improve separation and take over in a network with multiple APs set to use the same SSID to provide roaming. Since these offsets are also expressed in dBm, they can be used without conversion for correcting this margin.
Note
Note
|
|
Test build: N.B. there is still no conversion for existing settings of the max. TX power. Best to install this on a clean build or one that can be cleared if you now have an RSSI of less than 70 dBm on your node. (or move the node closer to the AP) |
Maybe you could add a command I was wondering if the settings version should be increased as well, but that's probably waiting for that conversion. Have a spare Wemos D1 mini Pro (clone, without a metal shield) laying around, I'll do some testing on that unit tonight. (though my WiFi coverage is quite good in and around the house, and the rest of that batch is working just fine) |
The increment of the version is used to make those settings transitions. |
The nice thing about this PR is that the new settings also allow to 'stress test' bad WiFi coverage as you can set the WiFi Sensitivity Margin to a negative value. I am also using a MikroTik AP for these kind of tests as they are extremely versatile to tweak all settings (half of the settings I had to Google when I first started using them, even with decades of network experience) and are also extremely affordable.
|
Also added the current WiFi TX power to the sysinfo plugin.
|
New test build: Implemented:
ToDo:
|
|
I've been testing for a short while now (fetched the PR just before you published the build above to have the settings conversion 😃), and I'm really impressed how quick it adapts to a changing WiFi signal while I'm walking from a very good connection (1 mtr from an AP) to a very poor connection (close to dead WiFi area in 1 corner of the house), and back 👍. Does adding commands to set/get the tx power and sensitivity margin, etc., from rules/serial, make it onto the todo list? Or should that be auto-fine-tuning, and so not to be messed with externally? |
|
The response on changed WiFi signal is at sub-second interval. I will also add the commands for get/set the TX power and sensitivity margin. |
|
New test build: The main changes in this build are:
|
|
New test build: Only difference is the unit will not allow to connect to WiFi until uptime > 2000 msec. @thomastech Can you also test it? |
|
Tested: With 100K across xtal: Browser access normal. Good Web UI performance. -Thomas |
|
@thomastech What RF power do you use? |
|
Lower TX power means lower bandwidth (Generally) means more air time for the radio, means more CPU blocked waiting for transmission and receive. So far ditching N and using G mode for my nodes that are on the edge of coverage has worked fine for me. I will test this PR and report back. |
|
A new (ESP8266 only) test build: Main changes are:
|
Yep, it is blocking longer, but still we hardly ever connect below 6 Mbps, so even serving the most elaborate web page (40kB) only takes roughly 60 msec to send. That's with an estimated effective band width of 50% of the WiFi connection speed. |
|
From my very un-scientific tests the WiFi is very adaptive to me moving around the node and also when covering it with my hand. I like it a lot! |
|
Yep, WiFi TX power is updated very quickly. However, the amount of energy reduction when sending at 0dBm is less than I would have expected it to be. |
It was +7dBm during the test. -Thomas |
5 participants
Management of the credentials for WiFi networks had become way too complex.
This introduces a list of good candidates for connecting to, based on scan result and found RSSI values.