Startprobleme: MQTT und RS485/Modbus mit EM540

[andyknownasabu]

Hallo zusammen,

ich bin neuer, stolzer Besitzer eines WARP2 Charger Smart  und eines Energy Manager mit Schütz für die 3-Phasen Umschaltung. Die Geräte sind frisch installiert und ich wollte mich als nächstes nun in die Einstellungen einarbeiten bzw. die Geräte in meine bestehende Victron/HomeAssistant Infrastruktur einbinden. Ich bin dabei auf zwei Probleme gestoßen und hoffe nun, hier in diesem Forum Hilfe zu finden. Ich nutze Firmware 1.0.91-65492465 aus dem Forum.

 

1) Autodiscovery über MQTT funktioniert nicht: Ich habe die Einstellungen entsprechend anderer MQTT-angebunderer Geräte gemacht und im MQTTExplorer sehe ich auch, dass sich der Energy Manager erfolgreich beim Broker (Mosquito) angemeldet hat: Ich kann die Topics/Werte dort alle sehen. Allerdings erkennt HomeAssistant bzw. Mosquito das Gerät nicht. In der MQTT Integration taucht der Energy Manager nicht auf. Liegt das vielleicht daran, dass HomeAssistant das Autodiscovery vor kurzem angepasst hat?

 

2) Ich nutze, wie fast alle mit einem Victron ESS, einen Smart Meter von Carlo Gavazzi. In meinem Fall einen EM540. Dieser ist mit einem USB to RS485 an den Victron Cerbo GX angeschlossen und liefert dort in Echtzeit die Loads etc. Ich habe versucht, diesen über Modbus auch an den Charger anzuhängen, indem ich den Bus mit drei Adern verlängert habe (das sollte meinem Verständnis nach gehen). Das heißt: Cerbo -> EM540 -> Charger. In diesem Fall erkennt der Cerbo den EM540 dann jedoch nicht mehr. Und auch der Charger erkennt keinen Zähler bzw. bekommt keine Werte. Wird dieser Zähler nicht unterstützt (in diesem Fall würde ich dringend darum bitten - die Carlo Gavazzi Zähler werden wir gesagt von einer großen Anzahl von Leuten benutzt) - wenn es gehen sollte: Was mache ich falsch und was muss ich im Zähler/Charger ggf. einstellen, damit es funktioniert?

Danke und VG!

[MatzeTF]

Zu 1) Das ist ein interessanter Punkt. Die Home-Assistant-Integration vom Energy Manager ist gar nicht vorgesehen. Die Option gibt es nur, weil das MQTT-Modul das selbe ist, dass auch bei den Wallboxen verwendet wird. Wahrscheinlich sollten wir beim Energy Manager die Auto-Discovery vorerst ausblenden.

Zu 2) Modbus verwendet eine Client-Server-Architektur, bei der ein Client mehrere Server abfragen kann. Sowohl der USB zu RS485-Konverter als auch der Energy Manager sind Modbus-Clients, die jetzt gleichzeitig versuchen, den Zähler abzufragen. Das gibt dementsprechend Kollisionen und nichts funktioniert. Diese Kombination ist einfach nicht möglich. Weißt du, ob der Victron ESS oder Cerbo GX SunSpec unterstützen? Dann kannst du die Werte darüber auslesen.

Edit: Ich sehe gerade, dass du den Zähler an den Charger hängen wolltest, also an die Wallbox und nicht an den Energy Manager? Das macht sowieso keinen Sinn, da die Wallbox einen Stromzähler nur dazu verwendet, den geladenen Strom eines angeschlossenen Fahrzeuges mitzuzählen.

[andyknownasabu]

1) Verstehe. MQTT Auto-Discovery bei der Wallbox wird dann aber vermutlich auch nicht funktionieren, wenn es beim EM schon nicht klappt?! (Habe die Wallbox aktuell noch nicht dranhängen). Sollte das funktionieren bzw. soll ich hier ggf. ein Issue/Feature Request auf GitHub aufmachen?

