Retours de l'intégration Dreame : widgets en mode sombre, carte aspirateur, petits bugs du cœur

Développement
1

Bonjour @pierre-gilles,

Le sujet des widgets d’intégration (Permettre aux intégrations de déclarer leurs propres widgets de dashboard (schéma JSON)) étant fermé, je regroupe ici un retour terrain et quelques points du cœur rencontrés en développant l’intégration externe Dreame (robots aspirateurs laveurs). Elle est testée en réel par @Chris75 sur un dreame.vacuum.r2449a (Demande d'intégration externe pour robot aspirateur/laveur DREAME).

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 :folded_hands: Trois sujets :

1. Bug : en mode sombre, un bouton de widget mis en avant ne se distingue plus

  • Constat : en mode sombre, un bouton style: "primary" est peint comme les autres, son icône disparaît, et le choix mis en avant devient invisible (captures de Chris75 : Demande d'intégration externe pour robot aspirateur/laveur DREAME - #32 par Chris75).
  • 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 !