Vai al contenuto

Box del cliente (mdm_installation, mdm_frigate_wrapper, mdm_privacy_mode)

Il software che gira sul computer installato dal cliente. Ubuntu, Docker, immagini da ECR (mdm8670650/installation, .../frigate_wrapper, .../dsniff).

Cosa fa

  • Gestisce la configurazione del sistema e delle telecamere.
  • Avvia e controlla il detector: Frigate (software) oppure GANZ (apparato).
  • Riceve i comandi dal midserver via MQTT ed esegue: inserimento/disinserimento, suoni sulla tromba, snapshot, live stream, riavvio servizi, aggiornamento, backup/restore della configurazione, privacy mode.
  • Manda al midserver lo stato periodico, gli errori, i log e le risposte ai comandi.
  • Il frigate wrapper (FastAPI) si interpone tra installazione e Frigate: gestisce la configurazione di Frigate, legge gli eventi MQTT di Frigate dal broker locale e li trasforma in callback HTTP e heartbeat. Dal 2026 arma/disarma via MQTT invece che riscrivendo un file, senza riavviare il container.
  • Privacy mode (mdm_privacy_mode): oscura singole telecamere deviando il loro traffico con ARP spoofing (immagine dsniff).

Controlla anche se le telecamere sono coperte o spostate (check_camera_damage); il risultato oggi non arriva agli operatori: anti-manomissione-telecamere.md. Altre funzioni (incendio, inserimento a orario, rifiuto dell'inserimento, eventi e Telegram dal box, controlli di salute, protezione delle API): funzioni-del-box.md.

Due linee di rilascio

Linea main Linea stage
Versioni 3.2.x (ultima 3.2.9, 03/08/2026; commit fino al 19/10) 3.9.0-stage (03/08/2026); prima 3.8.x
Sul parco tutti i 38 box, versioni 3.1.9–3.2.9 solo il box di prova MDMTESTGANZ1 (D22)
I/O PIN (gpio_usb, scheda seriale) IO config (tabella io_settings nel database, IOManager, più schede)
Cluster master/slave no sì (node_id)
Stato include has_pin formato nuovo, senza has_pin

Le due linee divergono dal 02/02/2026: 637 commit solo su stage, 42 solo su main. Decisione del 27/10/2026: la nuova versione andrà in produzione, e le modifiche recenti di main vanno riportate su stage prima.

Configurazione

  • app/config/configuration_files/config.json: configurazione del box (MAC, detector, telecamere, gpio_usb, privacy mode…).
  • app/config/configuration_files/.env (file nascosto) letto con load_dotenv dentro il processo: SERVERBASEURL, SIGNALINGURL (= http://172.16.16.253:5000/), MQTTURL/MQTTPORT (= 172.16.16.253/1883), credenziali MQTT e del server, URL del log server. Per questo docker exec env non mostra queste variabili.
  • .env.build_tag / .env.build_tag.stage: tag delle immagini (INTERNAL_BUILD_TAG, WRAPPER_BUILD_TAG, DSNIFF_BUILD_TAG) secondo l'ambiente. Il file è montato dall'host nel container internal_server, e il box dichiara la propria versione leggendolo: se un aggiornamento cambia il file ma il docker compose pull/up fallisce, la versione dichiarata non corrisponde all'immagine in esecuzione. Il tag reale si vede solo con docker ps.
  • L'indirizzo di OME è nel codice: srt://185.31.66.185:9999 (app/services/mqtt/handlers/web_rtc_handler.py:186, M15).

Variabili d'ambiente nella linea stage

Nella linea stage le variabili del box non sono scritte a mano: l'installer chiede l'ambiente (Stage o Prod), che sceglie il branch (stage/main) e il segreto AWS mdm/installation/stage o mdm/installation/prod. All'avvio infra unisce segreto e infra/environments/<env>/.env* in infra/environments/<env>/.infra.generated.env, caricato dal container internal_server. Il meccanismo è della libreria infra-lib (infra-cli), inclusa come sottomodulo. Per cambiare una variabile per tutti i box di un ambiente si modifica il segreto e si rigenera la configurazione sul box (aggiornamento o riavvio dello stack con infra).

Valori rilevanti (28/10/2026, solo indirizzi):

Chiave Stage Prod
SERVERBASEURL https://mdm.dev.midserver.bsqdev.uk/ https://api.bsqdev.uk/ (via Cloudflare, non la VPN)
MQTTURL 170.10.0.107 (VM di dev) mqtt.bsqdev.uk → 185.31.66.185, porta 1883 inoltrata a un IP inesistente (M27)
WEBRTC_SRT_BASE_URL srt://mdm.dev.ome.bsqdev.uk:9999… (OME dev) srt://172.16.16.253:9999… (OME prod via VPN)
LOGSERVERBASEURL https://api.bsqcontrol.it https://apidev.bsqcontrol.it (sembrano invertiti)

Build

CodeBuild mdm-installation-build-main e mdm-installation-build-stage (buildspecs/build.yml): immagine mdm8670650/installation:<INTERNAL_BUILD_TAG>. Anche il frigate wrapper ha build main/stage, e il privacy mode una build main.

Aggiornamento remoto

update.yml → dev_scripts/updater.py, eseguito sull'host attraverso una named pipe (app/services/host_system_manager/host_manager.py). Canali production e stage. Vedi 06-runbook/aggiornamento-box.md.

Problemi noti

  • M15: IP di OME nel codice.
  • M14: segreti di default nel compose (FRIGATE_RTSP_PASSWORD, credenziali MQTT di default) e credenziali probabilmente uguali su tutti i box.
  • Frigate genera più falsi allarmi di GANZ e manda l'evento completo solo a fine "review".
  • Le zone attive per fascia oraria (possibili con GANZ) con Frigate richiederebbero modifiche alla configurazione pianificate.
  • Box con versioni e modifiche locali diverse: l'aggiornamento remoto funziona solo se nessuno ha toccato i container a mano.

Cluster master/slave

Impianti con molte telecamere divisi su più box. Esistono due modi: siti multi-box "vecchi" già in produzione (stack indipendenti, slave dietro il proxy del master) e il cluster vero della linea stage (master che coordina gli slave via MQTT), mai provato sul campo. Analisi completa del codice in cluster-master-slave.md.

Nota sulla linea stage

La linea stage contiene anche un client Telegram nel box (app/core/clients/telegram_client.py), con chat per cliente, centrale operativa e centro guasti. È la parte delle funzioni del sistema di Michele riportata nel software del box. Va considerata quando si pianifica lo spegnimento di Telegram (T10.2).