Wi-Fi signal quality parameters - confused interpretation

[zokl]

PROBLEM DESCRIPTION

Hello,

While analyzing data obtained via MQTT, I encountered a problem interpreting Wi-Fi parameters RSSI and Signal. From the values, it seems that both parameters are swapped. RSSI is Receive Signal Strength Indicator and should be reported in dBm, and it is always a negative number. As for the second item, it seems to take values from 0 to 100, and it is probably the CCQ - Client Connection Quality. This parameter is commonly called only connection quality or simple quality.

Is that correct? Is it possible to correct and relabel it?

References:
CCQ - https://wiki.mikrotik.com/wiki/Manual:Wireless_FAQ#What_is_CCQ_and_how_are_the_values_determined?
RSSI - https://en.wikipedia.org/wiki/Received_signal_strength_indication

REQUESTED INFORMATION

Make sure your have performed every step and checked the applicable boxes before submitting your issue. Thank you!

• Read the Contributing Guide and Policy and the Code of Conduct
• Searched the problem in issues
• Searched the problem in discussions
• Searched the problem in the docs
• Searched the problem in the chat
• Device used (e.g., Sonoff Basic): all ESP8266 ESP32
• Tasmota binary firmware version number used: 12.2.0.6
  • Pre-compiled
  • Self-compiled
• Flashing tools used: _____
• Provide the output of command: Backlog Template; Module; GPIO 255:

  Configuration output here:

• If using rules, provide the output of this command: Backlog Rule1; Rule2; Rule3:

  Rules output here:

• Provide the output of this command: Status 0:

  STATUS 0 output here:

• Set weblog to 4 and then, when you experience your issue, provide the output of the Console log:

  Console output here:

esp32:

