Live-MQTT-Steuerung

Diese Anleitung hilft Ihnen bei der Konfiguration von MQTT auf Ihrem SmartgridOne Controller, um Batterie- und Solaranlagen aus der Ferne zu steuern und zu überwachen.

Ersteinrichtung (Ausgangspunkt für neue Benutzer)

Ich habe einen SmartgridOne Controller, den ich für die MQTT-Fernsteuerung einrichten möchte.

Bevor Sie fortfahren, stellen Sie sicher, dass Ihr Netzwerk und Ihre Geräte bereit sind, indem Sie der Anleitung MQTT-Einrichtung folgen.

1. MQTT-Externesignal hinzufügen

2. MQTT-Fernsignal aktivieren

Das Timeout des Fallback-Mechanismus teilt dem SmartgridOne Controller mit, wie lange es auf neue Befehle warten soll. Wenn das SmartgridOne Controller keine Befehle mehr empfängt, übernimmt es nach diesem Timeout automatisch die Standardstrategie.

Wählen Sie anschließend alle Geräte aus, die Sie in die MQTT-Fernsteuerung aufnehmen möchten.

3. Fernsignal hinzugefügt

Die MQTT-Fernsteuerungsschnittstelle wurde nun auf dem SmartgridOne Controller aktiviert.

Wir können nun mithilfe eines einfachen Beispiels einige grundlegende Befehle senden. Die Spalte „Status“ zeigt an, ob ein Befehl aktiv ist.

Python-Demonstrationsskript

Ein guter erster Schritt ist, Ihre neu eingerichtete Integration mit einem einfachen Beispiel zu testen.

Dieser Testcode sendet kontinuierlich die folgenden Befehle:

• Batterie: Mit 5 kW laden
• Solar: Leistung auf 0 kW setzen

Das SmartgridOne Controller antwortet kontinuierlich mit einer „Feedback“-Nachricht, die die beobachteten Leistungswerte von Netz und Anlagen enthält. Diese Funktion ist ebenfalls in diesem Beispiel enthalten.

Bitte laden Sie die untenstehende Datei in Ihrer bevorzugten Python-IDE herunter. Tragen Sie Ihre Seriennummer und MQTT-Zugangsdaten ein und führen Sie das Skript aus:

Wenn dies erfolgreich funktioniert, können Sie mit dem Senden anderer Befehlstypen fortfahren. Alle Befehle sind in unserer Dokumentation zur MQTT-Fernsteuerung beschrieben.

MQTT-Dokumentation zum Senden von Befehlen

Dieser Abschnitt beschreibt das MQTT-Nachrichtenformat und die Payload-Anforderungen für die Fernsteuerung von Leistungsrichtlinien auf Geräten innerhalb des Netzwerks des SmartgridOne Controller.

MQTT-Topic

Das zum Senden von Befehlen verwendete MQTT-Topic ist wie folgt strukturiert:

standard1/rp_one_s/remoteControlMetrics/'controller SN'

Dabei sollte „controller SN“ durch die tatsächliche Seriennummer des SmartgridOne Controller ersetzt werden, das Sie steuern möchten.

MQTT-Payload-Struktur

Befehle werden als JSON-Payloads gesendet. Die Payload-Struktur dient dazu, verschiedene Energiemanagementrichtlinien und Sollwerte für unterschiedliche Komponenten des Smart-Grid-Systems festzulegen. Nachfolgend finden Sie den Aufbau der Payload mit detaillierten Feldbeschreibungen:

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

Felderbeschreibung

• extraTags (Object):
  • nodeId (String): Eine eindeutige Kennung für den Knoten innerhalb des Netzwerks des SmartgridOne Controller. Sie entspricht bei den meisten SmartgridOne Controller Ihrer Seriennummer, gefolgt von „_site_0“.
• time (Integer): Unix-Zeitstempel in Sekunden, der den Zeitpunkt des Sendens der Nachricht angibt.
• fields (Object):
  • <Component>_policy (String): Richtlinientyp für die Komponente. Das Feld ist optional. Wenn es nicht angegeben wird, verwendet das System die Standardeinstellung des SmartgridOne Controller.
  • <Component>_power_setpoint_w (Float): Gewünschter Leistungssollwert der Komponente in Watt. Dieses Feld ist optional und nur relevant, wenn eine entsprechende Richtlinie angegeben ist.

