Stato del progetto al 29/10/2026¶
Sintesi a semaforo¶
| Area | Stato | In breve |
|---|---|---|
| Operatività quotidiana degli allarmi | 🟢 | Funziona sul sistema vecchio (Telegram, progetto di Michele, GANZ). |
| Infrastruttura (server, pfSense, VPN) | 🟡 | Stabile da 117 giorni, ma con punti critici unici, accessi condivisi, backup solo settimanali e monitoraggio affidato al solo Raspberry di Michele, senza backup (segnalato, fuori scope per ora). |
| Midserver in produzione (v2) | 🟡 | Funziona, ma usa il server di sviluppo di Flask, non ha pipeline né backup del database, e Redis può svuotarsi con un comando sbagliato. |
| Midserver nuovo (v3) | 🟠 | In dev da giugno, fermo. Mancano 2 endpoint usati dai box, la pagina live usata dall'app Protexia e 5 redirect per il pannello. Mai provato con box reali. Non regge più istanze. |
| Software dei box | 🟡 | 38 box registrati, 28 rispondono al censimento, tra 3.1.9 e 3.2.9 (linea main). La linea stage (3.9.0) gira solo sul box di prova; prima della produzione servono i comportamenti della 3.2.9, l'import delle configurazioni con il ponte di aggiornamento e la verifica degli allarmi GANZ (R16). |
| Video e telecamere | 🟠 | Il live del sistema nuovo consuma sessioni delle telecamere usate dal rilevamento (R14); proposta: DVR come sorgente (P10). Anti-manomissione e incendio non arrivano agli operatori (R15, R17). |
| qAlarm 2 | 🟠 | Funzioni base pronte in dev, mai usato dalla centrale. 3 problemi bloccanti per la prod (Q1–Q3). |
| App Protexia | 🟡 | In uso. La versione con la chat verso qAlarm 2 non è pubblicata. Indirizzi scritti nel codice. |
| Sicurezza | 🟠 | Niente esposto da internet oltre il necessario, ma la VPN lascia ogni box raggiungere tutto. Credenziali nei repository e negli script, compreso il token Telegram del monitoraggio (M28); stessa password admin su tutti i box stage (M31). |
| Documentazione e conoscenza | 🔴 | Ricostruita il 27–29/10 (questa cartella), revisione di coerenza il 29/10. Michele lascia l'azienda (presente fino al 30/10): passaggio di consegne urgente (T0.9). Restano da verificare con lui le parti del sistema vecchio (domande aperte). Team del progetto: Lorenzo e Mattia. |
Pagine di dettaglio¶
| Pagina | Contenuto |
|---|---|
| versioni-e-branch.md | Cosa gira dove, con quale versione e da quale branch |
| fix-main-da-portare-in-stage.md | Correzioni presenti solo in main del box e quali riportare in stage |
| dati-e-registro-installazioni.md | Dove stanno i dati (Redis vs MySQL) e cosa implica |
| sorgenti-dati-installazioni.md | Tutti gli elenchi delle installazioni (BSQ, Redis, Raspberry, pfSense…), chi li usa e la proposta di fonte unica |
| parita-midserver-v3.md | Cosa manca alla v3 per sostituire la v2 |
| rischi-e-problemi.md | Registro di problemi e rischi con priorità |
| decisioni.md | Decisioni prese, con data e motivazione |
| domande-aperte.md | Cosa non sappiamo ancora e chi può rispondere |
Cosa è stato verificato e come¶
Tutto in sola lettura il 27/10/2026:
- codice delle repository locali (branch e confronti indicati nelle pagine);
- Coolify dev via MCP;
- API Proxmox (risorse, VM, rete, firewall, backup);
- pannello pfSense (interfacce, NAT, regole, WireGuard, ARP, stati);
- comandi sul server di prod eseguiti dall'utente (docker ps, ss, git diff, conteggi su MySQL e Redis);
- prova di raggiungibilità di Proxmox da rete mobile senza VPN.
Non verificato: il contenuto dei box sul campo (oltre a una configurazione letta su un box), il codice del sistema di Michele, le regole del firewall di Cava, il ripristino da backup.