Rückmeldungen zur Dreame-Integration: Widgets im Dunklen Modus, Staubsaugerkarte, kleine Herz-Bugs

Entwicklung
1

Hallo @pierre-gilles,

Da das Thema der Integrations-Widgets (Permettre aux intégrations de déclarer leurs propres widgets de dashboard (schéma JSON)) geschlossen ist, fasse ich hier eine Zusammenfassung der Erfahrungen aus der Praxis und einige Kernprobleme, die bei der Entwicklung der externen Integration Dreame (Saug- und Wischroboter) aufgetreten sind. Sie wird von @Chris75 in der Praxis an einem dreame.vacuum.r2449a getestet (Demande d'intégration externe pour robot aspirateur/laveur DREAME).

Sie veröffentlicht 4 Widgets (den Roboter mit der Wohnungsübersicht, eine Schnellreinigung, eine Einstellung mit Schaltflächen und die Wartung) und die Funktion läuft sehr gut, danke :folded_hands:. Drei Punkte:

1. Fehler: In dunklem Modus ist eine hervorgehobene Widget-Schaltfläche nicht mehr erkennbar

  • Beobachtung: Im dunklen Modus wird eine Schaltfläche mit style: "primary" wie die anderen eingefärbt, ihr Symbol verschwindet und die hervorgehobene Auswahl wird unsichtbar (Screenshots von Chris75: Demande d'intégration externe pour robot aspirateur/laveur DREAME - #32 par Chris75).
  • Ursache, in front/src/components/boxs/external-widget/style.css: Die Regel :global(.dark-mode) .button (zwei Klassen) übertrifft .buttonPrimary, und es gibt keine dunkle Regel für diesen Stil, obwohl das Horizon-Theme seine eigenen hat (:global(.glass-theme) .buttonPrimary…). Nach derselben Logik sollten auch die aktiven Zustände der Schaltflächen device_feature (.buttonActive) und .buttonDanger betroffen sein (aus der CSS abgeleitet, aber nicht beobachtet).
  • Vorgelegter Korrekturvorschlag: Regeln :global(.dark-mode) .buttonPrimary, .buttonActive und .buttonDanger (und ihr .buttonIcon), platziert nach der Regel von .button. Ich kann den Pull Request erstellen.

2. Die Einstellungen und die Idee einer „Staubsauger“-Karte im Kern

  • Ich habe verstanden, dass Listen und Schieberegler aus den Widgets ausgeschlossen sind, aus Prinzip (« Out of scope » von dashboard-widgets.md). Zum Testen habe ich ein Widget erstellt, das eine Einstellung in einer Reihe von Schaltflächen anzeigt. Das Urteil von Chris75 ist klar: Die Geräte-Box mit ihren Listen und Schiebereglern ist vollständiger und kompakter. Das bestätigt die Spezifikation.
  • Allerdings verlangt er, was wirklich fehlt: eine vollständige Karte pro Roboter, „nützlich für alle Roboter“. Heute benötigt er das Widget der Integration (Karte, Zustand) sowie eine Geräte-Box mit 8 bis 19 Zeilen (Modus, Saugkraft, Route, Luftfeuchtigkeit, Waschfrequenz, Raumauswahl…).
  • Vorschlag, im Sinne der Zusammenfassung der Lampen (buildDeviceRows, device-features/light/): In der Geräte-Box die Funktionen vacuum-cleaner eines Geräts in einer einzigen Zeile zusammenfassen. Dort hätte man ein Symbol, das je nach Zustand eingefärbt ist, den Namen, den aktuellen Zustand, die Schaltflächen Start/Pause und Basis, und ein Panel, das die anderen ausgewählten Funktionen des Geräts mit ihren nativen Steuerungen öffnet. Das wäre generisch: Die Kategorie dient bereits Matter (#2516) und den externen Integrationen Roborock und Dreame.
  • Andere Option, wenn du sie bevorzugst: Eine Widget-Komponente, die die nativen Kernzeilen (DeviceRow) der Funktionen der Integration selbst anzeigt. Das Roboter-Widget würde dann seine Einstellungen tragen, immer noch von Gladys gezeichnet.
  • Welche Richtung erscheint dir die richtige? Ich werde den Pull Request vorbereiten, sobald die Richtung bestätigt ist.

3. Kleine Kernfehler, die unterwegs aufgetreten sind (überprüft auf master am 02/10)

  • Feld secret in einer Aktion: Kann nicht eingegeben werden. ActionsCard.jsx übergibt touchedSecrets={{}} an ConfigField, das touchedSecrets[Schlüssel] ? Wert : '' anzeigt: Die Eingabe wird bei jedem Tastendruck gelöscht. Ich musste das Passwort als string durchgeben.
  • Der default-Wert der Aktionsfelder wird nie angewendet, weder bei der Anzeige noch in runAction auf Serverseite, obwohl required überprüft wird: Man erhält eine 422 bei einem select, das scheinbar gefüllt ist.
  • Feste Listen der Staubsauger: VacuumCleanerCleanModeDeviceFeature bietet immer die 7 Reinigungsmodi an, ohne die supported_options zu berücksichtigen. Ein Roboter mit 4 Saugstufen zeigt also Optionen an, die er nicht hat, und ich musste stattdessen ein text/select veröffentlichen. Dasselbe gilt für den Betriebsmodus, der immer „Kartieren“ anbietet.
  • Generische Bezeichnung: Wenn eine Funktion die einzige ihrer Art ist, zeigt getDeviceFeatureName die Bezeichnung des Typs (« Doudou (Text) », « Betriebsmodus ») an, statt des veröffentlichten Namens, außer bei MQTT (DISPLAY_FEATURE_NAME_FOR_THOSE_SERVICES). Die externen Integrationen wählen jedoch ihre eigenen Namen: Sollten sie zu dieser Regel hinzugefügt werden?

Ich kann schnell die Pull Requests zum Punkt 1 und zu den ersten beiden Fehlern aus Punkt 3 vorschlagen, wenn du einverstanden bist.

Danke!