qAlarm 2 (qAlarm2_be, qAlarm2_fe)

La nuova console per gli operatori di centrale. Nata per la videosorveglianza: deve sostituire Telegram e la pagina comandi, e in futuro assorbire anche la telemetria del vecchio qAlarm.

Stato

• Non è in produzione. Gira solo su Coolify dev (mdm.dev.qalarm.backend.bsqdev.uk, mdm.dev.qalarm.panel.bsqdev.uk), con deploy automatico a ogni commit sul branch deploy_dev.
• Funzioni presenti (call del 30/09 e del 19/10): allarmi in tempo reale, chat con il cliente via Protexia (anche di gruppo, completata a ottobre), comandi di automazione, inserimento/disinserimento, live streaming delle telecamere, contatti e procedure del cliente.
• Mai provata con impianti reali in modo continuativo. La chat richiede l'aggiornamento dell'app Protexia, non ancora pubblicato.
• Richiesta aperta della centrale: barra sempre visibile con gli impianti offline.
• 28/10/2026: deploy dev del commit 46ba967 completato dopo la correzione del nome progetto Compose e l'attivazione di Preserve repository during deployment. Backend, worker, Redis e servizi di supporto avviati; riconoscimento dei container e lettura log Coolify ripristinati. API e handshake Socket.IO verificati. Redis conserva lo stesso volume e 8 chiavi, con backup RDB/AOF verificato. Stato running:unknown, senza health check Docker. Dettagli e limiti in Coolify dev.

Architettura

• Backend (qAlarm2_be): FastAPI, MySQL/SQLAlchemy, Redis, Socket.IO (AsyncRedisManager), integrazioni con BSQ, midserver, S3 e SQS. Avvio: uv run qalarm run (HTTP) o uv run qalarm run --app main:sio_app (HTTP + Socket.IO).
• Worker (event_worker/): processo separato (uv run qalarm worker) che legge lo stream event_stream dal Redis del midserver (gruppo notification_consumers, consumer worker_1).
• Frontend (qAlarm2_fe): React/Vite servito da nginx.
• Dati: usa anche tabelle del database BSQ (utenti, installazioni, notifiche, procedure). L'elenco delle installazioni è la tabella BSQ installation filtrata per tipo (il database BSQ contiene anche gli impianti Ajax e degli altri servizi); il collegamento al box è installation.code == mac. Quindi mostra anche impianti senza box. Vedi sorgenti-dati-installazioni.md.

Il Redis del midserver diventa quindi critico anche per qAlarm: va reso persistente e raggiungibile solo dalla rete interna.

Problemi noti (Q1–Q9)

#	Problema
Q1	Il frontend costruito da CodeBuild punta a un IP privato di fallback (http://172.16.16.254:8000): il buildspec non passa VITE_API_BASE_URL/VITE_SOCKET_URL.
Q2	Il JWT completo viene stampato nei log a ogni richiesta (app/middlewares/jwt_var.py:19).
Q3	Nessuna build ECR per backend e worker.
Q4	Nessun endpoint di health; /metrics pubblico.
Q5	CORS aperto a tutti con credenziali; Socket.IO con cors_allowed_origins="*".
Q6	Il worker non ritenta gli eventi falliti (niente XAUTOCLAIM) e ha nome consumer fisso.
Q7	Porta host fissa e WebSocket: serve attenzione per l'aggiornamento senza fermo.
Q8	index.html senza no-cache: dopo un deploy i browser possono tenere la versione vecchia.
Q9	prod.yml con IP privati fissi (172.16.16.253, OTLP 192.168.200.202).
—	wss://ome.bsqdev.uk/app scritto nel codice del frontend (src/features/cameras/components/OvenPlayerWrapper.tsx:10).

Documentazione nel repository

qAlarm2_be/docs/ (architettura, test di accettazione locali, checklist), qAlarm2_be/AGENTS.md.