SmartgridOne logo
SmartgridOne logo
AppController
Externe Signale
DSO

AgrolaAutarcoAxpoBEE EnergyCKWCompanion EnergyDexterDiagnosetestsDNO Relay ControlDynamic Energy TradingEdmijElia
Elindus
Energie-Flexibilitätslösungen (EFS)EnervalisEngieEPEX Spot SolarEuropean CommoditiesFleco PowerFlowerFrank EnergieFuseboxGreenchoiceHallostroomHive PowerImbyIntegration gemäß Paragraph 14aKratTrade
Mqtt
BaselinesFCRGeplante MQTT-SteuerungLive-MQTT-SteuerungMQTT-EinrichtungOnboarding-AblaufVirtuelles Kraftwerk
Neue IntegrationenNext EnergyOpinumPlan-ahead-APIPleeviPowernautRepoweredScholt
Trevion
Überwachung
VGT EnergyvZEV – EnergiegemeinschaftYuso – BatteriesteuerungYuso – Solardrosselung
Fehlerbehebung
Geräte
Installation
Konfiguration von A bis Z
Kundenspezifisch
LizenzNetzwerkRichtlinien für Verdrahtung und KonnektivitätSchnellstartSicherheits-, Wartungs- und rechtliche HinweiseSpezifikationenStatus-LEDsSteuerungsreaktionszeit
Toolbox
VideotutorialsZertifikate
Zubehör
Externe SignaleMqtt

Geplante MQTT-Steuerung

Tipp
Tipp

Die geplante MQTT-Steuerung ist für im Voraus geplante Nachrichten vorgesehen. Für die Live-Steuerung siehe stattdessen 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.

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

Image 1
Image 1
Image 1

2. MQTT-Fernsignal aktivieren

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

Image 1

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 fortlaufend den folgenden Zeitplan:

  • Batterie: In 10 Minuten 15 Minuten lang mit 5 kW laden
  • Solar: In 30 Minuten die Leistung für eine Stunde auf 0 kW setzen

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

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

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 war, können Sie mit dem Senden anderer Nachrichtentypen fortfahren. Alle Nachrichten werden unten beschrieben.

MQTT-Dokumentation zum Senden von Befehlen

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

MQTT-Themen

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

Dabei sollte <controller SN> durch die tatsächliche Seriennummer des SmartgridOne Controller ersetzt werden, 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": "<Device Type>",
        "node_id": "<Node ID>" (Optional),
        "start_time": <Unix Timestamp>,
        "end_time": <Unix Timestamp>,
        "policy": "<Policy>",
        "power_setpoint_w": <Setpoint in watts>,
        "site_import": <Site Import in Watts>,
        "site_export": <Site Export in Watts>,
        "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": <Schedule ID>,
            "deleted_ids": <Schedulde IDs deleted if 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": "<Device Type>",
            "node_id": "<Node ID>" (Optional),
            "start_time": <Unix Timestamp>,
            "end_time": <Unix Timestamp>,
            "policy": "<Policy>",
            "power_setpoint_w": <Setpoint in watts>,
            "site_import": <Site Import in Watts>,
            "site_export": <Site Export in Watts>,
            "remove_overlap": <True/False> (Optional) (default=False),
        }",
        "1": "{
            "device_type": "<Device Type>",
            "node_id": "<Node ID>" (Optional),
            "start_time": <Unix Timestamp>,
            "end_time": <Unix Timestamp>,
            "policy": "<Policy>",
            "power_setpoint_w": <Setpoint in watts>,
            "site_import": <Site Import in Watts>,
            "site_export": <Site Export in Watts>,
            "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": <Schedule IDs>,
            "deleted_ids": <Schedulde IDs deleted if remove_overlap=True>
        },
        "responseCode": 0
    }
}

3. Zeitplan abrufen (get_schedule)

Ruft einen bestimmten Zeitplan anhand seiner ID ab.

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

Antwort:

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

4. Aktiven Zeitplan abrufen (get_active_schedule)

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

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