Komponenten und Richtlinien

Jede Komponente im fields-Objekt kann eine Richtlinie und einen Leistungssollwert enthalten. Die folgenden Komponenten können gesteuert werden:

• solar_policy und solar_power_setpoint_w:

  • Steuert die Richtlinie und den Sollwert der Solarstromerzeugung. Unterstützte Richtlinien:
    • Policy setpoint: Legt die maximale Leistung fest, die von allen verbundenen Solaranlagen zusammen erzeugt wird. Das Feld solar_power_setpoint_w sollte auf die Produktionsleistungsgrenze in Watt gesetzt werden.
    • Policy feed-in-restriction: Erzeugt die volle Leistung unter Einhaltung der aktuellen Netzgrenzen.
    • Policy cost: Aktiviert die Kostenminimierung auf Basis der Day-Ahead-Preise (EPEX-Spotmarkt) für die Solarproduktion. Bei negativen Einspeisepreisen drosseln wir die Produktion auf den Eigenverbrauch. Wenn sowohl der Bezugs- als auch der Einspeisepreis negativ sind, schalten wir alle Solaranlagen aus. Das Feld solar_power_setpoint_w wird ignoriert.
    • Policy off: Deaktiviert sämtliche Interaktionen für alle Solaranlagen. Warnung: In diesem Modus werden Grenzwerte nicht überwacht. Das Feld solar_power_setpoint_w wird ignoriert.

• storage_policy und storage_power_setpoint_w:

  • Steuert die Richtlinie des Energiespeichersystems sowie dessen Lade- oder Entladeleistung.
    • Policy setpoint: Legt die gesamte Ladeleistung (positiver Sollwert) oder Entladeleistung (negativer Sollwert) für die Batteriegruppe fest. Bei mehreren angeschlossenen Batterien wird der Sollwert entsprechend der verfügbaren Lade-/Entladeleistung aufgeteilt, um die Batterien gleichmäßig zu belasten. Das Feld storage_power_setpoint_w wird auf die gewünschte Batterieleistung gesetzt.
    • Policy peak-shaving-only: Aktiviert die Optimierung des Peak-Shavings für die Batterie. Dies muss mit vier Peak-Shaving-Parametern auf Standortebene kombiniert werden.
    • Policy cost: Aktiviert die Kostenoptimierung auf Basis der Day-Ahead-Preise (EPEX-Spotmarkt) für die Batterien, indem sie in günstigen Stunden geladen und in teuren Stunden genutzt werden. Das Feld storage_power_setpoint_w wird ignoriert.
    • Policy self-consumption: Aktiviert einen einfachen Eigenverbrauchsalgorithmus für die Batterien. Überschüssige Solarproduktion wird tagsüber in der Batterie gespeichert; bei fehlender Sonne wird Energie aus der Batterie entnommen. Das Feld storage_power_setpoint_w wird ignoriert.
    • Policy off: Deaktiviert sämtliche Interaktionen für alle Batterieanlagen. Warnung: In diesem Modus werden Grenzwerte nicht überwacht. Das Feld storage_power_setpoint_w wird ignoriert.

• heat_pump_policy:

  • Schaltet Wärmepumpensysteme ein oder aus. Die minimale und maximale Einschaltdauer wird immer eingehalten.
    • Policy cost: Aktiviert die Kostenoptimierung auf Basis der Day-Ahead-Preise (EPEX-Spotmarkt) für die Wärmepumpen. Der lokale Algorithmus für dynamische Preise bestimmt die besten Einschaltzeiträume.
    • Policy self-consumption: Schaltet die Wärmepumpen ein, wenn überschüssige Solarenergie erzeugt wird.
    • Policy power_off: Schaltet die Wärmepumpen aus.
    • Policy power_on: Schaltet die Wärmepumpen ein.

