Passa al contenuto principale

Controllo MQTT in tempo reale

suggerimento

Il controllo MQTT in tempo reale è destinato al controllo dal vivo. Per inviare programmazioni in anticipo, vedere Controllo MQTT Programmato invece.

Questa guida ti aiuterà a configurare MQTT sul tuo SmartgridOne Controller per controllare e monitorare a distanza le installazioni di batterie e pannelli solari.

Cosa ti serve

  1. SmartgridOne Controller con connettività internet.
  2. Credenziali MQTT: possono essere richieste inviando un'email a support@eniris.be.
  3. Ambiente di sviluppo Python (o qualsiasi altro client MQTT). Questa guida utilizza un esempio base scritto in Python per aiutarti a iniziare con MQTT e l'invio di comandi. Raccomandiamo di usare Python per facilità d'uso, ma è supportato anche qualsiasi altro client MQTT.

Informazioni extra

MQTT è un protocollo di comunicazione veloce su internet. È un sistema di messaggistica publish/subscribe, che consente una connessione diretta tra la tua macchina e il SmartgridOne Controller. I tuoi asset sono classificati in gruppi di solare, batterie, veicoli elettrici e HVAC.

Configurazione per la prima volta (Punto di partenza per nuovi utenti)

Ho un SmartgridOne Controller che vorrei configurare per il Controllo Remoto MQTT.

1. Controlla la tua rete

Assicurati che la tua rete consenta il traffico di rete mqtt sulla porta 1883. Puoi farlo utilizzando il comando:

nc -zv mqtt.eniris.be 1883

Quando questo comando non è disponibile, puoi alternativamente scaricare ed eseguire questo codice python.

Quando hai dei dubbi, consulta il tuo ingegnere di rete o utilizza temporaneamente l'hotspot 4G/5G del tuo telefono quando si verificano errori di connessione.

note

Quando la porta 1883 non è accessibile dalla tua rete, offriamo un backup sulla porta 80. Questo può essere configurato nel tuo client MQTT a un passo successivo di questo manuale.

2. Aggiungi i tuoi dispositivi

Accedi all'interfaccia di commissioning e assicurati che i dispositivi siano aggiunti al SmartgridOne Controller.

3. Aggiungi il segnale esterno MQTT

Immagine 1
Immagine 1
Immagine 1
Immagine 1

4. Abilita il segnale remoto MQTT

Il campo 'VPP ID' deve rimanere vuoto.

Il timeout del meccanismo di fallback indica al SmartgridOne Controller quanto tempo deve attendere nuovi comandi. Quando il SmartgridOne Controller smette di ricevere comandi, riprende automaticamente la strategia predefinita dopo questo timeout.

Dopo, seleziona tutti i dispositivi che desideri includere nel Controllo Remoto MQTT.

Immagine 1
Immagine 1

5. Il segnale remoto è stato aggiunto

L'interfaccia di Controllo Remoto MQTT è stata ora attivata sul SmartgridOne Controller.

Ora siamo pronti a inviare alcuni comandi basilari utilizzando un semplice esempio. La colonna Stato ti indica se qualche comando è attivo.

Immagine 1

Script demo Python

Un buon primo punto di partenza sarebbe testare la tua integrazione appena configurata con un semplice esempio.

Questo codice di test svolge un compito semplice di inviare continuamente i seguenti comandi:

  • Batteria: Carica a 5 kW
  • Solare: Imposta la potenza a 0 kW

Il SmartgridOne Controller risponde continuamente con un messaggio di 'feedback' contenente i valori della potenza della rete e degli asset osservati. Questa funzione è inclusa anche in questo esempio.

Si prega di scaricare il file sottostante nel proprio IDE Python preferito. Compila il tuo numero di serie e le credenziali MQTT ed esegui lo script:

Quando quanto sopra ha successo, puoi continuare a inviare altri tipi di comandi. Tutti i comandi sono descritti nella nostra Documentazione sul Controllo Remoto MQTT.

