rtrbt

Firmware: WARP1 2.6.1, WARP2 2.6.1, WARP3 2.6.1

• Unterstützung für weitere Modbus-TCP-Geräte hinzugefügt: GoodWe Hybrid-Wechselrichter
• Registrierung des Fernzugriffs mit Safari repariert
• Benutzerinterface der Registierung des Fernzugriffs verbessert
• Benutzerinterface der Stromzähler-Unterseite verbessert
• Sichergestellt, dass Stromzählergraph nur angezeigt wird, wenn Zähler verbunden ist
• (Nur WARP3) Repariert, dass WARP Energy Manager einen WARP3 Charger zu einphasigem Laden gezwungen hat
• Repariert, dass Lastmanagement ein Fahrzeug nicht als voll erkannt hat, wenn der Ladevorgang sofort (durch einen A->C-Übergang) gestartet wurde (Durch Update auf Ladecontroller-Firmware 2.1.12 (WARP1) bzw. 2.2.6 (WARP2, WARP3))

Download: WARP1 2.6.1 bzw. WARP2 2.6.1 bzw. WARP3 2.6.1

Die Pin-Belegung kannst du im Schematic des Ladecontrollers nachsehen: https://github.com/Tinkerforge/evse-v3-bricklet/blob/main/hardware/evse-v3-schematic.pdf

Von Pin 1 (links) an:

1. 5V
2. LED Rot
3. LED Grün
4. LED Blau
5. Switch
6. Ground

Der Taster ist ein Öffner, d.h. wenn du Pin 5 und 6 verbindest, dann betrachtet der Ladecontroller den Knopf als nicht gedrückt, wenn du die Pins nicht verbindest, dann ist der Knopf gedrückt.

On 9/11/2024 at 5:45 PM, universal-dilettant said:

Ich habe mich nicht mit der Architektur der WB Software befasst und kenne die Abhängigkeiten nicht. Eine Möglichkeit, breaking changes zu mitigieren wäre jedoch sicherlich, den meters output (und ggf. anderen) konfigurierbar zu machen. Man taggt in der WEB UI diejenigen Felder, die man gerne im Output hätte, und es werden die entsprechenden mqtt messages, die für sich eineindeutig sind, generiert. Meinethalben auch noch mit einem Intervall, so dass nicht jede Sekunde, sondern nur alle x sec dieser zusätzliche Output erzeugt wird. Und wenn du es richtig geil machen willst, machst du auch die Namen der topics konfigurierbar :-)

https://github.com/Tinkerforge/esp32-firmware/issues/36 steht auf der Liste, aber wie du siehst schon länger :D

Schon. Führt dann aber unter anderem dazu dass 1. die API an der Stelle auseinanderläuft zwischen den Wallbox-Varianten (das wäre hässlich aber notfalls verschmerzbar) und 2. dann wieder andere Leute hier im Forum sich beklagen, dass wir unnötig viel Traffic per MQTT rausschicken. API-Design ist schwierig (und bei der Wallbox definitiv nicht optimal, aber brechende Änderungen nach Jahren tun weh) und wir balancieren oft mehr Anforderungen, als man auf den ersten Blick sieht.

Wir haben u.A. vor irgendwann in der Zukunft eine vereinfachte API zu entwickeln, als Alternative zum Vollausbau, der im Moment existiert (und teilweise auf die Anforderungen des Webinterfaces zugeschnitten ist). Eventuell können wir da auch eine einfacher zu benutzende Variante des Meldens von Zählerdaten einbauen.

Um dein konkretes Problem zu lösen: Es gibt z.B. das final-Plugin für telegraph: https://docs.influxdata.com/telegraf/v1/plugins/#aggregator-final mit dem du anscheinend zwei Datenquellen zusammenlegen kannst. Dann hast du IDs und Messwerte auf einem "Topic" (oder wie das in Influx-sprech auch immer heißt) und das Plugin sollte für dich auch das Reihenfolgenproblem lösen. (Disclaimer: Ich bin kein Influx-Experte, aber es klingt als könnte das irgendwie funktionieren)

