Zum Hauptinhalt springen

Geplante MQTT-Steuerung

tipp

Die geplante MQTT-Steuerung ist für geplante Nachrichten im Voraus gedacht. Für die Live-Steuerung siehe stattdessen Live MQTT Control.

Dieser Leitfaden hilft Ihnen, MQTT auf Ihrem SmartgridOne Controller zu konfigurieren, um Batterie- und Solarpanel-Installationen aus der Ferne zu steuern und zu überwachen.

Was Sie benötigen

  1. SmartgridOne Controller mit Internetverbindung.
  2. MQTT-Zugangsdaten: Diese können angefordert werden, indem Sie eine E-Mail an support@eniris.be senden.
  3. Python-Entwicklungsumgebung (oder einen anderen MQTT-Client). Dieser Leitfaden verwendet ein einfaches Beispiel, das in Python geschrieben ist, um Ihnen den Einstieg mit MQTT und das Senden von Befehlen zu erleichtern. Wir empfehlen die Verwendung von Python wegen der Benutzerfreundlichkeit, aber jeder andere MQTT-Client wird unterstützt.

Zusätzliche Informationen

MQTT ist ein schnelles Kommunikationsprotokoll über das Internet. Es handelt sich um ein Publish/Subscribe-Nachrichtensystem, das eine direkte Verbindung zwischen Ihrer Maschine und dem SmartgridOne Controller ermöglicht. Ihre Anlagen werden in Gruppen für Solar, Batterie, EV und HVAC klassifiziert. Momentan erlaubt diese Integration eine Steuerung pro Gruppe, nicht pro Gerät.

Ersteinrichtung (Ausgangspunkt für neue Benutzer)

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

1. Überprüfen Sie Ihr Netzwerk

Stellen Sie sicher, dass Ihr Netzwerk den MQTT-Datenverkehr über Port 1883 erlaubt. Sie können dies mit dem folgenden Befehl tun:

nc -zv mqtt.eniris.be 1883

Wenn dieser Befehl nicht verfügbar ist, können Sie alternativ diesen Python-Code herunterladen und ausführen.

Wenn Sie Zweifel haben, konsultieren Sie Ihren Netzwerkadministrator oder verwenden Sie vorübergehend den 4G/5G-Hotspot Ihres Telefons, wenn Verbindungsfehler auftreten.

hinweis

Wenn Port 1883 von Ihrem Netzwerk aus nicht zugänglich ist, bieten wir einen Backup an Port 80 an. Dies kann in Ihrem MQTT-Client in einem späteren Schritt dieses Handbuchs konfiguriert werden.

2. Fügen Sie Ihre Geräte hinzu

Loggen Sie sich in die Inbetriebnahme-Schnittstelle ein und stellen Sie sicher, dass die Geräte hinzugefügt werden zu dem SmartgridOne Controller.

3. Fügen Sie das MQTT-Außensignal hinzu

Bild 1
Bild 1
Bild 1

4. Aktivieren Sie das MQTT-Fernsignal

Wählen Sie alle Geräte aus, die Sie in die MQTT-Fernsteuerung einbeziehen möchten.

Bild 1

5. Fernsignal wurde hinzugefügt

Die MQTT-Fernsteuerungsoberfläche wurde nun auf dem SmartgridOne Controller aktiviert.

Wir sind nun bereit, einige grundlegende Befehle mit einem einfachen Beispiel zu senden. Die Statusspalte zeigt Ihnen an, ob ein Befehl aktiv ist.

Python-Demo-Skript

Ein guter Ausgangspunkt wäre es, Ihre neu eingerichtete Integration mit einem einfachen Beispiel zu testen.

Dieser Testcode führt die einfache Aufgabe aus, kontinuierlich den folgenden Zeitplan zu senden:

  • Batterie: Aufladen mit 5 kW für 15 Minuten in 10 Minuten
  • Solar: Leistung auf 0 kW für eine Stunde in 30 Minuten

Der SmartgridOne Controller antwortet mit einer Bestätigungsnachricht, die die eindeutige Zeitplan-ID enthält, oder mit einer Fehlermeldung.

Anschließend holen wir den nächsten Zeitplan für beide Gerätetypen ab und bestätigen, dass der Befehl erfolgreich war.

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

Wenn das oben Genannte erfolgreich war, können Sie mit dem Senden anderer Arten von Nachrichten fortfahren. Alle Nachrichten sind unten beschrieben.

