Shelly, Huawei e Modbus in un'unica piattaforma: come funziona l'interoperabilità

"Interoperabilità" è una parola che si usa spesso e si spiega raramente. Nel monitoraggio energetico multi-vendor significa una cosa precisa: che la potenza letta da un inverter Huawei via cloud, quella misurata da un meter Shelly, e quella letta da un contatore su bus Modbus finiscano tutte nello stesso schema dati, con lo stesso nome di campo e la stessa unità di misura — a prescindere da come, tecnicamente, sono state raccolte.

Il problema: ogni fonte parla una lingua diversa

Un inverter Huawei esposto via FusionSolar restituisce dati tramite un'API cloud proprietaria, con nomenclatura e struttura decise dal produttore. Uno Shelly è un dispositivo IoT che va gestito da remoto tramite l'API cloud di Shelly (non un driver locale REST — il dispositivo non è raggiungibile localmente in molte installazioni), con un proprio formato JSON per canale di potenza. Un contatore Modbus/TCP, dall'altra parte, non parla né REST né JSON: espone registri numerici su un protocollo binario che va interrogato, letto e interpretato in base a una mappa di registri specifica del dispositivo.

Tre fonti, tre protocolli di trasporto, tre formati di payload. Se ogni fonte finisse in dashboard e allarmi con il proprio formato originale, ogni funzionalità della piattaforma (grafici, KPI, allarmi di staleness) dovrebbe conoscere i dettagli di ogni singolo protocollo. Non scala, ed è fragile: basta che un produttore cambi la struttura della propria risposta API perché tutto il resto si rompa a cascata.

La soluzione: un connettore per fonte, un modello canonico per tutti

L'architettura risolve il problema separando due responsabilità che spesso vengono confuse: raccogliere il dato e rappresentarlo. Ogni fonte ha un proprio connettore, responsabile di parlare il protocollo specifico (chiamare l'API cloud di FusionSolar, interrogare l'API cloud di Shelly, leggere i registri Modbus) e di tradurre quello che riceve in un set di misure canoniche: campi come potenza istantanea di produzione, potenza di consumo, energia cumulata — con nome e unità sempre identici, qualunque sia la fonte originale.

Da quel punto in poi, per il resto della piattaforma — dashboard, calcolo dei KPI, motore di allarmi, API pubblica — non esiste più "il dato Huawei" o "il dato Shelly": esiste solo la misura canonica, con il suo timestamp e il suo device di origine. Aggiungere un nuovo vendor significa scrivere un nuovo connettore che produce lo stesso tipo di misure; non richiede toccare nessun'altra parte del sistema.

Perché questo conta lato API

Questo stesso modello canonico è ciò che viene esposto tramite l'API REST v1 con autenticazione OAuth2. Chi integra SunPilot — che sia un cruscotto di terze parti, uno script di reportistica o un altro gestionale — non deve conoscere se un dato viene da un inverter cloud o da un meter locale: interroga un endpoint di misure e riceve sempre la stessa forma. È lo stesso principio che rende possibile, ad esempio, l'integrazione con un CRM esterno per chi vuole collegare anagrafica impianto e monitoraggio senza ricopiare dati a mano.

Stato attuale, onestamente

Anche qui vale la stessa regola di trasparenza: oggi il connettore Huawei FusionSolar è quello completo, dal collegamento account alla misura canonica. I connettori per Shelly Cloud e per dispositivi Modbus/TCP condividono la stessa architettura e lo stesso modello di misure canoniche, e sono i prossimi in roadmap — non richiederanno un ripensamento del sistema, solo l'implementazione dell'adattatore specifico per ciascun protocollo.

Se gestisci impianti con hardware misto e vuoi essere avvisato quando i prossimi connettori entrano in produzione, entra in lista d'attesa.