Bon en espérant que le code pour la conversion convienne, il fonctionne parfaitement. Si on change notre unité de distance « imperial/US » ou « SI », on convertit les unités de distances associées.
J’aurais fait l’inverse dans les icônes, ça me semble plus logique. On voit que la porte est ‹ fermée › ou ‹ pas fermée ›, fenêtre ‹ fermée › ou ‹ pas fermée ›.
Non?
2ème PR : Ajout des catégories / types vues précédemment spécifiques au VE. Nécessitant la 1ère PR pour la gestion de la consigne d’intensité, j’ai juste mis en commentaire l’appel au code d’affichage de la commande de consigne dans le fichier front/src/components/boxs/device-in-room/DeviceRow.jsx. Testé avec, tout est fonctionnel. PR2 - Add Categorie VE - Electrical Vehicle by Terdious · Pull Request #2318 · GladysAssistant/Gladys · GitHub
3ème PR : Ajout de la gestion des conversions d’unités de distance imperial US (mile) / SI (mètre). Bien entendu, pour cette PR, je suis parti de la PR n°2 pour avoir de quoi faire, j’ai donc juste laissé les nouvelles unités en doublons dans les 2 PR. Testé et fonctionnel dans la PR n°2 et testé avec les types existants DEVICE_FEATURE_CATEGORIES.DISTANCE_SENSOR et DEVICE_FEATURE_CATEGORIES.LEVEL_SENSOR.
Les conversions de inch vers mm ou cm selon la dimension est OK.
Les conversions de feet vers cm ou m selon la dimension est OK.
Les conversions de mile vers mm ou cm selon la dimension est OK.
Etc.
Tests écris. Tu peux regarder le fonctionnement que j’ai mis. [WIP] - PR3 - Vehicle electrical - Add convert units imperial US / SI by Terdious · Pull Request #2323 · GladysAssistant/Gladys · GitHub
Peut être un détail pour le moment, mais au niveau des consommations, il faudrait qu’on précise s’il s’agit des celle depuis le départ / depuis la dernière recharge / du dernier trajet.
Car en l’état on ne peut pas le deviner.
Non tu as raison, ce n’est pas un détail car pour les datas des API, les types placés ne pourront pas être bougés après coup.
Pour la 1ère étape, il ne s’agira que des valeurs envoyées par l’API, les types sont liés, ensuite c’est au développement des API qu’on pourra spécifier dans le Nom de la feature ce que ça représente. Il n’y a que les spécifiques qui peuvent être liées à de l’interface qui ont un type spécifique. Il y aura ensuite la possibilité d’ajouter des types plus généralistes qui pourront être affiliés à du Custom si on veut faire des calculs (via MQTT fake device) et là ce sera à l’utilisateur de mettre les bons noms.
Dans les captures d’écran que j’ai mis, ce sont des fake_device que j’ai mis pour les tests, je n’ai pas forcément bien répercuté les noms des features.
@Terdious Le fait que l’intensité de consigne évolue en incrément de 1 seulement, c’est pratique ou pas ? (Je me rend pas compte des valeurs que ça va être)
Oui, généralement sur de la commande d’intensité comme ça, on n’augmente pas différemment de cette valeur sur l’échelle Ampère. Et sincèrement je ne vois pas d’autre utilisation que pour une voiture ou des batteries solaires à ce jour.
Pour un véhicule par exemple en règle générale on est sur une échelle de 5 à 32A dans la plupart des cas (certaines visiblement vont de 1 à 32A) et en puissance on est donc sur des incréments de 250W.