Edit: Alternativ gibt es noch das merge-Plugin: https://github.com/influxdata/telegraf/blob/release-1.31/plugins/aggregators/merge/README.md damit hatte jemand, der deinen Use-Case hatte aber Probleme: https://community.influxdata.com/t/why-are-my-fields-from-mqtt-topics-not-merged/32929 und wurde auf das final-Plugin verwiesen.

Es gibt ocpp/state und darin das Feld "connected". ocpp/state ist im Moment aber absichtlich undokumentiert, weil wir uns noch die Möglichkeit offenhalten wollen, die API zu ändern.

Fairerweise: Ich bekome es gerade nicht hin (ohne das Vorwissen einzusetzen, dass ich die API kenne), die Suche der API-Dokumentation davon zu überzeugen, mich zu evse/indicator_led zu führen. Mal sehen ob wir die Suche etwas tunen konnen.

Edit: Ja, da ist irgendetwas mit der Suche kaputt. Ich kann nach beliebigen APIs suchen (z.B. nfc/config oder auch energy_manager/sdcard_state) aber nicht nach evse/ APIs. Die tauchen nicht auf.

(Achtung Totschlagargument! :D ) Das hat technische Gründe. Konkret: Der Mikrocontroller, den wir benutzen, hat nur begrenzt RAM. Deshalb müssen wir die Maximallänge von APIs beschränken, gerade von APIs die sich oft ändern, weil dann viele MQTT-Pakete generiert werden, die sich bei eventuell langsamen WLAN durchaus mal aufstauen können. Die IDs (die sich nur maximal einmal ändern sollten) und die Werte (die sich sekündlich ändern können) zu koppeln würde dazu führen, dass deutlich größere MQTT-Pakete generiert werden. Das wird auf einer WARP1 (die weniger RAM als eine WARP2 oder 3 hat) dann eng.

Das Lastmanagement ist in der frisch veröffentlichten Firmware 2.6.0 enthalten. Danke fürs testen!

@pene8@dinkel1975 Testet bitte beide mal die Firmware im Anhang. Problem Nummer 2 sollte damit behoben sein. Das ist jetzt eine Firmware mit dem Stand von 2.5.0 + Lastmanagement-Beta, d.h. mit Fernzugriff usw., falls ihr damit spielen wollt.

Edit: Veraltete Firmware entfernt.

Leider noch nicht. Es gibt ein offenes Issue dazu, damit wir das Problem nicht vergessen. https://github.com/Tinkerforge/esp32-firmware/issues/262

On 9/3/2024 at 2:02 PM, mrks said:

Evtl. könnt ihr den kleinen Typo im PDF Export noch korrigieren :)

Erledigt, danke für den Hinweis :) https://github.com/Tinkerforge/esp32-firmware/commit/7478a93af5469069ae14c3d1070b3e304afc4d38