2) Nein, sorry, falls das missverständlich war. Den Zähler wollte ich mit dem EnergyManager verbinden, das hat aber - nach deiner Erklärung offensichtlichen - Grund nicht geklappt. Ob Victron/Cerbo SunSpec unterstützen kann ich nicht sagen. Auf die Schnelle habe ich nichts dazu gefunden. Probiere ich aus, aber habe ich wenig Hoffnung. Wie könnte man so etwas ansonsten technisch umsetzen? Sollte der EM540 mit dem EnergyManager funktionieren? Habe ich Tomaten auf den Augen oder wie/wo kann ich die mehrfach gesehen Alternative, Smartmeter Werte per MQTT an den EnergyManager zu übertragen, einstellen/konfigurieren?

[MatzeTF]

1) Die Auto-Discovery ist aktuell nur für Wallboxen. Mit der Wallbox sollte das also funktionieren.

2) Der EM540 wird am Energy Manager nicht funktionieren, da wir keine Direktverbindung zu dem Zähler unterstützen. Ist für dich aber auch nicht relevant, da der EM540 ja schon von einem deiner anderen Geräte beansprucht wird und der Energy Manager also sowieso nicht darauf zugreifen darf.

Den Energy Manager per MQTT/HTTP mit Werten funktioniert so, dass du mit irgendeinem Stück selbstgeschriebener Software die Werte aus deinem vorhandenen Zähler ausliest und im passenden Format an den Energy Manager schickst. Einige hier im Forum nutzen dazu ioBroker bzw. Node Red. Ob oder wie man das mit Home Assistant machen kann, weiß ich nicht.

[andyknownasabu]

Also der Cerbo kann leider kein SunSpec wie es aussieht. Unseren Fronius WR konnte ich jedoch zumindest als Erzeugungszähler einrichten.

