Elle publie 4 widgets (le robot avec la carte du logement, un nettoyage express, un réglage en boutons, l’entretien) et la capacité marche très bien, merci Trois sujets :
1. Bug : en mode sombre, un bouton de widget mis en avant ne se distingue plus
Cause, dans front/src/components/boxs/external-widget/style.css : la règle :global(.dark-mode) .button (deux classes) l’emporte sur .buttonPrimary, et aucune règle sombre n’existe pour ce style, alors que le thème Horizon a les siennes (:global(.glass-theme) .buttonPrimary…). Par la même logique, l’état actif des boutons device_feature (.buttonActive) et .buttonDanger devraient être touchés aussi (déduit du CSS, pas constaté).
Correctif proposé : des règles :global(.dark-mode) .buttonPrimary, .buttonActive et .buttonDanger (et leur .buttonIcon), placées après celle de .button. Je peux faire la PR.
2. Les réglages, et l’idée d’une carte « aspirateur » dans le cœur
J’ai bien noté que les listes et les curseurs sont exclus des widgets, par choix (« Out of scope » de dashboard-widgets.md). Pour voir, j’ai fait un widget qui expose un réglage en rangée de boutons. Le verdict de Chris75 est net : la boîte Appareils, avec ses listes et ses curseurs, est plus complète et plus compacte. Ça confirme le choix de la spec.
En revanche, il réclame ce qui manque vraiment : une carte complète par robot, « utile pour tous les robots ». Aujourd’hui il lui faut le widget de l’intégration (carte, état) plus une boîte Appareils de 8 à 19 lignes (mode, aspiration, itinéraire, humidité, fréquence de lavage, sélection de pièces…).
Proposition, dans l’esprit du regroupement des lumières (buildDeviceRows, device-features/light/) : dans la boîte Appareils, regrouper les fonctionnalités vacuum-cleaner d’un même appareil en une seule ligne. On y aurait une icône teintée selon l’état, le nom, l’état en direct, les boutons démarrer/pause et base, et un panneau ouvrant les autres fonctionnalités choisies de l’appareil avec leurs contrôles natifs. Ce serait générique : la catégorie sert déjà Matter (#2516) et les intégrations externes Roborock et Dreame.
Autre piste, si tu la préfères : un composant de widget qui affiche les lignes natives du cœur (DeviceRow) des fonctionnalités de l’intégration elle-même. Le widget du robot porterait alors ses réglages, toujours dessinés par Gladys.
Laquelle te semble la bonne direction ? Je préparerai la PR une fois la direction validée.
3. Petits bugs du cœur rencontrés en route (vérifiés sur master au 02/10)
Champ secret dans une action : impossible à saisir. ActionsCard.jsx passe touchedSecrets={{}} à ConfigField, qui affiche touchedSecrets[clé] ? valeur : '' : la saisie s’efface à chaque frappe. J’ai dû passer le mot de passe en string.
Le default des champs d’action n’est jamais appliqué, ni à l’affichage, ni dans runAction côté serveur, alors que required est contrôlé : on obtient une 422 sur un select qui paraît pourtant rempli.
Listes figées des aspirateurs : VacuumCleanerCleanModeDeviceFeature propose toujours les 7 modes de nettoyage, sans tenir compte des supported_options. Un robot à 4 niveaux d’aspiration affiche donc des choix qu’il n’a pas, et j’ai dû publier un text/select à la place. Même chose pour le mode de fonctionnement, qui propose toujours « Cartographier ».
Libellé générique : quand une fonctionnalité est seule de son type, getDeviceFeatureName affiche le libellé du type (« Doudou (Texte) », « Mode de fonctionnement ») au lieu du nom publié, sauf pour MQTT (DISPLAY_FEATURE_NAME_FOR_THOSE_SERVICES). Les intégrations externes choisissent pourtant leurs noms : faut-il les ajouter à cette règle ?
Je peux proposer rapidement les PR du point 1 et des deux premiers bugs du point 3 si tu es d’accord.
Merci @pierre-gilles pour la réactivité et les issues Je crée la demande de fonctionnalité pour la carte aspirateur, et je me lance dans la PR.
Une question sur le dernier point, qui n’a pas eu d’issue : quand une fonctionnalité est seule de son type, le tableau de bord affiche le libellé du type (« Doudou (Texte) ») au lieu du nom publié (« Doudou (Erreur) »). C’est voulu ? Pour les intégrations externes, qui choisissent leurs noms, le nom publié serait plus parlant.
je rebondis sur le sujet, c’est bien de créer un widget spécial robot, mais ne pourrait-on pas donner accès aux intégrations externes de pouvoir créer des widgets avec plus de possibilités tels que Liste déroulante, Sélecteurs, Curseurs, plus d’images, plus de textes, plus de boutons, …
Trois sujets :
