rtrbt

Firmware: WARP1 2.8.5, WARP2 2.8.5, WARP3 2.8.5, WARP Energy Manager 2.4.5, WARP Energy Manager 2.0 1.3.5 (Nur WARP1, WARP2, WARP3) Hinzugefügt, dass Stromzähler verwendet wird um die Versorgungsspannungen zu prüfen Sichergestellt, dass Debug-Report niemals WireGuard-Keys enthält Striktheit der Prüfung eingegebener IP-Adressen erhöht, um Tippfehler zu vermeiden (Nur WARP3) Behoben, dass Phasenumschaltung zu langsam durchgeführt wurde, wenn das Fahrzeug wieder schnell genug reagiert (durch Update auf Ladecontroller-Firmware 2.2.13) Modbus TCP: PV-Leistung für Deye-Niederspannungs-Hybrid-Wechselrichter repariert Übersetzungen verbessert Download: WARP1 2.8.5 bzw. WARP2 2.8.5 bzw. WARP3 2.8.5 bzw. WARP Energy Manager 2.4.5 bzw. WARP Energy Manager 2.0 1.3.5

Siehe auch https://www.meinid.com/thread/9219-probleme-mit-ladepausen-beim-photovoltaik-überschussladen-mit-software-5-4 Das Problem tritt mit diversen Wallboxen, auch denen von VW selbst auf.

Leider nicht. Die Ladefreigaben (von denen OCPP und die "externe Steuerung" also meistens MQTT) sind alle parallel, es müssen also alle Freigaben, die aktiv sind, freigeben. Kurze Bestandsaufnahme: Die Freigabe über EVCC läuft über die Fahrzeugerkennung? Oder benutzt du da ein NFC-Tag, dass EVCC kennt? Wie gehst du im Moment mit dem anderen Fall um, dass EVCC blockiert, wenn OCPP freigibt?

Firmware: WARP1 2.8.4, WARP2 2.8.4, WARP3 2.8.4, WARP Energy Manager 2.4.4, WARP Energy Manager 2.0 1.3.4 (Nur WARP1, WARP2, WARP3) Fronttaster-Zustandsregister zur WARP-Modbus-TCP-Registertabelle hinzugefügt Modbus TCP: Unterstützung für Carlo Gavazzi EM580-Stromzähler hinzugefügt Modbus TCP: Unterstützung für Fox ESS H3 Smart und Pro Wechselrichter hinzugefügt Modbus TCP: Unterstützung für virtuellen Last- und PV-Stromzähler für Fox ESS-Wechselrichter hinzugefügt Modbus TCP: Unterstützung für virtuellen PV-Stromzähler für GoodWe-Wechselrichter hinzugefügt Modbus TCP: Unterstützung für Solax String-Wechselrichter hinzugefügt Modbus TCP: Unterstützung für virtuellen PV-Stromzähler für Solax-Wechselrichter hinzugefügt Modbus TCP: Unterstützung für virtuellen PV-Stromzähler für Sungrow-Wechselrichter hinzugefügt Modbus TCP: Voreingestellten Messort für Carlo Gavazzi EM270- und EM280-Stromzähler repariert Modbus TCP: Fox ESS-Wechselrichter Netzanschluss-Energie-Export-Wert repariert Modbus TCP: GoodWe-Wechselrichter Leistungswerte und Leistungsfaktoren sowie Lastenergiewerte repariert Modbus TCP: Behandlung des GoodWe-Wechselrichter-Batteriespeichers repariert Modbus TCP: Alpha ESS / Hailei-Wechselrichter PV-Energiewert repariert Modbus TCP: Virtueller Victron Energy GX-Wechselrichter-Stromzähler auf PV umgestellt Robustheit der SMA Speedwire-Implementierung verbessert Robustheit von WireGuard und Fernzugriff verbessert (Nur WARP1, WARP2, WARP3) Repariert, dass Ladelimits nicht korrekt wiederhergestellt wurden (Nur WARP2, WARP3) Standardkonfiguration der von OCPP gesampleten Zählerwerte korrigiert (Nur WARP1, WARP2, WARP3) Ladetracker: Hinzugefügt, dass gespeicherter Briefkopf gelöscht werden kann mDNS-Spam behoben (Nur WARP Energy Manager) Abschalten des Schützes bei Fehlern repariert (Nur WARP Energy Manager) Sichergestellt, dass Schützfehler nur beim Auftreten gemeldet wird (Nur WARP Energy Manager, WARP Energy Manager 2.0) Jahr der Echtzeituhr repariert, falls diese noch nicht gestellt wurde (Nur WARP2, WARP3) Unterbrechungen des Ladevorgangs mit BMW PHEVs behoben (durch Update auf Ladecontroller-Firmware 2.2.12) (Nur WARP2, WARP3) Behoben, dass Phasenumschaltung zu schnell durchgeführt wurde, wenn das Fahrzeug nicht reagiert; behebt Probleme mit Polestar EVs (durch Update auf Ladecontroller-Firmware 2.2.12) (Nur WARP2, WARP3) Sichergestellt, dass Schützprüfung nicht direkt nach einem Neustart kurz einen Fehler meldet (durch Update auf Ladecontroller-Firmware 2.2.12) (Nur WARP2, WARP3) Dritten und vierten Versuch des Fahrzeug-Weckrufs (mittels IEC-Zustand F) hinzugefügt (durch Update auf Ladecontroller-Firmware 2.2.12) Übersetzungen verbessert Download: WARP1 2.8.4 bzw. WARP2 2.8.4 bzw. WARP3 2.8.4 bzw. WARP Energy Manager 2.4.4 bzw. WARP Energy Manager 2.0 1.3.4

