Live MQTT Control

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

Erste Konfiguration (Startpunkt für neue Benutzer)

Ich habe einen SmartgridOne Controller und möchte ihn für die MQTT-Fernsteuerung einrichten.

Baselines werden nicht von allen Controllern unterstützt. Bitte kontaktieren Sie den Support für weitere Informationen.Bevor Sie fortfahren, stellen Sie sicher, dass Ihr Netzwerk und Ihre Geräte bereit sind, indem Sie der Anleitung Wiring Best Practices

Fordern Sie den erforderlichen Eniris-MQTT-Benutzernamen und das Passwort über denEniris-Webshop an, bevor Sie mit der Konfiguration beginnen. Support-Tickets und SmartgridX/Insights sind keine Bereitstellungskanäle für neue MQTT-Anmeldedaten.

1. MQTT-Externsignal hinzufügen

2. MQTT-Fernsignal aktivieren

Das Timeout des Fallback-Mechanismus teilt dem SmartgridOne Controller mit, wie lange auf neue Befehle gewartet werden soll. Wenn der SmartgridOne Controller keine Befehle mehr empfängt, übernimmt er nach Ablauf dieses Timeouts 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-Fernsteuerungsoberfläche wurde nun auf dem SmartgridOne Controller.

Wir können nun anhand eines einfachen Beispiels einige grundlegende Befehle senden. In der Spalte „Status“ sehen Sie, ob ein Befehl aktiv ist.

Python-Demoskript

Ein guter erster Schritt ist, Ihre neu eingerichtete Integration anhand eines einfachen Beispiels zu testen.

Dieser Testcode sendet kontinuierlich die folgenden Befehle:

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

Der SmartgridOne Controller antwortet kontinuierlich mit einer „Feedback“-Nachricht, die die gemessenen Netz- und Anlagenleistungswerte enthält. Diese Funktion ist ebenfalls in diesem Beispiel enthalten.

Laden Sie die untenstehende Datei in Ihre bevorzugte Python-IDE herunter. Tragen Sie Ihre Seriennummer und die über den Eniris-Webshop angeforderten MQTT-Anmeldedaten ein und führen Sie anschließend das Skript aus:

Wenn dies erfolgreich war, können Sie weitere Arten von Befehlen senden. 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 im Netzwerk des SmartgridOne Controllers.

MQTT Topic

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

standard1/rp_one_s/remoteControlMetrics/'controller SN'

Dabei ist „controller SN“ durch die tatsächliche Seriennummer des SmartgridOne Controller zu ersetzen, den Sie steuern möchten.

MQTT Payload Structure

Befehle werden als JSON-Payloads gesendet. Die Payload-Struktur dient dazu, verschiedene Leistungsmanagementrichtlinien und Sollwerte für unterschiedliche Komponenten des Smart-Grid-Systems festzulegen. Die folgenden Beispiele verwenden fiktive Kennungen und beispielhafte Grenzwerte. Ersetzen Sie die Standortknoten-ID, den Zeitstempel und die Werte durch die für Ihre Installation geeigneten Angaben:

{
    "extraTags": {
        "nodeId": "DEMO_CONTROLLER_SiteA"
    },
    "time": 1791547200,
    "fields": {
        "storage_policy": "setpoint",
        "storage_power_setpoint_w": 5000,
        "site_policy": "limit",
        "site_import": 25000
    }
}

Beschreibung der Felder

• extraTags (Object):
  • nodeId (String): Eine eindeutige Kennung für den Knoten im Netzwerk des SmartgridOne Controllers Netzwerk. Verwenden Sie die tatsächliche Standortknoten-ID aus der Installation. Sie kann sich von der Seriennummer gefolgt von '_site_0' unterscheiden; gehen Sie nicht automatisch von diesem Suffix aus.
