Hello! 
While working on the Netatmo fixes (PR #2618), we noticed that a failed command (e.g., thermostat setpoint when the service is unreachable) is invisible to the user: the API responds immediately (asynchronous architecture of actions), the dashboard displays the requested value optimistically, and the failure only exists in the server logs. The user believes their setpoint has been applied when nothing has been sent.
#2618 lays the groundwork for Netatmo (the error now propagates to the action executor instead of being swallowed by the service), and we’d like to propose the next steps. Three options, from the lightest to the most ambitious — @pierre-gilles, we’d love your input on the concept before we write anything 
Option A — State Reconciliation (recommended)
In case of failure, the server emits a websocket event and the dashboard redisplays the true value (cancellation of the optimistic update) with a discreet and temporary indicator on the affected control (
« Command not applied »). No new notification channel: just an honest UI, where the user is looking. Works identically on PC, mobile, and tablet since the indicator lives in the device card.
Option B — Message via the existing API (update notification 4.58 pattern)
Failure → message to the user who triggered the command, via the message API: visible in Discussion, Telegram, Gladys Plus push. With deduplication to avoid spam if a service is persistently unreachable.
Option C — Generic Toast
A small global toast component (websocket ui.notification), initially powered by command failures, reusable later by other core domains. This is the richest option but also the one that raises the most questions (persistence, history…).
Our preference: A, possibly supplemented by B — both remain small and do not introduce a « notification system » to maintain. Of course, C is also conceivable as an addition later without being « mandatory ». What do you think?