Dafür musst du übrigens den EM300 auswählen. Mit der nächsten Firmware wird der EM340 mit erwähnt: https://github.com/Tinkerforge/esp32-firmware/commit/563ec60583389d03fb3422c23d5d7a3d41415d21

https://github.com/Tinkerforge/dbus-warp-charger die hohe CPU-Load sollte gefixt sein. Stellt sich raus das Script hat alle 250ms 9 HTTP-Requests gemacht, das war etwas viel. Es gibt jetzt in der config.ini den Wert UpdateInterval, der angibt wie oft die Daten aktualisiert werden, mit default 1 (=Sekunden). Außerdem macht ein Update nur noch die Hälfte an Requests und die Auto-Start-Logik war kaputt, das sollte jetzt auch passen.

Die config liest nicht den error_state, sondern den charger_state. charger_state 4 bedeutet, dass irgendein Fehler vorliegt.

Leider noch nicht.

Zieh bitte einmal einen Debug-Report (unter System->Ereignislog) und poste ihn hier oder schicke ihn an erik@tinkerforge.com

Das steht leider nicht direkt auf der API, sondern das Webinterface baut den Text zusammen. Im Endeffekt musst du evse/slots auswerten. Jeder Slot dessen Wert gleich dem Minimalwert ist, ist einer der vom Webinterface aufgelistet werden würde. Die Namen der Slots findest du z.B. hier: https://github.com/Tinkerforge/esp32-firmware/blob/586496e0e54e6ab4c4fa5e9efe5e6e9877dae3ff/software/web/src/modules/evse_common/translation_de.tsx#L123-L139 (da steht ein TODO an der API-Dokumentation, weil die Slotnamen fehlen, das hat leider noch keiner geschafft einzubauen)

Das liegt vermutlich daran, dass deine WARP2 als Energiewert (für Ladetracker usw.) noch den Bezugs + Einspeisungswert verwendet. Der wird dann auch im Modbus Register 2004 ausgegeben. Details hier: https://www.tinkerforge.com/de/blog/new-features-in-warp2-221-and-wem-202/ (letzte Zwischenüberschrift) Du kannst jetzt entweder stattdessen Register 2160 lesen oder wie im Blogpost beschrieben einmal die aufgezeichneten Ladevorgänge löschen, dann wechselt die Wallbox auf den Bezugswert. (Oder das "offizielle" Registerset aus der Testfirmware verwenden)

Genau, die werden nur im RAM gehalten. 7680 Ladevorgänge lang. Da war die Idee, dass selbst eine sehr gut genutzte Wallbox (10 Ladevorgänge am Tag) mehr als 2 Jahre aufzeichnen können soll. Wenn die 7680 Ladevorgänge erreicht sind, wird der erste Block (256 Ladevorgänge) weggeworfen, damit neue aufgezeichnet werden können.

Uns ist adhoc nicht klar, wie es sein kann, dass die Konfiguration kaputt ist. Versuch bitte mal die Firmware im Anhang. Die sollte dir ins Ereignislog ausgeben, was in der Konfiguration drin steht. [Edit: Test-Firmware entfernt]

Du kannst übrigens unter Energiemanagement -> Lastmanagement die Details aufklappen und da bei den Limits einen Blick auf PV Min werfen. Das ist der Wert, der mindestens bei 18,000 A (= 4140W/230V) liegen muss. Edit: Drei Phasen -> 18 A statt 6.

Laut https://docs.evcc.io/docs/devices/chargers#solaredge-home-ev-charger spricht die SolarEdge-Wallbox Modbus TCP mit dem selben Registerset wie die Keba Wallboxen. Das Keba-Registerset kann der WARP Charger emulieren (unter Schnittstellen -> Modbus TCP aktivieren und als Registerset "Kompa­tibel zu Keba P30 C-Series" auswählen) Mit Glück funktioniert das dann einfach.

Das Verhalten kennen wir von fast allen VWs: Wenn der Stecker nicht ganz drin steckt, dann kann das Auto nicht den Verriegelungsstift ausfahren und lädt in einer Art Notlademodus. Siehe z.B. hier

