Oui le but est le même, le LQI prend en compte le RSSI et les paquets envoyés/reçus et la route, les unités sont différentes mais dans les deux cas l’utilisateur veut des barres réseaux dans l’UI.
Un petit peu d’explication => https://www.sciencedirect.com/topics/engineering/link-quality
Le problème du 1 à 5 c’est que si l’on souhaite faire des scènes ( message si signal faible ) on perd en précision. De mon côté c’est acceptable. A voir ce qu’en penses les autres.
On peut couper la poire en deux, passer à du 0 à 10 par exemple. Pas sûr que plus de précision soit si utile que ça 
Après, je pense vraiment que ça vaut le coup de factoriser entre les différents services, comme ça on développe une fois l’UI et tout est compatible
Je comprends bien ce que tu souhaites, mais il ne faut pas mélanger LQI et RSSI ce sont deux unités différentes.
Link quality , unité = LQI spécifique zigbee => pourquoi manipuler la plage ? ( 0 - 255 )
Là on parle de qualité
RSSI Signal strength => unité = dBm ( Commun à tous les protocoles radio )
Là c’est une unité de puissance
Factoriser ok, mais j’ai l’impression que ça n’a ne fait pas sens dans ce cas
Du coup je vois pas trop l’utilité de « convertir » la plage zigbee 0-255 en 0-10 , ça ajoute des lignes de code qui ne servent à rien.
La discussion n’est pas claire car on mélange deux notions là 
Oui mais en tant qu’utilisateur, c’est quoi la différence ?
Tu affiche comment dans l’UI le LQI ?
Et comment tu affiche le RSSI ?
De la même manière, même si ce sont 2 features différentes.
J’avais l’impression que tu n’en voulais qu’une seule
Merci pour tes explications @VonOx c’est un peu plus clair.
Très naïvement, est-ce que cette solution serait plus envisableable ?
Exemple :
[EDIT] Sinon effectivement, on peut créer 2 features, dont une sera spécifique au Zigbee.
Oui mais du coup quel est l’intérêt d’avoir 2 features différentes ?
Le seul intérêt que je vois ce serait potentiellement d’afficher dans la nouvelle vue « graphique » un affichage détaillé de l’évolution du LQI précis.
Après, est-ce que c’est vraiment utile ?
En fait ce que je veux éviter, c’est qu’on fasse un développement spécifique Zigbee et qui ne profite pas aux autres intégrations, car chaque protocole fait sa sauce (c’est toujours comme ça), et qu’après on soit obligé de développer une UI différente par protocole, ce qui n’est pas le but de Gladys !
Après, si il y a une vrai différence, et un vrai besoin de différencier les deux, pas de soucis on peut garder les deux séparé, je veux juste être sûr de l’usage exact pour l’utilisateur final
Non le graph ne sert à rien dans ce cas 
Les unités ne sont pas les mêmes, ces deux features sont en quelques sorte très liées mais elles ne portent pas la même information.
Ce que je ne voulais pas faire c’est convertir la donnée zigbee et ne pas avoir une valeur « gladys » pour le link quality car elle est déjà définie avec ses specs côté zigbee ( pour la partie server ). Si je me met à la place d’un user qui fait une scene et que la doc zigbee lui indique 0-255 et que côté gladys c’est 0-5 ça va générer de la frustration
Côté affichage/icone du « signal » dans l’UI ça sera des barres classiques dans les 2 cas.
Pour info, dans Tasmota, on peut utiliser le signal strength également. On y trouve le RSSI et le signal…
18:59:57.869 MQT: tele/tasmota_C5B00A/STATE = {"Time":"2021-10-04T18:59:57","Uptime":"25T06:33:06","UptimeSec":2183586,"Heap":30,"SleepMode":"Dynamic","Sleep":50,"LoadAvg":20,"MqttCount":354,"Wifi":{"AP":1,"SSId":"XXXXXXXX","BSSId":"XXXXXXXXXX","Channel":6,"RSSI":92,"Signal":-54,"LinkCount":61,"Downtime":"0T00:15:31"}}
Pourtant, tu veux afficher exactement la même information dans l’UI ! Du coup je ne comprend pas!
Quel est l’intérêt de stocker ça à deux endroits différents si la finalité c’est d’afficher la même chose ?
Comment ça va être utilisé?
Justement, ça pour moi c’est un argument pour la factorisation!
Dans l’UI, l’utilisateur ne doit pas avoir à rentrer des valeurs, à éplucher des docs (on est pas dans Home Assistant) si c’est généralisé côté Gladys, on est capable de faire une UI spécifique avec les valeurs pré-remplie.
Exemple: Le On/Off, j’ai fais un composant générique (l’utilisateur n’a pas à connaitre que 0 c’est off et que 1 c’est on: L’UI le fait pour lui)
Autre exemple: la couleur:
L’utilisateur n’a pas a deviner que la couleur est stockée en RGB, en HEX, ou je ne sais quoi: il veut juste contrôler la couleur, peut-importe le protocole utilisé, et il a un color picker qui fait le job peut-importe la marque, et la couleur est envoyée convertie à chaque marque: c’est le développeur qui a fait le job, pas l’utilisateur.
D’où ma remarque pour la qualité de signal, si on généralise le comportement, on sera capable de faire un composant dans l’UI qui te permet de sélectionner de 0 à 5 « barres » (à nous d’imaginer le format du composant), et l’utilisateur n’aura même pas à lire la doc Zigbee
Un argument de plus pour factoriser !
Ici je peux voir que le signal est carrément négatif
A nous de mettre un peu d’ordre sinon ça va être le bazar, et on devra coder 5 UI différentes pour chaque type d’appareil.
Bah c’est des dBm toujours négatif. Pas des LQI.
Du coup je comprend pas la discussion, on veut gérer des m3 comme des mètres en quelque sorte. Pas envie de me lancer là dedans ça n’a aucun sens.
Je connais pas bien ces unités, my bad si je dis des bêtises !
Du coup si ces unités sont différentes, pour l’utilisateur ça se manifeste comment dans l’UI?
Mettons de côté la technique, je veux juste savoir en tant qu’utilisateur comment on affiche ces données
Je veux du concret, dans l’interface ça va ressembler à quoi ?
On peut aussi s’appeler pour en discuter c’est peut-être plus simple 
Comme tu veux !
L’idée c’est juste d’intégrer ça dans une optique utilisateur, plutôt que de penser backend en premier et de se retrouver avec une implémentation différente par intégration 
A voir selon dispo
Sinon pour l’utilisateur ça donnerai ça ( c’est un montage j’ai pas ajuster la couleur de l’icone signal )
Idem pour le RSSI
, elle te plaît cette icone !
Oui je te le confirme, elle est sympa je trouve
C’est propre
Bon du coup tu sais ce que je vais te répondre, je sais pas si je dois le redire 
Du coup pour continuer à dérouler le truc, on est d’accord dans les deux cas on a un chiffre en entrée (le LQI, ou le RSSI), et en sortie on veut un entier de 0 à 5 pour afficher ces 5 vignettes différentes.
Et de ce que je comprend de ce débat, @VonOx toi tu es pour faire le travail de conversion dans le frontend (et stocker la donnée brut en DB), et moi je suis plutôt pour le faire dans le backend (et stocker la donnée transformé en DB)
Après les deux approches ont des pour et des contres:
Exact
Exact car pour moi on a deux unités différentes qui n’ont pas la même signification. Même si l’UI est identique dans ça représentation.
Du coup il faut d’autres avis 
( je ne suis pas dev de métier donc mon avis compte moins)
Après rien n’empêche de changer le nommage de la feature, vu que ce 0-5 n’est plus ni un LQI ni un RSSI mais une valeur « déduite », on peut créer une feature propre à Gladys, « qualité du signal » allant de 0 à 5.
Ensuite on crée des fonctions de conversions pour passer de l’un à l’autre.
Est ce que ça te semblerait cohérent ?
Ou est ce que toi tu serais vraiment pour faire toute la conversion côté frontend ?
Parce que le problème de faire la conversion côté frontend, c’est qu’on doit la faire un peu partout: le Dashboard, les triggers des scènes, les actions des scènes, les messages, etc…
Alors que si on fait ça côté backend, le traitement n’est fait qu’une fois.
Je vois pas pourquoi il y’aurai conversion:
Coté front que je fasse:
if signal = 1 alors tel icone ( valeur générique gladys )
ou
if signal <= 10 alors tel icone ( valeur brute )
C’est pareil non ? J’ai peut être loupé un truc
Coté scene j’exploite la valeur réelle.
Si dans le futur on ajoute une option de box qui permet d’afficher en plus de l’icone la valeur ( LQI ou dBm ) c’est encore plus simple
C’est ce que je voulais proposer dans mon message précédent :
Cela reviendrais à :
signal-strenght