14:58:01.910 MQT: tele/TemesIoT_33D858/STATE = {"Time":"2022-12-16T14:58:01","Uptime":"0T04:40:15","UptimeSec":16815,"Heap":146,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Berry":{"HeapUsed":3,"Objects":43},"POWER1":"OFF","POWER2":"OFF","POWER3":"OFF","POWER4":"OFF","Wifi":{"AP":1,"SSId":"TemesIoT","BSSId":"2C:C8:1B:63:D6:19","Channel":8,"Mode":"11n","RSSI":92,"Signal":-54,"LinkCount":1,"Downtime":"0T00:00:10"}}
14:58:01.920 MQT: tele/TemesIoT_33D858/SENSOR = {"Time":"2022-12-16T14:58:01","Switch1":"ON"}
15:03:01.883 MQT: tele/TemesIoT_33D858/STATE = {"Time":"2022-12-16T15:03:01","Uptime":"0T04:45:15","UptimeSec":17115,"Heap":149,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Berry":{"HeapUsed":3,"Objects":43},"POWER1":"OFF","POWER2":"OFF","POWER3":"OFF","POWER4":"OFF","Wifi":{"AP":1,"SSId":"TemesIoT","BSSId":"2C:C8:1B:63:D6:19","Channel":8,"Mode":"11n","RSSI":92,"Signal":-54,"LinkCount":1,"Downtime":"0T00:00:10"}}
15:03:01.892 MQT: tele/TemesIoT_33D858/SENSOR = {"Time":"2022-12-16T15:03:01","Switch1":"ON"}
15:08:01.870 MQT: tele/TemesIoT_33D858/STATE = {"Time":"2022-12-16T15:08:01","Uptime":"0T04:50:15","UptimeSec":17415,"Heap":149,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"Berry":{"HeapUsed":3,"Objects":43},"POWER1":"OFF","POWER2":"OFF","POWER3":"OFF","POWER4":"OFF","Wifi":{"AP":1,"SSId":"TemesIoT","BSSId":"2C:C8:1B:63:D6:19","Channel":8,"Mode":"11n","RSSI":88,"Signal":-56,"LinkCount":1,"Downtime":"0T00:00:10"}}
15:08:01.880 MQT: tele/TemesIoT_33D858/SENSOR = {"Time":"2022-12-16T15:08:01","Switch1":"ON"}

esp8266:
02:49.385 MQT: tele/Kotelna_CS300/STATE = {"Time":"2022-12-16T15:02:49","Uptime":"0T20:00:20","UptimeSec":72020,"Heap":18,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER1":"OFF","POWER2":"OFF","Wifi":{"AP":1,"SSId":"Dum300-1","BSSId":"B8:69:F4:E7:A5:DC","Channel":1,"Mode":"11n","RSSI":36,"Signal":-82,"LinkCount":1,"Downtime":"0T00:00:06"}}
15:02:49.470 MQT: tele/Kotelna_CS300/SENSOR = {"Time":"2022-12-16T15:02:49","ANALOG":{"MQ2_0":3.36},"DS18B20-1":{"Id":"00000E68984D","Temperature":47.3},"DS18B20-2":{"Id":"00000E9495AD","Temperature":52.6},"DS18B20-3":{"Id":"00000E95AA10","Temperature":47.5},"DS18B20-4":{"Id":"0004334EAFFF","Temperature":49.1},"AM2301":{"Temperature":24.9,"Humidity":19.7,"DewPoint":0.1},"TempUnit":"C"}
15:07:49.485 MQT: tele/Kotelna_CS300/STATE = {"Time":"2022-12-16T15:07:49","Uptime":"0T20:05:20","UptimeSec":72320,"Heap":18,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":19,"MqttCount":1,"POWER1":"OFF","POWER2":"OFF","Wifi":{"AP":1,"SSId":"Dum300-1","BSSId":"B8:69:F4:E7:A5:DC","Channel":1,"Mode":"11n","RSSI":32,"Signal":-84,"LinkCount":1,"Downtime":"0T00:00:06"}}
15:07:49.638 MQT: tele/Kotelna_CS300/SENSOR = {"Time":"2022-12-16T15:07:49","ANALOG":{"MQ2_0":3.31},"DS18B20-1":{"Id":"00000E68984D","Temperature":47.3},"DS18B20-2":{"Id":"00000E9495AD","Temperature":52.1},"DS18B20-3":{"Id":"00000E95AA10","Temperature":47.4},"DS18B20-4":{"Id":"0004334EAFFF","Temperature":48.8},"AM2301":{"Temperature":24.9,"Humidity":20.0,"DewPoint":0.3},"TempUnit":"C"}

TO REPRODUCE

Steps to reproduce the behavior:

EXPECTED BEHAVIOUR

A clear and concise description of what you expected to happen.

SCREENSHOTS

If applicable, add screenshots to help explain your problem.

ADDITIONAL CONTEXT

(Please, remember to close the issue when the problem has been addressed)

[sfromis]

They are the way they are for historical reasons, it would be a breaking change to update. Originally, RSSI was transformed to a "human-friendly" value, with the "Signal" added later for people preferring the dBm value directly. Obviously, we are well aware of what the definitions are, but this is not going to be changed.

[szczukot]

In my opinion, the explanation that it would be a breaking change is weak. You can't go wrong with "mistake" because "it's always been that way"
Today, I also thinkung what
"RSSI":64,"Signal":-68
is meaning.

Especially since I have something like this:
#21370

[Jason2866]

Open Source change like you want.

[sfromis]

It means that it is sort of 64%, with the dBm value of -68. And backwards compatibility is a major concern when a change could wreck havoc on existing users. This is very different from "it's always been that way".

Thus, this is is a strong explanation, even if you may not like it.

The specific calculation is quality = 2 * (dBm + 100), capped at values 0..100. Hence, dBm values of -50 or better gets to be 100, 0 is only when extremely horrible at -100 or worse, while a quality about 50 is about the minimum usable signal strength, -75 dBm.

I suspect that the quality conversion of the dBm value was due to Domoticz seemingly expecting "RSSI" to be a signal quality from 0..10, or around that.

[szczukot]

In every software has "breaking changes".
The main/major version is then bumped, these changes will be recorded in the changelog, and it is up to the user what to do with them.
This is what development and bug fixing is all about.

[s-hadinger]

To be clear, we will not introduce a breaking change in the API (json) without a bigger benefit.

We know that the naming is not ideal, but we have to live with it. The only option is to create a new attribute with a new (correct) name. But we have no short term plan to add 2 more parameters.