Hier noch mehr Leute mit dem selben Problem (und auch anderen Wallboxen. Das Verhalten von EVCC ist aber sehr ähnlich zu dem was wir tun) https://github.com/evcc-io/evcc/discussions/15964

Leider nur noch die absurden: Es gibt bei diversen VW-Autos (auch Cupra, Skoda usw.) Probleme nach dem Software-Update auf/über Version 3.7, wenn du die per OTA-Update (also nicht in der Werkstadt) bekommen hast. Abhilfe schafft da gerüchteweise, wenn du eine bestimmte Sicherung im Motorraum ziehst. Siehe z.B.: https://github.com/evcc-io/evcc/discussions/12791 und

Das ist geplant, aber leider noch nicht implementiert: https://github.com/Tinkerforge/esp32-firmware/issues/47

Ja. Ich wollte schon die Screenshots von warp-charger.com verlinken, aber in der Tat sind die alle nicht im Handy-Modus. Guck alternativ mal hier: https://play.google.com/store/apps/details?id=com.tinkerforge.warp Das ist unsere App, die aber 1:1 das Webinterface durchreicht (Sinn der App ist, dass du von außerhalb deines Heimnetzes auf die Wallbox zugreifen kannst. Ist komplett optional, aber ganz praktisch) Von den Screenshots werden wir ein paar zu den Impressionen packen, danke für den Hinweis! Demo-Webinterface ist angedacht (siehe https://github.com/Tinkerforge/warp-charger/issues/31), aber noch nicht implementiert.

Das Webinterface sollte mit allen modernen Browsern problemlos funktionieren, ansonsten ist das ein Bug, den wir fixen müssen. Es gibt ein paar Einschränkungen bei Safari, die wir nicht oder nur mit sehr viel Aufwand fixen können: Die Anmeldeseite sieht nicht so schön aus wie in Firefox/Chrome/Edge/... und das Passwort muss ggfalls zwei Mal eingegeben werden: https://github.com/Tinkerforge/esp32-firmware/issues/342 Die Fortschrittsanzeige bei der Firmware-Aktualisierung springt sofort auf 100%: https://github.com/Tinkerforge/esp32-firmware/issues/180 Ansonsten wäre mir im Moment nichts bekannt. Es gab immer mal kleinere Bugs bei Nischenbrowsern wie z.B. dass der DuckDuckGo-Browser auf Android eine ganze Weile lang keine Debug-Reports herunterladen konnte: https://github.com/duckduckgo/Android/issues/1010#issuecomment-1006492456 das ist inzwischen aber gefixt.

Ich habe gerade versucht dein Problem mit den Zugangsdaten zu reproduzieren, bei mir funktioniert es aber auf einer frischen WARP3 mit Firmware 2.7.6 einen Nutzer anzulegen, dann auf 2.7.3 downzugraden und mich dann einzuloggen. Hattest du Test-Firmwares aus dem Forum laufen und wenn ja, welche? Edit: Ich frage das, weil der Login in der Tat kaputt war, aber nur in einem Firmware-Stand, den du nicht gehabt haben solltest, soweit ich den Thread hier nachgelesen habe.

Wie lange wartest du zwischen disconnect true und disconnect false? Versuch mal CP mindestens 60 Sekunden getrennt zu lassen.

Genau, der Fix ist in 2.7.6 schon drin. Fast genau so funktioniert das Lastmanagement schon: Es wird erst dann auf dreiphasig umgeschaltet, wenn das 1. notwendig ist und 2. vermutlich nicht sofort wieder auf einphasig gewechselt werden muss. 1. bedeutet, dass nur umgeschaltet wird, wenn das Lastmanagement feststellt, dass es den PV-Überschuss nicht einphasig los wird. 2. bedeutet, dass der PV-Überschuss mindestens für die Dauer des Wolkenfilters der dreiphasige Minimalstrom gewesen sein muss. Die Details sind noch etwas komplizierter, du kannst dir https://docs.warp-charger.com/docs/tutorials/charge_management_details mal ansehen, wenn du möchtest. Das ist leider schon wieder etwas veraltet (weil die Änderungen für Wallboxen in verschiedenen Lademodi noch nicht berücksichtigt sind), die Grundlagen stimmen aber noch.

Versuch mal direkt console.log(data.response.data) anstatt von const test = Buffer.from( data.response.data ) console.log( test ) data.response.data ist schon ein Array von Buffern. Ich bekomme [ <Buffer 00 00>, <Buffer 00 01>, <Buffer ff ff>, <Buffer ff ff> ] wenn ein Auto angesteckt ist, also einen Buffer pro Register mit je 2 Byte drin. Du müsstest dann noch herausbekommen, wie man aus jeweils zwei Buffern eine 32-Bit-Zahl macht.