MQTT-Dokumentation zum Senden von Befehlen

Dieser Abschnitt beschreibt das MQTT-Nachrichtenformat und die Anforderungen an die Nutzlast für die Einrichtung der geplanten Steuerung von Geräten im Netzwerk des SmartgridOne Controller.

MQTT-Themen

  • Subscribe-Thema: standard1/rp_one_s/remoteScheduleMetrics/<controller SN>
  • Feedback-Thema: standard1/outbound/remoteScheduleMetrics/feedback/<controller SN>

Wobei <controller SN> durch die tatsächliche Seriennummer des SmartgridOne Controller ersetzt werden sollte, den Sie steuern möchten.

MQTT-Nachrichtentypen

1. Zeitplan festlegen (set_schedule)

Erstellt einen neuen Zeitplan für einen Gerätetyp.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix-Timestamp>,
"message_type": "set_schedule",
"fields": {
"device_type": "<Gerätetyp>",
"node_id": "<Knoten-ID>" (Optional),
"start_time": <Unix-Timestamp>,
"end_time": <Unix-Timestamp>,
"policy": "<Richtlinie>",
"power_setpoint_w": <Sollwert in Watt>,
"remove_overlap": <True/False> (Optional) (default=False),
"tag": <Tag-String> (Optional) (default=None)
}
}

Antwort (Erfolg):

{
"requestTime": <Unix-Timestamp>,
"time": <Unix-Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "set_schedule_ack",
"state": {
"schedule_id": <Zeitplan-ID>,
"deleted_ids": <Gelöschte Zeitplan-IDs, wenn remove_overlap=True>,
"tag": <Tag-String> (default=None)
},
"responseCode": 0
}
}

2. Zeitpläne festlegen (set_schedules)

Erstellt mehrere neue Zeitpläne.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix-Timestamp>,
"message_type": "set_schedules",
"fields":
"0": {
"device_type": "<Gerätetyp>",
"node_id": "<Knoten-ID>" (Optional),
"start_time": <Unix-Timestamp>,
"end_time": <Unix-Timestamp>,
"policy": "<Richtlinie>",
"power_setpoint_w": <Sollwert in Watt>,
"remove_overlap": <True/False> (Optional) (default=False)
},
"1": {
"device_type": "<Gerätetyp>",
"node_id": "<Knoten-ID>" (Optional),
"start_time": <Unix-Timestamp>,
"end_time": <Unix-Timestamp>,
"policy": "<Richtlinie>",
"power_setpoint_w": <Sollwert in Watt>,
"remove_overlap": <True/False> (Optional) (default=False)
},
...
}

Antwort (Erfolg):

{
"requestTime": <Unix-Timestamp>,
"time": <Unix-Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "set_schedules_ack",
"state": {
"schedule_ids": <Zeitplan-IDs>,
"deleted_ids": <Gelöschte Zeitplan-IDs, wenn remove_overlap=True>
},
"responseCode": 0
}
}

3. Zeitplan abrufen (get_schedule)

Ruft einen bestimmten Zeitplan anhand der ID ab.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix-Timestamp>,
"message_type": "get_schedule",
"fields": {
"id": <Zeitplan-ID>
}
}

Antwort:

{
"requestTime": <Unix-Timestamp>,
"time": <Unix-Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_schedule_ack",
"state": <Zeitplan>,
"responseCode": 0
}
}

4. Aktiven Zeitplan abrufen (get_active_schedule)

Ruft den derzeit aktiven Zeitplan für einen Gerätetyp ab.

