Sorgenti dei dati sulle installazioni: situazione e proposta¶
Analisi del 28/10/2026 sul codice di qAlarm2_be, qAlarm2_fe, mdm_mid_server (v2 dev e v3), api.bsq e sui dati letti in sola lettura (Redis, MySQL del midserver, database del Raspberry, pfSense).
Il problema in una frase¶
Oggi non esiste una fonte unica che dica "questi sono gli impianti che monitoriamo, e questi sono i loro box". Ci sono almeno sei elenchi, ognuno parziale, collegati tra loro da chiavi diverse (MAC, codice, nome, IP VPN) e senza un processo che li tenga allineati.
Gli elenchi che esistono oggi¶
| # | Dove | Cosa contiene | Chi lo scrive | Chi lo legge | Chiave |
|---|---|---|---|---|---|
| 1 | Database BSQ (bsq_dwh su AWS RDS), tabella installation (una riga per impianto, con code = MAC del solo box master: gli slave non hanno una riga) |
anagrafica di tutti i servizi, distinti da type_id (1 GANZ, 2 Ajax, 3 Frigate): cliente, descrizione, tipo, indirizzo, date, utenti collegati, procedure, dispositivi venduti |
gestionale BSQ e altri servizi; qAlarm 2 scrive le procedure | qAlarm 2 (elenco, utenti, procedure), midserver (client_info: nomi), api.bsq/Protexia |
id; code = MAC del box master per gli impianti MDM |
| 2 | Redis del midserver, chiave = MAC | ultimo stato di ogni box che ha mai fatto sync_state (38 al 27/10) |
i box | pannello MDM (/installation/get_all), midserver |
MAC |
| 3 | MySQL del midserver (q_alarm_mid) |
solo backup delle configurazioni (installations) e registrazioni in corso (new_installations) |
pannello / box | pannello (backup, restore) | MAC o codice, misti |
| 4 | Database del Raspberry (ganzcortrol_controls.system) |
68 impianti MDM e GANZ, IP VPN, relè Sonoff, controlli | Michele, a mano | watchdog Sonoff, controlli online/offline | id interno, nome, IP VPN (niente MAC né codice BSQ) |
| 5 | pfSense, peer WireGuard | 66 peer: solo impianti dei clienti | a mano | — | descrizione libera, IP VPN |
| 6 | FreePBX, account eWeLink, Telegram | interni delle trombe, relè, argomenti per cliente | a mano | centrale, sistema di Michele | nomi liberi |
Come lo usano i programmi¶
flowchart LR
BSQ[(1 · BSQ installation<br/>anagrafica)]
RD[(2 · Redis midserver<br/>stato dei box)]
RPI[(4 · Raspberry<br/>impianti + Sonoff)]
QA[qAlarm 2]
PAN[Pannello MDM]
WD[Watchdog Michele]
QA -- "elenco: tutte le installazioni dei tipi scelti" --> BSQ
QA -- "stato per code = MAC" --> RD
PAN -- "elenco: chiavi Redis" --> RD
PAN -- "nomi: code, description WHERE type_id != 2" --> BSQ
WD --> RPI
Hold "Ctrl" to enable pan & zoom
- qAlarm 2 (
qAlarm2_be/app/features/installation/data/repo_impl/installation.py): l'elenco è la tabella BSQinstallationfiltrata per tipo (type_id, scelto dall'operatore nella barra laterale), cliente, utente e testo. Il collegamento al box èInstallation.code == mac(get_installation_by_mac). Lo stato del box viene chiesto al midserver (/info/current_state/{mac},/installation/info/{mac}). - Pannello MDM: l'elenco sono le chiavi di Redis. I nomi vengono dal database BSQ (
mdm_mid_serverapp/connections/bsq_dwh_connector.py:SELECT code, description FROM installation WHERE type_id != 2). - Protexia /
api.bsq: usanoinstallation.codecomemacnelle chiamate al midserver. - Sistema di Michele: usa solo il proprio database.
Cosa non va¶
- qAlarm mostra installazioni che non sono monitorate. Mostra tutto ciò che il gestionale ha di un certo tipo, anche impianti senza box o dismessi e, con il tipo 1, i vecchi impianti GANZ non ancora migrati, che in qAlarm non devono comparire (D25). E non mostra i box che non hanno una riga BSQ con
codeuguale al loro MAC: tra questi tutti gli slave. - Il collegamento
code = MACfunziona, ma è fragile.installation.codeè il MAC univoco del box master (confermato il 28/10). Negli impianti con più box BSQ ha solo la riga del master (per esempioMDMXXXXXXX00, 30/10). Gli slave esistono solo nel sistema MDM, con il codice<MAC>-01,<MAC>-02(le "sotto installazioni" del pannello e le chiavi Redis), lo stesso formato che genera il cluster della lineastage(next_slave_mac). Limiti: - è un campo di testo inserito a mano nel gestionale, senza controllo;
- il legame tra master e slave è solo una convenzione sul nome del codice, non un dato, e non è registrato in BSQ;
- per risalire dal MAC di uno slave all'anagrafica bisogna togliere il suffisso: nessun programma lo fa in modo esplicito;
- non vale per gli impianti GANZ.
- Il midserver non ha un registro persistente dei box: l'elenco è Redis, una cache che non scade e non dimentica i box dismessi.
- Il database del Raspberry è l'elenco più completo, ma non ha MAC né codice BSQ, vive su un Raspberry con credenziali di amministratore nel codice ed è mantenuto a mano da chi sta lasciando l'azienda.
- Lo stesso impianto ha nomi diversi in BSQ, Raspberry, pfSense, FreePBX, Telegram.
- Gli indirizzi VPN vengono riusati dopo una dismissione (caso
172.16.16.21): l'IP non è una chiave stabile. Il registro tecnico deve conservare lo storico delle assegnazioni (impianto, IP, da quando, fino a quando). - Il database BSQ contiene impianti di tutti i servizi, non solo la videosorveglianza. I
type_idnoti (30/10) sono 1 GANZ, 2 Ajax (antintrusione, non fa parte di MDM) e 3 Frigate. Il midserver esclude Ajax (type_id != 2), qAlarm filtra per il tipo scelto dall'operatore. Il filtro per tipo però distingue il servizio, non dice se un impianto ha davvero un box MDM collegato. Il tipo 1 comprende probabilmente sia i vecchi impianti GANZ (Windows) sia i box MDM con detector GANZ (indicazione di Lorenzo del 30/10, da verificare con la riconciliazione):type_idnon basta a distinguerli, lo deve fare il registro tecnico (tipo di impianto e detector del box).
Proposta: due fonti, con ruoli separati¶
Non serve un unico database per tutto. Servono due fonti di verità con responsabilità chiare e un collegamento esplicito tra loro.
| Fonte | Responsabile di | Dove | Chi scrive |
|---|---|---|---|
| Anagrafica | cliente, sito, indirizzo, contratto, utenti dell'app, contatti, procedure della centrale, tipo di servizio (type_id: GANZ, Ajax, Frigate) |
database BSQ (resta com'è, è condiviso con gli altri servizi) | gestionale BSQ e altri servizi; qAlarm 2 scrive solo le procedure (qalarm_procedure), per il resto legge |
| Registro tecnico | quali impianti monitoriamo e con quali apparati: box (MAC, ruolo master/slave, detector, versione), IP VPN e peer, relè Sonoff, interni delle trombe, stato del ciclo di vita (in prova, attivo, sospeso, dismesso) | nuovo, nel midserver v3 (MySQL), con un'API | registrazione dei box, pannello MDM, import iniziale |
Più un terzo livello che non è una fonte di verità:
| Livello | Cosa | Dove |
|---|---|---|
| Stato in tempo reale | online/offline, ultimo stato, telecamere, carico | Redis del midserver (cache, ricostruibile) |
Il collegamento¶
- Ogni impianto del registro tecnico ha il riferimento alla sua riga di anagrafica:
bsq_installation_id(l'idnumerico della tabellainstallation, che non cambia) e ilcode(= MAC del master), come oggi. Così Protexia,api.bsqe qAlarm continuano a funzionare. - Il registro aggiunge quello che in BSQ manca: i box dell'impianto (master e slave) con il loro ruolo, invece della sola convenzione
<MAC>-01. Gli slave non hanno una riga BSQ: si risale all'anagrafica solo tramite il loro impianto. - Gli allarmi di qualunque box (master, slave, box "da associare") si gestiscono come gli altri: lo stato nel registro non li blocca. Oggi però
mdm_alarm.installation_idin qAlarm è un riferimento obbligatorio ainstallation.iddi BSQ: un allarme di uno slave va attribuito all'impianto del master tramite il registro, e per un box senza anagrafica serve una regola esplicita. - Il registro tecnico copre anche gli impianti GANZ ancora sul sistema vecchio, così può sostituire il database del Raspberry. Per ogni impianto distingue sistema vecchio e sistema MDM: un vecchio GANZ entra in qAlarm solo quando è migrato su un box MDM (D25).
Chi legge cosa, dopo¶
| Programma | Elenco degli impianti | Dettagli |
|---|---|---|
| qAlarm 2 | registro tecnico (solo impianti attivi sul sistema MDM, con detector Frigate o GANZ; niente vecchi GANZ, D25) | arricchito con l'anagrafica BSQ tramite bsq_installation_id |
| Pannello MDM | registro tecnico | stato da Redis |
| Watchdog Sonoff e controlli online/offline | registro tecnico (API del midserver) | — |
Protexia / api.bsq |
invariato (BSQ + code) |
— |
Le incongruenze diventano visibili: un report del midserver elenca le installazioni BSQ di videosorveglianza senza impianto tecnico, gli impianti senza anagrafica e i box che fanno sync_state ma non sono nel registro.
Quali dati spostare, e da dove¶
| Dato | Oggi in | Va nel registro tecnico | Note |
|---|---|---|---|
| Elenco degli impianti, tipo MDM/GANZ, stato attivo | Raspberry system |
sì (import iniziale) | da confrontare con BSQ per trovare bsq_installation_id |
| IP VPN, nome del peer | Raspberry, pfSense | sì, con lo storico delle assegnazioni | all'inizio si aggiornano a mano sia pfSense sia il registro (D24); in seguito pfSense diventa la configurazione di riferimento e il registro la verifica |
Relè Sonoff (sonoff_id), ultimo riavvio, soglie di controllo |
Raspberry system, check_* |
sì | necessario per portare il watchdog (T10.1, T10.2) |
| MAC dei box, versione, detector, ruolo cluster | Redis (stato), box | sì | il MAC si collega all'impianto tramite IP VPN (log sync_state) o installation.code |
| Interni delle trombe | FreePBX | sì (solo il numero dell'interno) | la password SIP resta in FreePBX |
| Backup delle configurazioni | MySQL midserver | restano dove sono | collegati al box tramite MAC |
| Cliente, indirizzo, utenti, procedure | BSQ | no | restano in BSQ; il registro tiene solo il riferimento. Le procedure le scrivono qAlarm e altri servizi: qAlarm le tiene in cache Redis per 15 minuti, quindi una modifica fatta altrove può arrivare in ritardo |
Log storici dei controlli (logs_vpn, 17,8 milioni di righe) |
Raspberry | no | archiviare o buttare, da decidere |
Come arrivarci, per passi¶
- Riconciliazione in sola lettura (subito). Uno script incrocia BSQ (
installation, tipi di videosorveglianza), Redis (MAC e IP dai logsync_state), Raspberry, pfSense e censimento. Produce un report riservato con: corrispondenze certe, dubbi, mancanze da ogni lato. Gli slave si collegano al master tramite il codice<MAC>-01, non tramite BSQ. - Decisione sul modello (questa pagina) e sulle regole: cosa è "attivo", come si chiama un impianto, chi può creare o dismettere.
- Registro tecnico nel midserver v3: tabelle impianti e box, API, report delle incongruenze. Il registro si popola anche da solo: un box sconosciuto che fa
sync_statecompare come "da associare". Si prova nell'ambiente dev e arriva in produzione insieme alla v3 del midserver, dopo che la v3 ha sostituito la v2. - Import iniziale dal report del passo 1, con revisione manuale.
- Spostare i lettori: pannello, qAlarm (elenco dal registro, anagrafica da BSQ), poi watchdog.
- Dismettere il database del Raspberry insieme al sistema di Michele (T10.2).
Domande aperte¶
- ~~Quali
type_idsono videosorveglianza?~~ 1 GANZ, 2 Ajax, 3 Frigate (30/10): videosorveglianza = 1 e 3; il filtro!= 2del midserver esclude Ajax. Il tipo 1 comprende probabilmente sia i vecchi GANZ sia i box MDM con detector GANZ: da confermare con la riconciliazione (MDM-019). - ~~
installation.codecontiene sempre il MAC?~~ Sì, è il MAC univoco del box master (28/10). Resta: per i GANZ cosa c'è? - ~~Come sono registrati gli impianti con più box?~~ In BSQ solo il master (30/10; correggeva l'indicazione del 28/10 di una riga per box). Gli slave
<MAC>-01,<MAC>-02esistono solo nel sistema MDM. - Come si registra in qAlarm un allarme di un box senza anagrafica BSQ, visto che va gestito come gli altri?
- Il gestionale può aggiungere un campo o un tipo per distinguere "impianto monitorato da MDM"? (Non indispensabile, se si adotta il registro tecnico.)