Migrazione da ThingsBoard a Connhex: una guida completa

Questa guida fornisce un piano per la migrazione della tua soluzione IoT da ThingsBoard a Connhex.

Sebbene entrambe le piattaforme siano dedicate al mondo IoT, sono progettate con filosofie diverse. ThingsBoard è una piattaforma all-in-one con una UI configurabile, mentre Connhex è una suite di servizi specializzati, API-first, progettati per massimizzare flessibilità ed integrazione.

Filosofia generale​

Per migrare con successo la tua soluzione basata su ThingsBoard a Connhex, dovrai tenere presente i diversi approcci:

• ThingsBoard: fornisce un'esperienza all-in-one con UI integrata per la configurazione e la gestione dei dispositivi.
• Connhex: enfatizza un approccio modulare e basato su API. Le applicazioni per l'utente finale vengono costruite interagendo tramite API con servizi distinti (Resources, IAM, Core, Rules Engine, OTA, ecc.)

Mappatura dei concetti principali​

Considerazioni dettagliate sulla migrazione​

1. Data Model (Entities & Attributes)​

• ThingsBoard: entità strutturate (Device, Asset, Customer, Tenant) con relazioni predefinite e scope degli attributi (Server, Shared, Client).
• Connhex: utilizza risorse generiche definibili tramite JSON Schema flessibili. Anche le relazioni tra risorse sono definite e gestite allo stesso modo.
• Migrazione:
  1. Definisci i vari JSON Schema in Connhex Resources per ciascuno dei tuoi tipi di entità ThingsBoard (ad es., uno Schema per un dispositivo "Termostato", uno schema per un asset "Edificio").
  2. Migra gli attributi di ThingsBoard:
     • Gli attributi Server-side diventano parte dei dati della risorsa in Connhex.
     • Gli attributi Shared possono far parte della configurazione iniziale del dispositivo fornita da Connhex Remote Init o essere gestiti come attributi aggiornabili delle risorse.
     • Gli attributi Client-side sono dati riportati dal dispositivo e possono essere memorizzati come parte dei dati della sua risorsa o mantenuti come info in Connhex Core.
  3. Ricrea le gerarchie delle entità (ad es., Tenant > Customer > Asset > Device) definendo relazioni tra i tuoi Connhex Resources. Assicurati di sfruttare Connhex IAM per autorizzazioni e permessi.
• Da tenere presente: il passaggio da tipi di entità fissi a risorse definite attraverso JSON Schema flessibili richiede una fase preliminare di progettazione, specialmente nel caso di relazioni complesse.

2. Dati di telemetria​

• ThingsBoard: gestisce l'ingestion della telemetria come coppie chiave-valore.
• Connhex: Connhex Core gestisce l'ingestion dei messaggi. La Connhex Message Policy (CMP) è fortemente raccomandata per le nuove integrazioni, categorizzando i dati in infos (informazioni statiche sul dispositivo), params (parametri configurabili) e data (telemetria, time-series). Ciò consente uno storage ed un recupero dei dati ottimizzati.
• Migrazione:
  1. Assicurati che il firmware attuale del dispositivo invii i dati in un formato compatibile con Connhex Core (JSON o SenML).
  2. Se possibile, adotta la CMP per benefici a lungo termine. Per i dispositivi esistenti, potresti inizialmente inviare tutta la telemetria come data e rifinire in seguito, oppure utilizzare Connhex Mapper se risulta difficile modificare il firmware.
• Da tenere presente: tra le diverse opzioni, scegli quella che meglio si adatta alle tue esigenze. Generalmente la decisione va presa in base a quanto sia difficile modificare il firmware: implementare la CMP è più complesso, ma porta a benefici sostanziali in termini di prestazioni nel medio termine. Configurare Connhex Mapper è spesso immediato, ma si perderanno tali ottimizzazioni.

3. RPC (Remote Procedure Calls)​

