Improve WiFi scan result display

[DL6ER]

Description:

Checklist:

• The pull request is done against the latest dev branch
• Only relevant files were touched
• Only one feature/fix was added per PR and the code change compiles without warnings
• The code change is tested and works on Tasmota core ESP8266 V.2.7.4.9
• The code change is tested and works on Tasmota core ESP32 V.1.0.5-rc4
• I accept the CLA.

I cannot test ESP32 myself, however, compilation passes fine.

This improves WiFi scan results:

• Reveal if multiple AP have the same SSID but different signal strengths and show them group them together
• Color-code the signal quality to improve accessibility

Exemplary screenshots:

Further less important details like encryption type and RSSI are hidden in a tooltip, like

[s-hadinger]

This is a nice feature but I'm not in favor of spending precious flash space for a cosmetic feature used only once in the lifetime of the device.

Even if we were to add the feature, avoid float calculation as much as possible. It is very expensive in code size.

[DL6ER]

Current development:

RAM:   [======    ]  57.2% (used 46832 bytes from 81920 bytes)
Flash: [======    ]  58.4% (used 597500 bytes from 1023984 bytes)

My branch:

RAM:   [======    ]  57.2% (used 46832 bytes from 81920 bytes)
Flash: [======    ]  58.4% (used 597692 bytes from 1023984 bytes)

If we leave off the description of the WiFi encryption type (because it shouldn't really matter), we get my new scanning display at a mere 96 bytes of extra space:

RAM:   [======    ]  57.2% (used 46832 bytes from 81920 bytes)
Flash: [======    ]  58.4% (used 597596 bytes from 1023984 bytes)

[DL6ER]

The failed CI run seems to be a mistake of the CI itself:

Error: read ECONNRESET

[s-hadinger]

With both suggested changes, you should be at only +64 bytes.

[s-hadinger]

You can save code with
String nextSSID;

You don't need to give it a value, is it still initialized.

[s-hadinger]

You can save even more here:

            if(quality > 50) {
              // Scale red component to go from yellow to green (full green)
              colors[0] = changeUIntScale(quality, 50, 100, 0xFF, 0);
            } else {
              // Scale green component to go from red to yellow (full red)
              colors[0] = changeUIntScale(quality, 0, 50, 0, 0xFF);
            }

I would also suggest to avoid pure Yellow #FFFF00 which is not readable with light background. Maybe going for a darker version would still do it:

            uint8_t colors[2] = { 0xAA, 0xAA };
            if(quality > 50) {
              // Scale red component to go from yellow to green (full green)
              colors[0] = changeUIntScale(quality, 50, 100, 0xAA, 0);
            } else {
              // Scale green component to go from red to yellow (full red)
              colors[0] = changeUIntScale(quality, 0, 50, 0, 0xAA);
            }

[DL6ER]

I figured that most (all?) will run Tasmota in the standard configuration which seems to be a black background. This seems to be a wrong assumption and getting colors what are visible for all (e.g. green or orange background) is hard if not impossible.

Removing the quality colors isn't much of a loss as the results are anyway sorted by RSSI (= quality) and I still think my improvement brings advantage to the display. Removing the color code, we're down to 597492 bytes so even less (8 bytes) than current development.

[DL6ER]

Alternative - and color-independent - representation would be using HTML5 progress-bar

I haven't pushed this so far, but it'd come at 597536 bytes (+36 compared to development). As said before, my change without color or progress-bar comes at 597542 bytes (-8 compared to development).

[arendst]

As said in the original issue I won't do changes regarding preferred (b)ssid. This change is only half of what needs to be changed as the command line part has not been tackled.

Changing that too will increase code while current functionality is good enough for most users.

As it stands I won't merge but I will keep it in mind.

[DL6ER]

This change is not meant at all into the direction of preferred BSSID, it just helps users to get a better picture of their WiFi neighborhood at the exact location of the Tasmota device. Hence, I also felt no need to change the command line part.

Concerning BSSID, I can see SetOption56/57 is the preferred choice, even when I cannot use it right now as it leads to malfunction on my side (but that's a separate issue, #10254).

[arendst]

No offence at all but did you notice you are using the same channel on equal ssids? The general approach is to NOT have the same channels on near APs. They should not overlap as if they do they interfere eachother.

If you manage to change them you'll see tasmota will much easier switch to the strongest signal AP.

[DL6ER]

I have the very widely used Fritz!Box in its "Mesh" configuration. I noticed this defect as well, however, the manufacturer says that it is expected. I set both 2.4 GHz and 5GHz to "auto-channel". As result, the 2.4 GHz WiFi are all on the same channel. The interesting bit to note is that the 5GHz are all on different channels... And, of course, the channels can only be configured at the "master", not allowing any manual intervention as to what channels the individual APs use.

Feel free to close the PR if this is not where you think the project should be going. I'll rather concentrate on features rather than UI tweaks in the future (even when we have a variant right now that uses even less Flash than the current development build ;-)).

[arendst]

In the end it became this:

at the cost of over 500 bytes (!) but I would like to see the Signal Strength Indicator. It can be disabled by removing #define USE_ENHANCED_GUI_WIFI_SCAN (as I use it myself ;-)

Thx for the idea.

NB. To not needing translations and screwing up GUI I do not display texts like "Channel" or "Quality". The Italians tend to use abnormal long names for simple things ;-)