modbus-proxy (https://pypi.org/project/modbus-proxy/) hilft in meiner Situation auch nicht wirklich, oder?

[MatzeTF]

modbus-proxy hilft dir nicht, weil der Zähler dafür bereits per Modbus TCP erreichbar sein muss.

Wenn etwas Python-Programmierung im Rahmen deiner Möglichkeiten liegt, kannst du bestimmt irgendwie die Zählerwerte aus deinen vorhandenen Geräten auslesen und entweder per MQTT oder HTTP in den Energy Manager schieben.

[andyknownasabu]

Darf ich fragen, ob es hierfür irgendwo ein gutes Beispiel gibt? Ich denke MQTT wäre einfacher und vllt. sogar direkt in HA machbar...

[MatzeTF]

Aktuell müsstest du ein Paket an das Topic „wem/UID/meter/values_update“ senden. wem/UID musst du entsprechend des Topic-Präfixes bei den MQTT-Einstellungen des Energy Managers anpassen. Der Inhalt des Paketes muss so aussehen:

{"power":123.456,"energy_rel":null,"energy_abs":null}

Statt 123.456 muss da natürlich der tatsächliche Netzbezug in Watt stehen. Aktualisierungen solltest du im Sekundentakt senden.

Demnächst wird sich die API ändern und der Paketinhalt sowie das Topic sind dann etwas anders, aber das Konzept bleibt gleich.

Ein Beispiel, wie man das mit HA macht, kann ich dir leider nicht anbieten.

[Nitrox09]

Hallo, ich bin auch gerade dabei zu versuchen aus Home Assistant den Meter-Wert per MQTT an den WEM zu senden. Ich stehe noch vor ein paar Schwierigkeiten den Wert des Paketes (so wie von MatzeTF erwähnt) darzustellen. Hat dies jemand bereits erfolgreich hinbekommen?

Des Weiteren habe ich den Meter-Wert bereits erfolgreich händisch in "wem/UID/meter/values" veröffentlicht. MQTT Explorer stellt mir diesen Wert auch dar. Ich habe aber den Eindruck im WEM wird der Wert nicht aktualisiert, bzw. kommt gar nicht erst an. Zumindest kann ich Debug-Report den aktualisierten Wert nicht finden. Einer 'ne Idee wo der Fehler liegt?

[andyknownasabu]

Ich habe mich schlussendlich gegen die MQTT Lösung entschieden. Und stattdessen EVCC (und EM/Charger entsprechend) konfiguriert. Das funktioniert hervorragend und kann out of the box alle Werte vom Cerbo GX (und damit dem smart meter), EM/Charger und meinem Fronius Wechselrichter auslesen. PV Überschussladen ist damit u.a. auch möglich, genauso wie Verbindung zu tibber et al. um preisabhängig laden zu können. Kann ich nur empfehlen und ist viel weniger Headache als MQTT.

Mein Setup sieht damit so aus:

Smart Meter <--RS485--> CerboGX <--TCP/IP--> Homeassistant mit EVCC <--TCP/IP--> Warp EM/Charger

                                                                                    \---Modbus/TCP---->  Fronius

bearbeitet December 14, 2023 at 07:37 von andyknownasabu

[Nitrox09]

EVCC in Verbindung mit dem WEM habe ich auch am Laufen. Das ist nicht das Problem. Mein Problem ist aber, dass der Eastron SDM630 Stromzähler, von dem mein WEM die Werte vom Netzzähler bekommt aus unerfindlichen Gründen nicht richtig zählt (wurde bereits getauscht, Problem bleibt). Ich möchte das System aber auch ohne EVCC nutzen können. Den Zählerwert bekomme ich derzeit durch Tibber in Home Assistant. Nun möchte ich diesen Wert aber an den WEM pushen.

Das Ganze diente erstmal als Versuch, ob ich das überhaupt alles so konfiguriert bekomme. Wir bekommen demnächst einen neuen Speicher, der auch Modbus/TCP kann. Von hier möchte ich dann die Werte in HA abgreifen und an den WEM weiterleiten.

So weit bin ich aber noch gar nicht. Ich habe versucht einen einzelnen Wert im o. g. Format an "wem/UID/meter/values" zu pushen. Allerdings scheint der nicht vom WEM verarbeitet zu werden.

[MatzeTF]

Ist der SDM630 noch verbunden oder hast du ihn abgeklemmt? Wenn der noch verbunden ist, kämpfen der SDM und deine manuellen Updates gegeneinander. Spätestens nach einer Sekunde werden deine Werte immer vom SDM630 überschrieben. Außerdem musst du in den WEM-Einstellungen unter Energiemanager → Stromzähler-Einstellungen den Stromzähler-Typ auf „Benutzerdefinierter Zähler (MQTT/HTTP)“ stellen.

Wenn der SDM630 aktuell noch verbunden ist und du ihn abklemmen will, solltest du den WEM dafür stromlos machen, damit er den Zähler auch wirklich vergisst. Ein Neustart über das Webinterface reicht dafür nicht.

Wir arbeiten aktuell an einer neuen Zählerverwaltung, die den Konflikt zwischen SDM und API beseitigt. Man muss dann manuell auswählen, ob man den angeschlossenen Zähler oder einen per API befüllten Zähler nutzen möchte. Wenn man den API-Zähler auswählt, ist es dann egal, ob ein anderer angeschlossen ist oder nicht. Man kann auch beide Zähler gleichzeitig Werte anzeigen lassen und auswählen, welcher von beiden für PV-Überschussladen verwendet werden soll.

Was mir gerade noch einfiel: Wenn du die Zählerwerte per MQTT an die API schickst, musst du als Topic „wem/UID/meter/values_update“ angeben. Auf /values kannst du nur Werte lesen aber nicht setzen.

[Nitrox09]

Am 14.12.2023 um 11:10 schrieb MatzeTF:

Ist der SDM630 noch verbunden oder hast du ihn abgeklemmt? Wenn der noch verbunden ist, kämpfen der SDM und deine manuellen Updates gegeneinander. Spätestens nach einer Sekunde werden deine Werte immer vom SDM630 überschrieben. Außerdem musst du in den WEM-Einstellungen unter Energiemanager → Stromzähler-Einstellungen den Stromzähler-Typ auf „Benutzerdefinierter Zähler (MQTT/HTTP)“ stellen.

Wenn der SDM630 aktuell noch verbunden ist und du ihn abklemmen will, solltest du den WEM dafür stromlos machen, damit er den Zähler auch wirklich vergisst. Ein Neustart über das Webinterface reicht dafür nicht.

Wir arbeiten aktuell an einer neuen Zählerverwaltung, die den Konflikt zwischen SDM und API beseitigt. Man muss dann manuell auswählen, ob man den angeschlossenen Zähler oder einen per API befüllten Zähler nutzen möchte. Wenn man den API-Zähler auswählt, ist es dann egal, ob ein anderer angeschlossen ist oder nicht. Man kann auch beide Zähler gleichzeitig Werte anzeigen lassen und auswählen, welcher von beiden für PV-Überschussladen verwendet werden soll.

Was mir gerade noch einfiel: Wenn du die Zählerwerte per MQTT an die API schickst, musst du als Topic „wem/UID/meter/values_update“ angeben. Auf /values kannst du nur Werte lesen aber nicht setzen.

Das mit dem SDM630 habe ich bemerkt. Der Zählertyp ist auf „Benutzerdefinierter Zähler (MQTT/HTTP)“ gestellt und und den SDM630 habe ich stromlos gemacht und der WEM wurde auch komplett vom Strom getrennt. Danach war der Zähler dann auch tatsächlich auf 0. Vorher stand noch der letzte Wert vom SDM630 drin.

 

"values_update" habe ich tatsächlich auch probiert. Weil ich es hier schon gelesen hatte, brachte aber auch keine Besserung.

UPDATE: Ok, es geht nun doch! 😀 Vielen Dank!
Ich bekomme die Werte nun automatisiert sekündlich von Home Assistant per MQTT passend an den WEM versendet. Ich freu mich!

bearbeitet December 14, 2023 at 12:08 von Nitrox09

[andyknownasabu]

Vielleicht an dieser Stelle eine Frage an die mitlesenden/-helfenden Warp Entwickler/innen: EVCC kann alle Werte zu PV, Batterie und Zählern offensichtlich robust aus dem CerboGX auslesen. Wäre es keine gute Idee, sich den entsprechenden Code mal anzuschauen und zu sehen, ob man diesen in den EM/Charger übernehmen kann? SunSpec Autodiscovery ist nice, aber funktioniert halt nur mit Systemen, die dieses Protokoll sprechen. An Victron lässt sich so ziemlich alles anschließen/-binden und wir dann vom Cerbo zentral zusammengeführt. Auslesen dort würde dem Warp EM/Charger erlauben, von dieser großen Kompatibilität zu profitieren, ohne diese selbst implementieren zu müssen...

Was ich mir konkret vorstelle: Dass man in der Konfiguration neben SunSpec auch "Victron" auswählen, eine IP Adresse angeben und dann die von Victron/Cerbo erkannten Geräte auswählen kann. Das wäre doch noch nicer :)

