Registro delle decisioni¶
Ogni decisione: data, cosa si è deciso, perché, conseguenze. Le nuove decisioni vanno aggiunte in fondo.
| # | Data | Decisione | Motivazione | Conseguenze |
|---|---|---|---|---|
| D1 | apr 2026 | La produzione MDM resta su Netsons, non su AWS. | Il traffico video della VPN su AWS costerebbe troppo. | Midserver, VPN, OME e la nuova VM restano sul server Proxmox. |
| D2 | apr 2026 | Il database principale BSQ resta su AWS RDS. | Ci scrive il gestionale; separarlo è complesso. | qAlarm 2 e midserver dipendono dal collegamento Netsons ↔ AWS. |
| D3 | mag 2026 | Coolify per i deploy in dev. | Velocizzare i deploy. | Coolify dev su VM 200. |
| D4 | 27/10/2026 | La base del midserver per la prod è refactor/v1 (v3). |
È la versione più avanzata e già in dev; nessun lavoro non pubblicato altrove. | Vanno portate le mancanze (parità). |
| D5 | 27/10/2026 | Per più istanze del midserver: shared subscription MQTT + lock Redis. | Refactoring minimo, il web resta un solo servizio. | Attività T3.5, T3.6. |
| D6 | 27/10/2026 | Il vecchio sistema resta in parallelo finché il nuovo non è completo. | Il nuovo non copre ancora la gestione allarmi. | Nessuna modifica deve rompere Telegram, il progetto di Michele o la VPN degli impianti non migrati. |
| D7 | 27/10/2026 | ewelink-integration resta in prod finché le sue funzioni non sono nel midserver. |
Serve al watchdog e all'apertura cancelli. | Porta 8080 e token preservati in ogni intervento su ServerIT. |
| D8 | 27/10/2026 | M1 (chiavi AWS nei repository) rimandato. | Scelta dell'utente. | Da riprendere prima di aprire la prod (T10.6). |
| D9 | 27/10/2026 | La linea 3.8 dei box andrà in prod, dopo un test completo in dev con midserver v3 e pannello. | Contiene IO config, cluster, formato di stato nuovo. | Serve un ambiente dev completo e box di test. |
| D10 | 27/10/2026 | Le modifiche recenti della 3.2.x vanno riportate nella 3.8 (linea stage). |
Evitare regressioni sui fix di stato e monitoraggio. | Attività T2.1. Analisi del 29/10: quattro comportamenti da riscrivere (dettaglio). |
| D11 | 27/10/2026 | Nuovo dominio su AWS Route 53, affiancato a bsqdev.uk. |
bsqdev.uk non è sotto il nostro controllo; non si può dismettere perché scritto nel codice di app distribuite. |
Attività T6.1; NPM/Traefik continuano a servire bsqdev.uk. |
| D12 | 27/10/2026 | Il PIN non è prioritario nella v3. | Nessuno dei 38 box ha la scheda (has_pin falso ovunque). |
Il pannello deve solo gestire l'assenza della funzione. |
| D13 | 27/10/2026 | Il signaling WebRTC non si porta nella v3. | Codice morto: il live passa da OME. | Rimozione dal pannello. |
| D14 | 27/10/2026 | La VM 400 è inutilizzata e si può ignorare (candidata alla rimozione). | Vecchia VM di sviluppo. | Libera risorse per la nuova VM. |
| D15 | 27/10/2026 | Le porte 1996/2000 e le porte alte usate da Cava sono fuori scope. | Non servono agli obiettivi attuali. | Vincolo: non bloccare l'accesso di Cava ai box. |
| D16 | 27/10/2026 | Il nuovo dominio su Route 53 lo registra Lorenzo. | — | Attività T6.1. |
| D17 | 27/10/2026 | chat/snapshot non si implementa nella v3. Tutte le funzioni di chat recenti (qAlarm 2 + Protexia) vanno mantenute. |
Il topic q_security/chat_snapshot non è pubblicato da nessuno dal 2024. Le chiamate di qAlarm 2 al midserver esistono già nella v3. |
Nessuna attività sulla v3 per la chat. |
| D18 | 28/10/2026 | Team del progetto: Lorenzo e Mattia. Nessun altro viene introdotto; accessi limitati a loro. | Sistema di sicurezza critico: serve sapere chi modifica cosa (Emanuele). | Accessi personali da organizzare; le regole VPN si possono restringere sapendo chi deve accedere. |
| D19 | 28/10/2026 | Nessun IP pubblico nuovo. Gli IP disponibili sono 3–4 per server fisico, tutti già in pfSense (Firewall → Virtual IPs); i servizi delle VM si espongono con NAT su quegli IP. | Logica usata finora da Michele. | La nuova VM, se si fa, usa 185.31.66.186. |
| D20 | 28/10/2026 | Prima si risolvono i problemi principali, poi si va in produzione con il sistema nuovo. | Sistema critico: meglio non dover rifare tutto dopo un incidente (Lorenzo, Mattia, condiviso da Emanuele). | Il piano mantiene i gate prima di ogni passaggio in prod. |
| D21 | 28/10/2026 | qAlarm dev usa l'UUID della risorsa come nome progetto Compose nei comandi personalizzati e conserva il repository durante il deploy. | Evitare progetti diversi a ogni tentativo e bind /app verso directory temporanee; mantenere il volume Redis esistente. |
Configurazione applicata e deploy verificato; dettagli e backup in Coolify dev. |
| D23 | 29/10/2026 | Anche Mohammad lavora al progetto, insieme a Lorenzo e Mattia (aggiorna D18). | Indicazione di Lorenzo; Mohammad ha scritto con Franco il midserver v3 e la linea stage, e ha proposto il DVR come sorgente del live. | Ticket del midserver v3 e del live assegnati a lui come proposta (lavagna). Accessi personali da organizzare come per gli altri. |
| D22 | 29/10/2026 | I box dei clienti non hanno mai la linea stage. stage è sviluppo e gira solo sui box di prova Stage; arriva ai clienti solo dopo l'unione in main, con le immagini di produzione e l'update normale dal pannello. | Il box deve dichiarare la versione che è davvero (Lorenzo). | Migrazione dalla 3.2.x progettata dentro la release unita in main (migrazione); MDM-080, MDM-081. |
| D24 | 30/10/2026 | IP VPN e peer: all'inizio si aggiornano a mano sia in pfSense sia nel registro tecnico. In seguito pfSense diventa la configurazione di riferimento e il registro la importa e la verifica. | Partire senza un'integrazione con pfSense (Lorenzo). | Rischio di disallineamento finché si scrive a mano in due posti: il report delle incongruenze di MDM-054 deve confrontare registro e pfSense. Il registro conserva lo storico delle assegnazioni, perché gli IP vengono riusati. |
| D25 | 30/10/2026 | In qAlarm compaiono solo gli impianti sul sistema MDM (box con detector Frigate o GANZ). I vecchi impianti GANZ non compaiono finché non sono migrati su un box MDM. | Indicazione di Lorenzo. Il type_id 1 di BSQ comprende probabilmente sia i vecchi GANZ sia i box MDM con detector GANZ, quindi non basta a separarli. | Il registro tecnico deve distinguere sistema vecchio e sistema MDM, e la migrazione cambia questo stato; MDM-054, MDM-066. Oggi qAlarm, filtrando per tipo 1, mostra anche i vecchi GANZ. |
| D26 | 30/10/2026 | La scheda GPIO su USB ("PIN") dei box 3.x non si supporta più. La migrazione alla nuova versione non importa gpio_usb né pin.json. | Il driver è stato tolto dalla linea stage il 27/02/2026; nessuno dei 29 box del censimento la usa (has_pin = false). | Tolti dalla stage i gestori MQTT del PIN e il campo gpio_usb, e dal pannello il campo corrispondente; l'import segnala un gpio_usb valorizzato. Dettaglio in MDM-080. |
| D27 | 02/11/2026 | Live Protexia solo nel player interno: rimossa la pressione lunga; la pagina /installation/live_stream/{token} non si porta nella v3. | Eliminare la seconda modalita di riproduzione. | MDM-043/T3.12 annullati per la nuova app; rollout e prova live ancora aperti. Vecchie app e pagina v2 preservate. La proposta di token di servizio BSQ e stata successivamente annullata (D28). |
| D28 | 02/11/2026 | Annullare le modifiche API BSQ a URL e token di servizio. In futuro rimuovere il passaggio BSQ dalla creazione degli stream. | Evitare di sviluppare ulteriormente un passaggio destinato alla rimozione. | PHP/Dockerfile/test e relativa documentazione BSQ ripristinati; configurazione e player Protexia mantenuti. Il flusso attuale passa ancora da BSQ; nuova API, autorizzazione e migrazione non sono implementate. Restano URL prod fisso e incompatibilita JWT con la v3. |
Decisioni proposte, da confermare¶
| # | Proposta | Perché | Chi deve confermare |
|---|---|---|---|
| P1 | Dove mettere qAlarm 2 in prod. Nessun IP pubblico nuovo serve in nessuna opzione. (a) consigliata: nuova VM "prod-apps" con un Coolify di prod, raggiunta da 185.31.66.186, che ha 80/443 liberi. (b) Su ServerIT, accanto al midserver, dietro NPM su 185.31.66.185: niente VM nuova, ma niente Coolify (il suo Traefik va in conflitto con NPM su 80/443), deploy a mano, e qAlarm condivide la macchina con il midserver che verrà sostituito. |
ServerIT non serve "solo per le nuove installazioni": la usano ogni minuto il watchdog ewelink, ogni giorno pannello, comandi e video, e i box ci mandano stato e log. È la macchina che cambierà di più nella Fase 8. Separare la console degli operatori la protegge da quel cambio. Le risorse non sono un problema in nessuno dei due casi. | Lorenzo, Michele, Enrico |
| P2 | Midserver v3 in prod sulla stessa VM ServerIT, mantenendo 172.16.16.253, porte 5000/1883 e OME su 185.31.66.185. |
I box conoscono questi indirizzi; nessuna riconfigurazione del parco. | Lorenzo, Michele |
| P3 | Strategia di compatibilità (a): prima la v3 compatibile con i box 3.2.x, poi la migrazione graduale dei box alla 3.8. | Il lato server si riporta indietro facilmente, 38 box remoti no. | Lorenzo |
| P4 | Allineare tutti i box a 3.2.9 prima del cambio di midserver. Aperta (29/10, domanda A25). | Una sola versione da testare invece di un intervallo; costa un giro di aggiornamenti in più sugli impianti. | Lorenzo, Michele |
| P5 | Immagini da ECR per tutti i servizi, con amazon-ecr-credential-helper sui server Coolify. |
Deploy ripetibili e rollback per tag. | Lorenzo |
| P6 | Monitoraggio minimo con allarmi notturni (es. Uptime Kuma). Fuori scope per ora (27/10/2026): R1 resta segnalato. | R1. | Enrico, Michele |
| P8 | Due fonti di verità sulle installazioni: anagrafica nel database BSQ (solo lettura per noi) e registro tecnico nel midserver v3 (impianti, box, VPN, Sonoff, trombe, ciclo di vita), collegati da bsq_installation_id. Redis resta solo stato in tempo reale. Il database del Raspberry viene importato e poi dismesso. qAlarm prende l'elenco dal registro. |
Oggi sei elenchi parziali con chiavi diverse; qAlarm mostra impianti non monitorati; code = MAC non regge gli impianti con più box. Dettagli in sorgenti-dati-installazioni.md. |
Lorenzo, Mattia, Enrico (per il gestionale) |
| P10 | DVR come sorgente del live (Mohammad e Marco, 29/10/2026): il live legge dal DVR dell'impianto attraverso webrtc_streams, senza un media server in più sul box; go2rtc di Frigate sui box Frigate; mai l'URL della telecamera. |
Il live non tocca le sessioni del rilevamento; nessun componente nuovo su box con poche risorse. Dal censimento del 29/10 in 11 impianti Frigate legge già da un DVR/NVR. | Lorenzo, Mattia, dopo le prove di MDM-037 |
| P9 | Convenzione dei branch uniforme su tutti i repository del progetto: main = produzione, stage = prossima versione. Per il midserver, refactor/v1 diventa stage quando la v3 è la base ufficiale; dev viene archiviato. Pannello e qAlarm valutati caso per caso (deploy_dev serve al deploy automatico). |
Convenzione già usata in molti progetti (28/10); oggi ogni repository ne ha una diversa. | Lorenzo, Mattia |
| P7 | Macchine di test: non installare solo l'ultima versione. Almeno una macchina con la 3.8 aggiornata (dopo T2.1–T2.3) e almeno una con la 3.2.9, la versione del parco. La 3.2.9 serve a provare che la v3 funziona con i box di oggi e a provare l'aggiornamento remoto 3.2.9 → 3.8 che poi si farà sui clienti. Se le macchine sono due, la seconda si porta da 3.2.9 a 3.8 durante la prova. | Il parco resterà sulla 3.2.x per settimane anche dopo il cambio di midserver: con solo la 3.8 non si proverebbe né la compatibilità né il percorso di aggiornamento. | Lorenzo |