{
"extraTags": {
```json
{
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_active_schedule",
"fields": {
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Optional),
}
}

Response (Erfolg):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_active_schedule_ack",
"state": <Schedule>,
"responseCode": 0
}
}

5. Nächsten Zeitplan abrufen (get_next_schedule)

Ruft den nächsten anstehenden Zeitplan für einen Gerätetyp ab.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_next_schedule",
"fields": {
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Optional),
}
}

Response (Erfolg):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_next_schedule_ack",
"state": <Schedule>,
"responseCode": 0
}
}

6. Zeitpläne abrufen (get_schedules)

Ruft alle Zeitpläne für ein bestimmtes Datum ab.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_schedules",
"fields": {
"date": "<Date String of Format dd/mm/yyyy>"
}
}

Response (Erfolg):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_schedules_ack",
"state": {
"schedules": [<Schedule>, ...]
},
"responseCode": 0
}
}

7. Zukünftige Zeitpläne abrufen (get_future_schedules)

Ruft alle zukünftigen Zeitpläne ab.

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

Response (Erfolg):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_future_schedules_ack",
"state": {
"schedules": [<Schedule>, ...]
},
"responseCode": 0
}
}

8. Zeitplan entfernen (remove_schedule)

Entfernt einen bestimmten Zeitplan anhand der ID.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "remove_schedule",
"fields": {
"id": <Schedule ID>
}
}

Response (Erfolg):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "remove_schedule_ack",
"state": "Zeitplan <Schedule ID> erfolgreich entfernt",
"responseCode": 0
}
}

9. Standort-Feedback abrufen (get_feedback)

Ruft detailliertes Feedback zum Zustand des Systems ab.

{
"extraTags": {
"nodeId": "<Controller SN>_site_0"
},
"time": <Unix Timestamp>,
"message_type": "get_feedback",
"fields": {
"device": <Device (node) level>
}
}

Response (Erfolg):

Feedback-Payload-Struktur

10. Standorttopologie (get_toplogy)

Erhält die Topologie des Standorts.

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

Response (Erfolg):

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "get_topology_ack",
"state": {
"nodeId": <nodeId>,
"nodeType": <nodeType>,
"children": [{<ChildObject>}]
},
"responseCode": 0
}
}

Standard-Zeitplan-Antwortformat

{
"id": <Schedule ID>,
"device_type": "<Device Type>",
"node_id": "<Node ID>" (Optional),
"start_time": <Unix Timestamp>,
"end_time": <Unix Timestamp>,
"policy": "<Schedule Policy>",
"power_setpoint_w": <Setpoint in watts>,
"created_at": <Unix Timestamp>
}

Komponententypen und -richtlinien

Für Details zu verfügbaren Komponenten und Richtlinien, die geplant werden können, beziehen Sie sich auf den Abschnitt MQTT-Komponenten und -richtlinien in der Live-MQTT-Steuerungsdokumentation.

Gerätespezifische Zeitpläne können unter Verwendung des optionalen Feldes node_id gesendet werden, das sich auf die Node-ID des steuerbaren Geräts bezieht.

Fehlerbehandlung

Alle Nachrichten können eine Fehlermeldung mit responseCode: 1 zurückgeben, wenn ein Fehler auftritt:

{
"requestTime": <Unix Timestamp>,
"time": <Unix Timestamp>,
"siteNodeId": "<Controller SN>_site_0",
"data": {
"message_type": "<Message Type>_ack",
"error": <Error Body>,
"responseCode": 1
}
}

Wenn ein nicht verwandter Fehler auftritt, wird der Nachrichtentyp (general_error) sein.

Häufige Fehler umfassen:

  • Überschneidung von Zeitplänen mit bestehenden Zeitplänen
  • Ungültiger Zeitraum
  • Gerätetyp nicht gefunden
  • Zeitplan-ID nicht gefunden
  • Ungültige Richtlinie für den Gerätetyp

Regeln zum Zeitplanmanagement

  1. Überschneidungsregeln
    • Zeitpläne dürfen sich für denselben Gerätetyp nicht überschneiden
    • Zeitpläne dürfen sich für dasselbe Gerät nicht überschneiden
    • Zeitpläne für dasselbe Gerät und denselben Gerätetyp dürfen sich nicht überschneiden
    • Bestehende, sich überschneidende Zeitpläne werden gelöscht, wenn die Variable remove_overlap beim Erstellen eines neuen Zeitplans auf True gesetzt ist.
  2. Jeder Zeitplan muss haben:
    • Einen gültigen Gerätetyp
    • Eine Startzeit (Unix-Zeitstempel)
    • Eine Endzeit (Unix-Zeitstempel)
    • Eine Richtlinie (die den verfügbaren Richtlinien des Gerätetyps entspricht)
    • Einen Leistungszielwert (für Richtlinien, die ihn erfordern)
  3. Die Startzeit muss vor der Endzeit liegen
  4. Wenn die Startzeit in der Vergangenheit liegt, wird sie automatisch auf "jetzt starten" geändert
  5. Zeitpläne können nur gelöscht werden, wenn sie noch nicht begonnen haben. Aktive Zeitpläne können nicht gelöscht werden.
  6. Zeitpläne können unabhängig für verschiedene Gerätetypen festgelegt werden
  7. Das System wendet automatisch die passende Richtlinie an, wenn ein Zeitplan aktiv wird