Documentazione MQTT per l'invio di comandi

Questa sezione dettaglia il formato di messaggistica MQTT e i requisiti del payload per controllare a distanza le politiche di potenza sui dispositivi all'interno della rete del SmartgridOne Controller.

Argomento MQTT

L'argomento MQTT utilizzato per inviare comandi è strutturato come segue:

standard1/rp_one_s/remoteControlMetrics/'controller SN'

Dove 'controller SN' deve essere sostituito con il numero di serie reale del SmartgridOne Controller che intendi controllare.

Struttura del Payload MQTT

I comandi sono inviati come payload JSON. La struttura del payload è progettata per specificare varie politiche di gestione della potenza e punti di impostazione per diversi componenti del sistema di smart grid. Ecco lo schema del payload con descrizioni dettagliate dei campi:

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": "<Unix Timestamp>",
"fields": {
"<Component Policy>": "<Policy Type>",
"<Component Power Setpoint>": <Setpoint in watts>
}
}

Descrizione dei campi

suggerimento

Più tipi di dispositivi (ad es. batterie + pannelli solari) possono essere controllati contemporaneamente.

  • extraTags (Oggetto):
    • nodeId (Stringa): Un identificatore unico per il nodo all'interno della rete del SmartgridOne Controller. Questo è uguale al tuo numero di serie, seguito da '_site_0' per la maggior parte dei dispositivi SmartgridOne Controller.
  • time (Intero): Timestamp Unix in secondi che indica il momento in cui il messaggio viene inviato.
  • fields (Oggetto):
    • <Component>_policy (Stringa): Tipo di politica per il componente. È opzionale e se non specificato, il sistema entrerà nella configurazione predefinita del SmartgridOne Controller.
    • <Component>_power_setpoint_w (Float): Punto di impostazione della potenza desiderata in watt per il componente. Questo è facoltativo e solo rilevante se è specificata una politica corrispondente.

Componenti e politiche

informazioni

Gli asset dello stesso tipo (ad es. due batterie) saranno combinati come un unico componente. Ad esempio, quando vengono installate due batterie da 5 kWh, verrà considerata come una batteria da 10 kWh.

