MatzeTF

Ich konnte einen Windows-PC auftreiben und habe den Login mit Edge 120.0.2210.77 und Warp2 2.1.5 getestet, konnte dein Problem allerdings nicht reproduzieren. Als Passwort habe ich per Firefox „abcd!:.abcd“ gesetzt und konnte mich mit Edge problemlos einloggen. Du könntest testweise dein Passwort auf „abcd!:.abcd“ ändern und es dann nochmal probieren. Funktioniert es dann, hat dein eigentliches Wallbox-Passwort irgendeine Eigenschaft, mit der Edge in der aktuellen Version nicht zurechtzukommen scheint. Funktioniert es nicht, habe ich aktuell auch keine Idee.

Dann reicht es wahrscheinlich, wenn ich dich darauf hinweise, dass die Benutzeranmeldung der Wallbox kein POST verwendet, sondern HTTP Digest Authentication, bei der UTF-8 erwartet wird. 😉 Da (deutsches) Windows an vielen Stellen immer noch CP-1252 als Zeichensatz verwendet, war das auch nur eine spontane Vermutung meinerseits, die zumindest in diesem Fall nicht relevant war. Wir haben leider keine Version 120.0.2210.77 da und haben auch sonst noch nicht von Problemen gehört. Da HTTP Basic Auth komplett browserseitig berechnet wird, weiß ich gerade auch nicht, wie wir das debuggen können, da ein anderer Browser bei dir funktioniert und es somit auch wallboxseitig funktioniert. Wäre nett, wenn du das im Blick behalten könntest, wenn es eine neue Edge-Version gibt.

Enthält dein Passwort zufällig deutsche Sonderzeichen wie ä, ö, ü, ß oder €? Microsoft-Browser sind leider nicht dafür bekannt, sich gut an Standards zu halten. Falls dein Passwort entsprechende Zeichen enthält, wäre meine Vermutung, dass Edge Passwörter nicht als UTF-8 codiert, wie das alle anderen Browser machen und alle Webseiten erwarten. Sonderzeichen wie !<>=&?()-:@+%"';_[]^\/{}*#$|~` sollten keine Probleme verursachen, da sie im ASCII-Zeichensatz enthalten sind, was eine Untermenge von UTF-8 ist. Ansonsten sind natürlich A-Z, a-z und 0-9 erlaubt. Alles andere, wie die Umlaute, kann Probleme verursachen und sollte nicht in Passwörtern verwendet werden.

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.

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. 😒

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.

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.

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.

Hast du nach den curl-Befehlen manuell einen Neustart durchgeführt? Ich hatte leider nicht darauf hingewiesen, dass du das machen musst, und es sieht so aus, als wäre noch kein Neustart gemacht worden und die Änderung von "verbose" auf true wurde noch gar nicht angewandt. Sorry. 😑

Die 8 A hatten wir auch schon in Verdacht. Interessant, dass es da einen Zusammenhang zu geben scheint. Wir haben uns also einen weiteren Test für dich überlegt: Deaktiviere das Lastmanagement auf der Wallbox, damit der Energy Manager keinen Einfluss mehr hat. Aktiviere die manuelle Ladefreigabe. Stell in der Wallbox den konfigurierten Ladestrom auf 8 oder 6 A. Auto anschließen und einschlafen lassen. Irgendwann per „Start“ die Ladung starten. Damit kannst du testen, ob sich der Peugeot möglicherweise nicht mit einem niedrigen Ladestrom aufwecken lässt. Ich würde den Test zuerst mit 6 A machen, in der Hoffnung, dass das Problem dann wahrscheinlicher auftritt. Wir haben ansonsten noch eine weitere Idee, allerdings testen wir das erst hier. Bei Gelegenheit könntest du schon mal einen Debug-Report (von der Unterseite „Ereignis-Log“) von dem Energy Manager mit den 8 A hier anhängen.

Korrektur: Ursprünglich war das nicht vorgesehen, aber es gibt den Standard ISO 15118, der meines Wissens für DC-Schnellader entwickelt wurde und dort notwendig ist, inzwischen aber auch optional bei AC-Wallboxen eingebaut werden kann. Leider verursacht die Unterstützung dafür zusätzliche Kosten und ist erst bei entsprechend hohem Absatz realistisch machbar. Da den hohen Kosten als einziger Vorteil Plug & Charge gegenübersteht, bieten die meisten AC-Wallboxen, wie auch der WARP Charger, das aktuell leider noch nicht an. Wir sind aber sehr interessiert daran und behalten das weiter im Auge, damit wir auch eine Unterstützung dafür anbieten können, sobald das realistisch machbar ist.

Nein, das ist bei Wallboxen mit Typ 2-Stecker leider nicht möglich, da die Information nicht übers Kabel übertragen wird.

Genau das Feature ist schon geplant und steht auf unserer Todo-Liste, existiert aber leider noch nicht. Das Github-Issue dazu findest du hier.

Ich weiß zugegebenermaßen nicht, wie EVCC die Werte erhält, aber ich kann dir zumindest die andere Seite erklären: Sobald du im WEM einen MQTT-Server eingetragen hast, werden die Zählerwerte automatisch dorthin übertragen. Aktuell findest du sie unter dem Topic wem/ABC/meter/values bzw. /all_values. Demnächst gibt es eine neue WEM-Firmware mit neuer API dafür und dementsprechend wäre es sinnvoll, noch etwas zu warten. Das Prinzip bleibt das gleiche, allerdings werden die Werte dann z.B. unter wem/ABC/meters/0/values veröffentlicht. Manche Hausautomatisierungen bieten dir schon die Möglichkeit, MQTT-Daten weiter zu verarbeiten. Alternativ kann man mit etwas Programmiererfahrung die Werte recht einfach z.B. mit der MQTT-Bibliothek für Python verarbeiten und beliebig weiterschicken.

Per Modbus TCP können prinzipiell mehrere Clients einen Host abfragen. Problematisch wird es allerdings, wenn der Host eine Modbus RTU-Bridge ist und jede Anfrage über eine lahme serielle Verbindung an einen Zähler geht. In dem Fall wird die serielle Schnittstelle der Flaschenhals sein und du wirst häufig Timeouts bekommen. Hat der Host die Werte selbst, können problemlos mehrere Clients sie abfragen. Wenn du EVCC verwendest, steuert das wahrscheinlich das Überschussladen. In dem Fall braucht der EM die Werte gar nicht. Ansonsten kannst du die Werte per MQTT bekommen. Der EM stellt alle ihm bekannten Stromzählerwerte per MQTT zur Verfügung.

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.