Vai al contenuto

Flussi principali

Ogni flusso indica cosa succede oggi (prod, midserver v2) e cosa cambia con il sistema nuovo. I riferimenti al codice sono relativi ai repository in C:\Users\l.mioso\Documents\GitHub\.

1. Allarme (evento di intrusione)

Oggi (sistema vecchio, quello usato dalla centrale): 1. Il detector (Frigate o GANZ) rileva un oggetto in una zona protetta. 2. Il frigate wrapper sul box manda un webhook HTTP all'API BSQ (es. https://api.bsqcontrol.it/endpointVideoEvent.php). L'URL è configurato dal pannello (PUT /api/v1/webhooks sul wrapper, passando dal midserver). 3. Il sistema vecchio (API BSQ / progetto di Michele) inoltra l'allarme con le foto su Telegram.

Aggiornamento dal censimento del 28/10: sui box 3.2.9 il webhook del wrapper punta a http://0.0.0.0/alarm/operativecenter/alarm.php, cioè a un servizio PHP sul box stesso (porta 80). Il percorso reale è quindi probabilmente wrapper → PHP locale (sistema di Michele sul box) → Telegram/centrale. Da confermare con Michele. 4. L'operatore vede l'allarme su Telegram e apre le telecamere.

Il midserver non è nel percorso dell'allarme: un suo fermo oggi non blocca gli allarmi.

Con il sistema nuovo (in dev): 1. Il box pubblica l'evento su MQTT (q_security/event). 2. Il midserver lo riceve, salva le immagini su S3 (bsq.protexia/qalarm_snapshots/) e scrive l'evento nel Redis Stream event_stream (mdm_mid_server/app/events/sinks/redis_stream_sink.py). 3. Il worker di qAlarm legge lo stream (gruppo notification_consumers), salva l'evento e lo invia agli operatori via Socket.IO e ai clienti come notifica. 4. L'operatore gestisce l'allarme in qAlarm.

Rischi noti: con più istanze del midserver ogni evento verrebbe scritto due volte (M6); il worker non ritenta gli eventi falliti (Q6).

2. Comando dalla centrale al box (inserimento, suono, riavvio servizi…)

  1. Pannello o qAlarm chiamano un endpoint REST del midserver (autenticato con JWT).
  2. Il midserver genera un token, pubblica il comando su MQTT verso il box, e si mette in attesa su una lista Redis con il nome del token (RedisConnection.wait, brpop fino a 15 s).
  3. Il box esegue e risponde con POST common/installation/callback/{token} (o async/callback per i comandi lunghi).
  4. Il midserver legge la risposta da Redis e la restituisce al chiamante. Se non arriva in tempo: errore di timeout.

3. Stato e online/offline

  1. Ogni box chiama POST common/installation/sync_state/{mac} a intervalli regolari con il suo stato completo (telecamere, versione, carico, has_pin, detector…).
  2. Il midserver salva lo stato nella chiave Redis <mac> (senza scadenza) e crea MAC_<mac> con scadenza (intervallo + 20 s).
  3. Se il box smette di chiamare, MAC_<mac> scade: il listener delle scadenze Redis segna il box offline e manda una notifica.
  4. Il pannello costruisce l'elenco delle installazioni leggendo tutte le chiavi di stato in Redis (/installation/get_all).

Conseguenza: un box dismesso resta nell'elenco finché qualcuno non cancella la sua chiave. Vedi dati e registro.

4. Video in diretta

  1. Il pannello chiede /live_stream/... al midserver.
  2. Il midserver manda il comando live_stream via MQTT al box.
  3. Il box avvia ffmpeg e invia il flusso in SRT a OME, all'IP scritto nel codice 185.31.66.185:9999 (mdm_installation/app/services/mqtt/handlers/web_rtc_handler.py:186, problema M15).
  4. Pannello, qAlarm e app Protexia riproducono da OME via WebSocket (wss://ome.bsqdev.uk/...).

Il vecchio percorso WebRTC con signaling sul midserver (/signaling/*) è codice morto.

In parallelo la sede di Cava legge flussi RTSP attraverso la VPN (porte 8554/554): è la maggior parte del traffico VPN. Dal censimento delle telecamere del 29/10 solo 4 box hanno go2rtc sulla 8554: quali flussi legga davvero la centrale va ricontrollato (MDM-037).

5. Nuova installazione

  1. Il tecnico prepara il PC (Ubuntu), installa Docker e lancia lo script installer.sh, servito dal midserver (mdm_mid_server/app/static/installer.sh). Lo script contiene credenziali AWS (problema M16).
  2. Il box si registra (POST installation/new/register) e compare tra le "nuove installazioni" (new_installations in MySQL).
  3. Dal pannello si completa la configurazione (MAC, tipo di detector, impostazioni) e il midserver la invia al box via MQTT.
  4. Il tecnico configura sul detector i flussi RTSP delle telecamere, le zone escluse e i preset.
  5. Il box viene aggiunto alla VPN (nuovo peer WireGuard su pfSense).

Procedure dettagliate: guide PDF di Maurizio/Franco in raw/doc_maurizio/Guide/. Vedi 06-runbook/nuova-installazione.md.

6. Aggiornamento del software di un box

  1. Dal pannello si lancia l'aggiornamento.
  2. Il box riceve il comando ed esegue dev_scripts/updater.py sull'host attraverso una named pipe (app/services/host_system_manager/host_manager.py), secondo update.yml.
  3. Canali: production (branch main) e stage (branch stage). Le immagini arrivano da ECR.

Funziona se sul box nessuno ha modificato i container a mano. Non è mai stato usato in modo sistematico su tutto il parco.

7. Riavvio a distanza di un impianto bloccato

  1. Il watchdog (script sul Raspberry in centrale, sede di Cava) controlla ogni minuto lo stato dei relè Sonoff, chiamando ewelink-integration (api_devices).
  2. Se un impianto non risponde, spegne e riaccende il relè (api_switch off → on), e l'intero impianto si riavvia.
  3. Il riavvio del solo PC si fa invece dal pannello, senza toccare telecamere e switch.

8. Voce e suoni sulla tromba

  • Messaggi registrati: comando dal pannello/qAlarm → midserver → box → API della tromba (/sound/play).
  • Voce in diretta: l'operatore chiama l'interno SIP della tromba dal centralino FreePBX, come una telefonata. Funziona anche se il box o la VPN del cliente sono fermi. Le chiamate vengono registrate e copiate ogni giorno su S3.