• ThingsBoard: dispone di meccanismi RPC client-side e server-side dedicati, inclusi RPC persistenti.
• Connhex: non ha un servizio "RPC" diretto. Le funzionalità sono ottenute tramite protocolli di comunicazione standard (MQTT, HTTP) gestiti da Connhex Core e potenzialmente da Connhex Edge (per il canale control).
• Migrazione:
  • Server-to-Device (RPC Server-Side di ThingsBoard):
    1. Definisci topic MQTT o endpoint HTTP per i comandi.
    2. I dispositivi si sottoscrivono a questi topic/si mettono in ascolto sugli endpoint.
    3. La tua applicazione (o Connhex Rules Engine) pubblica i messaggi di comando.
    4. Per RPC bidirezionali, il dispositivo pubblica una risposta a un topic/endpoint di risposta predefinito.
  • Device-to-Server (RPC Client-Side di ThingsBoard):
    1. Il dispositivo pubblica un messaggio su un topic MQTT/endpoint HTTP specifico, ad esempio utilizzando l'addon Edge Rules Engine.
    2. Questo messaggio può attivare Connhex Rules Engine o un backend applicativo personalizzato costruito sulle API Connhex, che elabora la richiesta e può inviare una risposta al dispositivo.
• Da tenere presente: la logica RPC persistente (accodamento dei comandi per dispositivi offline) è gestita solo se i tuoi dispositivi utilizzano Connhex Edge, altrimenti deve essere integrata nel tuo firmware. La corrispondenza richiesta-risposta potrebbe necessitare dell'aggiunta di un campo message_id.

4. Allarmi​

• ThingsBoard: gli allarmi includono tipi, severità, stato e propagazione. Sono solitamente configurati nei Device Profile o nel Rule Engine.
• Connhex: la logica degli allarmi è principalmente costruita utilizzando Connhex Rules Engine, che fornisce condizioni di soglia/delta, finestre temporali e logiche di durata.
• Migrazione:
  1. Ricrea le condizioni di allarme (soglie, cambi di stato) come Conditions all'interno di Connhex Rules Engine.
  2. Il Rules Engine si occuperà di lanciare notifiche tramite Connhex Notifications.
• Da tenere presente: la logica degli allarmi deve essere adattata alle API esposte da Connhex Rules Engine.

5. Aggiornamenti OTA​

• ThingsBoard: gestisce firmware/software in un repository OTA e li assegna a dispositivi/profili.
• Connhex: OTA Firmware Update di Connhex utilizza Models (tipi di dispositivo che supportano OTA) e Releases (versioni firmware per un modello). I dispositivi si possono autenticare utilizzando init_id e init_key.
• Migrazione:
  1. Definisci i vari Models in Connhex OTA per i tuoi tipi di dispositivo.
  2. Carica le versioni del firmware come Releases per questi modelli.
  3. Assicurati che i dispositivi possano autenticarsi con init_id e init_key.
  4. Se non stai usando Connhex Edge: implementa le chiamate HEAD (verifica della disponibilità) e GET (download, con header Range per download parziali) sul dispositivo.
  5. Se non stai usando Connhex Edge: implementa la verifica del checksum sul dispositivo.
• Da tenere presente: la logica lato dispositivo per il recupero degli aggiornamenti deve essere allineata al flusso OTA di Connhex.

6. Provisioning e inizializzazione dei dispositivi​

• ThingsBoard: utilizza chiavi/secrets di provisioning nei Device Profile. Supporta il claim.
• Connhex:
  • Connhex Provisioning: crea il Connectable (digital twin), genera i certificati tramite Connhex Certs.
  • Connhex Remote Init: fornisce la configurazione iniziale (parametri di connessione, impostazioni personalizzate) al dispositivo in seguito alla sua prima connessione autenticata (usando init_id, init_key).
  • Connhex Manufacturing: memorizza informazioni dettagliate sulla produzione dei dispositivi.
  • Connhex Device Ownership: per associare utenti a dispositivi (claim).