Du musst dir zwei Keypaare generieren (wie z.b. hier beschreiben: https://wiki.archlinux.org/title/WireGuard#Key_generation) und dann die entsprechenden Schlüssel verteilen. Wenn du zum Beispiel mit

wg genkey | (umask 0077 && tee warp.key) | wg pubkey > warp.pub

wg genkey | (umask 0077 && tee peer.key) | wg pubkey > peer.pub

die Keys erstellst, dann musst du auf der Wallbox warp.key als eigenen privaten Schlüssel und als öffentlichen Schlüssel der Gegenstelle. Bei deiner Gegenstelle musst du dann peer.key als dessen privaten Schlüssel konfigurieren und warp.pub als öffentlichen Schlüssel (der Gegenstelle der Gegenstelle, also der Wallbox)

On 8/29/2024 at 1:04 AM, MatzeTF said:

esp32/temperature

Fairerweise: Die API ist nicht dokumentiert, weil ich mir offen halten will, sie nochmal zu ändern.

Wenn der charger_state == 3 ist solltest du eventuell noch auf evse/low_level_state["time_since_state_change"] nachsehen, dass nicht jetzt gerade angefangen wurde zu laden. Das sind Millisekunden, also kannst du z.B. auf > 40000 prüfen, um dem Auto 40 Sekunden zu geben, mit dem Ladevorgang anzufangen. 40 Sekunden ist ein sinnvoller Wert, weil die Wallbox nach 30 Sekunden einmal versucht das Auto per CP-Trennung zu wecken. Es ist robuster, wenn du nicht genau während der CP-Trennung stop + start aufrufst, sonst sieht das Auto das nicht.

Die Ladeleistung kannst du auf zwei Arten abfragen:

1. Über die alte Meter-API https://docs.warp-charger.com/docs/mqtt_http/api_reference/meter#meter_values_warp3 z.B. mit curl -s http://$HOST/meter/values | jq .power

2. Über die neue Meters-API (die ist komplizierter, aber flexibler) https://docs.warp-charger.com/docs/mqtt_http/api_reference/meters#meters_X_values_warp3 z.B. mit curl -s http://$HOST/meters/0/values | jq '.[24]' Dass du auf Index 24 zugreifen musst, kannst du wie folgt herausfinden: https://docs.warp-charger.com/docs/mqtt_http/api_reference/meters#meters_X_value_ids_warp3 gibt dir die IDs der Messwerte des gewünschten Zählers (Zähler 0 ist der in der Wallbox verbaute), die Liste der IDs und deren Bedeutung findest du hier: https://github.com/Tinkerforge/esp32-firmware/blob/master/software/src/modules/meters/meter_value_id.csv und auf der Liste suchst du Power Active LSum ImExDiff (Die Active Power, also Wirkleistung, summiert über alle drei Phasen, Import (also Bezug des Autos) - Export (theoretisch mögliche Einspeisung des Autos))

Edit: Da warst du schneller :D

Damit ich das Protokoll richtig lese (Siehe Zahlen im Graph)

1. Du hast das Protokoll gestartet, als du gerade in dem Zustand warst, dass das Auto nicht laden wollte,
2. hast dann Stop+Start gedrückt
3. dann hat es dreiphasig angefangen zu laden.
4. Dann hast du auf einphasig umgeschaltet,
5. das Auto lädt wieder.
6. Dann hast du auf dreiphasig umgeschaltet und das Auto lädt nicht mehr.
7. Dann hast du ~ 4 Minuten später Stop+Start gedrückt

Das Auto sieht die Phasenumschaltung und fordert dann wieder Strom an (das sind die beiden rot eingekreisten Stufen bei 4 und 6 auf dem CP-Widerstands-Messwert). Bei einer Phasenumschaltung geht der CP-Widerstand auf "unendlich" also ~ 4 Milliarden Ohm, weil die Wallbox die CP-Leitung trennt, dann die Phasen umschaltet und dann die CP-Leitung wieder verbindet. Dann sehen wir kurz 2700 Ohm (das bedeutet, dass ein Auto angeschlossen ist, aber nicht lädt) und kurz danach 880 Ohm (das bedeutet, dass das Auto Strom anfordert). Das Schütz wird dann wieder durchgeschaltet, das Auto zieht dann aber keinen Strom, obwohl es könnte.

Zwei Fragen dazu:
1. Hast du bei 6. auf dreiphasig umgeschaltet? Das Timing ist extrem interessant, weil diese Umschaltung genau 30 Sekunden nach der 3->1phasig-Umschaltung passiert. Wir haben einen anderen Prozess, der 30 Sekunden nach der Ladefreigabe CP trennt, aber nur, wenn das Auto nicht die 880 Ohm anlegen würde. Das sollte bei dir nicht passieren.

2. Wenn du die Wallbox auf einphasig stellst, dann das Auto ansteckst, es > 5 Minuten laden lässt und erst dann auf dreiphasig umschaltest, funktioniert das ohne dass du Stop+Start drücken musst?

Edit: Wenn du den Graph im Original sehen willst, kannst du das Debug-Protokoll auf https://vislog.warp-charger.com/ hochladen. Das ist aber noch etwas experimentell.

Unter Wallbox -> Ladestatus kannst du ein Lade­proto­koll erstellen. Drücke da mal auf Start (ab dann musst du den Tab auflassen, kannst aber zurück auf die Statusseite gehen) und mach dann die einphasig -> dreiphasig-Umschaltung. Dann warte 2 Minuten und drück Stop + Download. Das Log kannst du hier anhängen, eventuell sehen wir dann noch etwas. Prinzipiell sieht das aber nicht gut aus. Wenn die Wallbox auf Ladebereit steht, dann muss das Auto Strom anfordern, sonst passiert nichts.

Firmware ist aktuell? Wir hatten bei anderen Autos das Problem, dass der Weckruf (das ist eine Trennung der CP-Leitung für ein paar Sekunden, womit dem Auto vorgetäuscht wird, dass du das Kabel Wallboxseitig rausgezogen hast) zu kurz war. Deshalb machen wir seit Firmware 2.3.0 noch eine 30 Sekunden lange Trennung, wenn die kürzere nicht geholfen hat.

Ansonsten scheint das beim 500e ein häufiges Problem zu sein, z.B. hier haben mehrere Leute das Problem spezifisch bei einer Phasenumschaltung und verschiedensten Wallboxen: https://www.goingelectric.de/forum/viewtopic.php?f=231&t=69865

Was für einen Ladestrom gibst du vor, wenn du auf dreiphasig wechselst? Ich habe den goingelectric-Thread nur grob überflogen, aber es scheint da Probleme zu geben, wenn der Ladestrom zu niedrig ist. Z.B. bei Renault Zoes und älteren elektrischen Smarts gibt es das Problem, dass dreiphasig erst ab ~ 9 A effizient geladen wird.

Ja, in evse/low_level_state. Die API für die ESP-Temperatur ist noch undokumentiert, damit wir die nochmal ändern können. Im Moment haben wir die Temperaturdaten, aber fangen damit noch nichts an.

On 8/7/2024 at 7:22 PM, alestrix said:

D.h., wenn ich noch einen weiteren API Zähler "0" anlege und dem regelmäßig die Werte vom Wallbox-Stromzähler übermittle, dann funktionieren auch so Dinge wie Energielimit?

Genau.

On 8/7/2024 at 7:22 PM, alestrix said:

Ah, nein, hab's mit dem Watchdog verwechselt. Ich nehme an, der Watchdog bezieht sich auf den Netzanschlusszähler, die Zählerüberwachung auf den Wallboxzähler?

Fast. Der Watchdog ist nur relevant, wenn du direkt auf charge_manager/available_current_update schreibst. Also "statisches" Lastmanagement machst, aber selbst den verfügbaren Strom per API vorgibst und dann sichergehen willst, dass wenn das Programm crasht, dass die API befüllt, nicht der letzte verfügbare Stromwert weiter verwendet wird.

Wenn du einen API-Zähler für den PV-Überschuss verwendest dun dann dein Programm crasht, wird im Moment der letzte Wert weiterverwendet. Auf der TODO-Liste steht, damit auch umzugehen, das wird im Zuge des dynamischen Lastmanagements kommen.

On 8/17/2024 at 4:53 PM, Henrik said:

Failed to deserialize: Payload was empty. Please send valid JSON

Laut Fehlermeldung sieht die Wallbox keinen Payload, was seltsam ist. Wie schickst du den HTTP-Request oder die MQTT-Nachricht?

On 8/17/2024 at 4:53 PM, Henrik said:

2) Wenn ist diesen Parameter in der WebGUI ändern will (Manual charge release, inhaltlich umgekehrte Logik, aber egal), dann muss einmal ein Reboot durchgeführt werden. Muss ich hier etwas über die Schnittstelle bedienen, oder geht das automatisch?

Der Auto-Start (bzw. manual charge release im Webinterface; ist übrigens umgekehrt, weil anscheinend die Nutzer so weniger verwirrt sind) ist eine der wenigen Einstellungen, die sofort greifen, das weiß aber das Webinterface nicht. D.h. wenn du nur den verstellst, kannst du dir den Neustart sparen. Jede Änderung des Auto-Starts wird aber in den Flash des Ladecontrollers geschrieben, du solltest den Wert also nicht zu oft schreiben (z.B. stündlich ist okay, sekündlich nicht), damit der Flash nicht abgenutzt wird.