bearbeitet December 14, 2023 at 16:37 von andyknownasabu

[MatzeTF]

Ja, schön wäre das, allerdings gibt es mehr herstellerspezifische Lösungen als wir unterstützen können. Fängt man mit einer davon an, ist die Frage, wo man aufhört. Deswegen unterstützen wir aktuell keine herstellerspezifischen Lösungen und haben stattdessen das herstellerübergreifende SunSpec implementiert.

[andyknownasabu]

Verstehe ich. Wenn ihr doch mal damit anfangen wollt, würde ich wie gesagt Victron empfehlen. Denn das war ja genau der Punkt, dass Victron hier als "Proxy" zu den Geräten anderer Hersteller fungieren könnte und ihr so eben nicht jeden einzelnen unterstützen müsst. Und Victron ist gerade im DIY Bereich sehr weit verbreitet/beliebt...

[poohnet]

Mit Victron / EM540 kann ich leider nicht dienen, aber für das SMA Energy Meter 2.0 habe ich ein Plugin für den WARP Energy Manager implementiert:

 

Vielleicht findet sich ja jemand, der (wie ich) eine solche Implementierung in einem Fork der Firmware vornehmen kann?

Gruß Thomas

[andyknownasabu]

Ich glaube ja eigentlich auch, dass Tinkerforge hier einen Vorteil von OpenSource (noch) nicht ausnutzt - nämlich, dass die Community nach und nach die Anbindung an die diversen Hersteller bereitstellen würde. Wie du für SMA, andere dann für weitere Hersteller. Es müssen ja nicht alle Hersteller direkt vollumfänglich unterstützt werden - wenn die Anbindung nach und nach erweitert wird, wäre das trotzdem ein (stetig wachsender) Selling Point.