• time (Integer): Unix-Zeitstempel in Sekunden, der den Zeitpunkt des Nachrichtenversands angibt.
• fields (Object):
  • <Component>_policy (String): Richtlinientyp für die Komponente. Wenn dieser weggelassen wird, kann eine vorherige Gruppenrichtlinie bis zu ihrem ursprünglichen Timeout aktiv bleiben. Verwenden Sie eine explizite fallback-Richtlinie, um die Steuerung abzugeben.
  • <Component>_power_setpoint_w (Float): Gewünschter Leistungssollwert in Watt für die Komponente. Dies 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 für die Solarstromerzeugung. Unterstützte Richtlinien:
    • Policy setpoint: Legt die maximale Leistung fest, die von allen angeschlossenen Solaranlagen zusammen erzeugt wird. Das Feld solar_power_setpoint_w muss 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 anhand von Day-Ahead-Preisen (EPEX-Spotmarkt) für die Solarproduktion. Bei negativen Einspeisepreisen wird die Produktion auf den Eigenverbrauch reduziert. Wenn sowohl der Bezugs- als auch der Einspeisepreis negativ sind, werden alle Solaranlagen abgeschaltet. Das Feld solar_power_setpoint_w wird ignoriert.
    • Policy off: Deaktiviert jegliche Interaktion mit allen 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 die Lade- oder Entladeleistung.
    • Policy setpoint: Legt die Gesamtlad Leistung (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 zur Spitzenlastkappung für die Batterie. Dies muss mit vier Parametern zur Spitzenlastkappung auf Standortebene kombiniert werden.
    • Policy cost: Aktiviert die Kostenoptimierung anhand von Day-Ahead-Preisen (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 Sonneneinstrahlung wird Energie aus der Batterie entnommen. Das Feld storage_power_setpoint_w wird ignoriert.
    • Policy off: Deaktiviert jegliche Interaktion mit allen Batterieanlagen. Warnung: In diesem Modus werden Grenzwerte nicht überwacht. Das Feld storage_power_setpoint_w wird ignoriert.

• heat_pump_policy:

  • Schaltet Wärmepumpensysteme ein bzw. aus. Die minimale und maximale Einschaltdauer wird immer eingehalten.
    • Policy cost: Aktiviert die Kostenoptimierung anhand von Day-Ahead-Preisen (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 bzw. aus. Dabei kann es sich um das integrierte Relais oder um netzwerkverbundene Relais handeln.
    • Policy cost: Aktiviert die Kostenoptimierung anhand von Day-Ahead-Preisen (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 Gesamtlad Leistung 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 anhand von Day-Ahead-Preisen (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 jegliche Interaktion mit allen Elektrofahrzeuganlagen. Das Feld variable_power_load_power_setpoint_w wird ignoriert.

Power Limits

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

Zum Beispiel:

{
    "extraTags": {
        "nodeId": "DEMO_CONTROLLER_SiteA"
    },
    "time": 1791547200,
    "fields": {
        "storage_policy": "limit",
        "storage_maxChargePower_W": 10000,
        "storage_maxDischargePower_W": 10000,
        "solar_policy": "limit",
        "solar_maxProductionPower_W": 15000
    }
}

Das Präfix des Feldes ist storage, solar oder die zutreffende Geräte-Knoten-ID. Fügen Sie beim Senden von Befehlen, die nur Grenzwerte enthalten, wie oben die entsprechende limit-Richtlinie ein. Die Grenzwerte von Befehlen sind nichtnegative Beträge: Beispielsweise storage_maxDischargePower_W: 10000 bedeutet eine Entladegrenze von 10 kW. Dies unterscheidet sich vom Feedback, bei dem max_discharge_power_W negativ oder null ist.

Site Control

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

• defaultoder einfallback Alle aktiven Standortbefehle entfernen
• export Die Einspeisegrenze des Standorts festlegen
• import Die Bezugsgrenze des Standorts festlegen
• setpoint Ein Standortsollwert kann in beide Richtungen um bis zu 5 % abweichen
• setpoint_A Noch nicht implementiert

Die folgenden Variablen sind Parameter zur Spitzenlastkappung und werden nur angewendet, wenn die Batteriestrategie auf Spitzenlastkappung eingestellt ist.

• startChargeBelow_W
• stopChargeAbove_W
• startDischargeAbove_W
• stopDischargeBelow_W

Ein Standortsollwert ist NICHT mit einer Bezugs-/Einspeisegrenze kompatibel.

Zum Beispiel:

{
    "extraTags": {
        "nodeId": "DEMO_CONTROLLER_SiteA"
    },
    "time": 1791547200,
    "fields": {
        "storage_policy": "self-consumption",
        "site_policy": "limit",
        "site_export": 10000,
        "site_import": 25000
    }
}

Device Control

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

• nodeId_policy und nodeId_power_setpoint_w

Fallback-Verhalten

Das Weglassen einer Gruppenrichtlinie führt nicht zu einer sofortigen Aufhebung: Ein zuvor empfangener Gruppenbefehl kann bis zu seinem ursprünglich konfigurierten Timeout aktiv bleiben. Verwenden Sie einen expliziten fallback-Befehl für die Gruppe oder das Gerät, wenn Sie die Fernsteuerung abgeben möchten. Gerätespezifische Befehle werden nicht im selben Cache für Gruppenbefehle beibehalten. Siehe dazu den folgenden Hinweis zum leeren Befehl.

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 auf lokale Steuerungsmodi zurückfallen

Ein aktiver Befehl kann durch Senden einer Fallback-Befehl message.

Fallback Command

Ein Fallback-Befehl cancel den bestehenden Befehl immediately und das SmartgridOne Controller übernimmt die Steuerung der Anlage. Die ausgeführte Richtlinie hängt davon ab, was in den Einstellungen des SmartgridOne Controller Settings.

festgelegt ist. Dies kann auch verwendet werden, wenn ein sekundäres Steuersignal, beispielsweise ein Zeitplan, als Fallback dient.

Nachrichtenbeispiele:

{
    "extraTags": {
        "nodeId": "DEMO_CONTROLLER_SiteA"
    },
    "time": 1791547200,
    "fields": {
        "storage_policy": "fallback"
    }
}

Empty Command

Ein leerer Befehl gibt aggregiertes Standort-Feedback zurück, ist jedoch keine schreibgeschützte Statusabfrage. Er ersetzt die zuletzt empfangene Nachricht und kann frühere gerätespezifische Befehle entfernen. Noch gültige Gruppenrichtlinien können bis zum Ablauf ihres ursprünglichen Fallback-Timeouts wiederverwendet werden. Verwenden Sie dies nicht als Abfrage, wenn die gerätespezifische Steuerung unverändert bleiben soll.

Der leere Befehl ist wie folgt aufgebaut:

{
    "extraTags": {
        "nodeId": "DEMO_CONTROLLER_SiteA"
    },
    "time": 1791547200,
    "fields": {}
}

Beispiel-Payload

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

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

In diesem Beispiel wird die Solarproduktion auf 5000 Watt begrenzt, und der negative Speichersollwert fordert eine Entladung mit 5000 Watt an. Ein positiver Speichersollwert würde das Laden anfordern. Das Weglassen einer Gruppenrichtlinie hebt den vorherigen Befehl nicht unbedingt auf. Verwenden Sie eine explizite fallback-Richtlinie, wenn Sie diese Gruppe wieder der lokalen Steuerung übergeben möchten.

MQTT-Dokumentation zum Empfangen von Feedback

MQTT Feedback Topic

Abonnieren Sie das Feedback-Topic, um den Zustand des Standorts und das Ergebnis eines verarbeiteten Befehls zu lesen:

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

Ersetzen Sie <Controller SN> durch die Seriennummer des Controllers. Die Seriennummer im Topic und die siteNodeId des Standorts sind unterschiedliche Kennungen: Verwenden Sie stets die tatsächliche Standortknoten-ID, die nicht unbedingt mit _site_0.

endet.

Die Standardverbindung für die Live-Steuerung gibt einen Zustands-Snapshot zurück, wenn sie einen Befehl akzeptiert und die Steuerungsverarbeitung auslöst. Dies bestätigt nicht, dass das physische Gerät den neuen Sollwert bereits erreicht hat.

Ein leerer Befehl mit "fields": {} gibt ebenfalls den aggregierten Zustand zurück, ist jedoch keine abfrage ohne Seiteneffekte: Er ersetzt die letzte Nachricht und kann zuvor adressierte gerätespezifische Befehle entfernen. Frühere Gruppenrichtlinien können nur innerhalb ihres ursprünglichen Fallback-Timeouts aktiv bleiben. Verwenden Sie keine leeren Befehle zur Abfrage, wenn die gerätespezifische Steuerung unverändert bleiben soll.

Einige anbieterspezifische MQTT-Verbindungen veröffentlichen außerdem ungefähr alle 30 Sekunden unaufgefordert Feedback. Diese periodische Veröffentlichung ist verbindungsspezifisch und kein garantiertes Intervall für jede MQTT-Integration. Periodische Snapshots und Antworten auf leere Befehle enthalten keinen gerätespezifischen Zustand.

Maschinenlesbare Feedback-Spezifikation

Verwenden Sie das JSON Schema zur Validierung von Feedback-Payloads oder das AsyncAPI-Dokument zur Beschreibung des Feedback-Kanals des Controllers. Beide beschreiben Feedback, nicht die vollständige Befehlsschnittstelle oder anbieterspezifische Erweiterungen.

Nachrichtenhülle

responseCode: 0 beweist nicht, dass jedes Gerät seinen angeforderten Sollwert erreicht hat. Lesen Sie zusätzlich die gemessene Leistung, ausgeführten Sollwerte, Beschriftungen von Begrenzungen und Gerätefehlercodes aus.

Erfolgreiche Antwort

Dieser beispielhafte Snapshot verwendet fiktive Kennungen und bewusst nur eine kleine Auswahl an Messwerten. Weitere verfügbare Felder werden weiter unten beschrieben.

{
  "time": 1791547201,
  "requestTime": 1791547200,
  "siteNodeId": "DEMO_CONTROLLER_SiteA",
  "fields": {},
  "data": {
    "responseCode": 0,
    "errors": "",
    "state": {
      "load": { "load_power_W": 12000 },
      "grid": { "active_power_W": 7000, "import_limit_W": 25000 },
      "storage": {
        "active_power_W": -5000,
        "mean_soc_perc": 60,
        "max_charge_power_W": 10000,
        "max_discharge_power_W": -10000,
        "dynamic_max_charge_power_W": 8000,
        "dynamic_max_discharge_power_W": -9000,
        "executed_power_W": -5000,
        "executed_policy": ["setpoint"],
        "errorCodes": {},
        "nr_devices": 1
      }
    }
  }
}

Fehlerantwort

Versuchen Sie bei einem Verarbeitungsfehler nicht, data.state:

{
  "time": 1791547201,
  "requestTime": 1791547200,
  "siteNodeId": "DEMO_CONTROLLER_SiteA",
  "fields": {},
  "data": {
    "responseCode": 1,
    "error": "Command could not be processed"
  }
}

Aggregierten Zustand lesen

Die Abschnittsnamen sind grid, load, storage, solar, heat_pump, switched_load und variable_power_load. Jeder Asset-Abschnitt fasst Geräte dieses Typs zusammen. Zwei Solargeräte mit jeweils 3 kW Kapazität ergeben beispielsweise eine aggregierte Kapazität von 6 kW.

solar und storage kann ein leeres Objekt ({}) sein, wenn keine passenden Geräte vorhanden sind. Die Abschnitte für Wärmepumpen, geschaltete Lasten und variable Leistungslasten behalten in diesem Fall null Zähler, leere Arrays/Maps und zutreffende Leistungswerte mit dem Wert null bei.

Behandeln Sie ein fehlendes Feld oder null des WattsNext-Gehäuses ein.nicht verfügbar und nicht als null. Viele Messwerte werden bei unbekanntem Zustand weggelassen; einige Felder enthalten ausdrücklich null. Eine Summe kann nur die Geräte enthalten, für die ein Wert verfügbar ist. Leiten Sie nicht allein aus nr_devices auf eine vollständige Messwertabdeckung.

Die folgenden gemeinsamen Felder gelten für storage, solar, heat_pump, switched_load und variable_power_load:

3. Kommunikation überprüfen

Jeder Messwert und jeder Grenzwert in state.grid ist optional und wird bei unbekanntem Zustand weggelassen. Werte sind Zahlen; Leistung wird in Watt, Energie in Wattstunden und Strom in Ampere angegeben.

Standortlast

state.load.load_power_W ist eine Zahl oder null. Sie gibt den sonstigen Verbrauch des Standorts an, ohne separat erfassten EV-Lade- und Wärmepumpenverbrauch. Sie ist weder der Gesamtverbrauch des Standorts noch eine andere Bezeichnung für die Netzleistung.

Speicher

Verwenden Sie dynamic_max_charge_power_W und dynamic_max_discharge_power_W für das aktuelle Feedbackformat. Sie ersetzen die früheren Felder realised_charge_power_W und realised_discharge_power_W. Die dynamische Fähigkeit ist eine Schätzung und keine Garantie dafür, dass jeder angeforderte Sollwert ausgeführt werden kann; Standort- und Geräteeinschränkungen gelten weiterhin.

Solar

Diese numerischen Felder werden weggelassen, wenn sie nicht verfügbar sind:

Wärmepumpen

Geschaltete Lasten

EV-Ladegeräte und Verbraucher mit variabler Leistung

Der Abschnitt heißt variable_power_load, nicht variable_load.

Zähler für geladene Energie, Stromgrenzwerte, Unterstützung des Pausierens und Ladevorgänge gehören zu einzelnen Geräten, nicht zu diesem aggregierten Abschnitt.

Gerätespezifisches Feedback

Damit der Status eines Geräts enthalten ist, muss der Befehl sein <nodeId>_policy Feld enthalten und ein erkanntes Gerät adressieren. Ein gerätespezifischer Sollwert allein fordert kein Feedback für einzelne Geräte an. Weder ein leerer Befehl noch ein periodischer Snapshot enthält dieses Feedback.

Der Speicherort ist:

data.state.<section>.individual_devices.<nodeId>

Beispielsweise kann ein Befehl, der sowohl "DEMO_BATTERY_1_policy": "setpoint" und "DEMO_BATTERY_1_power_setpoint_w": -5000 enthält, dieses Fragment unter data.state.storage:

{
  "executed_policy": ["setpoint"],
  "errorCodes": {},
  "nr_devices": 1,
  "individual_devices": {
    "DEMO_BATTERY_1": {
      "active_power_W": -5000,
      "executed_power_W": -5000,
      "executed_policy": "setpoint",
      "constraint_ph0_label": null,
      "nr_devices": 1
    }
  }
}

Richtlinien-, Betriebsart- und Einschränkungsfelder pro Gerät sind Einzelwerte, keine aggregierten Listen. Unbekannte Messwerte können null sein. Das errorCodes des Geräts ist ein Array von Fehler-/Statuseinträgen und wird nur aufgenommen, wenn das Gerät Einträge meldet; es handelt sich nicht um eine weitere Node-ID-Zuordnung.

Individuelle EV-Felder

Ein ausgefülltes Objekt eines Ladevorgangs enthält:

Separate VPP-Verbindungen

vpp_id gehört zu einer separat konfigurierten VPP-Verbindung. Fügen Sie es nicht zur gewöhnlichen Live-MQTT-Konfiguration oder zu Befehlen hinzu; der standardmäßige Feedbackstatus erfordert es nicht. Anbieterspezifische Erweiterungen dürfen nicht als Teil der allgemeinen Live-Steuerungsschnittstelle behandelt werden.

Storage Constraint Labels

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 dasconstraint_ph0_label Feedback-Feld.

MQTT Error Codes

Fehlercodes werden 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 hinsichtlich des Verhaltens 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 normalerweise (Silent Drop), ohne die Verbindung zu beenden. Dadurch eignet sich MQTT 3.1 in manchen Fällen besser, wenn Robustheit gegenüber Konfigurationsfehlern oder vorübergehend fehlenden Berechtigungen wichtiger ist als eine strikte Durchsetzung der Sicherheitsvorgaben.

MQTT 5.0 ermöglicht zwar die Verwendung von Reason Codes (z. B. PUBACK mit einem Ablehnungsgrund), dies setzt jedoch Unterstützung sowohl auf Client- als auch auf Serverseite voraus. Eine Migration auf MQTT 5.0 erfordert daher zusätzlichen Implementierungsaufwand.

Folgen der Nichtbeachtung der Kompatibilität: Wenn sich ein Client mit MQTT 3.1.1 verbindet 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 Verbindungsaufbauversuche führen.

Recommended Approach: 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.