Vai al contenuto

App Protexia e sistema BSQ

App Protexia (protexia)

App mobile (Flutter) per i clienti: notifiche di allarme, chat con la centrale, inserimento/disinserimento, video.

  • È collegata a due backend: api.bsq (il backend principale) e qAlarm 2.
  • Nel codice aggiornato il 02/11/2026 gli indirizzi video sono nei config/*.json: signalling, ome_signalling, turn, stun. Dev e configurazioni locali usano midserver/OME dev; prod mantiene i server video di produzione. development.json usa qAlarm dev remoto.
  • Il live resta nel player WebRTC interno, anche a schermo intero. Rimossa la pressione lunga che apriva la pagina HTML /installation/live_stream/<token>; quella pagina non viene portata nella v3 (D27).
  • Le app già distribuite possono ancora usare i vecchi indirizzi e la pagina v2: i domini e il servizio legacy non vengono dismessi da questa modifica. Pubblicazione e adozione della nuova app restano da eseguire.
  • La versione con la chat verso qAlarm 2 non è ancora pubblicata.
  • Push: Firebase (segreto prod/firebase/protexia in Secrets Manager) e lambda in lambdaFunctionsPython (usata solo per le notifiche push).

API BSQ (api.bsq) e database

  • Backend PHP del sistema BSQ, usato da Protexia e dal vecchio flusso allarmi (endpointVideoEvent.php su api.bsqcontrol.it).
  • VIDEO_ALARM_API_URL e ancora fissato a api.bsqdev.uk in common/config.inc.php. Le modifiche a URL/token di servizio e Dockerfile proposte durante il lavoro del 02/11 sono state annullate: il backend conserva il comportamento precedente.
  • Per il live, BSQ inoltra il JWT dell'utente ricevuto nella richiesta; non esiste una nuova variabile video_alarm_api_token. La modifica della configurazione video nell'app non modifica questo passaggio backend.
  • Il database principale è su AWS RDS. Il gestionale ci scrive l'anagrafica; qAlarm 2 e il midserver ne leggono alcune tabelle (utenti, installazioni, notifiche, procedure, informazioni cliente). Per questo il database non si sposta su Netsons (decisione di aprile 2026). Il collegamento Netsons ↔ AWS ha avuto in passato perdite di pacchetti: è un punto di attenzione.
  • Il login del pannello MDM passa da qui (POST /auth/login/).

Altri servizi AWS collegati

  • qalarm-ajax su ECS (bsq-cluster-production): integrazione delle centrali Ajax con qAlarm.
  • Lambda qalarm e regola qalarm-onboard-disable (giornaliera alle 11:00 UTC).

Dettagli in 03-infrastruttura/aws.md.

Flusso attuale del live e differenza v2/v3 (02/11/2026)

  1. Protexia chiama BSQ POST /protexia/createLiveStream?installationId=...&cam=... con il JWT dell'utente.
  2. BSQ controlla permesso Protexia e accesso del cliente all'impianto, legge il codice e chiama /live_stream/create sul midserver di produzione fissato nella configurazione, inoltrando lo stesso JWT.
  3. Nella v2, jwt_auth_middleware_in_header accetta token statico/pannello oppure verifica il token tramite BSQ: JWTAUTHURL, apiMethod=checkJwt, app=qalarm, con autenticazione M2M JWTAUTHTOKEN. Una risposta HTTP 200 consente di proseguire.
  4. Nella v3, verify_token accetta token statico o JWT pannello; manca il fallback remoto BSQ. verify_token_or_basic_auth aggiunge le credenziali Basic dei box ma non ripristina quel fallback. Il JWT inoltrato da BSQ resta quindi una lacuna di compatibilita, non risolta da un cambio di host nell'app.
  5. Dopo l'autorizzazione il midserver chiede al box di avviare il flusso e restituisce il token dello stream. Quel token e distinto dal JWT del login e viene usato dall'app per OME.

Direzione futura (D28)

Rimuovere il passaggio API BSQ dalla creazione dello stream. E una direzione concordata, non una funzione implementata. Il sostituto (qAlarm BE o midserver), i controlli di accesso e la migrazione dei client vanno definiti prima del cambio. Non e stata introdotta adesso una nuova piattaforma JWT ne ripristinata la verifica remota v2 nella v3.

qAlarm BE possiede gia un percorso di creazione tramite midserver; cio non prova che sia pronto per utenti Protexia. qAlarm FE mantiene ancora OME prod nel codice e richiede un intervento separato. Login, anagrafica e altre funzioni BSQ non sono comprese nell'obiettivo di rimozione del solo passaggio live.

Stato e verifiche

  • Le modifiche PHP/Dockerfile/test del token di servizio sono state annullate, insieme alla relativa documentazione API BSQ. Nessun deploy o provisioning era stato eseguito.
  • Rimangono le modifiche locali Protexia: OME/TURN/STUN configurabili, target dev e rimozione del browser live. Le vecchie app e la pagina v2 non sono dismesse.
  • Il percorso dev completo resta incompleto: BSQ punta ancora al midserver prod e la v3 non accetta il JWT inoltrato nel modo precedente. Non dichiarare il live dev funzionante.
  • Configurazioni qAlarm mancanti nei JSON production e local_mj restano una lacuna preesistente; nessun URL qAlarm prod e stato inventato. Il database BSQ dipende dalle sue variabili esistenti, non dagli host OME dell'app.
  • Con l'SDK locale coerente con i pacchetti (Dart 3.13.7), senza aggiornamenti delle dipendenze: 20 test streaming superati, uno fallito sullo shader ink_sparkle.frag, anche con Impeller disabilitato. Analisi Dart interrotta dal plugin custom_lint locale. Il precedente tentativo con FVM 3.35.5 non compilava per il disallineamento dei pacchetti. Nessuna prova live su telefono o box.
  • Dev app: fvm flutter run -t lib/main_dev.dart; il main.dart predefinito resta un placeholder.

Fonti: configurazione BSQ, controller e permessi BSQ, modello live BSQ, auth v3, rotta live v3, config dev app, controller app, pulsante app. Per il comportamento v2, confrontare git show main:app/middle_ware/auth_middleware.py e git show main:app/live_stream/live_stream_routes.py nel repository midserver.