0.6.9: il bridge corretto (boost con la durata) e i comandi con argomento in PROTOCOL

La copia del bridge dentro l'app va tenuta allineata: contiene la correzione
del boost, dell'assenza, di ACS off e del riscaldamento forzato, che la
libreria accetta solo con un argomento. Il pacchetto Sailfish non cambia (il
bridge non entra nell'RPM), quindi non serve ricostruire l'RPM.

docs/PIANO.md

@@ -382,6 +382,24 @@ la copre; se l'area non c'è la riga resta dov'era. Nuovo controllo statico
 esiste, e l'id del comando confrontato con la tabella del bridge — un id
 sbagliato sarebbe un 400 scoperto solo sul telefono.
 
-**Stato attuale (0.6.9).** 85/85 verifiche del nucleo, 48/48 del bridge,
+**Il boost non partiva: mancava un argomento (correzione del bridge).** Il primo
+tocco sul boost ha mostrato in rosso, in fondo alla Home, *«richiesta non
+valida: ActivateHotWaterBoosting.__init__() missing 1 required positional
+argument: 'hot_water_boost_duration'»*. Non era l'impianto a rifiutare: il
+comando non veniva nemmeno costruito. La libreria pretende un argomento per
+quattro comandi della whitelist — `hot_water_boost_on`, `hot_water_heating_off`
+e `force_heating_on` una durata, `away_mode_on` inizio, fine e la temperatura da
+tenere in casa — e il bridge li chiamava senza. Il boost è solo il primo che è
+stato toccato: anche l'assenza, il tasto accanto, sarebbe fallita così. Ora
+ognuno ha il suo ramo in `build_command`, con i default in cima al file (60
+minuti per le tre durate, 7 giorni e 15 °C per l'assenza) e un `value`
+opzionale che l'app può mandare. `test_bridge_commands.py` ora costruisce
+**tutti** i comandi della whitelist e li incarta come li manda la libreria: se
+uno resta senza argomento obbligatorio si vede lì (74/74). Provato dal vivo con
+un `ping` (200, con la ricezione dall'impianto) e con un boost fuori intervallo,
+respinto con 400 **prima** di partire.
+
+**Stato attuale (0.6.9).** 85/85 verifiche del nucleo, 74/74 del bridge,
 191/191 stringhe tradotte, `qmllint` pulito, contratto UI↔bridge rispettato.
-Nessun comando è stato inviato all'impianto: tutto quanto sopra è a sola lettura.
+All'impianto è stato inviato un solo comando, di prova e innocuo: un `ping`
+diagnostico, che non cambia nulla. Nessun comando di regolazione è mai partito.

docs/PROTOCOL.md

@@ -153,11 +153,11 @@ Risposta: `{"ok": true, "id": "...", "result": {...}}`.
 | `set_hot_water_target` | 45–60 | temperatura ACS obiettivo |
 | `set_heating_setpoint` | 5–30 | temperatura obiettivo della casa (zona, default 1) |
 | `set_cooling_setpoint` | 5–30 | temperatura obiettivo del raffrescamento (zona, default 1) |
-| `hot_water_boost_on` / `hot_water_boost_off` | — | boost ACS una tantum |
-| `hot_water_heating_on` / `hot_water_heating_off` | — | riscaldamento ACS |
-| `away_mode_on` / `away_mode_off` | — | modalità assenza |
+| `hot_water_boost_on` / `hot_water_boost_off` | minuti, 15–240 (default 60) | boost ACS una tantum |
+| `hot_water_heating_on` / `hot_water_heating_off` | minuti, 15–1440 (default 60) | riscaldamento ACS |
+| `away_mode_on` / `away_mode_off` | giorni, 1–60 (default 7) | modalità assenza |
 | `night_mode_1h` | — | night mode per un'ora |
-| `force_heating_on` / `force_heating_off` | — | riscaldamento forzato |
+| `force_heating_on` / `force_heating_off` | minuti, 15–240 (default 60) | riscaldamento forzato |
 | `heating_on` / `heating_off` | — | funzione riscaldamento |
 | `legionella_cycle` | — | ciclo antilegionella |