Ogni componente nell'oggetto fields può includere una politica e un punto di impostazione della potenza. I seguenti componenti possono essere controllati:

  • solar_policy e solar_power_setpoint_w:

    • Controlla la politica di generazione di energia solare e il punto di impostazione. Politiche supportate:
      • Politica di punto di impostazione: Imposta la potenza massima prodotta da tutte le installazioni solari collegate combinate. Il campo solar_power_setpoint_w deve essere impostato sul limite di potenza di produzione in watt.
      • Politica di restrizione di immissione: Produce a piena potenza, seguendo i limiti attuali della rete.
      • Politica di costo: Abilita la minimizzazione dei costi in base al prezzo del giorno successivo (mercato EPEX Spot) sulla produzione solare. Quando si verificano prezzi di iniezione negativi, riduciamo la produzione a consumo proprio. Quando sia il prezzo di prelievo che quello di iniezione sono negativi, spegniamo tutte le installazioni solari. Il campo solar_power_setpoint_w viene ignorato.
      • Politica off: Disabilita tutta l'interazione per tutti gli asset solari. Attenzione: i limiti non vengono controllati in questa modalità. Il campo solar_power_setpoint_w viene ignorato.
  • storage_policy e storage_power_setpoint_w:

  • Controlla la politica del sistema di stoccaggio dell'energia e il tasso di scarica o carica dell'energia.

    • Punto di impostazione della politica: Imposta la potenza di carica totale (punto di impostazione positivo) o la potenza di scarica (punto di impostazione negativo) per il gruppo di batterie. Quando più batterie sono collegate, il punto di impostazione viene suddiviso in base alla potenza di carica/scarica disponibile per stressare equamente le batterie. Il campo storage_power_setpoint_w è impostato sulla potenza desiderata della batteria.
    • Costo della politica: Abilita l'ottimizzazione dei costi a giorno (mercato EPEX Spot) per le batterie, caricandola durante le ore economiche e utilizzando l'energia nelle ore costose. Il campo storage_power_setpoint_w viene ignorato.
    • Autoconsumo della politica: Abilita un semplice algoritmo di autoconsumo sulle batterie. L'eccesso di produzione solare viene immagazzinato nella batteria durante il giorno e, quando il sole è assente, l'energia viene prelevata dalla batteria. Il campo storage_power_setpoint_w viene ignorato.
    • Politica disattivata: Disabilita tutte le interazioni per tutti gli asset delle batterie. Attenzione: i limiti non sono protetti in questa modalità. Il campo storage_power_setpoint_w viene ignorato.
  • heat_pump_policy:

    • Attiva/disattiva i sistemi della pompa di calore. I tempi di accensione minimi e massimi saranno sempre rispettati.
      • Costo della politica: Abilita l'ottimizzazione dei costi a giorno (mercato EPEX Spot) per le pompe di calore. L'algoritmo locale di pricing dinamico decide i migliori periodi di accensione.
      • Autoconsumo della politica: Accende le pompe di calore se viene prodotta un'eccedenza di energia solare.
      • Politica spegnimento: Spegne le pompe di calore.
      • Politica accensione: Accende le pompe di calore.
  • switched_load_policy:

    • Attiva/disattiva i sistemi controllati da relè. Questo potrebbe essere il relè integrato o relè connessi in rete.
      • Costo della politica: Abilita l'ottimizzazione dei costi a giorno (mercato EPEX Spot) per il relè.
      • Autoconsumo della politica: Accende il relè se viene prodotta un'eccedenza di energia solare.
      • Politica spegnimento
      • Politica accensione
  • variable_power_load_policy e variable_power_load_power_setpoint_w:

    • Gestisce la politica di consumo di potenza dei veicoli elettrici e il punto di impostazione.
      • Punto di impostazione della politica: Imposta la potenza di carica totale per il gruppo di veicoli elettrici. Il campo variable_power_load_power_setpoint_w è impostato sulla potenza di carica desiderata.
      • Costo della politica: Abilita l'ottimizzazione dei costi a giorno (mercato EPEX Spot) per le batterie, caricandola durante le ore economiche. Il campo variable_power_load_power_setpoint_w viene ignorato.
      • Autoconsumo della politica: Abilita la carica se viene prodotta un'eccedenza di energia solare. Il campo variable_power_load_power_setpoint_w viene ignorato.
      • Politica disattivata: Disabilita tutte le interazioni per tutti gli asset dei veicoli elettrici. Il campo variable_power_load_power_setpoint_w viene ignorato.
  • site_policy e site_power_setpoint_w:

    • Gestisce i limiti di esportazione del sito.
      • Politica di esportazione: Imposta il limite di esportazione per il sito. Il campo site_power_setpoint_w è impostato sul limite di esportazione.
      • Politica predefinita: Ripristina il limite del sito alla potenza di esportazione predefinita, impostata nella configurazione del controller.

Controllo dispositivo

Dispositivi specifici possono essere controllati, anziché gruppi di dispositivi in base ai loro tipi. Il messaggio è strutturato in modo identico:

  • nodeId_policy e nodeId_power_setpoint_w
informazioni

Quando vengono inviati due comandi allo stesso asset (ad esempio un comando specifico per un dispositivo a un inverter solare e un comando a tutti i dispositivi solari), il metodo di controllo specifico del dispositivo avrà priorità sul controllo per tipo di dispositivo.

Comportamento di fallback

