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 . Drei Punkte:
1. Fehler: In dunklem Modus ist eine hervorgehobene Widget-Schaltfläche nicht mehr erkennbar
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 @pierre-gilles für die Schnelligkeit und die Issues Ich erstelle den Feature-Request für die Karte Aspirateur und beginne mit dem PR.
Eine Frage zum letzten Punkt, der kein Issue hatte: Wenn eine Funktion allein ihrer Art ist, zeigt das Dashboard die Typenbezeichnung (« Doudou (Text) ») an, statt des veröffentlichten Namens (« Doudou (Fehler) »). Ist das beabsichtigt? Für externe Integrationen, die ihre Namen selbst wählen, wäre der veröffentlichte Name aussagekräftiger.
ich greife das Thema auf, es ist gut, ein spezielles Roboter-Widget zu erstellen, aber könnten wir nicht den externen Integrationen Zugang gewähren, um Widgets mit mehr Möglichkeiten zu erstellen, wie z. B. Dropdown-Listen, Selektoren, Schieberegler, mehr Bilder, mehr Text, mehr Buttons, …
Ein Pull Request wurde erstellt, damit die Listen der Modi des Staubsaugers (Reinigung und Laufwerk) die tatsächlich vom Gerät unterstützten Optionen einhalten:
Zögert nicht, dem PR zu folgen, zu testen (optional, vor allem bei kleinen Anfragen) und euer Feedback hier zu hinterlassen, falls nötig.
. Drei Punkte:
