Vai al contenuto

Storia e contesto: come si è arrivati qui

Ricostruzione dalle call (marzo–ottobre 2026) e dal codice. Le date sono quelle delle fonti; dove manca una data, non è stata inventata.

1. All'inizio: GANZ su Windows e Telegram

  • I primi impianti (dal 2022–2023) usano un PC Windows con il server GANZ, un software commerciale con licenza costosa. Il detector GANZ manda gli eventi via HTTP.
  • La centrale si collegava via VPN ai PC dei clienti con il client GANZ.
  • Michele ha costruito intorno a questo il progetto televigilanza-mdm: riceve gli allarmi e li inoltra su Telegram (un gruppo con un argomento per cliente, più bot per distribuire il carico), gestisce gli automatismi (saluti all'inserimento, foto all'apertura, messaggi sempre diversi per sembrare un operatore vero), la pagina comandi per la centrale, il controllo online/offline degli impianti e il riavvio via relè Sonoff. Parte di questo gira su un Raspberry in centrale.
  • Una parte degli impianti appartiene a una società esterna che affida all'azienda solo la gestione allarmi: restano su GANZ e non sono migrabili.

2. Il sistema nuovo (MDM)

Obiettivo: togliere Windows e la licenza GANZ, avere box Linux gestiti in modo centralizzato.

  • mdm_installation: il software del box (Ubuntu + Docker), con detector Frigate o GANZ.
  • mdm_mid_server: il server centrale (Flask), con MQTT verso i box.
  • mdm_web_panel: il pannello web interno (Flutter).
  • mdm_frigate_wrapper e mdm_privacy_mode.
  • Franco, con Lorenzo e Mohammad, ha riportato nel midserver le funzioni del progetto di Michele (automatismi, suoni).

A ottobre 2026 38 impianti sono sul sistema nuovo (versioni 3.1.9–3.2.9). Gli allarmi però passano ancora dal percorso vecchio: il frigate wrapper li manda all'API BSQ (api.bsqcontrol.it) e da lì a Telegram.

3. qAlarm 2 e Protexia

  • qAlarm (vecchio) è la web app per gli allarmi di telemetria (veicoli), usata insieme a KFT.
  • qAlarm 2 nasce (inizio 2026) per sostituire la parte di videosorveglianza: allarmi in tempo reale, video, comandi, procedure del cliente, chat. In futuro dovrebbe assorbire anche la telemetria.
  • L'app Protexia permette al cliente di armare/disarmare e di chattare con la centrale. La chat con qAlarm 2 richiede una nuova versione dell'app, non ancora pubblicata (call del 30/09).
  • Richiesta della centrale (13/05): una barra sempre visibile con gli impianti offline.

4. Il refactoring v3 e l'ambiente dev

  • Tra maggio e giugno 2026 Franco e Mohammad scrivono la v3 del midserver (refactor/v1, FastAPI), e la linea 3.8 del software dei box (stage, con IO config e cluster).
  • Ad aprile 2026 si decide di restare su Netsons e non spostarsi su AWS: il traffico video dei box (178 TB contati sulla VPN all'8 aprile, periodo di riferimento non precisato) su AWS costerebbe troppo. Il database principale BSQ resta su AWS RDS, perché il gestionale ci scrive l'anagrafica.
  • A maggio viene installato Coolify su una VM di dev per velocizzare i deploy.
  • Il lavoro si ferma da giugno. Franco lascia l'azienda. A fine settembre si decide di riprendere: Mattia viene inserito, Lorenzo riprende qAlarm e la parte MDM.

5. Ottobre 2026: ripartenza

  • 19/10: Michele presenta l'infrastruttura (Proxmox, pfSense, VPN, centralino trombe, backup).
  • 27/10: analisi completa in sola lettura di codice, Coolify dev, Proxmox, pfSense e server di prod. Ne nascono questa documentazione e il piano operativo.
  • Decisioni del 27/10: la v3 del midserver e la linea 3.8 dei box andranno in produzione, prima con un test completo in dev; nuovo dominio su AWS Route 53, affiancato a bsqdev.uk. Vedi decisioni.
  • 28/10: allineamento con Enrico, Emanuele, Michele e Mattia sulla documentazione prodotta. Michele lascia l'azienda (presente fino al 30/10): serve chiudere il passaggio di consegne. Il team del progetto è Lorenzo + Mattia. Approccio confermato: risolvere i problemi principali prima di andare in produzione, perché è un sistema critico.

Lezioni da non ripetere

  • Release diverse su box diversi senza tracciamento: rende difficile capire cosa gira dove (call del 30/09).
  • Lavoro fermo e non provato: la v3 e la sostituzione di Telegram sono pronte "sulla carta" ma non sono mai state provate end-to-end con impianti veri.
  • Conoscenza in una sola persona: accessi, rete e operatività dipendono da Michele. Il codice v3 dipendeva da Franco.
  • Credenziali condivise (root, admin, chiavi AWS negli script): da riorganizzare.