Per ciascun componente, se non viene specificato _policy e _power_setpoint_w, il sistema utilizzerà automaticamente la politica di fallback configurata nel SmartgridOne Controller. Ciò garantisce che ogni dispositivo o gruppo di dispositivi operi in sicurezza e continui a funzionare anche se non vengono fornite istruzioni specifiche.

Se non viene inviato alcun comando, dopo 60 secondi (o periodo di timeout configurato), le politiche predefinite per gli asset verranno riattivate.

Annulla comandi esistenti e torna a modalità di controllo locale

Un comando attivo può essere annullato inviando un messaggio di comando di fallback.

Comando di Fallback

Un comando di fallback annullerà immediatamente il comando esistente e il SmartgridOne Controller assumerà il controllo dell'installazione. La politica eseguita dipende da ciò che è impostato nelle impostazioni del SmartgridOne Controller.

Questo può essere utilizzato anche nei casi in cui viene utilizzato un segnale secondario di controllo, come un programma, come fallback.

Esempi di messaggi:

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": "<Unix Timestamp>",
"fields": {
"<Component Policy>": "fallback",
}
}

Comando Vuoto

Un comando vuoto può essere inviato in qualsiasi momento per raccogliere informazioni sul sito. Questo non annullerà il comando corrente e non sovrascriverà i comandi provenienti da segnali di controllo secondari con priorità più basse.

Il comando vuoto è strutturato come segue:

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": "<Unix Timestamp>",
"fields": {}
}

Esempio di payload

Di seguito è riportato un esempio di payload per impostare varie politiche e punti di impostazione:

{
"extraTags": {
"nodeId": "OM12404080000000000_site_0"
},
"time": 1714652046,
"fields": {
"solar_policy": "setpoint",
"solar_power_setpoint_w": 5000,
"storage_policy": "setpoint",
"storage_power_setpoint_w": -5000
}
}

In questo esempio, la potenza solare è impostata per generare fino a 5000 watt, e il sistema di stoccaggio dell'energia è impostato per caricare o scaricare a una velocità di 5000 watt, a seconda del segno del valore del punto di impostazione. Se venissero omessi solar_policy o storage_policy, il rispettivo dispositivo tornerebbe alle impostazioni predefinite determinate dal SmartgridOne Controller.

Documentazione MQTT per Ricevere Feedback

Questa sezione delinea la struttura e il contenuto dei messaggi di feedback inviati dal SmartgridOne Controller tramite MQTT. Questi messaggi vengono pubblicati nel tema standard1/outbound/remoteControlMetrics/feedback/<Controller SN> dopo che un comando è stato elaborato.

Tema di Feedback MQTT

Il tema di feedback MQTT è strutturato come segue:

standard1/outbound/remoteControlMetrics/feedback/<Controller SN>

Dove <Controller SN> deve essere sostituito con il numero di serie del SmartgridOne Controller che invia il feedback.

Struttura del Payload di Feedback MQTT

note

Tutti gli asset sono raggruppati per tipo. Questo significa che due installazioni solari individuali di 3 kW saranno trattate come un asset di 6 kW.

I messaggi di feedback sono formattati come payload JSON. Questi payload forniscono feedback dettagliato sullo stato del sistema dopo aver applicato i comandi di punto di impostazione, considerando i limiti della rete/dispositivo. Di seguito è riportata la struttura del payload di feedback con le descrizioni dei suoi campi:

{
"time": "<Unix Timestamp>",
"data": {
"state": {
"grid": {
"active_power_W": <Potenza Attiva in Watt della Rete>,
"today_imported_energy_Wh": <Energia Importata dalla Rete in Watt-ore>,
"today_exported_energy_Wh": <Energia Esportata dalla Rete in Watt-ore>,
"import_limit_W": <Limite di Importazione della Rete in Watt>,
"export_limit_W": <Limite di Esportazione della Rete in Watt>
},
"vpp_id": "<Identificativo della Centrale Elettrica Virtuale>",
"storage": {
{
"energy_stored_Wh": <Energia immagazzinata in Wattore>,
"energy_capacity_Wh": <Capacità totale di energia in Wattore>,
"mean_soc_perc": <Percentuale media dello stato di carica>,
"active_power_W": <Potenza attiva in Watt>,
"executed_power_W": <Punto impostato di potenza inviato ai dispositivi in Watt>,
"executed_policy": <Politica eseguita dal controllore>,
"max_charge_power_W": <Potenza di carica massima in Watt>,
"max_discharge_power_W": <Potenza di scarica massima in Watt>,
"today_charged_Wh": <Energia caricata oggi in Wattore>,
"today_discharged_Wh": <Energia scaricata oggi in Wattore>,
"nr_devices": <Numero di dispositivi di immagazzinamento controllati installati>
},
"solar": {
"active_power_W": <Potenza attiva solare in Watt>,
"executed_power_W": <Punto impostato di potenza inviato ai dispositivi in Watt>,
"executed_policy": <Politica eseguita dal controllore>,
"capacity_W": <Capacità solare in Watt>,
"today_energy_Wh": <Energia prodotta oggi in Wattore>,
"nr_devices": <Numero di dispositivi solari controllati installati>
},
"heat_pump": {
"executed_policy": <Politica eseguita dal controllore>,
"operation_modes": <Modalità operative della pompa di calore>,
"executed_power_W": <Punto impostato di potenza inviato ai dispositivi in Watt>,
"nr_devices": <Numero di dispositivi di pompa di calore controllati installati>
},
"switched_load": {
"executed_policy": <Politica eseguita dal controllore>,
"devices_on": <Numero di dispositivi accesi>,
"devices_off": <Numero di dispositivi spenti>,
"executed_power_W": <Punto impostato di potenza inviato ai dispositivi in Watt>,
"nr_devices": <Numero di dispositivi di carico commutato controllati installati>
},
"variable_load": {
"executed_policy": <Politica eseguita dal controllore>,
"executed_power_W": <Punto impostato di potenza inviato ai dispositivi in Watt>,
"active_power_W": <Potenza del dispositivo in Watt>,
"ev_requiring_charge": <Il veicolo elettrico richiede carica>,
"currentL1_A": <Corrente del dispositivo sulla fase 1 in Ampere>,
"currentL2_A": <Corrente del dispositivo sulla fase 2 in Ampere>,
"currentL3_A": <Corrente del dispositivo sulla fase 3 in Ampere>,
"executed_current_A": <Punto impostato di corrente inviato ai dispositivi in Ampere>,
"today_charged_Wh": <Energia caricata oggi in Wattore>,
"today_discharged_Wh": <Energia scaricata oggi in Wattore>,
"total_charged_Wh": <Energia totale caricata in Wattore>,
"total_discharged_Wh": <Energia totale scaricata in Wattore>,
"min_charge_current_A": <Corrente di carica minima in Ampere>,
"max_charge_current_A": <Corrente di carica massima in Ampere>,
"allow_zero_current": <Il caricabatterie supporta la pausa>,
}
},
"response_code": <Codice di risposta>
},
"fields": {},
"requestTime": "<Timestamp Unix>",
"time": "<Timestamp Unix>",
"siteNodeId": "<Controller SN>_site_0"
}
- executed_policy (Str): Le politiche che sono state applicate ai controllabili,
- executed_power_W (Float): La somma totale di potenza richiesta dagli asset, inviata dal nostro algoritmo di controllo.
- active_power_W (Float): Rappresenta la potenza attiva attuale sulla rete in watt.
- ev_requiring_charge (Bool): L'EV ha bisogno di carica. (È un'auto connessa).
- currentL1_A (Float): Corrente del dispositivo sulla fase 1 in Ampere.
- currentL2_A (Float): Corrente del dispositivo sulla fase 2 in Ampere.
- currentL3_A (Float): Corrente del dispositivo sulla fase 3 in Ampere.
- executed_current_A (Float): La somma totale della corrente richiesta dagli asset, inviata dal nostro algoritmo di controllo.
- today_charged_Wh (Float): L'energia caricata nell'asset(i) del caricatore EV oggi. Nota: Oggi è indicato nell'ora UTC.
- today_discharged_Wh (Float): L'energia scaricata dall'asset(i) del caricatore EV oggi. Nota: Oggi è indicato nell'ora UTC.
- total_charged_Wh (Float): L'energia totale caricata nell'asset(i) del caricatore EV.
- total_discharged_Wh (Float): L'energia totale scaricata dall'asset(i) del caricatore EV.
- min_charge_current_A (Float): Corrente minima alla quale l'EV può essere caricato.
- max_charge_current_A (Float): Corrente massima alla quale l'EV può essere caricato.
- allow_zero_current (Bool): Il caricatore EV consente la pausa.
- nodeId (Object):
- Se un nodeId è incluso nel comando, il feedback conterrà lo stato corrispondente del dispositivo.
- response_code (Int):
- Indica lo stato dell'operazione. Un response_code di 0 significa tipicamente successo, mentre altri valori possono indicare diversi tipi di errori o informazioni di stato (questi dovrebbero essere dettagliati in un riferimento separato).

