MatzeTF

Bitte Beta 5 ausprobieren. Du findest sie im ersten Post.

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.

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.

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.

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.

Die Verteilung von belegten Blöcken im Speicher ist teilweise nichtdeterministisch. Es kann passieren, dass ein belegter Block weit „hinten“ liegt und dementsprechend der größte freie Block, der typischerweise am Ende des Speichers liegt, entsprechend kleiner ist. Du kannst beliebig oft neu starten, bis du zufällig eine gute Verteilung triffst. 😉 Üblicherweise ist der größte freie Speicherblock nicht so wichtig, da z.B. bei deepflyer911s letztem Crash viele Blöcke mittlerer Größe gleichzeitig für vsprintf angefordert wurden.

Ja, das sollte gehen. Aktuell ist das bei wechselnder Bewölkung leider noch nicht sehr effizient und es kann passieren, dass ein Fahrzeug häufig ein- und ausgeschaltet wird.

Soweit ich weiß ist die Phasenumschaltung über den WEM aktuell in EVCC so implementiert, dass der WEM als eine Zusatzoption für die Wallbox angesehen wird. Man hat also eine 1:1-Zuordnung zwischen Wallbox und WEM in EVCC. Eine zweite Wallbox kannst du nicht hinter den selben WEM hängen, wenn du EVCC nutzen möchtest.

@deepflyer911 Ich habe mir gerade dein Log von Sonntag angesehen und es sieht so aus, als wäre deine Box im SoC-Modul wegen zu wenig freiem Speicher abgestürzt. MQTT verbraucht recht viel Speicher, von daher wundert mich das nicht. Die gute Nachricht ist: Für neue Features für WARP2 und den WEM reduzieren wir gerade den Speicherverbrauch verschiedener Module. Davon wird auch die WARP1 profitieren und Abstürze wegen zu wenig freiem Speicher sollten dann seltener auftreten.

Danke, aber ich hätte die .elf-Datei von deinem Release hier gebraucht, also die Datei mit Timestamp 6545e427.

Es gibt jetzt die Beta 4 mit ein paar Verbesserungen. Ihr findet die Firmware und die Liste der Änderungen im ersten Post dieses Threads.

Wenn du MQTT in der Konfiguration schon lange am Laufen hast, können das auch obsolete alte Nachrichten sein, die immer noch auf dem MQTT-Server vorgehalten werden. Hat der Server eine Option, um vorgehaltene Nachrichten mit „retain“-Flag zu löschen? Alternativ kannst du die Nachrichten auch von Hand mit einem Kommandozeilen-MQTT-Client löschen. Üblicherweise reicht es dazu, wenn du eine leere Nachricht mit „retain“-Flag an das entsprechende Topic sendest, also z. B. an warp2/XY4/modules.

Kannst du die .elf-Datei von deinem Release auch bereitstellen? Dann kann man sich die Exception mal ansehen. Das ist unproblematisch und bei WARP1-Firmware normal. Wegen zu wenig Speicher können wir MQTT nicht mehr als die knapp bemessenen 2k geben. Mit deiner Vermutung liegst du wahrscheinlich genau richtig. Die Fehlermeldung bedeutet, dass kein Speicher zur Verfügung steht, um eine Config-Struktur in einen String umzuwandeln. 6784 Bytes ist aber auch echt viel. Ich weiß spontan nicht, welcher unserer Configs so riesig sein soll. Hast du zufällig in einem deiner Module eine große Config angelegt? Möglicherweise mit einem ConfArray drin, dessen maximale Anzahl von Elementen sehr groß ist, selbst wenn die in der Praxis gar nicht alle genutzt werden?

Es gibt jetzt die Beta 3 mit ein paar Verbesserungen. Ihr findet die Firmware und die Liste der Änderungen im ersten Post dieses Threads.

Gut, dass du gleich einen Screenshot gemacht hast. Die Konfiguration ist nicht unvollständig und das Feld auch nicht aktiv (rot). Das Feld gehört zu der gleichen Gruppe wie die vier Felder drüber, passt wegen seinem langen Namen aber nicht mit den anderen in eine Zeile. Somit ist „OK“ das einzige aktive Feld aus der Gruppe.

