rtrbt

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.

Du benutzt connection.readHoldingRegisters versuch stattdessen mal connection.readInputRegisters

Nur um das offensichtliche auszuschließen: Du hast unter Schnittstellen -> Modbus TCP mindestens den Lesezugriff aktiviert und die WARP Charger-Registertabelle ausgewählt? Bekommst du im Ereignislog eine Ausgabe in der Art von "modbus_tcp_srvr | client connected: peer_address=123456789 port=47496"? Sorry, ich bin verwirrt. Du hast vor die Holding oder die Input Register zu lesen?

An Holding Register 1002 und 1003 liegt der von Modbus erlaubte Ladestrom, an 1004 und 1005 das Front-LED-Blinkmuster. Wolltest du stattdessen die Input Register 1002 bis 1005 lesen? Dann würdest du den Ladestatus und die User-ID zurückbekommen.

Das Problem sollte eigentlich mit WARP(1) 2.7.3 und WARP2/3 2.7.4 behoben sein. Falls du diese Firmware (oder neuer) schon hast, dann müsste ich versuchen, das hier zu reproduzieren. Das ist etwas schwierig, weil ich dafür die genauen (also die unveränderten Bytes der) Nutzernamen benötige. Dafür brauche ich von dir drei Dateien: Einen Debug-Report (kannst du unter System->Ereignislog herunterladen) Die Nutzernamen-Datei. Die kannst du herunterladen indem du mit dem Browser auf z.B. http://warp3-AbC/users/all_usernames gehst (warp3-AbC musst du auf deine Wallbox anpassen) Die getrackten Ladevorgänge im Binärformat. Die kannst du unter http://warp3-AbC/charge_tracker/charge_log herunterladen Die drei Dateien schickst du am besten per Mail an erik@tinkerforge.com oder als PM im Forum an mich.

Sollte sie eigentlich. Zieh bitte mal einen Debug-Report, wenn du das erzeugt bekommst (maximal ~ 45 Minuten später, damit die ganzen Entscheidungen noch im Log sind) Edit: Matze war schneller, trotzdem: Mit Debug-Report sehen wir was los ist.

Wir haben hier einen (sehr neuen) ID.3, der auch einmal Probleme mit der 1p->3p Umschaltung hat, das hat sich aber inzwischen gelöst. Was hast du genau für einen Softwarestand?

Hm, da habe ich einen echt blöden Logikfehler eingebaut: Eigentlich wird nur phasenumgeschaltet, wenn mindestens 9 Ampere dreiphasig (also 27 Ampere, ~ 6,2kW PV-Überschuss) zur Verfügung stehen, um die Wahrscheinlichkeit zu reduzieren, dass in ein paar Minuten wieder runtergeschaltet werden muss. (Weil die untere Ladestromgrenze ja 6 Ampere pro Phase sind). Es gibt aber eine Optimierung für den normalen Hausgebrauch (im Gegensatz zu großen Anlagen wo immer mehrere Wallboxen aktiv sind), dass wenn gerade nur maximal eine Wallbox lädt, dann schalten wir direkt bei 6 A dreiphasig (also 18 A, ~4,1kW) um. Die Logik an der Stelle war aber invertiert. Teste bitte die Firmware im Anhang, wenn die Sonne das nächste Mal scheint, damit sollte es funktionieren. Phasen angefordert bedeutet übrigens, was irgendwelche Teile der Software vom Ladecontroller selbst angefordert haben. Das ist typischerweise das Lastmanagement, die manuelle Phasenumschaltung über das Webinterface, oder auch die Erkennung einphasig ladender Autos. Edit: Veraltete Firmware entfernt.

Ich habe das mal ad-hoc implementiert: Du kannst jetzt ein anderes Energielimit auswählen, sowohl auf der Statusseite für einen Ladevorgang, als auch auf der Einstellungsseite als Standard-Limit. Es gibt aber jeweils nur einen Platz für ein eigenes Limit, also wenn du z.B. 2,5 kWh auswählst und dann danach 7 kWh auswählst, verschwindet der 2,5 kWh-Eintrag wieder. Edit: Veraltete Firmware entfernt.

