Visuelle Rückmeldung bei fehlgeschlagenen Befehlen (Dashboard) — 3 Ansätze — Kategorie feature-request-core

Hallo! :waving_hand:

Bei der Arbeit an den Netatmo-Fixes (PR #2618) haben wir festgestellt, dass ein fehlgeschlagener Befehl (z. B. eine Thermostat-Einstellung, während der Dienst nicht erreichbar ist) für den Benutzer unsichtbar ist: Die API antwortet sofort (asynchrone Architektur der Aktionen), das Dashboard zeigt den angeforderten Wert optimistisch an, und der Fehler existiert nur in den Server-Logs. Der Benutzer glaubt, dass seine Einstellung angewendet wurde, obwohl nichts gesendet wurde.

Die #2618 legt die Voraussetzung für Netatmo fest (der Fehler wird nun bis zum Aktionsausführer weitergeleitet, anstatt im Dienst unterdrückt zu werden), und wir möchten den nächsten Schritt vorschlagen. Drei Ansätze, von dem leichtesten bis zum ambitioniertesten — @pierre-gilles, wir würden deine Meinung zum Konzept hören, bevor wir etwas schreiben :slightly_smiling_face:

Ansatz A — Zustandsabgleich (empfohlen)
Bei einem Fehler sendet der Server eine WebSocket-Nachricht und das Dashboard zeigt den tatsächlichen Wert erneut an (Rückgängigmachen der optimistischen Aktualisierung) mit einem diskreten und temporären Indikator auf der betroffenen Steuerung (:warning: „Befehl nicht angewendet“). Kein neuer Benachrichtigungskanal: nur eine ehrliche UI, dort, wo der Benutzer hinschaut. Funktioniert identisch auf PC / Mobilgerät / Tablet, da der Indikator in der Gerätekarte lebt.

Ansatz B — Nachricht über die bestehende API (Benachrichtigungsmuster der Version 4.58)
Fehler → Nachricht an den Benutzer, der den Befehl ausgelöst hat, über die Nachrichten-API: sichtbar in Diskussion, Telegram, Gladys Plus-Push. Mit Deduplizierung, um Spam zu vermeiden, wenn ein Dienst dauerhaft nicht erreichbar ist.

Ansatz C — Generisches Toast
Eine kleine globale Toast-Komponente (WebSocket ui.notification), zunächst mit Befehlsfehlern gefüllt, wiederverwendbar dann für andere Kernbereiche. Dies ist die reichhaltigste Option, aber auch die, die die meisten Fragen aufwirft (Persistenz, Historie…).

Unsere Präferenz: A, eventuell ergänzt durch B — beide bleiben klein und führen kein „Benachrichtigungssystem“ ein, das gewartet werden muss. Natürlich ist C auch als Ergänzung in der Zukunft denkbar, ohne „obligatorisch“ zu sein. Was denkst du?

Hallo @Terdious!

Ich bin total deiner Meinung, dass man da noch was verbessern könnte, und der Ansatz A scheint mir eine gute Lösung zu sein!