Antwort (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),
    }
}

Antwort (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>"
    }
}

Antwort (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": {}
}

Antwort (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 seiner ID.

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

Antwort (Erfolg):

{
    "requestTime": <Unix Timestamp>,
    "time": <Unix Timestamp>,
    "siteNodeId": "<Controller SN>_site_0",
    "data": {
        "message_type": "remove_schedule_ack",
        "state": "Schedule <Schedule ID> removed successfully",
        "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>
    }
}

Antwort (Erfolg):

Struktur der Feedback-Payload

10. Standorttopologie (get_toplogy)

Ruft die Topologie des Standorts ab.

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

Antwort (Erfolg):

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

Standardformat der Zeitplanantwort

{
    "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

Details zu den verfügbaren Komponenten und Richtlinien, für die Zeitpläne erstellt werden können, finden Sie im Abschnitt MQTT-Komponenten und -Richtlinien der Dokumentation zur Live-MQTT-Steuerung.

Gerätespezifische Zeitpläne können über das optionale Feld node_id gesendet werden, das auf die Knoten-ID des steuerbaren Geräts verweist.

Fehlerbehandlung

Alle Nachrichten können bei Auftreten eines Fehlers eine Fehlerantwort mit responseCode: 1 zurückgeben:

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

Wenn ein unabhängiger Fehler auftritt, lautet der Nachrichtentyp (general_error).

Häufige Fehler sind:

  • Zeitplan überschneidet sich mit vorhandenen Zeitplänen
  • Ungültiger Zeitbereich
  • Gerätetyp nicht gefunden
  • Zeitplan-ID nicht gefunden
  • Ungültige Richtlinie für den Gerätetyp

Regeln für die Zeitplanverwaltung

  1. Regeln für Überschneidungen
    • 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
    • Vorhandene, 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 Folgendes enthalten:
    • Einen gültigen Gerätetyp
    • Eine Startzeit (Unix-Zeitstempel)
    • Eine Endzeit (Unix-Zeitstempel)
    • Eine Richtlinie (entsprechend den verfügbaren Richtlinien des Gerätetyps)
    • Einen Leistungssollwert (für Richtlinien, die diesen erfordern)
  3. Die Startzeit muss vor der Endzeit liegen
  4. Wenn die Startzeit in der Vergangenheit liegt, wird sie automatisch auf den aktuellen Zeitpunkt geändert
  5. Zeitpläne können nur gelöscht werden, wenn sie noch nicht gestartet wurden. Aktive Zeitpläne können nicht gelöscht werden.
  6. Zeitpläne können unabhängig voneinander für verschiedene Gerätetypen festgelegt werden
  7. Das System wendet automatisch die entsprechende Richtlinie an, sobald ein Zeitplan aktiv wird
Last updated August 7, 2026Edit this page

FCR

Previous Page

Live-MQTT-Steuerung

Next Page

On this page

Geplante MQTT-SteuerungErsteinrichtung (Ausgangspunkt für neue Benutzer)1. MQTT-Externesignal hinzufügen2. MQTT-Fernsignal aktivieren3. Fernsignal hinzugefügtPython-DemonstrationsskriptMQTT-Dokumentation zum Senden von BefehlenMQTT-ThemenMQTT-Nachrichtentypen1. Zeitplan festlegen (set_schedule)2. Zeitpläne festlegen (set_schedules)3. Zeitplan abrufen (get_schedule)4. Aktiven Zeitplan abrufen (get_active_schedule)5. Nächsten Zeitplan abrufen (get_next_schedule)6. Zeitpläne abrufen (get_schedules)7. Zukünftige Zeitpläne abrufen (get_future_schedules)8. Zeitplan entfernen (remove_schedule)9. Standort-Feedback abrufen (get_feedback)10. Standorttopologie (get_toplogy)Standardformat der ZeitplanantwortKomponententypen und RichtlinienFehlerbehandlungRegeln für die Zeitplanverwaltung