• switched_load_policy:

  • Schaltet relaisgesteuerte Systeme ein oder aus. Dabei kann es sich um das integrierte Relais oder um netzwerkverbundene Relais handeln.
    • Policy cost: Aktiviert die Kostenoptimierung auf Basis der Day-Ahead-Preise (EPEX-Spotmarkt) für das Relais.
    • Policy self-consumption: Schaltet das Relais ein, wenn überschüssige Solarenergie erzeugt wird.
    • Policy power_off
    • Policy power_on

• variable_power_load_policy und variable_power_load_power_setpoint_w:

  • Verwaltet die Richtlinie und den Sollwert für den Stromverbrauch von Elektrofahrzeugen.
    • Policy setpoint: Legt die gesamte Ladeleistung für die Gruppe der Elektrofahrzeuge fest. Das Feld variable_power_load_power_setpoint_w wird auf die gewünschte Ladeleistung gesetzt.
    • Policy cost: Aktiviert die Kostenoptimierung auf Basis der Day-Ahead-Preise (EPEX-Spotmarkt) für die Batterien, indem sie in günstigen Stunden geladen werden. Das Feld variable_power_load_power_setpoint_w wird ignoriert.
    • Policy self-consumption: Aktiviert das Laden, wenn überschüssige Solarenergie erzeugt wird. Das Feld variable_power_load_power_setpoint_w wird ignoriert.
    • Policy off: Deaktiviert sämtliche Interaktionen für alle Elektrofahrzeuganlagen. Das Feld variable_power_load_power_setpoint_w wird ignoriert.

Leistungsgrenzen

Anstatt Steuerungsstrategien und Sollwerte festzulegen, können für Speicher- und Solargeräte auch Leistungsgrenzen eingestellt werden.

Zum Beispiel:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "{prefix}_maxChargePower_W": <Max Charge Power W>,
        "{prefix}_maxDischargePower_W": <Max Discharge Power W>,
        "{prefix}_maxProductionPower_W": <Max Production Power W>,
    }
}

Dabei ist prefix entweder storage, solar oder die zutreffende Geräte-nodeID.

Standortsteuerung

Der Standort kann separat gesteuert werden. Die folgenden Standortbefehle können an den Controller gesendet werden:

• default oder fallback Entfernt alle aktiven Standortbefehle
• export Legt die Exportgrenze des Standorts fest
• import Legt die Importgrenze des Standorts fest
• setpoint Ein Standort-Sollwert kann in beide Richtungen um bis zu 5 % variieren
• setpoint_A Noch nicht implementiert

Die folgenden Variablen sind Peak-Shaving-Parameter und werden nur angewendet, wenn die Batteriestrategie auf Peak-Shaving eingestellt ist.

• startChargeBelow_W
• stopChargeAbove_W
• startDischargeAbove_W
• stopDischargeBelow_W

Ein Standort-Sollwert ist NICHT mit einer Import-/Exportgrenze kompatibel.

Zum Beispiel:

{
    "extraTags": {
        "nodeId": "<Controller SN>_site_0"
    },
    "time": "<Unix Timestamp>",
    "fields": {
        "<Component Policy>": "<Policy Type>",
        "<Component Power Setpoint>": <Setpoint in watts>,
        "site_export": <Export Limit W>,
        "site_import": <Import Limit W>,
        "site_setpoint": <Setpoint W>,
        "site_startChargeBelow_W": <Value_W>
    }
}

Gerätesteuerung

Anstelle von Gerätegruppen nach Typ können auch bestimmte Geräte gesteuert werden. Die Nachricht ist identisch strukturiert:

• nodeId_policy und nodeId_power_setpoint_w

Fallback-Verhalten

Wenn für eine Komponente _policy und _power_setpoint_w nicht angegeben sind, verwendet das System automatisch die im SmartgridOne Controller konfigurierte Fallback-Richtlinie. Dadurch wird sichergestellt, dass jedes Gerät bzw. jede Gerätegruppe sicher arbeitet und auch ohne spezifische Anweisungen weiterhin funktioniert.

Wenn überhaupt kein Befehl gesendet wird, werden nach 60 Sekunden (oder nach dem konfigurierten Timeout) die Standardrichtlinien für die Anlagen wieder aktiviert.