bearbeitet December 16, 2023 at 18:01 von andyknownasabu

[MatzeTF]

On 12/16/2023 at 7:01 PM, andyknownasabu said:

Ich glaube ja eigentlich auch, dass Tinkerforge hier einen Vorteil von OpenSource (noch) nicht ausnutzt - nämlich, dass die Community nach und nach die Anbindung an die diversen Hersteller bereitstellen würde.

Die Idee hatten wir auch schon. Das Problem dabei ist, dass wir die von der Community bereitgestellten Anbindungen testen und warten müssen, wofür wir sämtliche benötigte Hardware vor Ort einsatzbereit halten müssen und mindestens ein Mitarbeiter muss sich hinreichend mit den Geräten auskennen. Das können wir aktuell leider noch nicht leisten.

[andyknownasabu]

Verstehe ich - das alte Problem... Und wenn ihr diese Unterstützung in eine "Extension" auslagert und explizit sagt, dass diese nicht von euch supported sind? Die Leute, die sie benötigen, können sie installieren/verwenden und ihr könnt organisch wachsen und bei Interesse diese nach und nach "offiziell" supporten

[MatzeTF]

Wallboxen sind ein Produkt für den Massenmarkt und ein signifikanter Teil unserer Kunden hat keine Ahnung von Open Source oder Community-Erweiterungen. Es ist für solche Leute schwer verständlich, warum sie, wenn sie ein in sich abgeschlossenes Produkt gekauft haben, für einige Funktionen keinen Support bekommen. Wir hatten schon überlegt, einige Option „FritzBox-Style“ hinter einem Expertenmodus zu verstecken. Dort könnte man vielleicht auch Community-Erweiterungen verstecken, aber das ist leider immer noch ein Punkt auf unserer ewig-langen Todo-Liste. 😒

[andyknownasabu]

Noch ein anderer Vorschlag: Ihr stellt nur eine einfach zu benutzende API für Erweiterungen bereit (vllt. gibt es die auch schon) und somit eine (einfache) Möglichkeit, dass Community-Erweiterungen von technisch versierten Leuten mittels dieser API entwickelt und bereitgestellt werden können. Auch wieder bei Victron gibt es das in Form von "https://github.com/kwindrem/SetupHelper". Normale" Kunden sehen davon dann nichts, sondern nur den Teil der supported ist. Gleichzeitig ist die Hürde für Erweiterungen aber auch geringer. Aktuell scheint mir diese noch relativ hoch (zumindest sehe ich keine größere Anzahl an privaten Projekten auf GitHub, die solche Erweiterungen anbieten)

[MatzeTF]

Bei der Wallbox-Firmware ist das leider nicht möglich, da sie als ein monolithischer Block bereitgestellt wird. Wenn eine Community-Erweiterung nutzbar sein soll, muss sie fest reinkompiliert werden. Ab der nächsten Firmware-Version wird es eine viel flexiblere API für Stromzähler geben, sodass externe Software einfacher Werte an die Wallbox liefern kann. Eine Community-Erweiterung für einen Zähler könnte dann z.B. ein Python-Script sein, dass der Nutzer auf einem Raspberry Pi laufen lassen kann.

[poohnet]

On 12/18/2023 at 1:14 PM, andyknownasabu said:

Aktuell scheint mir diese noch relativ hoch (zumindest sehe ich keine größere Anzahl an privaten Projekten auf GitHub, die solche Erweiterungen anbieten)

Man muss sich halt intensiv mit der Materie beschäftigen und in die ESP32-Entwicklung einsteigen - das ist sicher nicht trivial, aber auch kein Hexenwerk, zumal man durch die Jungs von TinkerForge wirklich 1a unterstützt wird. Ich selbst bin jedenfalls froh, mich damals für WARP entschieden zu haben und bin gespannt, was da noch so alles kommt.

Allerdings sind wahrscheinlich 99% der Anwender keine Softwareentwickler und wenn doch, dann entwickeln diese (wie ich) primär erstmal Erweiterungen für den eigenen Bedarf, die evtl. nur bedingt für andere interessant sind - zumal ein Test solcher Plugins ohne die entsprechende Hardware schwierig bis unmöglich ist.