Sistema di Michele (televigilanza-mdm) e Raspberry in centrale

Il "sistema vecchio" che oggi tiene in piedi l'operatività quotidiana. Repository su CodeCommit (televigilanza-mdm), copia locale C:\Users\l.mioso\Documents\GitHub\televigilanza-mdm.

Descrizione ufficiale su CodeCommit: componente di coordinamento di un impianto di televigilanza. Collega i servizi MDM/Protexia, i dispositivi locali, l'impianto di allarme del cliente e la centrale. Consente di inserire e disinserire l'impianto, ricevere immagini di allarme, inviare notifiche Telegram, azionare diffusori e relè e controllare la disponibilità dei servizi.

Cosa fa (dalle call del 30/09 e del 19/10)

• Allarmi su Telegram: riceve gli eventi e li inoltra a un gruppo Telegram, con un argomento per cliente e più bot per distribuire il carico. Limite: se arrivano tante foto insieme, Telegram blocca l'invio per alcuni minuti (errore 429).
• Integrazione con la centrale d'allarme del cliente: un dispositivo riceve via cavo lo stato inserito/disinserito e chiama via HTTP il progetto, che attiva l'impianto e riproduce un saluto.
• Automatismi "verosimilmente umani": messaggi sempre diversi, foto all'apertura e alla chiusura.
• Pagina comandi per la centrale: elenco impianti, inserimento/disinserimento, suoni (due pulsanti di inserimento: con snapshot al cliente o silenzioso).
• Controllo impianti online/offline e riavvio via Sonoff: database locale con impianti, IP, relè associati e porte da controllare, più 2–3 script di controllo continuo. Gira su un Raspberry in centrale.
• Strumenti per i box Windows (riavvio automatico di WireGuard dopo 5 minuti di disconnessione).
• Nginx proxy sul box per raggiungere NVR e telecamere del cliente dalla centrale.
• Monitoraggio dell'infrastruttura dal Raspberry (system_controls): l'elenco di ciò che si controlla è la tabella system, ogni voce con il suo argomento Telegram. Gli avvisi arrivano nel gruppo Telegram "Controllo Infrastrutture", finora seguito da Michele come reperibile e ora anche dall'ufficio IT (Michele, 30/10).
• Controllo di presenza dell'operatore (Michele, 30/10): il Raspberry è in centrale operativa e ogni ora suona un buzzer; l'operatore deve premere un pulsante entro 60 secondi, altrimenti un relè manda un allarme a un istituto di vigilanza esterno. Se il buzzer non suona, il Raspberry è fermo e va segnalato: è anche l'unico controllo sul Raspberry stesso.

Rapporto con il sistema nuovo

• Le funzioni di automazione e suoni sono state riportate nel midserver da Franco, ma mai provate sul campo (il test a casa di un collega non è stato fatto).
• Quando qAlarm 2 sarà in uso, Telegram e la pagina comandi andranno dismessi. Il controllo online/offline e il watchdog Sonoff dovranno passare a midserver/qAlarm.
• Circa 30 impianti sono ancora gestiti solo da questo sistema (call del 30/09).

Da documentare (manca)

• Elenco degli endpoint e dei consumatori del progetto.
• Dove gira esattamente ogni parte (Raspberry, server Netsons). Già noto: l'applicazione PHP si installa sul PC master di ogni cliente MDM, con Apache e un MySQL locale, cron di controllo della VPN e di pulizia dei log (preparazione-pc-ubuntu.md).
• Come si passa da un impianto "vecchio" a uno MDM per questo sistema.

Database del Raspberry (letto in sola lettura il 27/10/2026)

MariaDB 10.11 su 192.168.200.220:3306 (rete aziendale di Cava, raggiungibile dalla VPN aziendale). Le credenziali sono nel codice di Michele (raw/michele/sonoff/) e non vanno copiate altrove.

Base dati	Tabelle principali	Contenuto	Utile al progetto
ganzcortrol_controls	system (68 righe), check_count_vpn, check_count, check_sonoff (52), logs_vpn (~17,8 milioni di righe, ~2,3 GB)	anagrafica degli impianti: nome cliente, tipo (mdm / ganz), stato, hostname, indirizzo VPN, relè Sonoff associato, ultima azione Sonoff, timeout; contatori di errori VPN; stato dei relè	sì: è la base dell'inventario (T0.5)
system_controls	system (18 righe), check_count, logs (~5,4 milioni di righe, ~2,1 GB)	server e servizi controllati (Proxmox, SSH, Node-RED, Home Assistant…), ognuno con un argomento Telegram per gli avvisi	sì: è il monitoraggio esistente (vedi R1)
servicecenter_survival, vehicle_management	—	altri progetti aziendali (non MDM)	no, non letti

Numeri (27/10/2026): - ganzcortrol_controls.system: 68 impianti, 37 mdm e 31 ganz; 64 attivi (36 MDM, 28 GANZ), 4 disattivati; 65 con VPN collegata; 49 con relè Sonoff (35 MDM, 14 GANZ). Tutti hanno un indirizzo VPN 172.16.16.x (uno è duplicato). - Confronto con i 66 peer WireGuard di pfSense: 65 indirizzi in comune, 1 peer presente solo su pfSense (un impianto da identificare: sulla VPN non ci sono PC dei dipendenti, Michele 30/10), 2 indirizzi presenti solo nel database (peer rimossi o mai creati). - Riavvii via Sonoff: 29 impianti ne hanno avuto almeno uno, 14 nel solo ottobre 2026; 39 mai. - check_sonoff: 52 relè, 48 online.

Come si usa: gli script di controllo leggono system, verificano VPN e servizi, aggiornano i contatori e, oltre la soglia, chiamano ewelink-integration per spegnere e riaccendere il relè (sonoff_reboot, almeno un'ora tra due riavvii dello stesso impianto).

Export: le tabelle utili sono esportate in CSV in raw/raspberry_db/ (cartella riservata: contiene dati dei clienti).