Aggiornamento del software di un box

Bozza da completare in T1.5 con la prova sulle macchine di test. Finché la prova non è fatta, non aggiornare i box dei clienti in blocco.

Come funziona

• Dal pannello si lancia l'aggiornamento di un box.
• Il box esegue dev_scripts/updater.py sull'host attraverso una named pipe (mdm_installation/app/services/host_system_manager/host_manager.py), secondo update.yml.
• Canali: production (branch main, linea 3.2.x, tutti i box dei clienti) e stage (branch stage, solo box di prova, D22). Immagini da ECR.
• Funziona se sul box nessuno ha modificato i container a mano.
• Dalla 3.2.x alla nuova versione (linea stage unita in main) l'update da solo non basta: servono l'import delle configurazioni e un ponte nella nuova release. I box dei clienti non vanno mai portati su stage (D22). Vedi migrazione-box-alla-nuova-versione.md.

Procedura proposta (da validare)

1. Prima: verificare dal pannello che il box sia online e annotare versione e stato; verificare che non ci siano interventi in corso sul posto; avvisare la centrale.
2. Fare il backup della configurazione dal pannello.
3. Lanciare l'aggiornamento.
4. Attendere che il box torni online. Tempo atteso: da misurare in T1.5.
5. Verificare: versione nuova nello stato, telecamere online, un comando di prova (suono a volume basso o snapshot), live, inserimento/disinserimento se concordato con il cliente.
6. Annotare l'esito nell'inventario (T0.5).

Ondate (Fase 9)

1. Un box non critico.
2. Tre box.
3. Gruppi di 5–10 box.

Almeno 24–48 ore tra un'ondata e l'altra. Mai di notte, nel fine settimana o negli orari di apertura e chiusura.

Rollback

Da scrivere dopo T1.5: come tornare alla versione precedente da remoto, e cosa fare se il box non torna online (riavvio via relè Sonoff, intervento di un tecnico).