Macchine di test per lo sviluppo¶
Elenco delle macchine e degli apparati di laboratorio usati per provare box, aggiornamenti e telecamere. Aggiornato al 30/10/2026. Nessuna credenziale in questo file: le utenze sono nelle guide originali o vanno chieste a chi gestisce la macchina.
Ricontrollo del 02/11/2026: Frigate .168 è ora sulla 3.2.9, wrapper 3.4.0, una telecamera, online e inserito; la tabella e la descrizione dell'installazione iniziale sotto sono la baseline storica della 3.1.9. GANZ .165: 3.9.0-stage, una telecamera, online e disinserito. Nessun cambio di stato o riavvio effettuato durante il ricontrollo. Import candidato provato solo su una copia privata del backup GANZ; nessuna migrazione operativa eseguita. Isolamento del ricevitore degli allarmi Frigate confermato da Lorenzo; log BSQ del GANZ ancora da isolare/verificare. Esiti e limiti: verifica della migrazione.
Prova manuale successiva di Lorenzo, 02/11: disinserimento e reinserimento Frigate dal pannello dev riusciti, nessun nuovo errore per i comandi. Live bloccato dal nome della telecamera non configurato: confermati via SSH 0 stream WebRTC, CAM_1 assente. Prima di configurarli e aprire il live va verificata l'uscita SRT, che nella 3.2.9 punta ancora a OME di produzione; questo errore avviene prima dell'avvio del video e non dimostra un problema H.265.
Preparazione live successiva, 02/11: aggiunto lo stream MDM CAM_1 dalla sorgente NVR già usata da Frigate; modificato solo l'handler nel container 3.2.9 affinché invii SRT a OME dev (170.10.0.107:9999/UDP). Backup privato ~/backup/live-dev-20261102T103058Z/; riavviato solo MDM. Frigate non riavviato, healthy, impianto ancora inserito. La modifica dell'handler si perde ricreando il container: immagine e branch non modificati; questa istanza runtime non è più una 3.2.9 intatta. Live nel browser confermato da Lorenzo il 02/11 («il video compare»); controllo successivo: box e detector online, ancora inseriti, Frigate healthy senza riavvio, una connessione live attiva. Chiusura dello stream ancora da verificare; dettagli e ripristino.
Regola: su queste macchine si prova prima di toccare qualsiasi box dei clienti (D22, aggiornamento-box.md). Un box di test può mandare allarmi alla centrale vera: prima di accendere un detector vale la checklist di isolamento di MDM-014.
Elenco¶
| Macchina | Indirizzo | Ruolo | Stato al 30/10/2026 | Dettagli |
|---|---|---|---|---|
MDMTESTGANZ1 (HP ProDesk 400 G5 Mini, Ubuntu 24.04.3) |
192.168.200.165 (SSH 22 con chiave dedicata, API box 5005) |
box di prova con detector GANZ | linea stage 3.9.0, ambiente stage, collegato al midserver dev; nel container internal_server è stato copiato il codice della stage del 30/10 per le prove di MDM-030. Backup completo della 3.2.9 precedente sul box |
box-test-mdmtestganz1.md |
| GANZ "AI Box" di laboratorio | 192.168.200.164 (HTTPS 8443) |
detector GANZ di MDMTESTGANZ1 |
in uso, una sorgente video (canale 1) | box-test-mdmtestganz1.md |
| Telecamera di laboratorio 1 | 192.168.200.166 (80, 443, 554) |
canale 1 del GANZ | connessa al GANZ; usata per le prove di connessione e audio (G.711); dal 30/10/2026 non più usata dal box Frigate della .168 |
connessioni-telecamere.md |
| Box Frigate di prova (HP EliteDesk 800 G5 Mini, Ubuntu 26.04) | 192.168.200.168 (SSH 22 con chiave dedicata, utente bsqsecurity; API box 5005, wrapper 5050, Frigate 5000) |
box di prova 3.1.9 Frigate MDMTESTFRIGATE1 per la prova A1 |
installato e configurato il 30/10 come sul parco, collegato al dev; da inserire prima della prova (dettaglio) | questa pagina |
NVR 192.168.3.101 (non è una telecamera) |
192.168.3.101 (HTTP 80, RTSP 554, ONVIF su /onvif/device_service, 8000) |
candidato come sorgente video per il box Frigate | rilevato il 30/10/2026 via ONVIF, sola lettura (nessun flusso video aperto): Uniview NVR302-32S, firmware NVR-B3601.39.52.251216, circa 19 canali attivi (per lo più 1080p 25 fps, alcuni 1440p e 2688×1520), flussi rtsp://192.168.3.101:554/unicast/c<canale>/s0/live (principale) e /s1/live (secondario, 640×360–720×576). Raggiungibile dalla .168. Credenziali fornite da Lorenzo, non trascritte. Canale scelto per le prove (30/10/2026): canale 1 "D1 (Confine discesa)", flusso secondario c1/s1, in realtà H.265 720×576 a 25 fps con audio G.711 µ-law (l'ONVIF dichiara H.264). Proprietario dell'NVR non verificato; gli altri canali non vanno usati senza accordo |
questa pagina |
| Frigate remoto dello shadow | 172.16.16.66 (MQTT 1883, API 5000) |
sorgente eventi di frigate_wrapper_shadow su MDMTESTGANZ1 |
non gestito da noi; solo ascolto | box-test-mdmtestganz1.md |
| MidServerDEV / Coolify dev | 170.10.0.107 (172.16.16.252 via VPN) |
midserver, pannello e qAlarm di sviluppo | in uso; dal box GANZ risponde solo 170.10.0.107:1883 |
accessi.md |
Porte verificate il 30/10/2026 con una semplice connessione TCP da una postazione dell'ufficio, senza autenticarsi. Nessun accesso SSH alla .168 e nessuna richiesta alla telecamera .101.
La sottorete 192.168.3.0/24 è tra le reti di origine ammesse dalle API /api/v1 della linea stage (elenco scritto nel codice, che si aggiunge a utente e password: funzioni-del-box.md).
Rilievo della nuova macchina (30/10/2026)¶
Sola lettura, via SSH.
| Voce | Valore |
|---|---|
| Hardware | HP EliteDesk 800 G5 Desktop Mini, Intel Core i7-9700 (8 core), 14 GiB di RAM, SSD da 512 GB (433 GB liberi) |
| Sistema | Ubuntu 26.04 LTS, kernel 7.0.0-42 (il parco e MDMTESTGANZ1 usano versioni precedenti; compatibilità di Docker e del driver del Coral da verificare) |
| Coral | USB presente (1a6e:089a, l'identificativo che il Coral ha prima di essere inizializzato: normale) |
| GPU | Intel UHD 630 integrata |
| Utente | bsqsecurity, nel gruppo sudo, ma sudo chiede la password |
| Software | presente solo python3; mancano Docker, Docker Compose, git, AWS CLI, curl, ffmpeg |
| Rete | solo eno1, 192.168.200.168/24 via DHCP, gateway 192.168.200.1; nessun servizio in ascolto oltre a SSH |
| Midserver dev | 170.10.0.107: 1883 e 5005 aperte, 5000 chiusa |
Telecamera 192.168.3.101 |
80 e 554: connessione rifiutata (raggiungibile più tardi, vedi elenco) |
Conseguenze per le prove:
- un box della linea main (3.1.9–3.2.9) parla al midserver con le API v2 sulla porta 5000, mentre il dev espone solo la v3 sulla 5005. Prima di collegarlo va verificato che la v3 risponda alle chiamate della 3.1.9 (parita-midserver-v3.md); è la domanda già aperta in MDM-014;
- l'indirizzo IP viene dal DHCP: per un box di prova conviene fissarlo o riservarlo;
- serve una telecamera raggiungibile dalla LAN 192.168.200.0/24; in alternativa si può provare con la telecamera del laboratorio 192.168.200.166, che però è già usata dal GANZ (limite di connessioni, MDM-037).
Box Frigate di prova sulla .168¶
Installato il 30/10/2026 ripetendo a mano i passi dell'installer.sh servito dal midserver di produzione (mdm_mid_server, app/static/installer.sh). Lo script non è stato eseguito così com'è perché clona la testa di main (oggi 3.2.9), è interattivo e riavvia la macchina.
| Passo | Cosa è stato fatto |
|---|---|
| Sistema | git, cron, curl, unzip e simili da apt; Docker 29.9 e Compose v5.6 da get.docker.com (funziona anche su Ubuntu 26.04); AWS CLI v2; utente nel gruppo docker |
| AWS e git | AWS CLI configurata con l'utente IAM dei box (mdm_installation_user, la stessa chiave dell'installer); git con il credential helper di CodeCommit |
| Codice | ~/installation, clone di mdm_installation, branch main riportato al commit della 3.1.9 (31764c60): .env.build_tag con INTERNAL_BUILD_TAG=3.1.9 e WRAPPER_BUILD_TAG=2.0.1. Un update dal pannello fa quindi git pull origin main come su un box vero |
| Pipe verso l'host | FIFO internal_pip, execpipe.sh uguale a quello generato dall'installer, @reboot in crontab; lettore avviato |
| Collegamento al dev | in app/config/configuration_files/.env (file versionato, modificato solo sul box): midserver https://mdm.dev.midserver.bsqdev.uk/, MQTT 170.10.0.107:1883 e le utenze del dev, copiate dal file generato di MDMTESTGANZ1 senza trascriverle. I valori con caratteri speciali vanno tra apici singoli, altrimenti la 3.1.9 li legge male (Not authorized dall'MQTT) |
| Isolamento | LOGSERVERBASEURL=http://127.0.0.1:9/: i log non arrivano al backend BSQ condiviso (api.bsqcontrol.it). Il webhook del wrapper punta a alarm.php locale, che sulla .168 non esiste: gli allarmi restano sul box |
| Frigate | config.yaml dal modello della guida (frigate_init_default_config.yml): Coral USB, MQTT locale, una telecamera CAM_1, rilevamento spento all'inizio. CAM_1 era la 192.168.200.166 (telecamera del laboratorio, anche canale 1 del GANZ); dal 30/10/2026 è il canale 1 dell'NVR 192.168.3.101, flusso secondario (/unicast/c1/s1/live, H.265 720×576), con rilevamento a 720×576 invece di 1280×720. Copia della configurazione precedente in ~/backup/frigate-config.yaml.before-nvr-*. Con questo flusso il live dal pannello potrebbe non funzionare nei browser senza H.265 su WebRTC: il box non ricodifica il video |
| Wrapper | config.json dal modello della guida senza la chiave detection (formato del wrapper 3.4.0, assente sui box 3.1.9) |
| Avvio | docker compose --env-file .env.build_tag -f docker-compose.yml --profile frigate up -d, come l'installer (senza il profilo production, quindi senza dsniff) |
Esito al 30/10, 14:10:
- container internal_server:3.1.9, frigate_wrapper:2.0.1, frigate:0.17.1, mosquitto attivi;
- Coral riconosciuto al secondo avvio di Frigate (al primo uso cambia identificativo USB da 1a6e:089a a 18d1:9302), inferenza 10 ms;
- CAM_1 a 5 fps, rilevamento spento, wrapper {"status": false};
- MQTT del box collegato al dev;
- registrazione impossibile sul dev: il midserver v3 risponde 403 a POST installation/new/register (vedi parita-midserver-v3.md), quindi il box non compare tra le nuove installazioni;
- configurato a mano come MDMTESTFRIGATE1, come avrebbe fatto il completamento della registrazione dal pannello: config.json (detector frigate, url http://localhost:5000, wrapper_url http://localhost:5050, envirment production, nessuno stream WebRTC, niente GPIO né tromba), setting.json dal file di esempio, UUID tolto dal .env, message.from_mac del webhook del wrapper impostato. Copia dei file precedenti in ~/backup/pre-registration/;
- dopo il riavvio /status risponde 200, detector Frigate online e disinserito, sincronizzazione verso il dev senza errori. Prima della prova A1 va inserito dal pannello dev.
Copia del .env originale della 3.1.9 sul box: ~/backup/env.original.3.1.9.
Uso previsto per le prove di aggiornamento¶
Due percorsi, descritti in migrazione-box-alla-nuova-versione.md:
- Dentro la linea
main(3.1.9 / 3.2.2 → 3.2.9): possibile da subito, non serve codice nuovo. - Dalla 3.2.x alla nuova versione (
stageunita inmain): possibile solo dopo l'import delle configurazioni e il ponte (MDM-080, MDM-081).
| Prova | Macchina | Detector | Partenza |
|---|---|---|---|
| A1 | 192.168.200.168 + una telecamera raggiungibile dalla LAN (da definire) |
Frigate | 3.1.9 (wrapper 2.0.1, Flask) |
| A2 | 192.168.200.168 (reinstallata) |
Frigate | 3.2.2 (wrapper 2.1.3, Flask) |
| A3 | MDMTESTGANZ1 |
GANZ | 3.1.9; richiede di togliere temporaneamente la stage (vedi sotto) |
| B | entrambe | Frigate e GANZ | 3.2.9, con la release candidata (MDM-081) |
Ogni prova parte da un box configurato e inserito, con almeno una telecamera, e si lancia dal pannello dev come un update normale.
Collegare un box production al dev senza toccare la produzione¶
Un box della linea main (envirment = production) legge gli indirizzi del midserver, dell'MQTT e del server dei log dal file versionato app/config/configuration_files/.env, che punta alla produzione via VPN. Per la prova:
- prima del primo avvio, cambiare solo in locale quel file con gli indirizzi del dev (
170.10.0.107, porte e utenze del dev) e non committarlo; - il file è uguale dalla 3.1.9 alla testa di
main, quindigit pull origin mainlo lascia com'è e non va in conflitto; - l'update dal box fa
git pull origin maindal vero CodeCommit: per le prove A va bene (è il codice di produzione); per la prova B il remotooriginva puntato a un repository di prova (MDM-081); LOGSERVERBASEURLpunta al backend BSQ condiviso anche nella configurazione dev: verificare prima dove finiscono log e allarmi (checklist di MDM-014).
MDMTESTGANZ1 e la prova A3¶
Contenuto del box al 30/10/2026 (sola lettura): internal_server 3.9.0-stage, installation-dsniff-1, frigate_wrapper_shadow 3.5.0-stage; checkout su d02dbaee con il codice della stage del 30/10 copiato nel container. In ~/backup ci sono stage-cutover-20261028T151536Z (il backup della 3.2.9) e altre directory precedenti (installation_backup_prod, installation_slave_1, installation_slave_2, installation_stage), non analizzate. L'immagine di rollback locale è la 3.2.9 originale del 03/08 (sha256:bd38a99e…).
MDMTESTGANZ1 è oggi l'unico box stage. Per la prova A3 va riportato su main 3.1.9 e poi rimesso sulla stage. Sul box c'è il backup completo della 3.2.9 di partenza (/home/bsqsecurity/backup/stage-cutover-20261028T151536Z/), ma il ripristino non è mai stato provato. Da decidere se farla subito o dopo le prove della stage in corso.
Soluzione ideale¶
Un laboratorio che copre i formati di partenza del parco (3.1.9 GANZ, 3.1.9 e 3.2.2 Frigate, 3.2.9 Frigate) più la linea stage, tutto collegato al dev e isolato dalla centrale. Ogni macchina ha una scheda con versione installata, configurazione iniziale salvata e procedura di ripristino provata, così una prova di aggiornamento si ripete da capo in poco tempo.
Cosa dobbiamo fare¶
| # | Passo | Ticket |
|---|---|---|
| 1 | ✅ Rilievo della .168 (30/10). Restano: una telecamera raggiungibile dalla .168, l'accesso sudo per installare Docker, la porta del midserver dev per un box main |
MDM-014 |
| 2 | Rilevare la telecamera .101: modello, firmware, flussi principale e secondario, audio, numero massimo di connessioni |
MDM-014, MDM-037 |
| 3 | Installare sulla .168 la 3.1.9 Frigate come sul parco, collegata al dev (.env locale), telecamera aggiunta in Frigate, box registrato nel pannello dev |
MDM-014 |
| 4 | Salvare la configurazione iniziale e provare il ripristino prima di ogni prova | MDM-014 |
| 5 | Prove A1, A2 (Frigate) e, quando deciso, A3 (GANZ) secondo migrazione-box-alla-nuova-versione.md | MDM-016 |
| 6 | Prova B con la release candidata | MDM-081 |
| 7 | Tenere aggiornata questa pagina a ogni cambio di versione o di ruolo di una macchina | — |