• Migrazione:
  1. Integra il tuo processo di produzione/provisioning con Connhex Provisioning per creare i connectables e i loro init_id/init_key iniziali.
  2. Configura Connhex Remote Init per servire le configurazioni di avvio necessarie.
  3. Il firmware del dispositivo deve implementare la logica per recuperare la sua configurazione da Remote Init usando i suoi init_id/init_key.
  4. Se utilizzi il claiming dei dispositivi, migra questo flusso a Connhex Device Ownership.
• Da tenere presente: questo processo coinvolge più servizi in Connhex, e può essere completamente automatizzato tramite la Connhex CLI. Il dispositivo deve avere a disposizione init_id e init_key, o utilizzare una migration key.

7. Interfacce utente (UI)​

• ThingsBoard: fornisce UI configurabili per amministrazione, dashboard e gestione dei dispositivi.
• Connhex: è API-first. Fornisce Connhex Control (UI di back-office per l'amministrazione), Connhex Copilot (chat intelligente per gli amministratori di Connhex) ed integrazione con Grafana per dashboard ad uso interno. Anche se le applicazioni per l'utente finale devono essere sviluppate su misura, Connhex include moduli client (ad es., ngx-admin-ui-sdk per Angular) per accelerare lo sviluppo frontend.
• Da tenere presente: questa è una differenza fondamentale. Se utilizzi le UI di ThingsBoard per gli utenti finali, dovrai costruirle da zero o adattare dei template.

Funzionalità specifiche di Connhex​

Durante la migrazione della tua soluzione da ThingsBoard a Connhex, potresti trovare interessanti alcune funzionalità correlate. Ecco un elenco parziale di caratteristiche che, con ridotto sforzo implementativo, potrebbero risultare vantaggiose per la tua soluzione:

• Connhex IAM: gestione granulare delle identità e degli accessi con realms (per segregazione multi-applicazione/business unit) e tenants (per segregazione clienti/dati). Questo offre una gestione dei permessi molto più flessibile rispetto ai ruoli di ThingsBoard.
• Connhex Mapper: utile per trasformare i payload dei messaggi da dispositivi legacy già sul campo o integrare dispositivi con protocolli non standard, senza dover modificare il firmware.
• Connhex Exporter: esportazione asincrona e scalabile di dati, per reportistica o archiviazione, che consente di ridurre il carico sui sistemi primari.
• Connhex Manufacturing: servizio dedicato per tracciare dati dettagliati di produzione, separati dai dati IoT operativi. Questo risulta uno strumento fondamentale per la tracciabilità ed il controllo qualità.
• JSON Schema per Connhex Resources: fornisce meccanismi di validazione dei dati ed una chiara definizione per tutte le tue "entità", consentendo una migliore coerenza delle API e degli strumenti.
• Connhex Rules Engine - Events: storicizzazione dettagliata dei trigger delle regole e degli stati attuali delle condizioni, utile per audit e debug.
• Connhex Core: include alcune strategie avanzate di gestione dei dati, come aggregazione e decimazione o backup e conservazione dei dati configurabili

Se stai cercando di capire come questi aspetti si integrino con le funzionalità esclusive di Connhex, come Connhex Pay e Connhex AI, la documentazione è solitamente un buon punto di partenza.

Migrazione da ThingsBoard a Connhex: i prossimi passi​

Migrare da ThingsBoard a Connhex è un passaggio verso un'architettura più modulare e API-centrica.

Sebbene solitamente richieda un maggiore sviluppo personalizzato, una soluzione basata su Connhex offre maggiore flessibilità e controllo: per un'esperienza più fluida possibile, ti consigliamo di iniziare la migrazione con un piccolo sottoinsieme di dispositivi o un singolo caso d'uso. Un ottimo punto di partenza è:

• definire la strategia di modellazione dei dati tramite JSON Schema
• decidere se utilizzare Connhex Mapper o se aggiornare il firmware dei tuoi dispositivi

Se stai riscontrando difficoltà con alcuni aspetti della migrazione da ThingsBoard a Connhex, non esitare a contattarci. Abbiamo già supportato molti produttori di dispositivi nel passaggio da un progetto pilota basato su ThingsBoard a una soluzione di livello industriale basata su Connhex: è probabile che le tue domande abbiano già trovato risposta!