Mein Grid-Meter und mein PV Inverter werden über einen daemon auf einem anderen Server ausgelesen; die Daten werden auf einem MQTT Broker im lokalen Netz publiziert. Wie kann ich diese Daten in openEMS einlesen?
Hi @ulistermclane,
OpenEMS liefert zahlreiche Implementierungen für das direkte Auslesen von Stromzählern mit. Es empfiehlt sich, ein unterstütztes Modell zu verwenden.
Ein Stromzähler sollte folgende Kriterien erfüllen:
- Kommunikationsschnelle zur zeitlich hochaufgelösten Datenerfassung (< 1s)
- Register für Wirk-, Blind- und Scheinleistung (L1, L2, L3 und Gesamt)
- Getrennte Register für Wirkarbeit in Bezug- und Einspeiserichtung
Diese Messdaten werden an verschiedenen Stellen in der Applikation verwendet.
Selbst wenn es dir gelingt, hierfür eine Implementation zu schreiben, ist dies nicht empfehlenswert. OpenEMS “will” die Daten selbst abrufen, um:
- zu garantieren, dass die Daten zu jedem Zeitpunkt aktuell sind
- zu erkennen, ob eine Kommunikation z.B. unterbrochen ist
- entsprechend Fehler zu melden
Mit unregelmäßig eingehenden Zähler-Daten auf einem MQTT Broker wirst du unnötige Schwierigkeiten bekommen.
Viele Grüße
Simon
Hallo @ulistermclane,
willkommen in der OpenEMS Community!
Wie Simon bereits geschrieben hat, werden die Geräte üblicherweise direkt über einen Feldbus angesprochen, z. B. über Modbus/TCP oder Modbus/RTU. Technisch geht es natürlich auch anders; in dem Fall würde man eine “MQTT Bridge” benötigen und vielleicht einen generischen Zähler, der notwendigen Daten (Wirk-, Blind-, Scheinleistung, etc.) von Topics liest. Diese Komponenten gibt es im Standard OpenEMS bisher nicht.
Consolinno hat aber sowas anscheinend entwickelt - siehe:
Außerdem können virtuelle Werte subscribed und in Channel geschrieben werden.
Vielleicht kann @DerStoecki mehr dazu sagen.
Gruß,
Stefan
Hi,
ich schiebe @DerStoecki nochmal an. Soweit ich weiß ist folgendes möglich.
virtueller Zähler in OpenEMS kann mit Daten aus MQTT beschrieben werden. Damit kann OpenEMS dann arbeiten.
Allerdings muss die Syntax von MQTT “passen”
Schönen Gruß
Paul
Hallo Zusammen,
Ja das ist richtig.
Durch die mqtt v3 Impl von uns kann man bei Subscribe unter der TelemetryMqttComponent folgendes tun
→ Subscribe Config hinterlegen.
Payload-> Key:Value Paare mappen.
Dabei wird “Key” gleich der Key sein, der auch in der Payload steht (Beispiel folgt am ende) Value == Channel innerhalb von openems aber auch der “Value” der in der “echten” payload beim broker steht.
Beispiel:
Im broker steht folgende Nachricht (fiktive daten) unter der topic “data/meter-1”
{“time”:“2022-05-06T08:02:54.239+02:00”,
“device”:“meter-1”,
“active-power”:1,
“active-power-L1”:10,
“active-power-L2”:20,
“active-power-L3”:10,
“current-L1”:100,
“current-L2”:100,
“current-L3”:110,
“reactive-power-L1”:10,
“reactive-power-L2”:50,
“reactive-power-L3”:50,
“voltage-L1”:50,
“voltage-L2”:50,
“voltage-L3”:30,
“consumption-energy”:100}
nun möchte ich die Daten übernehemen
Ich weiß dass ich Daten eines bspw. Stromzählers (asymmetrisch) da zu stehen habe.
Nun konfiguriert man eine TelemetryMqttComponent
Dabei hinterlegt man bei der Payload
den “Key” aus dem Broker und den “Value” also den Channel wo der Wert aus dem Broker gespeichert werden soll unter dem reiter Payload. Dabei muss man die Konfiguration nur hintereinander schreiben mit einem “:” getrennt. Das sieht dann wiefolgt aus:
active-power:ActivePower:active-power-L1:ActivePowerL1:active-power-L2:ActivePowerL2:active-power-L3:ActivePowerL3:current-L1:CurrentL1:current-L2:CurrentL2
…
Danach kann man in der SubscribeConfig angeben, das heißt, welche Topic soll subscribed werden etc
Der Default entry ist für den Teil
@AttributeDefinition(name = “SubscriptionConfig”, description = "This List is for configuring subscriptions, the accepted form is: "
+ “Priority!Topic!QoS!RetainFlag!TimestampUseBoolean!PayloadNo!TimeToWait”)
String[] subscriptionList() default {
“LOW!Topic!0!true!false!0!10”
};
i.d.R. reicht es den “Topic” teil einfach abzuändern. also in unserem Beispiel:
LOW!data/meter-1!0!true!false!0!10
Anmerkung: Ich denke man sollte einen “Virtuellen” Zähler implementieren für seine Zwecke, der funktioniert ähnlich wie die vorhandenen Zähler etc. nur dass dieser keine Bridge benötigt und seine daten wie gesagt virtuell erhält (aka er hat dann einfach die channel und wartet darauf dass die befüllt werden)
Alternativ kann man nen “echten” zähler nehmen und ne virtuelle modbusbridge verwenden denke ich.
Weiteres:
Diejenigen die Konfigurieren müssen nicht zwangsläufig die Channel innerhalb von OpenEMS kennen.
Wenn man bei der “telemetryMqttComponent” den haken bei “configurationDone” nicht drückt, werden die publish/Subscribe tasks NICHT der mqtt bridge hinzugefügt (handling von broker connection und daten austausch) sondern es wird noch nichts gemacht.
Die Komponente wird in der Konfiguration unter dem Punkt “channelIds” mit den vorhandenen Channeln befüllt und man kann hier eine Übersicht erhalten, welche Channel die Komponente hat.
Ich hoffe das Beispiel war anschaulich, ansonsten würde ich nochmal Screenshots von Konfigurationen hochladen und dann zeigen 
Hallo,
Sorry,wenn ich mich hier als GIT Nullschnaller oute, aber wie kriege ich den MQTT Code in das Gesamtsystem integriert ? Vermutlich muss ich irgendwie den Pull Request mergen,um schliesslich einen gesamten Source Code Tree zu erhalten … Aber wie ?
Ist geplant, das MQTT feature in den Hauptzweig global zu integrieren, dass nicht jeder diese Aufgabe selber loesen muss ?
Vielleicht stell ich mich auch nur doof an … sorry dafuer.
Ok, habs hingekriegt …
1 Like
Wir arbeiten daran, den Code zu integrieren. Das dauert leider oft ein bisschen, weil das alles ehrenamtlich passiert…
Damit sich die nächsten User mit der gleichen Frage leichter tun: der einfachste Weg ist in so einem Fall, den entsprechenden Ordner (das ‘OSGi Bundle’) in sein OpenEMS-Verzeichnis zu kopieren und dann gemäß Doku beim Schritt 1.7. Enable the Component weiterzumachen.
Gruß,
Stefan
1 Like
Moin Stefan
Any update on merging this into the main project? Bidirectional MQTT gets my vote.
Br
Jens
Hi @DerStoecki
I can see from the bundle that you provided the possibility of using MQTTv5. Did you ever try this option or did the implementation only cover MQTTv3?
Br
Jens