Perché costruire un Dashboard OpenAPS personalizzato?

Gestione del diabete di tipo 1 con una configurazione OpenAPS (Open Artificial Pancreas System) produce un flusso costante di dati: valori di glucosio nel sangue, livelli di insulina-on-board, livelli di serbatoio, stato della batteria e allarmi di sistema.

Molti strumenti esistenti come Nightscout offrono una linea di base di funzionalità, ma potrebbero non esporre ogni punto di dati grezzo a cui tieni, o ti costringono a un particolare disegno visivo. Una dashboard personalizzata ti permette di rimuovere elementi inutili e concentrarti su ciò che più ti interessa. Ad esempio, puoi evidenziare frecce di tendenza e numeri IOB in caratteri di grandi dimensioni per uno sguardo rapido, fornendo ancora grafici di storia dettagliati per un'analisi più approfondita.

Comprendere OpenAPS fonti di dati

Prima di scrivere qualsiasi codice, è necessario sapere dove vivono i dati OpenAPS. Il sistema viene eseguito su un Raspberry Pi (o un computer simile a una singola scheda) eseguendo un algoritmo a ciclo chiuso che comunica con un monitor continuo di glucosio (CGM) e una pompa di insulina.

  • Letture di glucosio (BG) di Blood[[] – tipicamente ogni 5 minuti dalla CGM (ad esempio, Dexcom, Medtronic).
  • Storia della consegna dell'insulina[[] – tassi basali di temperatura, boli e calcoli insulin-on-board (IOB).
  • stato del sistema[[] – stato del loop (abilitato/disabilitato), batteria della pompa, volume del serbatoio e l'età del sensore.
  • Alerts and error[ – BG fuori gamma, batteria bassa, guasti di comunicazione.

OpenAPS memorizza questi dati localmente nei file JSON (ad esempio, , ) e lo espone anche attraverso un REST integrato nella rete locale del rig. L'API è il metodo preferito per l'autenticazione multipla in tempo reale perché consente l'accesso sicuro, basato su richiesta senza toccare direttamente il filesystem.

In pratica, il trasmettitore CGM può perdere temporaneamente la connessione, la pompa potrebbe non riconoscere un comando, o il Raspberry Pi potrebbe esaurire la memoria. Il cruscotto deve gestire tutti questi casi di bordo con grazia.

Panoramica della tecnologia

Il tuo cruscotto sarà un'applicazione web in esecuzione su un server o su una piattaforma cloud.

  • Backend[] – un server leggero (Node.js, Python Flask, or Go) che spinge le richieste alla piattaforma OpenAPS e in modo facoltativo i dati della cache.
  • Frontend[] – un'applicazione a singola pagina costruita con React, Vue.js, o JavaScript semplice.
  • Visualizzazione dei dati[[] – una libreria come Chart.js, D3.js, o ApexCharts per la grafica delle tendenze BG e della consegna dell'insulina.
  • Aggiornamento a tempo reale[] – ottenuto attraverso la regolazione periodica (setInterval) o connessioni WebSocket persistenti.
  • Hosting[] – un VPS, Raspberry Pi (locale), o una piattaforma senza server (ad esempio, Vercel, Netlify) con supporto WebSocket.

Se si preferisce evitare di costruire un backend completo, è possibile ospitare il cruscotto interamente sul rig stesso utilizzando un generatore di sito statico che consente di recuperare i dati direttamente dall'API del rig (CORS deve essere abilitato).

Una tendenza crescente è quella di combinare il cruscotto con un database di serie temporali come InfluxDB o TimescaleDB. Questo ti dà la possibilità di zoom molto indietro nel tempo (settimane o mesi) offrendo ancora aggiornamenti dal vivo. Il backend può scrivere in batch i punti di dati recenti nel database e servire le query storiche da esso, riducendo il carico sul piattaforma OpenAPS. Questo approccio è particolarmente prezioso se si desidera eseguire l'analisi retrospettiva o condividere i dati aggregati.

Passo 1: Accesso ai dati OpenAPS tramite API

Per ottenere i dati di glucosio, chiamare . La risposta contiene una serie di recenti letture BG con timestamp e direzioni di tendenza. Allo stesso modo, restituisce lo stato attuale del ciclo, IOB, livello della batteria, e più in genere.

Se il tuo impianto è dietro un firewall o hai bisogno di accesso remoto, considera l'utilizzo di un tunnel sicuro (ad esempio, ngrok) o di una VPN. Non esporre mai l'API OpenAPS direttamente all'Internet pubblico senza l'autenticazione. Per i dashboard di produzione, implementare un server proxy che aggiunge una chiave API, convalida le richieste e ostacola il traffico per prevenire l'abuso.

Un'altra considerazione è la velocità in cui si inquina l'API. La piattaforma OpenAPS può gestire alcune richieste al secondo, ma il martellamento costante può interferire con l'algoritmo del loop. Un intervallo di polling sicuro è ogni 5-10 secondi. Se avete bisogno di aggiornamenti più veloci, utilizzare WebSockets invece, che spingere i dati solo quando l'aggiornamento del rig può essere configurato per emettere un messaggio WebSocket ogni volta che vengono registrati nuovi dati di glucosio, dandovite vicino.

Fase 2: Progettazione del layout Dashboard

Inizia con un wireframe che mette il più critico, il glucosio nel sangue corrente, in alto o in centro.

  • Top righe[ – BG valore (grande), freccia di tendenza, tempo dall'ultima lettura.
  • Seconda riga[] – IOB, tasso basale attuale, livello di serbatoio.
  • Main area[[] – un grafico BG di 3 ore o 24 ore con zone codificate a colori (giallo per cautela, rosso per pericolo).
  • Pannello di sicurezza[] – recenti avvisi e indicatori di salute del sistema (batteria, età del sensore).

Utilizzare framework CSS reattivi come Bootstrap o Tailwind CSS per garantire che il cruscotto funziona su schermi mobili - molti utenti vogliono guardare da esso dal loro telefono. Considerare l'utilizzo di una libreria specifica del cruscotto come GridStack.js] per consentire la personalizzazione del layout di drag-and-drop, consentendo di riorganizzare i widget come le priorità cambiano.

Utilizzare schemi di colore ad alto contrasto che sono ancora distinguibili per gli utenti di colore (evitare di fare affidamento su solo rosso/verde). Aggiungi etichette di testo accanto agli indicatori di colore. Considerare l'utilizzo di una modalità scura per la visualizzazione notturna. Posizionare le informazioni più importanti in cui cattura l'occhio prima - di solito la sinistra superiore per le lingue di sinistra a destra.

Passo 3: Costruire il proxy backend (opzionale ma consigliato)

Un proxy backend aggiunge uno strato di sicurezza e cache. Ad esempio, un server Node.js Express può:

  • Ritira i dati OpenAPS ogni 5 secondi (o il più velocemente possibile gli aggiornamenti del rig).
  • Conservare l'ultimo stato in memoria per ridurre il carico sul rig e fornire risposte istantanee al frontend.
  • Esponga punti finali come e al frontend.
  • Aggiungere le intestazioni CORS e limitare la velocità.

Ecco un minimo di Node.js snippet usando :

const express = require('express');
const fetch = require('node-fetch');
const app = express();

let cache = {};

setInterval(async () => {
 const res = await fetch('http://openaps-rig:8080/api/v1/status.json');
 cache.status = await res.json();
}, 5000);

app.get('/api/status', (req, res) => res.json(cache.status));
app.listen(3000);

Questo approccio consente inoltre di aggregare i dati da più piattaforme se si dispone di un sistema di riserva o di monitorare il loop di un’altra persona. Per ulteriori informazioni, implementare l’autenticazione basata su JWT sui endpoint proxy. È inoltre possibile integrare una semplice cache in memoria che memorizza le ultime 24 ore di dati in modo che il frontend possa richiedere intervalli storici senza colpire più volte il rig.

Se il rig è irraggiungibile, il proxy dovrebbe restituire una versione cache (o un 503) piuttosto che crash. Log tutti gli errori in un file o un servizio di monitoraggio. Si può anche desiderare di esporre un punto finale di controllo sanitario che altri strumenti di monitoraggio (come UptimeRobot) possono ping per verificare che il proxy e il rig siano entrambi vivi.

Passo 4: Attuazione di Frontend con aggiornamenti in tempo reale

Riagisci è una scelta popolare a causa dei suoi metodi e ganci del ciclo di vita. Creare un componente che chiama il backend ogni 5 secondi ( con ) e aggiorna facilmente lo stato. Per le esperienze in tempo reale, sostituire l'inquinamento con una connessione WebSocket – entrambe le librerie di carica Nodej

Per la classificazione, installare Chart.js (con il numero di involucro di React [) o ApexCharts per le animazioni più lisce.

Non dimenticate di gestire con grazia i dati mancanti: mostrate un avviso “dati da favola” se l’ultima lettura è superiore a 10 minuti. L’implementazione della logica di ricollegamento se WebSocket scende, e visualizzate sempre il timestamp dell’ultimo aggiornamento di successo.

Passo 5: Opzioni di distribuzione e di hosting

Hai diversi obiettivi di distribuzione validi:

  • Local Raspberry Pi[] – eseguire il server di dashboard sullo stesso Pi di OpenAPS. Questo è il più semplice e privato. Accedere tramite un IP locale come . Essere consapevoli che l'esecuzione sia OpenAPS e un server di dashboard sullo stesso Pi può filtrare l'hardware se si aggiungono troppe funzionalità.
  • Cloud VPS (DigitalOcean, AWS, Linode)] – utilizzare un minimo gocciola Ubuntu, installare Node.js o Python, ed eseguire l'applicazione dietro un proxy inverso (Nginx) con SSL. Questo consente di visualizzare il cruscotto da qualsiasi luogo, ma richiede l'indurimento della sicurezza (firewall, fail2ban, HTTPS).
  • Piattaforme senza precedenti (Vercel, Netlify, Cloudflare Workers)[] – buone per frontend statici, ma lottano con connessioni WebSocket persistenti. È necessario affidarsi a polling e un backend separato per l'aggregazione dei dati. È inoltre possibile utilizzare Cloudflare Workers con oggetti durevoli per il supporto WebSocket, ma che aggiunge complessità e costi.

Per l'accesso remoto senza un IP pubblico, si consideri l'utilizzo ngrok] per creare un tunnel sicuro al proprio cruscotto locale. Abbinalo con uno strato di autenticazione (HTTP base auth o token-based) per impedire la visualizzazione non autorizzata. In alternativa, impostare una VPN WireGuard sulla tua rete domestica.

Se si sceglie di ospitare nel cloud, essere consapevoli delle normative HIPAA o GDPR se si tratta di dati sanitari.Al minimo, crittografare i dati in transito (TLS) e a riposo (basato crittografato).

Migliori Pratiche per il monitoraggio dei dati dei diabeti

La vostra dashboard sarà utilizzata per le decisioni critiche sulla vita, quindi l'affidabilità e l'accuratezza sono essenziali.

  • Redundancy[[] – se il cruscotto non riesce, l'utente dovrebbe ancora ottenere avvisi dal proprio ricevitore o pompa CGM. Mai fare affidamento solo su una dashboard personalizzata per gli allarmi. Il cruscotto dovrebbe servire come strumento complementare, non un sistema di allarme primario.
  • Valutazione dei dati[[] – rifiuta le letture con valori impossibili (ad esempio, BG < 20 mg/dL o > 600 mg/dL).
  • Gestione della zona di tempo[[] – utilizzare UTC per lo storage e convertire all'ora locale dell'utente sul frontend. I timestamp OpenAPS sono tipicamente UTC.
  • Accessibilità[] – utilizzare colori ad alto contrasto, grandi font e avvisi audio facoltativi (via Web Audio API) per bassi critici.
  • Logging[] – registrare dati storici per una successiva revisione (ad esempio, esportazioni CSV). Un database di serie temporali come InfluxDB può essere collegato per analisi di lungo termine e analisi di tendenza.

Se la pompa esaurisce l'insulina? Simulare questi scenari per garantire che il cruscotto si riprenda senza intervento manuale. Implementare i endpoint di controllo della salute che possono essere monitorati esternamente. Eseguire il cruscotto per una settimana prima di fidarsi di esso per uso critico. Avere un piano di fallback - tenere aperta l'applicazione ufficiale CGM sul telefono accanto al cruscotto personalizzato.

Caratteristiche avanzate da considerare

Una volta che hai un cruscotto di base in esecuzione, prendere in considerazione l'aggiunta di questi miglioramenti:

  • Linee di predizione[[] – utilizzare una semplice regressione lineare sulle letture BG passate per proiettare i prossimi 30 minuti. Gli utenti più avanzati possono integrare i modelli di apprendimento automatico tramite un microservizio separato.
  • ] Annunci vocali[[]] – integrare la sintesi vocale del browser per leggere l'attuale BG e IOB ogni 10 minuti, che è utile durante l'attività fisica.
  • Controllo di rimozione[[] – con estrema cautela, è possibile aggiungere pulsanti per attivare basali temporanei o snooze allarmi attraverso l'API OpenAPS. Questo richiede una rigorosa autenticazione e una finestra di dialogo di conferma per evitare modifiche accidentali.
  • Supporto utente multi[[[]] – consentire ai caregiver di visualizzare il cruscotto dai propri dispositivi con autorizzazioni diverse (ad esempio, in sola lettura per i genitori, controllo completo per l'utente primario).

Ogni funzione aggiunge complessità e potenziale rischio. Prova sempre in un ambiente sicuro (ad esempio, utilizzando dati storici o un impianto che esegue in modalità “elaborata” ma sicura) prima di affidarsi a loro per uso quotidiano. Considerate l’utilizzo di bandiere di funzionalità per far esplodere gradualmente nuove funzionalità. Ad esempio, potreste abilitare le linee predittive per un sottoinsieme di utenti prima e raccogliere feedback prima di abilitare per tutti.

Risoluzione dei problemi Problemi comuni

Durante lo sviluppo, si possono incontrare diversi problemi comuni. Ecco le soluzioni:

  • Data non aggiorna[[[] – Controlla la connettività di rete tra il server di dashboard e il rig. Verifica che l'API OpenAPS stia rispondendo curling diretto dell'endpoint. Assicura che le intestazioni CORS siano impostate se si effettuano richieste di cross-origin. Controllare le regole del firewall e che la porta 8080 del rig è accessibile.
  • Inserzioni dei dati di stato[[] – Se le letture sono più vecchie del previsto, aumenta l'intervallo di polling o riduce la cache TTL. Inoltre, confermare che il dispositivo CGM sta trasmettendo correttamente.
  • WebSocket disconnette[[[] – Riconnettersi automaticamente con backoff esponenziale. Controllare le impostazioni del proxy o le regole del firewall che possono cadere connessioni idle.
  • I valori non vengono visualizzati[ – Convalida la struttura dei dati JSON. Utilizza i log della console per ispezionare i dati prima di passare alla libreria di charting. Assicurare che i timestamp siano in un formato che la libreria si aspetta (ad esempio, millisecondi per Chart.js).

Aggiungi il login sia sul backend che sul frontend per catturare le condizioni di errore. Considera di configurare un servizio di monitoraggio come UptimeRobot per il cruscotto stesso. Crea una semplice pagina “salute” che elenca tutti gli stati conosciuti (rig raggiungibili, ultimo aggiornamento dati, stato WebSocket) in modo da poter diagnosticare rapidamente i problemi.

Conclusioni

Un dashboard personalizzato OpenAPS è più di un esercizio tecnico: è uno strumento che può migliorare la vostra fiducia e la qualità della vita mettendo i dati a portata di mano. Inizia piccolo: prendi un endpoint e visualizza un singolo grafico. Poi iserare aggiungendo più metriche, avvisi e perfezionamenti visivi. La combinazione dei dati aperti di OpenAPS e delle moderne tecnologie web ti dà una flessibilità senza pari per creare rapidamente l'esperienza di monitoraggio che hai bisogno.