Controllo MQTT in tempo reale

suggerimento

Il controllo MQTT live è destinato al controllo in tempo reale. Per inviare programmmi in anticipo, vedere Controllo MQTT Programmato invece.

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

Cosa ti serve

1. Sofar EMS con connettività internet.
2. Credenziali MQTT: Questo può essere richiesto inviando un’email a support@eniris.be.
3. Ambiente di sviluppo Python (o qualsiasi altro client MQTT). Questa guida utilizza un esempio di base scritto in Python per aiutarti a iniziare con MQTT e l’invio di comandi. Raccomandiamo di utilizzare Python per la semplicità d’uso, ma è supportato qualsiasi altro client MQTT.

Informazioni aggiuntive

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 Sofar EMS. I tuoi asset sono classificati in gruppi di pannelli solari, batterie, veicoli elettrici e HVAC.

Configurazione iniziale (Punto di partenza per i nuovi utenti)

Ho un Sofar EMS 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.

In caso di 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 in un passaggio successivo di questo manuale.

2. Aggiungi i tuoi dispositivi

Accedi all’interfaccia di commissioning e assicurati che i dispositivi siano aggiunti al Sofar EMS.

3. Aggiungi il segnale esterno MQTT

4. Abilita il segnale remoto MQTT

Il campo 'VPP ID' deve rimanere vuoto.

Il timeout del meccanismo di fallback indica al Sofar EMS quanto tempo deve aspettare per nuovi comandi. Quando il Sofar EMS smette di ricevere comandi, riprende automaticamente la strategia predefinita dopo questo timeout.

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

5. Il segnale remoto è stato aggiunto

L'interfaccia di Controllo Remoto MQTT è stata attivata sul Sofar EMS.

Siamo ora pronti a inviare alcuni comandi di base utilizzando un semplice esempio. La colonna Status indica se qualche comando è attivo.

Script demo Python

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

Questo codice di test esegue un semplice lavoro di invio continuo dei seguenti comandi:

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

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

Si prega di scaricare il file qui sotto 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 dei messaggi MQTT e i requisiti del payload per il controllo remoto delle politiche di potenza sui dispositivi all'interno della rete del Sofar EMS.

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 effettivo del Sofar EMS che intendi controllare.

Struttura del Payload MQTT

I comandi vengono 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 rete intelligente. Ecco il profilo 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 dispositivo (ad esempio batterie + solare) possono essere controllati contemporaneamente.

• extraTags (Oggetto):
  • nodeId (Stringa): Un identificatore unico per il nodo all'interno della rete del Sofar EMS. Questo è uguale al tuo numero di serie, seguito da '_site_0' per la maggior parte dei dispositivi Sofar EMS.
• 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. È facoltativo e se non specificato, il sistema si ritornerà all’impostazione predefinita del Sofar EMS.
  • <Component>_power_setpoint_w (Float): Punto di impostazione di potenza desiderato in watt per il componente. Questo è facoltativo e rilevante solo se viene specificata una politica corrispondente.

Componenti e politiche

informazioni

Gli asset dello stesso tipo (ad esempio due batterie) saranno combinati come un componente unico. Ad esempio, quando due batterie da 5 kWh sono installate, verranno trattate come una batteria da 10 kWh.

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

• solar_policy e solar_power_setpoint_w:

  • Controlla la politica di produzione di potenza 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 al limite di potenza di produzione in watt.
    • Politica di restrizione di immissione: Produci a piena potenza, seguendo i limiti attuali della rete.
    • Politica di costo: Abilita la minimizzazione dei costi dei prezzi giorno prima (mercato EPEX Spot) sulla produzione solare. Quando si verificano prezzi di iniezione negativi, limitiamo la produzione al proprio consumo. Quando sia il prezzo di approvvigionamento che quello di iniezione sono negativi, spegniamo tutte le installazioni solari. Il campo solar_power_setpoint_w è ignorato.
    • Politica di spegnimento: Disabilita tutte le interazioni per tutti gli asset solari. Attenzione: i limiti non vengono protetti in questa modalità. Il campo solar_power_setpoint_w è ignorato.

• storage_policy e storage_power_setpoint_w:

• Controlla la politica del sistema di accumulo energetico e il tasso di scarica o carica di potenza.

  • Punto di setpoint della politica: Imposta la potenza totale di carica (punto di setpoint positivo) o potenza di scarica (punto di setpoint negativo) per il gruppo di batterie. Quando più batterie sono collegate, il setpoint viene suddiviso dalla potenza di carica/scarica disponibile per stressare equamente le batterie. Il campo storage_power_setpoint_w è impostato sulla potenza della batteria desiderata.
  • Costo della politica: Abilita l'ottimizzazione dei costi della tariffa del giorno prima (mercato EPEX Spot) sulle batterie, caricandole nelle ore a basso costo e utilizzando l'energia nelle ore costose. Il campo storage_power_setpoint_w viene ignorato.
  • Politica di autoconsumo: Abilita un semplice algoritmo di autoconsumo sulle batterie. La produzione solare in eccesso viene immagazzinata nella batteria durante il giorno, e quando il sole tramonta, l'energia viene prelevata dalla batteria. Il campo storage_power_setpoint_w viene ignorato.
  • Politica off: 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 di pompe di calore. I tempi minimi e massimi di attivazione saranno sempre rispettati.
    • Costo della politica: Abilita l'ottimizzazione dei costi della tariffa del giorno prima (mercato EPEX Spot) sulle pompe di calore. L'algoritmo di tariffazione dinamica locale decide i migliori periodi di attivazione.
    • Autoconsumo della politica: Accende le pompe di calore se viene prodotta un'eccesso di energia solare.
    • Politica power_off: Spegne le pompe di calore.
    • Politica power_on: Accende le pompe di calore.

