Il forno viene acceso, la produzione solare cala e l’auto sta caricando. Le tre azioni appartengono a parti diverse della casa, ma si incontrano nello stesso bilancio elettrico. Un sistema di gestione energetica deve conoscere le potenze disponibili, rispettare i limiti dei dispositivi e decidere quali richieste possono adattarsi. Per verificare queste decisioni servono un modello coerente e una comunicazione osservabile fino al risultato.
SLX SolarPilot realizza il collegamento tra un impianto residenziale virtuale e una centralina touch Linux. Il simulatore Windows riproduce fotovoltaico, accumulo, elettrodomestici e ricarica EV; l’applicazione embedded usa LVGL su Raspberry Pi e scambia dati attraverso EEBUS. Il banco permette così di studiare insieme calcoli, protocolli e interazione dell’operatore.
La pagina del progetto SolarPilot presenta applicazione e architettura. Questo approfondimento esamina le grandezze fisiche, le scelte di comunicazione e i criteri per rendere verificabile una prova. Il repository GitHub e la versione Windows 0.4.5 sono disponibili per la valutazione.
kW e kWh: partire da due domande diverse
La potenza indica la velocità con cui si trasferisce energia in un dato istante. L’energia considera quel trasferimento nel tempo. Un assorbimento di 2 kW mantenuto per mezz’ora corrisponde a 1 kWh: 2 kW × 0,5 h = 1 kWh. Se il carico cambia, occorre integrare le potenze dei diversi intervalli.
Nel motore SolarPilot il passo fisico è di un secondo. Un intervallo con potenza costante P, espressa in watt, contribuisce all’energia con ΔE [Wh] = P [W] × Δt [s] / 3600. Un carico da 2000 W mantenuto per 180 secondi trasferisce quindi 100 Wh. È un controllo semplice, ma utile per scoprire errori di unità, conversioni applicate due volte o intervalli conteggiati oltre il termine di una ricarica.
La potenza installata del fotovoltaico, espressa in kWp, è un’ulteriore informazione: descrive la taglia nominale dei moduli in condizioni di prova. Non stabilisce quanta energia verrà prodotta in una giornata e non garantisce una potenza costante durante l’uso.
Dal sole alla potenza disponibile in casa
I moduli fotovoltaici producono energia elettrica in corrente continua. L’inverter la converte per il lato in corrente alternata dell’impianto. Irraggiamento sul piano dei moduli, orientamento, inclinazione, temperatura delle celle e limiti del convertitore contribuiscono al risultato. Le metodologie PVGIS del JRC descrivono questi fattori e distinguono la temperatura del modulo da quella dell’aria.
Come riferimento didattico si può scrivere una relazione semplificata: Pdc ≈ Pstc × (G / 1000) × [1 + γ × (Tcell − 25)]. G è l’irraggiamento in W/m², Tcell la temperatura della cella in gradi Celsius e γ il coefficiente termico del modulo. Le condizioni di riferimento usano 1000 W/m² e 25 °C di temperatura della cella. La relazione aiuta a leggere i fenomeni; non sostituisce un modello completo del componente.
Con 16 moduli da 450 Wp si ottengono 7,2 kWp nominali. Supponendo, soltanto per il calcolo illustrativo, G = 800 W/m², Tcell = 45 °C e γ = −0,0035 per grado, il fattore termico vale 0,93 e la potenza continua stimata è circa 5,36 kW. Sono ipotesi dichiarate, non una previsione per un tetto o un modulo commerciale. La descrizione PVWatts della collaborazione PVPMC di Sandia approfondisce modelli basati su irraggiamento e temperatura.
L’inverter aggiunge un proprio vincolo. Se l’energia disponibile sul lato DC consentirebbe una potenza maggiore del limite AC, l’uscita viene limitata: è il clipping. Per questo taglia dei moduli, potenza dell’inverter e capacità dell’accumulo devono rimanere parametri separati. In SolarPilot il modello istantaneo è deterministico e semplificato: proietta le componenti solari sui pannelli e applica fattori termici e limiti, senza calcolare ombreggiamenti locali dettagliati, stringhe elettriche o inseguimento MPPT completo.
PVGIS: un riferimento storico, con parametri conservati
PVGIS offre dati e stime di produzione fotovoltaica per località e configurazioni dichiarate. Il progetto include risposte di riferimento per Bologna, Roma e Palermo: 1 kWp sul gruppo sud, inclinazione di circa 26,565°, database SARAH3 e perdite di sistema impostate al 14%. La vista mensile le scala per la potenza nominale del gruppo sud.
Questi dati non cambiano automaticamente quando si ruota un oggetto nella scena, non stimano la falda nord e non prevedono il passaggio di una nuvola nei prossimi secondi. La simulazione istantanea resta un percorso distinto. Inoltre, il 14% dichiarato è già incluso nella risposta PVGIS: sottrarlo nuovamente ridurrebbe il risultato due volte. La FAQ ufficiale sulle perdite chiarisce anche perché fattori di perdita successivi si combinino moltiplicativamente.
Il bilancio deve chiudere a ogni intervallo
Il modello domestico sul lato AC adotta una convenzione esplicita: la rete è positiva quando si preleva, la batteria è positiva quando scarica. La carica dell’accumulo e l’immissione in rete hanno segno negativo. Il controllo numerico fondamentale è:
Pfv + Prete + Pbatteria − Pcasa − Pev = 0Il consumo EV è separato da quello della casa. Le potenze dell’inverter e della batteria si riferiscono al lato AC del bilancio; le perdite di accumulo sono contabilizzate nel passaggio verso o dall’energia immagazzinata. Questa scelta permette di verificare sia la conservazione della potenza sul nodo domestico sia l’evoluzione dello stato di carica.
Nell’esempio, 6,0 − 2,9 − 0,8 − 2,3 = 0 kW. Con l’aggiunta di un forno da 2,4 kW, mantenendo invariata la ricarica EV, una soluzione fisicamente possibile è ridurre la carica dell’accumulo da 2,9 a 0,5 kW. Altre priorità possono invece ridurre la ricarica o ammettere un prelievo dalla rete. Il bilancio indica le soluzioni ammissibili; la policy decide quale perseguire.
Un limite di prelievo non può far sparire la potenza richiesta dagli apparecchi. Se i carichi non differibili superano il margine disponibile, occorre rappresentare il sovraccarico e il comportamento previsto. Nel dimostratore un ciclo protetto già avviato può proseguire, mentre l’EMS riduce i nuovi avvii o le utenze flessibili.
Accumulo: capacità, potenza, riserva e rendimento
Una batteria da 10 kWh e una batteria capace di erogare 3 kW rispondono a due vincoli differenti: energia immagazzinabile e potenza trasferibile. Il SOC, State of Charge, rappresenta una frazione della capacità. Con il 55% su 10 kWh sono rappresentati 5,5 kWh immagazzinati nel modello; con una riserva impostata al 15%, l’energia utilizzabile prima della riserva è di 4 kWh.
SolarPilot applica un rendimento del 95% per direzione nella configurazione di base. Caricare a 2 kW per mezz’ora assorbe 1 kWh dal lato AC e aggiunge 0,95 kWh all’accumulo. Scaricare 1 kWh dall’energia interna consegna 0,95 kWh sul lato AC. Un ciclo completo alle stesse condizioni ha quindi rendimento 0,95 × 0,95 = 0,9025, circa il 90,25%.
La riserva entra nel calcolo prima di applicare il trasferimento. Nell’esempio dei 4 kWh interni utilizzabili, il lato AC può ricevere 3,8 kWh con rendimento 95%. A un carico costante di 0,8 kW corrisponderebbero 4,75 ore, soltanto entro queste ipotesi e senza altri consumi. È un esercizio sul modello, non una stima di autonomia di un’abitazione reale.
Vicino ai limiti del SOC, il controllo deve ridurre l’ultimo trasferimento al valore ancora possibile. Limitarsi a tagliare il SOC dopo un passo troppo grande altererebbe la contabilità: il contatore avrebbe visto energia che la batteria non poteva accettare o fornire. I test numerici indipendenti coprono anche questi casi.
Ricarica EV: obiettivo energetico e tempo disponibile
Nel banco il veicolo ha capacità dimostrativa di 60 kWh. Passare dal 45% all’80% richiede 60 × (0,80 − 0,45) = 21 kWh di incremento interno. Con rendimento di ricarica del 92%, l’energia AC necessaria nel modello è circa 21 / 0,92 = 22,83 kWh.
Se si impostano 16 A in un esempio monofase a 230 V e fattore di potenza unitario, la potenza è 3,68 kW. A potenza costante, 22,83 kWh richiederebbero circa 6 ore e 12 minuti. Sono condizioni idealizzate: il modello non rappresenta la curva completa di una vettura commerciale, il taper finale o il controllo elettrico IEC 61851.
La soglia dimostrativa minima è 6 A, cioè 1,38 kW a 230 V; i gradini della strategia corrispondono a 1 A. Il limite può dipendere da wallbox, potenza disponibile, modalità scelta e obiettivo. Le modalità surplus, rapida e partenza permettono di confrontare priorità diverse. Una verifica di fattibilità segnala quando tempo e potenza disponibili non bastano, senza garantire una produzione solare futura.
Anche l’ultimo secondo conta. Se il veicolo raggiunge il target durante l’intervallo, la potenza media del passo e la durata effettiva della carica devono restare coerenti. Il core distingue setpoint attivo, tempo di attività ed energia immagazzinata, evitando di trasferire energia oltre l’obiettivo.
Elettrodomestici: gestire un ciclo, non solo un interruttore
Una lavatrice non assorbe sempre la potenza della resistenza. Nel modello attraversa carico dell’acqua, riscaldamento, lavaggio, risciacquo e centrifuga; una lavastoviglie ha una propria sequenza. L’EMS deve considerare che autorizzare oggi una fase leggera può impegnare una potenza maggiore poco dopo.
Il controllo distingue i nuovi avvii differibili dai cicli protetti. Priorità e finestre operative governano l’ammissione; un’indisponibilità esplicita del dispositivo è un evento diverso dalla semplice riduzione del surplus. Forno, bollitore e piano cottura aiutano a riprodurre variazioni rapide e casi in cui la flessibilità disponibile è insufficiente.
La scena 3D rende riconoscibile l’oggetto associato al carico. L’apertura geometrica di uno sportello rimane però una funzione visiva: non introduce automaticamente un modello termico della porta aperta o un consumo misurato su un apparecchio reale.
EEBUS: dalla scoperta del dispositivo alla connessione operativa
La comunicazione nativa del banco utilizza SHIP 1.0.1 e SPINE 1.3.0, con revisioni delle librerie Enbility fissate nel progetto. Sono due responsabilità distinte: SHIP prepara e protegge il collegamento; SPINE descrive le risorse energetiche e le operazioni applicative. Il catalogo ufficiale EEBUS raccoglie specifiche, schemi e casi d’uso delle diverse versioni.
Discovery, indirizzo IP e identità
Nella rete locale il servizio viene annunciato come _ship._tcp attraverso mDNS/DNS-SD. La scoperta fornisce i dati necessari a raggiungere il nodo: host, porta, percorso WebSocket e informazioni identificative. In SolarPilot è disponibile anche l’impostazione manuale da IP. Le porte del banco, 4712 e 4713, sono valori configurabili del progetto, non numeri da assumere per ogni dispositivo EEBUS.
L’indirizzo indica dove si trova un nodo in quel momento; l’identità consente di riconoscere il partner autorizzato. SolarPilot conserva SKI, fingerprint e SHIP ID del peer selezionato. Il cambio di indirizzo dovuto al DHCP non deve quindi essere confuso con una nuova identità, mentre la sostituzione della chiave richiede una nuova valutazione della fiducia.
TCP, TLS, WebSocket e negoziazione SHIP
Il percorso descritto dalla documentazione SHIP comprende apertura TCP, collegamento TLS e canale WebSocket, seguiti dallo scambio di controllo SHIP. La presenza della connessione TCP dimostra soltanto che esiste un canale di trasporto: non certifica il completamento dell’associazione o la disponibilità dei dati energetici.
Il banco usa certificati ECDSA persistenti e conferma esplicita del partner. SKI e fingerprint hanno funzioni diverse dall’indirizzo IP; il fingerprint del certificato non va confuso con lo SKI. La verifica deve riferirsi all’identità attesa sul dispositivo, non al solo nome visualizzato durante la ricerca. Lo stack Enbility ship-go gestisce il collegamento, mentre l’applicazione controlla quali peer siano considerati fidati.
Dopo il canale sicuro, SHIP negozia lo scambio applicativo. L’interoperabilità richiede che le due estremità completino questa fase e raggiungano uno stato operativo. Le varianti di commissioning, i PIN e gli eventuali servizi di associazione previsti da altre revisioni vanno verificati sul prodotto scelto: il supporto di SHIP 1.0.1 nel banco non dichiara automaticamente tutte le funzioni del catalogo EEBUS.
SPINE: indirizzi, misure, limiti e risultati
Device, entity e feature
SPINE indirizza una funzionalità attraverso dispositivo, entità e feature. Un unico nodo può rappresentare più sottosistemi, ciascuno con misure e controlli propri. Il ruolo client o server appartiene alla singola feature: non coincide necessariamente con il lato che ha aperto la connessione TCP. La descrizione ufficiale SPINE illustra questa organizzazione.
Il profilo completo SolarPilot comprende otto entità: rete, casa, fotovoltaico, batteria, EVSE, lavatrice, lavastoviglie e produzione fotovoltaica disponibile prima del taglio. È un mapping del dimostratore. Per un dispositivo generico il client legge l’inventario attraverso nodeManagementDetailedDiscoveryData e identifica funzionalità, indirizzi e capacità dichiarate; non può assumere che l’entità 3 di un altro costruttore sia necessariamente il fotovoltaico.
La discovery delle feature è seguita dalle autorizzazioni applicative e, dove previste, da binding e subscription. Una connessione TLS riconosciuta non rende scrivibile ogni funzione. La subscription consente di ricevere aggiornamenti tramite notifica, mentre una lettura esplicita richiede una risposta: il client deve gestire questi percorsi senza attribuire una notifica spontanea alla richiesta sbagliata.
Il datagramma e la correlazione delle operazioni
La struttura del datagramma nello stack spine-go separa header e payload. L’header comprende versione, indirizzi sorgente e destinazione, classificatore e contatori. Il payload contiene i comandi applicativi. read e reply descrivono una lettura e la sua risposta; write modifica dati scrivibili; notify aggiorna il destinatario; result riporta un esito.
msgCounter identifica un messaggio SPINE e msgCounterReference collega una risposta all’operazione di origine. Non sono i numeri di sequenza TCP. Nella diagnostica SolarPilot il contatore permette di seguire una scrittura fino al relativo risultato, anche quando nel frattempo arrivano notifiche di altre misure.
Misure con numero, scala, unità e provenienza
Il percorso MPC, Monitoring of Power Consumption, trasferisce gli aggiornamenti tramite measurementListData. Un valore va interpretato insieme alla descrizione del punto: identificativo, grandezza, unità, timestamp e stato. Il frammento seguente illustra un elemento di misura, non un datagramma completo da inviare:
{
"measurementId": 1,
"value": { "number": 2530, "scale": 0 },
"valueSource": "calculatedValue"
}Se la descrizione associa quel punto alla potenza in watt, il valore rappresenta 2530 W. Con number=253 e scale=1 si ottiene la stessa grandezza. La struttura è documentata nei tipi Measurement di spine-go. Nel banco i dati sono marcati come calcolati: una misura proveniente dal simulatore non diventa una lettura di un sensore fisico perché viene trasmessa con un protocollo reale.
LPC e LPP: un limite non è un consumo imposto
LPC riguarda la limitazione del consumo; LPP quella della produzione. SolarPilot utilizza loadControlLimitListData per trasferire i tetti delle entità supportate. La specifica LPC descrive direzione, parametri e comportamento del caso d’uso. Nel modello un tetto di consumo pari a 2000 W non obbliga un’utenza a consumare 2000 W: ne limita la richiesta ammissibile.
Il nodo che riceve una scrittura restituisce un risultato correlato. resultData.errorNumber=0 indica accettazione applicativa; il comportamento effettivo viene verificato sulle misure successive. Per la batteria, riserva, SOC, disponibilità energetica e limiti locali continuano a delimitare ciò che può accadere. Le scelte del profilo sono riportate nel contratto del banco EEBUS SolarPilot.
Scadenza dei dati e watchdog del dimostratore
Il controllore di riferimento scarta misure MPC più vecchie di tre secondi. Nel profilo completo SLX devono inoltre essere recenti tutti e sei i limiti esterni richiesti dal banco e deve essere presente il collegamento SHIP. Alla perdita del controllo valido, EV e batteria vengono arrestati nel modello, mentre i cicli già avviati e l’interblocco locale sull’export mantengono il comportamento dichiarato.
Questo watchdog di tre secondi è una regola locale del dimostratore, distinta dai timer e dalla macchina di stato dei casi d’uso normativi. I profili generici usano i limiti delle singole entità e le relative durate; non richiedono la sequenza a sei canali del banco SLX. La conformità completa di una centralina regolamentata non può essere dedotta dal superamento di questa prova.
Che cosa mostra realmente il monitor dei messaggi
Il monitor EEBUS osserva il corpo applicativo SHIP nei punti di ingresso e uscita dello stack. Il JSON visualizzato è quindi disponibile all’applicazione dopo l’elaborazione del collegamento sicuro. Non è una cattura PCAP: non mostra gli header TCP, i record TLS cifrati o tutti i byte del framing WebSocket. Una cattura della rete e una traccia applicativa rispondono a domande differenti.
Le osservazioni PC TX ed EMS RX possono riferirsi allo stesso messaggio visto ai due estremi. Contarle come due telegrammi distinti falserebbe il traffico stimato. SolarPilot conserva un ring di 256 osservazioni; l’anteprima può essere troncata a 16 KiB, mentre il conteggio dei byte riguarda il corpo completo osservato.
Anche i tempi richiedono una definizione. Il valore RTT del banco locale comprende pubblicazione, ricezione, decisione della policy e ritorno dei limiti: non misura soltanto il tempo di volo di un pacchetto. Timestamp, contatore SPINE, direzione ed esito permettono invece di ricostruire la sequenza di una prova e distinguere ritardo, mancata risposta e comando accettato.
SunSpec Modbus TCP: leggere un telegramma e scoprire i modelli
Il trasporto Modbus TCP impiega l’header MBAP e una PDU con funzione e dati. Il protocollo applicativo Modbus V1.1b3 definisce le funzioni; SunSpec assegna significato ai punti energetici. Nel server SolarPilot la porta predefinita è 1502, configurabile anche a 502 quando richiesto dall’apparato esterno.
Esempio completo: richiesta della firma SunSpec
Nel mapping del banco, la Unit ID 2 rappresenta il contatore di rete e la firma SunSpec si trova alla base zero-based 40000. Una lettura FC03 di due registri può essere espressa dalla seguente richiesta didattica, con Transaction ID 42:
00 2A 00 00 00 06 02 03 9C 40 00 0200 2A: Transaction Identifier, ripreso nella risposta.00 00: Protocol Identifier del profilo Modbus TCP.00 06: numero di byte successivi, inclusi Unit Identifier e PDU.02: Unit Identifier del contatore nel banco.03: lettura dei registri holding.9C 40: indirizzo iniziale 40000 in formato big-endian.00 02: quantità richiesta, due registri da 16 bit.
La risposta contenente la firma SunS è:
00 2A 00 00 00 07 02 03 04 53 75 6E 53Il byte 04 indica quattro byte di dati. 53 75 6E 53 rappresenta la firma ASCII. Le lunghezze dei due esempi sono rispettivamente 12 e 13 byte. Il framing non può però dipendere da una singola chiamata di ricezione: TCP è uno stream e può consegnare una trama in più parti o più trame insieme.
La catena di modelli, gli indirizzi e i tipi
Dopo la firma, ogni blocco dichiara identificativo e lunghezza. Il client può così individuare un modello, leggerne i punti o saltarlo se non lo supporta. Il registro finale con identificativo 0xFFFF e lunghezza zero chiude la catena. Gli indirizzi delle singole grandezze dipendono dai blocchi precedenti: copiarli da un altro inverter senza eseguire la discovery è fragile.
Il server SolarPilot associa le Unit ID 1, 2 e 3 a fotovoltaico, rete e accumulo. Espone modelli 1, 101, 120 e 123 per il primo, 1 e 201 per il secondo, 1, 101, 120 e 124 per il terzo. Sono scelte del dimostratore. Le definizioni ufficiali SunSpec e la matrice SolarPilot consentono di verificare il mapping.
La rappresentazione può usare interi con scala o punti floating point, ciascuno con il proprio tipo. Il fattore di scala è un intero con segno: valore reale = valore grezzo × 10^SF. Nel profilo del contatore SolarPilot W_SF=1 offre una risoluzione di 10 W; un dato grezzo −123 rappresenta −1230 W, cioè immissione secondo la convenzione del banco. La quantizzazione del registro non modifica il calcolo fisico del core.
I valori non disponibili vanno distinti da zero. Per esempio il sentinel 0x8000 di un punto int16 non descrive una misura negativa utilizzabile. Anche la numerazione mostrata dal software client può aggiungere un’unità all’indirizzo di protocollo: la base 40000 usata nell’esempio va letta secondo la convenzione del client, non assunta dal testo visualizzato nel suo campo indirizzo.
Comandi SunSpec, errori e comportamento dell’accumulo
Scrivere un limite e verificarne l’effetto
Il server del banco accetta letture FC03/FC04 e scritture FC06 o FC16 nei punti implementati. FC06 scrive un registro, FC16 un gruppo di registri; SolarPilot valida la scrittura multipla prima di applicarla, evitando aggiornamenti parziali in caso di valori non ammessi. Funzioni, indirizzi o dati non validi producono eccezioni Modbus, anziché una conferma di applicazione.
Una risposta di eccezione alla funzione 03 utilizza il codice funzione 0x83, con il bit più significativo impostato, seguito dal motivo. I codici 01, 02 e 03 indicano rispettivamente funzione non ammessa, indirizzo non ammesso e valore dei dati non ammesso. Un timeout è invece assenza di risposta utile entro il termine del client: non va registrato come una conferma negativa ricevuta dal dispositivo.
Modbus TCP usa il modello richiesta/risposta: il client pianifica le letture e controlla Transaction ID, funzione, lunghezza e quantità dei dati prima di interpretare i registri. L’istante di ricezione non è automaticamente il timestamp fisico della misura. Le frequenze di polling vanno quindi concordate con aggiornamento dei dati, carico della rete e comportamento dell’apparato.
Per il fotovoltaico, il modello 123 comprende WMaxLimPct e WMaxLim_Ena. Il client deve leggere la scala, convertire la percentuale nella rappresentazione del punto, impostare il limite e abilitarlo. Un limite del 50% su una potenza nominale di 6 kW corrisponde a un massimo di 3 kW; non garantisce che il sole renda disponibili quei 3 kW. La definizione del modello 123 documenta i punti.
Dove implementato, un RvrtTms positivo determina il ripristino del controllo locale dopo quel numero di secondi reali; nel mapping SolarPilot zero mantiene il comando. Un riscontro di scrittura va seguito dalla rilettura dei parametri e delle misure, verificando anche che nessun limite locale più restrittivo ne impedisca l’effetto.
Il modello 124 e l’intervallo di carica e scarica
Nel modello 124, StorCtl_Mod abilita i controlli di carica e scarica; InWRte, OutWRte e MinRsvPct descrivono limiti e riserva. Nel mapping SolarPilot i controlli attivi delimitano l’intervallo:
−InWRte × WChaMax / 100
≤ Pbatteria ≤
OutWRte × WChaMax / 100Con WChaMax pari a 3 kW, InWRte = 50 e OutWRte = −50, abilitando entrambi i controlli, l’intervallo si riduce a −1,5 kW: una richiesta di carica secondo la convenzione del banco. Un intervallo impossibile viene rifiutato. SOC, riserva, disponibilità di energia e permesso di carica da rete restano vincoli del modello; il significato operativo va sempre confrontato con la documentazione dell’apparato di destinazione e con la definizione del modello 124.
Funzioni SLX e sicurezza del collegamento
L’estensione facoltativa SLX Energy/1 usa una banca separata: Unit ID 10 e registri 60000–60007. Identificazione, setpoint EV, consensi dei lavaggi e watchdog appartengono a questo contratto del banco. Non sono punti SunSpec universali e non servono per utilizzare le letture e i controlli standard implementati per PV e accumulo.
La demo usa Modbus TCP ordinario sulla rete di laboratorio, con accesso da limitare ai sistemi autorizzati del banco. La variante Modbus Security, con TLS e certificati, è un profilo distinto. La presenza di TLS nel collegamento EEBUS non protegge automaticamente il listener Modbus TCP separato.
Interoperabilità e verifica dei guasti
La compatibilità richiede un contratto comune a più livelli: trasporto, identità, ruolo applicativo, modelli disponibili, unità, punti scrivibili e comportamento temporale. Lo stesso nome di protocollo sul datasheet è una condizione iniziale, non l’esito del collaudo. La documentazione EEBUS sulla certificazione distingue ruoli e percorsi di verifica.
- Identità inattesa: il dispositivo trovato non va associato senza verificare il partner corretto.
- Punto assente o non disponibile: l’interfaccia deve conservare questa informazione, senza generare uno zero plausibile.
- Comando rifiutato: il risultato deve restare collegato alla richiesta che lo ha provocato.
- Risposta tardiva: la validità della misura va valutata sul tempo del dato, non sulla sola presenza del socket.
- Riconnessione: collegamento ripristinato e controllo nuovamente valido richiedono nuovi scambi coerenti.
Il progetto separa infine i protocolli di rete dal proprio collegamento interno fra processi: JSON Lines è usato nell’IPC locale verso il servizio protocolli; il laboratorio accelerato mantiene un percorso NNG/TCP/CBOR distinto. Un dispositivo di terzi non deve implementare questi meccanismi interni per parlare EEBUS o SunSpec. La documentazione del servizio precisa tale confine.
Linux embedded e LVGL: il controllo arriva sul dispositivo
La centralina usa una Raspberry Pi 3 Model A+ e un display touch da 10,1 pollici. L’immagine è costruita con Buildroot e mantiene i servizi necessari a rete, controllo, interfaccia, ora e persistenza. La versione del progetto impiega Linux 6.12.61 e LVGL 9.5. Il dettaglio di hardware, pagine e responsabilità è nella scheda del progetto.
La HMI riceve lo stato dal servizio applicativo e invia richieste validate. La navigazione non deve rimanere bloccata durante una scansione Wi-Fi; una risposta tardiva non deve riaprire una pagina che l’utente ha già lasciato. Sul display, animazione dei flussi, conferme ed eventi rendono visibili anche questi aspetti del sistema.
Il confronto ha due tempi distinti: i passi del modello fisico e il tempo reale di rete, watchdog e interazione. Le prove esterne procedono a 1×; gli scenari accelerati appartengono al laboratorio locale. Una registrazione permette di riesaminare dati e scelte, conservando questa distinzione.
Come trasformare una dimostrazione in una prova ripetibile
Una prova utile dichiara situazione iniziale, azione, risultato atteso e grandezze da osservare. Reset, stessa durata e stessi parametri permettono di confrontare le policy senza attribuire al controllore differenze introdotte dall’operatore.
| Caso | Variazione introdotta | Verifica |
|---|---|---|
| Surplus solare | Produzione superiore ai carichi | Ripartizione tra accumulo, EV e immissione; bilancio coerente |
| Nuvole e nuovi carichi | Riduzione della produzione e accensione di un’utenza | Rimodulazione della flessibilità e rispetto dei limiti disponibili |
| Riserva dell’accumulo | SOC vicino al minimo configurato | Ultimo trasferimento limitato e contabilità delle perdite |
| Obiettivo EV | SOC target raggiunto durante un intervallo | Arresto parziale senza energia aggiuntiva oltre il target |
| Perdita di comunicazione | Misure o comandi diventano scaduti | Stato segnalato, comportamento di fallback e recupero osservabili |
La verifica GitHub della versione pubblicata ha compilato l’interfaccia Windows ed eseguito con successo nove gruppi di test. Il percorso comprende calcoli energetici indipendenti, scenari, EMS, registrazione e protocolli. Le prove su Raspberry fisica dimostrano inoltre il collegamento del prototipo al banco; non qualificano automaticamente tutti gli apparati energetici di terzi.
Gli scenari e i report del software descrivono il modello dichiarato. La produzione di un impianto reale richiede dati del sito e dei componenti; il controllo sul campo richiede adattatori, protezioni e verifiche specifiche. Previsioni meteo operative, ottimizzazione tariffaria e integrazioni avanzate sono sviluppi su richiesta.
Provare SolarPilot e progettare un’integrazione
Per iniziare è sufficiente il pacchetto Windows x64: estrarre tutto l’archivio e avviare SLX-SolarPilot.exe, con un driver OpenGL 3.3. Il repository comprende interfaccia, SDK, documentazione e binari del core; l’uso è regolato dalla licenza di valutazione Silicon LogiX. Il firmware della centralina non è incluso nel pacchetto pubblico Windows.
Lo sviluppo di una centralina, di una HMI o di un adattatore energetico parte dalle interfacce degli apparecchi, dai vincoli dell’impianto e dai casi da riprodurre. La richiesta di una valutazione tecnica può indicare dispositivi da collegare, grandezze da controllare e condizioni da verificare. È il percorso per trasformare il banco dimostrativo in uno sviluppo su misura.
Riferimenti tecnici
- Progetto SLX SolarPilot: centralina touch e simulatore 3D.
- Modello energetico SolarPilot, strategie EMS e verifiche.
- JRC: metodi di calcolo PVGIS e API PVGIS 5.
- Sandia PVPMC: modello PVWatts.
- EEBUS SHIP, SPINE e casi d’uso ufficiali.
- SunSpec Alliance: specifiche, modelli e documentazione Modbus.
- Manuale Buildroot e documentazione LVGL.