### Esempio di Payload di Feedback
Ecco un esempio di un messaggio di feedback a seguito di un comando per impostare vari punti di impostazione della potenza:

<ClickableImage src="/img/generic/mqtt-example-feedback.png" alt="Immagine 1" maxWidth="450px" />

Questo feedback dimostra lo stato operativo attuale del sistema dopo l'esecuzione dei punti di impostazione, indicando gli effetti sulla generazione solare, sull'accumulo e sull'interazione complessiva con la rete.

## Versioni MQTT Supportate e Comportamento su Argomenti Non Autorizzati
Quando si utilizza MQTT, è importante considerare le differenze nelle specifiche tra le versioni 3.1, 3.1.1 e 5.0, in particolare riguardo al comportamento del broker quando i client pubblicano su argomenti non autorizzati.

Secondo la specifica MQTT 3.1.1 (vedi OASIS MQTT 3.1.1 Specification, sezione MQTT-3.3.5-2), un broker deve terminare la connessione non appena un client invia un PUBLISH a un argomento per il quale non ha autorizzazione. Questo comportamento può portare a disconnessioni inaspettate per i client che tentano di pubblicare su argomenti configurati in modo errato o non autorizzati.

Nella versione MQTT 3.1, questo requisito non è presente. Quando un client pubblica su un argomento non autorizzato in questa versione, il broker tipicamente ignora il messaggio (drop silenzioso) senza terminare la connessione. Questo rende MQTT 3.1 in alcuni casi più adatto quando la robustezza contro errori di configurazione o autorizzazioni temporaneamente mancanti è più importante della rigorosa applicazione della sicurezza.

Sebbene MQTT 5.0 introduca la possibilità di lavorare con codici di ragione (come PUBACK con un motivo di rifiuto), ciò richiede supporto sia da parte del client che del server. La migrazione a MQTT 5.0 comporta quindi uno sforzo di implementazione aggiuntivo.

__Consequenze dell'Ignorare la Compatibilità:__
Se un client si collega utilizzando MQTT 3.1.1 e tenta di pubblicare messaggi su argomenti non autorizzati, il broker terminerà bruscamente la sessione. Questo può portare a instabilità, perdita di connettività o aumento del carico a causa di ripetuti tentativi di riconnessione.

__Approccio Raccomandato:__
Per i sistemi in cui i client possono (temporaneamente) tentare di pubblicare su argomenti non autorizzati, o dove la gestione degli errori non è rigorosamente implementata, raccomandiamo di utilizzare MQTT 3.1. Questo garantisce connessioni più stabili e evita disconnessioni indesiderate durante l'esecuzione.