MatzeTF

Wenn es unbedenklich wäre, würden wir es offiziell veröffentlichen. 😉 Falls deine Frage darauf abzielt, ob etwas kaputtgehen kann: Nein. Durch die OCPP-Firmware werden weder dein Fahrzeug, noch deine Wallbox Schaden nehmen. Es könnte nur halt passieren, dass du nicht laden kannst, wenn irgendwas nicht richtig funktioniert. Meine Empfehlung wäre daher, ungenutzte Funktionen beim Bauen der Firmware zu deaktivieren. Dann sollten genug Ressourcen frei sein, damit deine Warp1 auch mit OCPP zuverlässig funktioniert. In der offiziell veröffentlichten Firmware können wir das nicht machen, weil dann ja manch anderen Nutzern eine Funktion fehlt.

@deepflyer911 Nur zur Sicherheit: Der MQTT-Server, zu dem sich deine Wallbox verbindet, ist nicht zufällig ioBroker? Edit: Ich habe gerade in einem deiner alten Posts gefunden, dass du ioBroker benutzt. Edit 2: Das Problem ist, dass sich ioBroker nicht standardkonform verhält und in der Default-Konfiguration Nachrichten per MQTT sendet, die bei der Wallbox verschiedene Probleme verursachen. Mit 2.1.4 ist es prinzipiell möglich, dass die Wallbox endlos von ioBroker neugestartet wird. Ich vermute stark, dass du genau auf dieses Problem gestoßen bist. Mit der noch nicht veröffentlichten Version 2.1.5, die mattsches netterweise bereits für dich gebaut hat, haben wir die häufigste unsinnige Nachricht von ioBroker rausgefiltert und das Problem sollte nicht mehr so leicht auftreten. Unabhängig davon empfehlen wir, ioBrokers MQTT-Option „Publish own states on connect“ immer zu deaktivieren.

Dann passt da wirklich etwas nicht, was du nur per USB rausfindest. Die USB-Schnittstelle habe ich dir unten im Bild markiert. Unter Linux kannst du ein Terminalprogramm deiner Wahl benutzen oder einfach unser „ff“-Script aus dem esp32-firmware git. Was man heutzutage unter Windows empfehlen kann, weiß ich nicht. Putty sollte auch serielle Schnittstellen können. Bitrate ist 115200, alles andere auf Default (8bit, ein Stopbit, keine Parität).

Daran kann man leider nichts Hilfreiches erkennen. Als du das zweite Debug Log runtergeladen hast, lief die Box seit mehr als 2 Minuten. Hattest du sie vorher selbst neugestartet? Angeblich wurde sie die letzten Male immer per Software neugestartet. Falls du keine Neustarts manuell ausführst, fürchte ich, dass man nur über den USB-Port in der Wallbox an irgendwelche hilfreichen Informationen zu den Neustarts kommt. Speicher sieht okay aus. 47 KiB frei ist für eine WARP1 nicht ungewöhnlich. Das Log davor mit weniger Uptime sagt allerdings was von 62 KiB frei. Könnte also auch ein Speicherleck sein. In dem Fall gibt es auch nur über USB irgendwas Hilfreiches.

Wie aktuell ist deine Codebasis? Wir haben am 14.9. etwas Speicher freigeschaulfelt. Wenn du glaubst, nah am Speicherlimit zu sein, nimm mal das „Debug“ Front- und Backendmodul mit rein. Das liefert dir jetzt mehr Informationen zum Speicherverbrauch.

@deepflyer911 Kannst du mal versuchen, ein Debug-Log runterzuladen und hier anzuhängen? Außerdem könntest du versuchen, MQTT-Server und was du sonst noch an Hostnamen irgendwo eingetragen hast, durch statische IPs zu ersetzen. Möglicherweise gibt es ein Problem beim Auflösen von Hostnamen, wenn der ESP gerade am Limit läuft.

Technisch wäre das möglich, aber es wird aktuell nicht unterstützt und es gibt auch keine Pläne dazu. Mit etwas Programmierkenntnissen kannst du dir aber die Warp1-OCPP-Firmware bauen. Die unterstützen wir nicht offiziell, weil du damit entweder den integrierten ESP32-Prozessor hart am Limit fährst oder auf einige der anderen Funktionen verzichten musst, wofür du die Modulliste auf deine Bedürfnisse abstimmen musst. Mit „etwas Programmierkenntnissen“ ist gemeint, dass du nach Anleitung die Entwicklungsumgebung nach einrichten und die Firmware kompilieren musst. Dazu musst du nur die Modulliste anpassen aber keine Zeile Code programmieren.