Wir können dir doch nicht ein Produkt verkaufen, das du dann gar nicht zum Laufen bekommst… Also laut Report gibt es keinen Fehler. Das sieht alles gut aus. Ist im Webinterface tatsächlich immer noch „Unvollständige Konfiguration“ auf rot?

Der untere/hintere Kontaktsatz ist richtig. In der Anleitung steht, dass ein Schließer zwischen Eingang 4 und 12 V angeschlossen werden muss. Die hinteren Klemmen am Hilfskontakt sind ein Schließer. Falls der WEM immer noch eine unvollständige Konfiguration meldet, lade doch bitte von der Ereignis-Log-Seite einen Debug-Report runter und hänge ihn hier an.

Wenn du EVCC eingerichtet hast, möchtest du wahrscheinlich PV-Überschussladen damit machen. In dem Fall darfst du die Option fürs PV-Überschlussladem im WEM nicht aktivieren. Das übernimmt schließlich EVCC. Ist die Option vielleicht doch an? In dem Fall meckert der WEM nämlich, wenn er keinen eigenen Stromzähler hat. Mögliche andere Fehler: Phasenumschaltung ist auf „Automatisch“ eingestellt obwohl die Option für das Schütz nicht eingeschaltet ist. Unter Energiemanager → Wallboxen ist oben der maximale Gesamtstrom der Wallboxen noch nicht eingetragen. Unter Energiemanager → Wallboxen ist noch keine Wallbox eingetragen.

Das mit der Firmware hast du richtig erkannt. Bei Lagerware kann es sein, dass sie mit einem alten Firmware-Stand ausgeliefert wird. Deswegen ist ein Update nach der Installation immer empfehlenswert. Wenn der WEM immer noch „Unvollständige Konfiguration“ anzeigt, fehlt im noch etwas. Wenn an der Stelle nicht mehr steht, schau im Webinterface mal unter System ins Ereignis-Log.

Der WEM verwendet die gleichen Codebasis wie die Wallboxen und ist nicht Docker-kompatibel. Ein Pi mit Docker liegt weit außerhalb der vorgesehenen Verwendung des WEM und wäre praktisch ein komplett anderes Produkt. Wenn du einen Pi mit Docker haben möchtest, solltest du dir selbst einen kaufen. Das ist für dich auch günstiger, als wenn wir ein neues Produkt entwickeln und da einen Pi reinstecken.

Für das Lastmanagement zwischen Wallboxen verschiedener Hersteller gibt es nur OCPP. Die Entwicklung einer Wallbox auf Pi-Basis ist aktuell nicht geplant.

Der WEM wird keinen OCPP-Server anbieten können. Das sprengt die Grenzen des ESP32 vom WEM. Du wirst dich entweder nach einem kostenlosen oder kommerziellen OCPP-Server umsehen oder dir selbst einen einrichten müssen, z. B. auf einem Raspberry Pi.

Das meiste hat dir poohnet ja schon beantwortet, aber dazu noch: Was genau meinst du mit „Ladestand“? Falls du den Ladestand der Fahrzeugbatterie meinst: den kennt die Wallbox nicht. Über den Typ 2-Stecker wird diese Information nicht übertragen. Die Wallbox meldet dem Auto nur den maximal erlaubten Ladestrom. Von allem anderen weiß sie nichts. Wenn du den Ladestand der Fahrzugbatterie in EVCC anzeigen möchtest, geht das nur über die entsprechenden Cloud-Schnittstellen des Fahrzeugherstellers.

Gibt es: feature-meters-7. Du solltest dort aber besser noch nichts entwickeln, da wir die Branches regelmäßig wechseln und rebasen. Das ist schon der Siebte. 😉 Schau dir vielleicht schon mal das Modul „meters-em“ an. Das ist recht übersichtlich und du kannst sehen, wie du die Values deines Stromzählers deklarieren und aktualisieren musst.

Schon mal dazu: Die API wird sich ändern, weil wir die Zählerbehandlung komplett ersetzen. Es gibt demnächst ein Framework für verschiedene Zähler. Wenn du noch etwas wartest, kannst du das SMA Energy Meter gleich als neue Zählerklasse implementieren.