• switched_load_policy:

  • Attiva/disattiva i sistemi controllati da relè. Questo potrebbe essere il relè integrato o relè connessi alla rete.
    • Costo della politica: Abilita l'ottimizzazione dei costi della tariffa del giorno prima (mercato EPEX Spot) sul relè.
    • Autoconsumo della politica: Accende il relè se viene prodotta un'eccesso di energia solare.
    • Politica power_off
    • Politica power_on

• variable_power_load_policy e variable_power_load_power_setpoint_w:

  • Gestisce la politica di consumo di potenza dei veicoli elettrici e il setpoint.
    • Punto di setpoint della politica: Imposta la potenza totale di carica 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 della tariffa del giorno prima (mercato EPEX Spot) sulle batterie, caricandole nelle ore a basso costo. Il campo variable_power_load_power_setpoint_w viene ignorato.
    • Autoconsumo della politica: Abilita la carica se viene prodotta un'eccesso di energia solare. Il campo variable_power_load_power_setpoint_w viene ignorato.
    • Politica off: 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 anche essere controllati, invece di gruppi di dispositivi basati sui loro tipi. Il messaggio ha la stessa struttura:

• nodeId_policy e nodeId_power_setpoint_w

informazioni

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

Comportamento di fallback

Per ciascun componente, se il _policy e _power_setpoint_w non sono specificati, il sistema utilizzerà automaticamente la politica di fallback configurata in Sofar EMS. Ciò assicura che ogni dispositivo o gruppo di dispositivi operi in modo sicuro e continui a funzionare anche se non vengono forniti istruzioni specifiche.

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

Esempio di payload

Di seguito un esempio di payload per impostare varie politiche e setpoint:

{
    "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 accumulo energetico è impostato per caricare o scaricare a una velocità di 5000 watt, a seconda del segno del valore del setpoint. Se sia solar_policy che storage_policy fossero omessi, il rispettivo dispositivo tornerebbe alle impostazioni predefinite determinate da Sofar EMS.

Documentazione MQTT per la Ricezione di Feedback

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

Topic di Feedback MQTT

Il topic di feedback MQTT è strutturato come segue:

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

Dove <Controller SN> deve essere sostituito con il numero di serie del Sofar EMS che sta inviando il feedback.

Struttura del Payload di Feedback MQTT

note

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

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

{
    "time": "<Unix Timestamp>",
    "data": {
        "state": {
            "grid": {
                "active_power_W": <Potenza Attiva della Rete in Watt>,
                "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": "<Identificatore della Centrale Elettrica Virtuale>",
            "storage": {
                "energy_stored_Wh": <Energia Immagazzinata in Watt-ore>,
                "energy_capacity_Wh": <Capacità Totale di Energia in Watt-ore>,
                "mean_soc_perc": <Media della Percentuale di Stato di Carica>,
                "active_power_W": <Potenza Attiva in Watt>,
                "executed_power_W": <Potenza di Setpoint Inviata ai Dispositivi in Watt>,
                "executed_policy": <Politica Eseguita dal Controller>,
                "max_charge_power_W": <Potenza Massima di Carica in Watt>,
                "max_discharge_power_W": <Potenza Massima di Scarica in Watt>,
                "today_charged_Wh": <Energia Caricata nel Giorno Corrente in Watt-ore>,
                "today_discharged_Wh": <Energia Scaricata nel Giorno Corrente in Watt-ore>,
                "nr_devices": <Numero di Dispositivi di Accumulo Controllati Installati>
            },
            "solar": {
                "active_power_W": <Potenza Attiva Solare in Watt>,
                "executed_power_W": <Potenza di Setpoint Inviata ai Dispositivi in Watt>,
                "executed_policy": <Politica Eseguita dal Controller>,
                "capacity_W": <Capacità Solare in Watt>,
                "today_energy_Wh": <Energia Prodotta Oggi in Watt-ora>.
                "nr_devices": <Numero di Dispositivi Solari Controllati Installati>
            },
            "heat_pump": {
                "executed_policy": <Politica Eseguita dal Controllore>,
                "operation_modes": <Modalità di Funzionamento della Pompa di Calore>,
                "executed_power_W": <Punto di Impostazione della Potenza Inviato ai Dispositivi in Watt>,
                "nr_devices": <Numero di Dispositivi della 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 di Impostazione della Potenza Inviato ai Dispositivi in Watt>,
                "nr_devices": <Numero di Dispositivi di Carico Commutato Controllati Installati>  
            }
        },
        "response_code": <Codice di Risposta>
    },
    "fields": {},
    "requestTime": "<Timestamp Unix>",
    "time": "<Timestamp Unix>",
    "siteNodeId": "<Controller SN>_site_0"
}
Se un client si connette 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 carico aumentato 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 è implementata in modo rigoroso, raccomandiamo di utilizzare MQTT 3.1. Questo assicura connessioni più stabili ed evita disconnessioni involontarie durante il runtime.