Zumindest den Teil kann ich dir beantworten: Das ist eine Debug-Ausgabe die langfristig verschwinden wird. Wir haben den Modbus-Server grundlegend überarbeitet, und künftig wird dann auch im Webinterface angezeigt werden, wer gerade verbunden ist bzw. vor kurzem verbunden war und warum die Verbindung weg ist. Das existiert aber noch nicht, deshalb steht die Information erstmal im Ereignislog. Die Victron-Software scheint zum Auslesen der Wallbox aber nicht einfach eine TCP-Verbindung offen zu halten, sondern alle 10 Sekunden eine Verbindung aufzubauen, die Register zu lesen und die Verbindung dann wieder zu trennen. Das führt dann zu maximalem Logspam. Was mir nicht klar ist: Das Script, dass die Victron-Integration hinzufügt, kommuniziert über HTTP mit der Wallbox, nicht mit Modbus TCP. Hast du noch mehr konfiguriert? Irgendwas muss das Victron-Gerät ja dazu bringen, eine Modbus-TCP-Verbindung zur Wallbox aufzubauen. Wie du willst. Hier bekommen es typischerweise mehr Leute mit -> Du bekommst schneller eine Antwort. Das ist so von Victron vorgegeben: https://github.com/victronenergy/venus/wiki/dbus#evcharger Autostart benutzt im Endeffekt die evse/auto_start_charging-API. Das ist also das, was du als "manuelle Ladefreigabe" im Webinterface aktivieren kannst. Enable Charging scheint auf /StartStop zu mappen, und damit auf unsere evse/start_charging und /stop_charging-API. Damit kannst du also den Ladevorgang einmal stoppen oder starten, je nachdem. Wenn du damit sowieso gerade rumspielst, teste bitte mal diese Version, falls du Muße dazu hast: https://github.com/Tinkerforge/dbus-warp-charger/blob/main/dbus-warp-charger.py Der einzige Unterschied sollte sein, dass jetzt /MaxCurrent und /SetCurrent implementiert sind, du solltest also einmal den maximal erlaubten Strom (der auch gespeichert wird) setzen können und per /SetCurrent den Strom beliebig verstellen.

Firmware: WARP1 2.7.1, WARP2 2.7.2, WARP3 2.7.2, WARP Energy Manager 2.3.1, WARP Energy Manager 2.0 1.2.1 Zähler-Messort hinzugefügt (Nur WARP Energy Manager, WARP Energy Manager 2.0) Leistungsübersicht zur Status-Seite hinzugefügt Lastmanagement: Min+PV-Lademodus repariert Lastmanagement: Min-Lademodus repariert Mehrere Fernzugriffs-Bugs behoben Zeitzonen-Datenbank aktualisiert Übersetzungen verbessert Download: WARP1 2.7.1 bzw. WARP2 2.7.2 bzw. WARP3 2.7.2 bzw. WARP Energy Manager 2.3.1 bzw. WARP Energy Manager 2.0 1.2.1

Laut Debug-Report hast du bei den Lastmanagement-Experteneinstellungen den Spielraum des Phasenstroms auf 1A gesetzt (default sind 3A). Das ist vermutlich zu wenig: Der Zoe bleibt gerne mehr als ein Ampere unter dem vorgegebenen Strom. Der Spielraum ist im Endeffekt wie viel Strom das Lastmanagement der Wallbox mehr zuteilt, selbst wenn wir sehen, dass das Auto nur weniger zieht. Deshalb bekommst du, wenn 15,4A gezogen werden 16,4A zugeteilt. Wenn du den Spielraum erhöhst, dann werden z.B. 18,4A zugeteilt, wenn 15,4 gezogen werden. Das sollte dann dazu führen, dass der Zoe mehr zieht (und dann wieder mehr zugeteilt wird usw.) Hier nochmal graphisch: X ist erlaubter Ladestrom, Y ist reell gezogener Strom. Der Spielraum muss größer sein, als der Abstand zwischen der Ideallinie und dem was das Auto wirklich zieht. (Die Daten findest du hier: https://github.com/Tinkerforge/warp-charger/blob/master/tools/current_ramp/allowed_vs_effective_3.gp falls du damit spielen möchtest. Wir messen immer alle Autos, die wir in die Finger bekommen, einmal durch, damit wir ein Gefühl bekommen, wie man diese ganzen Stellschrauben einstellen sollte)