Bestehende Befehle abbrechen und zu lokalen Steuerungsmodi zurückkehren

Ein aktiver Befehl kann durch Senden einer Nachricht mit einem Fallback-Befehl abgebrochen werden.

Fallback-Befehl

Ein Fallback-Befehl bricht den bestehenden Befehl sofort ab, und das SmartgridOne Controller übernimmt die Steuerung der Anlage. Die ausgeführte Richtlinie hängt von den Einstellungen des SmartgridOne Controller ab.

Dies kann auch verwendet werden, wenn ein sekundäres Steuersignal, beispielsweise ein Zeitplan, als Fallback eingesetzt wird.

Nachrichtenbeispiele:

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

Leerer Befehl

Ein leerer Befehl kann jederzeit gesendet werden, um Standortinformationen abzurufen. Dadurch wird der aktuelle Befehl nicht abgebrochen.

Der leere Befehl ist wie folgt strukturiert:

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

Beispiel-Payload

Nachfolgend sehen Sie ein Beispiel für eine Payload zum Festlegen verschiedener Richtlinien und Sollwerte:

{
    "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 diesem Beispiel wird die Solarleistung so eingestellt, dass bis zu 5000 Watt erzeugt werden, und das Energiespeichersystem wird abhängig vom Vorzeichen des Sollwerts auf eine Lade- oder Entladerate von 5000 Watt eingestellt. Wenn solar_policy oder storage_policy nicht angegeben würden, würde das jeweilige Gerät zu den vom SmartgridOne Controller bestimmten Standardeinstellungen zurückkehren.

MQTT-Dokumentation zum Empfangen von Feedback

Dieser Abschnitt beschreibt die Struktur und den Inhalt der vom SmartgridOne Controller über MQTT gesendeten Feedback-Nachrichten. Diese Nachrichten werden nach der Verarbeitung eines Befehls an das Topic standard1/outbound/remoteControlMetrics/feedback/<Controller SN> veröffentlicht.

MQTT-Feedback-Topic

Das MQTT-Feedback-Topic ist wie folgt strukturiert:

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

Dabei sollte <Controller SN> durch die Seriennummer des SmartgridOne Controller ersetzt werden, das das Feedback sendet.

MQTT-Feedback-Payload-Struktur

Feedback-Nachrichten werden als JSON-Payloads formatiert. Diese Payloads liefern detailliertes Feedback zum Systemstatus nach Anwendung der Sollwertbefehle unter Berücksichtigung von Netz- und Gerätebeschränkungen. Nachfolgend finden Sie die Struktur der Feedback-Payload mit Beschreibungen ihrer Felder:

{
    "time": "<Unix Timestamp>",
    "data": {
        "state": {
            "grid": {
                "active_power_W": <Grid Active Power in Watts>,
                "today_imported_energy_Wh": <Grid Imported Energy in Watt-hours>,
                "today_exported_energy_Wh": <Grid Exported Energy in Watt-hours>,
                "import_limit_W": <Grid Import Limit in Watts>,
                "export_limit_W": <Grid Export Limit in Watts>,
            },
            "storage": {
                "energy_stored_Wh": <Energy Stored in Watt-hours>,
                "energy_capacity_Wh": <Total Energy Capacity in Watt-hours>,
                "mean_soc_perc": <Mean State of Charge Percentage>,
                "active_power_W": <Active Power in Watts>,
                "executed_power_W": <Power Setpoint Sent to Devices in Watts>,
                "executed_policy": <Policy Executed by the Controller>,
                "max_charge_power_W": <Maximum Charge Power in Watts>,
                "max_discharge_power_W": <Maximum Discharge Power in Watts>,
                "today_charged_Wh": <Energy Charged Today in Watt-hours>,
                "today_discharged_Wh": <Energy Discharged Today in Watt-hours>,
                "realised_charge_power_W": <Adapted maximum charge power>,
                "realised_discharge_power_W": <Adapted maximum discharge power>,
                "constraint_ph0_label": <Constraint reason for limiting power setpoint>,
                "errorCodes": <Error status messages per device>,
                "nr_devices": <Number of Controlled Storage Devices Installed>
            },
            "solar": {
                "active_power_W": <Solar Active Power in Watts>,
                "executed_power_W": <Power Setpoint Sent to Devices in Watts>,
                "executed_policy": <Policy Executed by the Controller>,
                "capacity_W": <Solar Capacity in Watts>,
                "today_energy_Wh": <Energy Produced Today in Watt-hours>,
                "constraint_ph0_label": <Constraint reason for limiting power setpoint>,
                "errorCodes": <Error status messages per device>,
                "nr_devices": <Number of Controlled Solar Devices Installed>
            },
            "heat_pump": {
                "executed_policy": <Policy Executed by the Controller>,
                "operation_modes": <Heatpump Operation Modes>,
                "executed_power_W": <Power Setpoint Sent to Devices in Watts>,
                "constraint_ph0_label": <Constraint reason for limiting power setpoint>,
                "errorCodes": <Error status messages per device>,
                "nr_devices": <Number of Controlled Heat Pump Devices Installed>
            },
            "switched_load": {
                "executed_policy": <Policy Executed by the Controller>,
                "devices_on": <Number of Devices On>,
                "devices_off": <Number of Devices Off>,
                "executed_power_W": <Power Setpoint Sent to Devices in Watts>,
                "constraint_ph0_label": <Constraint reason for limiting power setpoint>,
                "errorCodes": <Error status messages per device>,
                "nr_devices": <Number of Controlled Switched Load Devices Installed>  
            },
            "variable_load": {
                "active_power_W": <Power of the device in Watts>,
                "ev_charging": <How many EVs are currently charging>,
                "ev_not_charging": <How many EVs are currently unconnected>,
                "executed_policy": <Policy Executed by the Controller>,
                "executed_power_W": <Power Setpoint Sent to Devices in Watts>,
                "ev_requiring_charge": <Does the EV require charge>,
                "currentL1_A": <Current of the device on phase 1 in Ampere>,
                "currentL2_A": <Current of the device on phase 2 in Ampere>,
                "currentL3_A": <Current of the device on phase 3 in Ampere>,
                "executed_current_A": <Current Setpoint Sent to Devices in Ampere>,
                "today_charged_Wh": <Energy Charged Today in Watt-hours>,
                "today_discharged_Wh": <Energy Discharged Today in Watt-hours>,
                "total_charged_Wh": <Total Energy Charged in Watt-hours>,
                "total_discharged_Wh": <Total Energy Discharged in Watt-hours>,
                "min_charge_current_A": <Minimum Charge in Ampere>,
                "max_charge_current_A": <Maximum Charge in Ampere>,
                "allow_zero_current": <Does the Charger Support Pausing>,
                "current_charging_session": {
                    "pluginTime": <The session start time>,
                    "endTime": <The session end time>,
                    "firstChargingStartTime": <The time when the vehicle first charged>,
                    "isFull": <Is the vehicle fully charged or not>,
                    "chargedEnergy_Ws": <How much energy has been charged this session>,
                    "usedPhases": <The list of phases used during charging>,
                    "historicMaxChargeCurrent_A": <The maximum current at which the vehicle was charged during the session>
                },
                "previous_charging_session": {
                    "pluginTime": <The session start time>,
                    "endTime": <The session end time>,
                    "firstChargingStartTime": <The time when the vehicle first charged>,
                    "isFull": <Is the vehicle fully charged or not>,
                    "chargedEnergy_Ws": <How much energy has been charged this session>,
                    "usedPhases": <The list of phases used during charging>,
                    "historicMaxChargeCurrent_A": <The maximum current at which the vehicle was charged during the session>
                },
                "constraint_ph0_label": <Constraint reason for limiting power setpoint>,
                "errorCodes": <Error status messages per device>,
                "nr_devices": <Number of Variable Power  Load Devices Installed>  
            }
        },
        "error": {
            <Errors occured during driver execution>
        }
        "response_code": <Response Code>
    },
    "fields": {},
    "requestTime": "<Unix Timestamp>",
    "time": "<Unix Timestamp>",
    "siteNodeId": "<Controller SN>_site_0"
}

Felderbeschreibung

• time (Integer): Unix-Zeitstempel, der den Zeitpunkt des Sendens der Feedback-Nachricht angibt.
• requestTime (Integer): Unix-Zeitstempel, der den Zeitpunkt des Sendens der ursprünglichen Steuerungsnachricht angibt.
• siteNodeId (String): Die nodeId des Standorts, der das Feedback sendet.
• fields (Object): Leeres Objekt
• data (Object):
  • state (Object):
    • vpp_id (String): Kennung des diesem Gerät zugeordneten virtuellen Kraftwerks.
    • grid (Object):
      • active_power_W (Float): Aktuelle Wirkleistung im Netz in Watt.
      • today_imported_energy_Wh (Float): Heute aus dem Netz bezogene Gesamtenergie in Wattstunden. Hinweis: „Heute“ wird in UTC angegeben.
      • today_exported_energy_Wh (Float): Heute ins Netz eingespeiste Gesamtenergie in Wattstunden. Hinweis: „Heute“ wird in UTC angegeben.
      • import_limit_W (Float): Importgrenze des Netzes in Watt,
      • export_limit_W (Float): Exportgrenze des Netzes in Watt,
    • storage (Object):
      • energy_stored_Wh (Float): Aktuell gespeicherte Energiemenge in Wattstunden.
      • energy_capacity_Wh (Float): Gesamte Energiekapazität des Speichersystems in Wattstunden.
      • mean_soc_perc (Float): Ladezustand in Prozent. Dies ist der gewichtete Durchschnitt aller angeschlossenen Batterien.
      • active_power_W (Float): Aktuelle Wirkleistung des Speichersystems in Watt, einschließlich Lade- oder Entladeleistung.
      • max_charge_power_W (Float): Maximale Leistung, mit der der Speicher geladen werden kann.
      • max_discharge_power_W (Float): Maximale Leistung, mit der der Speicher entladen werden kann.
      • executed_power_W (Float): Summe der von den Speicheranlagen angeforderten Lade-/Entladeleistung, die von unserem Steuerungsalgorithmus ausgegeben wird. Nur relevant, wenn die Richtlinie „follow_setpoint“ aktiv ist.
      • executed_policy (Str): Auf die steuerbaren Geräte angewendete Richtlinie.
      • today_charged_Wh (Float): Heute in die steuerbaren Batterieanlagen geladene Gesamtenergie. Hinweis: „Heute“ wird in UTC angegeben.
      • today_discharged_Wh (Float): Heute aus den steuerbaren Batterieanlagen entladene Gesamtenergie. Hinweis: „Heute“ wird in UTC angegeben.
      • realised_charge_power_W (Float): Angepasste maximale Ladeleistung, berechnet aus den Geräterückmeldungen,
      • realised_discharge_power_W (Float): Angepasste maximale Entladeleistung, berechnet aus den Geräterückmeldungen,
      • constraint_ph0_label (List[string]): Gründe, aus denen die externen Sollwerte begrenzt wurden.
      • errorCodes (Dict[str, Dict]): Von den Geräten empfangene Fehlercodes.
      • nr_devices (Int): Anzahl der steuerbaren Batterieanlagen.
    • solar (Object):
      • active_power_W (Float): Aktuelle von Solarmodulen erzeugte Wirkleistung in Watt.
      • capacity_W (Float): Gesamtkapazität des Solarerzeugungssystems in Watt.
      • executed_power_W (Float): Summe der von den Solaranlagen angeforderten Leistung, die von unserem Steuerungsalgorithmus ausgegeben wird. Nur relevant, wenn die Richtlinie „follow_setpoint“ aktiv ist.
      • executed_policy (Str): Auf die steuerbaren Geräte angewendete Richtlinie.
      • today_energy_Wh (Float): Heute von den steuerbaren Solaranlagen erzeugte Gesamtenergie. Hinweis: „Heute“ wird in UTC angegeben.
      • constraint_ph0_label (List[string]): Gründe, aus denen die externen Sollwerte begrenzt wurden.
      • errorCodes (Dict[str, Dict]): Von den Geräten empfangene Fehlercodes.
      • nr_devices (Int): Anzahl der steuerbaren Solaranlagen.
    • heat_pump (Object):
      • executed_policy (Str): Auf die steuerbaren Geräte angewendete Richtlinie.
      • operation_modes (Str): Betriebsmodus der Wärmepumpe (Sperrmodus, Boost-Modus, Selbststeuerungsmodus)
      • executed_power_W (Float): Erwartete aktuell verwendete Leistung.
      • errorCodes (Dict[str, Dict]): Von den Geräten empfangene Fehlercodes.
      • constraint_ph0_label (List[string]): Gründe, aus denen die externen Sollwerte begrenzt wurden.
      • nr_devices (Int): Anzahl der steuerbaren Wärmepumpen.
    • switched_load (Object):
      • executed_policy (Str): Auf die steuerbaren Geräte angewendete Richtlinie.
      • devices_on (Int): Anzahl eingeschalteter Geräte.
      • devices_off (Int): Anzahl ausgeschalteter Geräte.
      • executed_power_W (Float): Aktuell verwendete Leistung (falls verfügbar).
      • constraint_ph0_label (List[string]): Gründe, aus denen die externen Sollwerte begrenzt wurden.
      • errorCodes (Dict[str, Dict]): Von den Geräten empfangene Fehlercodes.
      • nr_devices (Int): Anzahl der steuerbaren ein-/ausschaltbaren Lasten.
    • variable_load (Object):
      • active_power_W (Float): Aktuelle Wirkleistung im Netz in Watt.
      • ev_charging (Int): Anzahl der aktuell verbundenen und ladenden Elektrofahrzeuge.
      • ev_not_charging (Int): Anzahl der nicht verbundenen Elektrofahrzeuge.
      • executed_policy (Str): Auf die steuerbaren Geräte angewendete Richtlinie,
      • executed_power_W (Float): Summe der von den Anlagen angeforderten Leistung, die von unserem Steuerungsalgorithmus ausgegeben wird.
      • ev_requiring_charge (Bool): Gibt an, ob das Elektrofahrzeug geladen werden muss (ob ein Fahrzeug verbunden ist).
      • currentL1_A (Float): Strom des Geräts auf Phase 1 in Ampere.
      • currentL2_A (Float): Strom des Geräts auf Phase 2 in Ampere.
      • currentL3_A (Float): Strom des Geräts auf Phase 3 in Ampere.
      • executed_current_A (Float): Summe des von den Anlagen angeforderten Stroms, die von unserem Steuerungsalgorithmus ausgegeben wird.
      • today_charged_Wh (Float): Heute in die Ladeanlagen für Elektrofahrzeuge geladene Energie. Hinweis: „Heute“ wird in UTC angegeben.
      • today_discharged_Wh (Float): Heute aus den Ladeanlagen für Elektrofahrzeuge entladene Energie. Hinweis: „Heute“ wird in UTC angegeben.
      • total_charged_Wh (Float): Insgesamt in die Ladeanlagen für Elektrofahrzeuge geladene Energie.
      • total_discharged_Wh (Float): Insgesamt aus den Ladeanlagen für Elektrofahrzeuge entladene Energie.
      • min_charge_current_A (Float): Mindeststrom, mit dem das Elektrofahrzeug geladen werden kann.
      • max_charge_current_A (Float): Maximalstrom, mit dem das Elektrofahrzeug geladen werden kann.
      • allow_zero_current (Bool): Gibt an, ob das Ladegerät das Pausieren unterstützt.
      • current_charging_sessions (Dict):
        • pluginTime (Date): Startzeit der Sitzung.
        • endTime (Date): Endzeit der Sitzung.
        • firstChargingStartTime (Date): Zeitpunkt, zu dem das Fahrzeug erstmals geladen wurde.
        • isFull (Bool): Gibt an, ob das Fahrzeug vollständig geladen ist.
        • chargedEnergy_Ws (Float): In dieser Sitzung geladene Energiemenge.
        • usedPhases (List[str]): Während des Ladens verwendete Phasen.
        • historicMaxChargeCurrent_A (float): Maximalstrom, mit dem das Fahrzeug während der Sitzung geladen wurde.
      • constraint_ph0_label (List[string]): Gründe, aus denen die externen Sollwerte begrenzt wurden.
      • errorCodes (Dict[str, Dict]): Von den Geräten empfangene Fehlercodes.
      • nr_devices (Int): Anzahl der steuerbaren ein-/ausschaltbaren Lasten.
    • nodeId (Object):
      • Wenn eine nodeId im Befehl enthalten ist, enthält das Feedback den entsprechenden Gerätestatus.
  • response_code (Int):
    • Gibt den Status des Vorgangs an. Ein response_code von 0 bedeutet normalerweise Erfolg; andere Werte können verschiedene Fehlerarten oder Statusinformationen anzeigen (diese sollten in einer separaten Referenz beschrieben werden).

Bezeichnungen für Speicherbeschränkungen

Die von einem externen Signal gesendeten Sollwerte können intern durch das EMS begrenzt werden. Die folgende Tabelle gibt einen Überblick über mögliche Beschränkungen für das Feedback-Feld constraint_ph0_label.

MQTT-Fehlercodes

Fehlercodes sind in Bereiche gruppiert, die die allgemeine Kategorie des Problems angeben:

Die einzelnen Fehlercodes sind unten aufgeführt.

Verbindungsfehler (200)

Verbindungsprobleme zwischen dem EMS und dem Gerät.

Antwortfehler (300)

Das Gerät ist verbunden, aber seine Antworten sind ungültig.

Steuerungsfehler (600)

Mess- und Sollwertfehler (1000)

Unterstützte MQTT-Versionen und Verhalten bei nicht autorisierten Topics

Bei der Verwendung von MQTT ist es wichtig, die Unterschiede in den Spezifikationen der Versionen 3.1, 3.1.1 und 5.0 zu berücksichtigen, insbesondere im Hinblick auf das Verhalten des Brokers, wenn Clients auf nicht autorisierten Topics veröffentlichen.

Gemäß der MQTT-3.1.1-Spezifikation (siehe OASIS MQTT 3.1.1 Specification, Abschnitt MQTT-3.3.5-2) muss ein Broker die Verbindung beenden, sobald ein Client eine PUBLISH-Nachricht an ein Topic sendet, für das er keine Berechtigung besitzt. Dieses Verhalten kann zu unerwarteten Verbindungsabbrüchen bei Clients führen, die versuchen, auf falsch konfigurierte oder nicht autorisierte Topics zu veröffentlichen.

In MQTT 3.1 ist diese Anforderung nicht enthalten. Wenn ein Client unter dieser Version auf ein nicht autorisiertes Topic veröffentlicht, ignoriert der Broker die Nachricht typischerweise (stilles Verwerfen), ohne die Verbindung zu beenden. Dadurch ist MQTT 3.1 in manchen Fällen besser geeignet, wenn Robustheit gegenüber Konfigurationsfehlern oder vorübergehend fehlenden Berechtigungen wichtiger ist als eine strikte Durchsetzung der Sicherheit.

Obwohl MQTT 5.0 die Möglichkeit einführt, mit Reason Codes zu arbeiten (z. B. PUBACK mit einem Ablehnungsgrund), erfordert dies Unterstützung sowohl auf Client- als auch auf Serverseite. Eine Migration zu MQTT 5.0 ist daher mit zusätzlichem Implementierungsaufwand verbunden.

Folgen der Nichtbeachtung der Kompatibilität: Wenn ein Client eine Verbindung mit MQTT 3.1.1 herstellt und versucht, Nachrichten an nicht autorisierte Topics zu veröffentlichen, beendet der Broker die Sitzung abrupt. Dies kann zu Instabilität, Verbindungsverlust oder einer erhöhten Auslastung durch wiederholte Verbindungsversuche führen.

Empfohlener Ansatz: Für Systeme, in denen Clients möglicherweise (vorübergehend) versuchen, auf nicht autorisierte Topics zu veröffentlichen, oder in denen die Fehlerbehandlung nicht strikt implementiert ist, empfehlen wir die Verwendung von MQTT 3.1. Dies gewährleistet stabilere Verbindungen und verhindert unbeabsichtigte Verbindungsabbrüche während des Betriebs.