Der Zähler vom Energieversorger ist auf den Bildern nicht zu sehen. Kann der die Momentanleistung anzeigen und falls ja, stimmt sie mit dem Zähler vom Batteriespeicher überein oder liegt der Wert zwischen den Werten der Zähler von Batteriespeicher und WEM?

Bei einer Einspeisung von 11 kW und einer Abweichung von 110 W beträgt der Messfehler 1 %, was im Bereich der Toleranz liegt. Wie sieht es aber aus, wenn am Hausanschluss kein Strom fließen sollte, weil entweder ein Fahrzeug oder der Batteriespeicher geladen wird?

Also da passt etwas nicht. Der SDM630 ist ein geeichter Zähler mit einem Messfehler < 1 %. Der Hausstromzähler muss mindestens genauso akkurat sein. Wenn der SDM630 richtig liegt, würdest du permanent 150 W zu viel Stromverbrauch bezahlen. Das wären jedes Jahr 1315 kWh bzw. ca. 400 €. Wenn du vermutest, dass der Hausstromzähler so weit daneben liegt, und du das nicht bezahlen möchtest, solltest du dich bei deinem Energieversorger beschweren. 😉 Wahrscheinlicher ist eher, dass der Hausstromzähler richtig liegt und der SDM630 nicht korrekt angeschlossen ist. Meine Vermutung ist, dass die Klappwandler vom SDM630 nicht direkt hinter dem Stromzähler angebracht sind, sondern dazwischen ein Abzweig ist, an dem irgendein Verbraucher hängt. Gerade bei nachgerüsteten Batteriespeichern ist die Verkabelung im Sicherungskasten oft sehr chaotisch. Ich habe schon Kästen gesehen, bei denen nicht nur der vom Zähler kommende Netzanschluss, sondern auch zwei ähnliche Stränge für die Hausverbraucher dreimal von Zähler ganz links zum Sicherungsfeld ganz rechts gingen. Bitte überprüfe nochmal, bzw. lasse überprüfen, ob die Klappwandler wirklich an den Leitungen angebracht sind, die direkt vom Zähler kommen. Es darf dazwischen keine Abzweige geben, auch nicht zum Batteriespeicher. Sinnvollerweise solltest du am besten zuerst überprüfen, ob das, was auf dem Webinterface des WEM angezeigt wird, auch das ist, was auf dem Display des Zählers angezeigt wird. Wenn du vier Mal auf die P-Taste drückst, sollte oben der Momentanbezug in kW angezeigt werden. Dieser Wert sollte mit der Leistungsaufnahme auf der Statusseite des WEM übereinstimmen. Das ist aktuell nicht vorgesehen. Die Abweichung sollte bei korrekt installierten Zählern unter 2 % liegen (< 1 % pro Zähler). Da bei PV-Überschussladen der Netzbezug auf 0 geregelt wird, sollte die Abweichung unter 2 W liegen (Genauigkeit der Nullpunkte), was unterhalb dessen liegt, wie akkurat ein Fahrzeug den erlaubten Ladestrom nutzt, und somit egal ist. Liegt die Zählerabweichung nicht in dem Bereich, muss die Zählerinstallation korrigiert werden. Einen Betrieb mit falsch installierten Zählern unterstützen wir nicht. Möglich ist das allerdings trotzdem über die Recovery-Seite des Energy Managers (http://wem-abc/recovery). Du kannst testweise mal das hier in das obere große Feld (unter API) kopieren und dann auf „Call API“ klicken. Dann sollte darunter der Code „200“ erscheinen. {"method":"PUT","url":"/energy_manager/config_update","payload":{"contactor_installed":null,"phase_switching_mode":null,"excess_charging_enable":null,"default_mode":null,"auto_reset_mode":null,"auto_reset_time":null,"guaranteed_power":null,"cloud_filter_mode":null,"relay_config":null,"relay_rule_when":null,"relay_rule_is":null,"input3_rule_then":null,"input3_rule_then_limit":null,"input3_rule_is":null,"input3_rule_then_on_high":null,"input3_rule_then_on_low":null,"input4_rule_then":null,"input4_rule_then_limit":null,"input4_rule_is":null,"input4_rule_then_on_high":null,"input4_rule_then_on_low":null,"target_power_from_grid":-250}} Die -250 am Ende kannst du nach Bedarf anpassen. Bitte beachte, dass anschließend im Webinterface das Feld für das Regelverhalten leer ist, da der Wert außerhalb des vorgesehenen Bereiches liegt. Da kannst trotzdem dort wieder einen Wert auswählen oder das Feld leer lassen, wenn du andere Einstellungen auf der Seite änderst. Selbst wenn das funktioniert, solltest du trotzdem deiner inkorrekten Zählerinstallation auf den Grund gehen! Das steht schon auf unserer Todo-Liste, aber nicht sehr weit oben weil das nicht ganz einfach ist. Wenn der Normalfall einphasig ist und ein gerade angeschlossenes Fahrzeug dreiphasig geladen werden soll, muss sofort eine Phasenumschaltung mit CP-Trennung durchgeführt werden. Manche Fahrzeuge mögen es aber nicht, wenn direkt nach dem Einstecken das CP-Signal verschwindet, und gehen dann in einen Fehlerzustand und lassen sich nicht mehr laden, bis der Stecker einmal aus- und wieder eingesteckt wird, woraufhin sich das Spiel wiederholen würde.

Das gehört nicht zum Standard und ist vom Fahrzeug abhängig. Renault Zoes mögen zweiphasiges Laden nicht und werfen gerne mal den FI raus, wenn du es trotzdem versuchst. Nein.

Jeder Elektrofachbetrieb darf die installieren. Das einzige Problem ist, dass manche Elektriker nicht deine selbstorganisierte Wallbox installieren wollen, sondern nur die, die sie selbst anbieten, weil sie die schon kennen (und wahrscheinlich besser dran verdienen). Du kannst versuchen, den Elektriker deiner Wahl damit zu ködern, dass das Feedback von anderen Elektrikern ist, dass unsere Wallbox einfach zu installieren ist und unser Telefonsupport gut ist, falls man doch Fragen hat. 😉

Per Mail kannst du das bestellen. Natürlich darf das Kabel nur von einer Elektrofachkraft angeschlossen werden. 😉 Korrektur: Eine Wallbox kannst du nicht ohne Kabel bestellen, insbesondere weil sie ohne Kabel nicht getestet werden kann. Möglich ist aber, dass du uns dein Kabel zukommen lässt, und wir bauen dir eine WARP2 mit deinem Kabel dran. Kannst du per Mail oder telefonisch bestellen. Es wollte schon mal jemand unbedingt ein 10 m Kabel haben, was wir nicht anbieten. Er hat dann ein selbst gekauftes 10 m-Kabel vorbeigebracht und wir haben es beim Zusammenbauen seiner WARP2 angeschlossen.

Ja, das stimmt. Sofern du dir das nicht wie ein paar andere Leute hier im Forum selber bauen willst. 😉 Das ist kein SunSpec sondern etwas Proprietäres und auch noch in einem Format, das lästig für Drittanbieter zu verarbeiten ist. Des werden wir wohl in nächster Zeit leider nicht unterstützen können.

Das ist prinzipiell möglich. Stellt sicher, dass das Fahrzeug tatsächlich komplett getrennt ist, bevor die Phasen umgeschaltet werden, und überwacht das Schütz auf Fehler. Siehe auch hier. Kannst du, sowohl per MQTT als auch per HTTP. Siehe hier. Das ist aktuell noch ein undokumentiertes Feature. Demnächst wird es eine offizielle API dafür geben, die allerdings anders aussehen wird. Wir arbeiten auch an einer direkten Unterstützung für Modbus TCP-fähige Geräte wie den KSEM. Wenn du die Werte aber schon per MQTT hast, ist es wahrscheinlich am einfachsten, die direkt in den Energy Manager zu schieben. Ist aktuell noch nicht in der Anleitung. Siehe Anhang. wem-contactor.svg

Meinst du unseren Energy Manager oder ist der Home Manager ein Produkt von Varta? Weißt du, ob der Batteriespeicher SunSpec oder zumindest Modbus TCP unterstützt? Falls ja, sollte das in absehbarer Zeit funktionieren. Hat der Batteriespeicher nur eine proprietäre Schnittstelle, müsste erst jemand eine Anbindung für das Gerät programmieren. Da wir keins davon haben, wird von uns in nächster Zeit nichts dazu kommen. Falls du Erfahrung mit C++-Programmierung hast, kannst du die Anbindung gerne beisteuern. 😉

Schau mal hier. Außer dem Schütz und ggf. den Anschlussklemmen kannst du an Innereien eigentlich nichts weiterverwenden. Bei einer Smart wäre das noch zu verschmerzen, aber da du eine Pro hast, brauchst du wahrscheinlich auch einen neuen Zähler, wodurch das Ganze recht teuer wird.

Meines Wissens nach nicht, aber er misst halt keinen Strom und ist somit nutzlos. 😉 Das ist machbar, erfordert aber schon ein wenig Fingerakrobatik. Siehe hier. Vielleicht klappt es besser, die Kabel anzuschließen, wenn der Zähler nicht auf der Hutschiene sitzt. Genau, die Warp1 kann das nicht. Bei manchen Fahrzeugen reicht es tatsächlich aus, den Ladevorgang zu beenden, bei manchen aber auch nicht. Ich würde es nicht ausprobieren wollen.

Meinst du „Publish own states on connect“ wieder einschalten? Sollte dann auch okay sein, aber ich weiß nicht, wofür du das brauchen solltest. Ich würde es einfach auslassen. 😉

Wir haben eine Möglichkeit für das Vergesslichkeitsproblem entdeckt, die aber eigentlich schon vor 2.1.3 bestanden haben sollte. Vielleicht hattest du da vorher einfach Glück gehabt. Wir machen das Zurücksetzen von Einstellungen jetzt robuster und mit 2.1.5 sollte das Problem nicht mehr auftreten. Es wäre nett, wenn du deinen Kollegen, der ebenfalls ioBroker einsetzt, darauf hinweist, dass er 2.1.4 besser auslassen und auf 2.1.5 warten sollte. Wenn er 2.1.4 nutzen möchte, weise ihn bitte auf die ioBroker-Option hin, die man vorher ausschalten muss.

Frage dazu: Hattest du eine 2.1.3 am Laufen, bevor du das erste Mal auf 2.1.4 aktualisiert hast, oder hast du vorher ein paar Versionen ausfallen lassen?

Der API-Endpunkt ist aktuell noch wem/abcd/meter/values_update. Als Payload musst du das hier schicken: {"power":123.456,"energy_rel":null,"energy_abs":12345.6789} „power“ ist der Bezug am Hausanschluss in Watt. Negative Werte sind Einspeisung. Diesen Wert versucht der Energy Manager auf Null zu regeln. „energy_abs“ ist der Bezugszähler in kWh. Dieser Wert ist optional; du kannst auch null senden. „energy_rel“ wird beim Energy Manager nicht verwendet, darf aber nicht weggelassen werden. Die empfohlene Updatefrequenz ist einmal pro Sekunde. Häufigere Updates bringen keinen Vorteil, langsamere Updates machen die Regelung schlechter.

Dann ist das Problem wahrscheinlich folgendes: Die Wallboxen bieten eine API an, über die auch Einstellungen zurückgesetzt werden können. Das Webinterface benutzt die z.B. für die „Zurücksetzen“-Buttons. Da die API für HTTP und MQTT gleich ist, kann man auch per MQTT seine Einstellungen zurücksetzen. Wenn man ein entsprechendes Paket zum Zurücksetzen hinschickt, macht das genau das, was man möchte. Bei MQTT-Nachrichten gibt es aber das „retain“-Flag, das dazu führt, dass eine Nachricht auf dem MQTT-Broker vorgehalten wird und beim nächsten Verbindungsaufbau gleich nochmal rausgeschickt wird. Eine Zurücksetzen-Nachricht mit „retain“-Flag würde dann bei jedem Neustart der Wallbox wieder die Einstellungen zurücksetzen. Da das dämlich ist, werden Zurücksetzen-Nachrichten mit „retain“-Flag rausgefiltert. ioBroker hat nun leider zwei ungünstige Eigenschaften: Es werden leere Nachrichten mit „retain“-Flag für praktisch alle API-Endpunkte der Wallbox vorgehalten. Auch für die, von denen die Wallbox nie selbst etwas gesendet hat. Warum ioBroker das macht, wissen wir nicht. Manchmal, möglicherweise aufgrund einer uns unbekannten Einstellung im ioBroker, werden Nachrichten mit „retain“-Flag beim Verbindungsaufbau zweimal rausgeschickt: einmal mit „retain“-Flag und einmal ohne. Die erste Nachricht wird aussortiert, aber die zweite Nachricht sieht wie eine erwünschte Nachricht aus und wenn Zurücksetzen gewünscht wird, wird das halt gemacht. Wenn es das ist, können wir da leider nicht viel machen. Das wäre dann ein ioBroker-Problem. Leider wissen wir bei beiden Punkte nicht, warum ioBroker das macht oder wie man es abstellen kann.

@Bratpfanne @Waschy Was für einen MQTT-Broker verwendet ihr? Ist das zufällig ioBroker?

Da wir das hier heute auch schon einmal beobachtet haben, scheint das tatsächlich ein Problem zu sein. 😒 Beim nächsten Mal bitte auch direkt einen Debug Report runterladen.