rtrbt

On 1/5/2023 at 8:53 AM, fridolin11 said:

Kann ich die Funktion welche von ...register_callback übergeben wird irgendwie anpassen, damit der Messwert in der Main() ebene übergeben wird?

Dafür gibt es den void *user_data Parameter der Callbacks: Was auch immer du in der ...register_callback-Funktion als user_data übergibst, bekommst du in der Callback-Funktion als user_data-Parameter. Darüber kannst du dir zum Beispiel einen Pointer ins Callback stecken, der dir sagt wo die voltage hingeschrieben werden soll.

Beispielsweise (gekürzt und verändert von hier:)

// last_voltage ist hier eine globale Variable, könnte aber auch z.b. ein Struktur-Member sein.
static int32_t last_voltage;

// Callback function for voltage callback
static void voltage_handler(TF_IndustrialDualAnalogInV2 *device, uint8_t channel,
                            int32_t voltage, void *user_data) {
	(void)device; // avoid unused parameter warning
  
	int32_t *write_to = (int32_t *)user_data;  
	*write_to = voltage;
}

static TF_IndustrialDualAnalogInV2 idai;

void example_setup(TF_HAL *hal) {
	//[...]
	// Hier den Pointer übergeben, den das Callback schreiben soll
	tf_industrial_dual_analog_in_v2_register_voltage_callback(&idai, voltage_handler, &last_voltage);
	//[...]
}

Sorry hatte es gestern nicht geschafft zu antworten, das Vorweihnachtschaos halt. In den Repos sollte jetzt alles aktuell sein und zueinander passen. Außerdem habe ich im anderen Thread gerade Beta 4 veröffentlicht.

Ich habe das mit der aktuellen Version, bei der ich noch eine Reihe Bugs mit dem OCPP-Test-Tool gefunden und gefixt habe, gerade nochmal probiert und spontan nicht erzeugt bekommen.

Ich habe noch ein paar andere Tests offen, dann sollte (je nach dem wie die Tests laufen ;) ) noch eine Beta- oder auch nicht-Beta Firmware mit OCPP kommen.

28 minutes ago, binderth said:

Kann denn nicht ein UNIX-Timestamp mitgeschickt werden bei `button_press_time`?

Das solltest du eigentlich nicht brauchen: Die einzige Prüfung die du machen musst ist "ist der neue Wert ungleich dem alten", was das für Zahlen sind ist dann egal. Damit ist auch der Überlauf behandelt.

Wenn den alten Wert zu speichern anstrengend ist, kannst du aber auch auf button_pressed prüfen. Das kann aber wie gesagt je nach Timing mal einen Knopfdruck übersehen.

Den Timestamp an der Stelle mitzuschicken ist eher kompliziert, weil die Daten direkt vom Ladecontroller durchgereicht werden.

Du suchst evse/button_state.

Darin bekommst du den letzten Zeitpunkt an dem der Knopf gedrückt und losgelassen wurde, und den aktuellen Zustand (also gedrückt/nicht gedrückt). Damit du keinen Knopfdruck verpasst solltest du am besten den Befehl für sofortiges Laden rausschicken, wenn die button_press_time sich ändert. Wenn du naiv auf button_pressed guckst, kann es passieren, dass ein Knopfdruck verloren geht wenn du schnell genug drückst.

2 hours ago, binderth said:

PS: Gibt es irgendwo eine Modbus-Docu? oder ist hier ein "Ich habe den Knopf gedrückt"-Event abfragbar?

Modbus-Doku gibt es im Moment im Webinterface selbst und in der Anleitung. Auf der API-Seite auf warp-charger.com fehlt sie im Moment noch.

Firmware: WARP 2.0.9 und WARP2 2.0.11

• Modbus-TCP-Unterstützung hinzugefügt
• Watchdog gegen Ausfall der WebSocket- und Ladecontroller-Kommunikation hinzugefügt
• Lange Laufzeit wiederholter WLAN-Scans behoben
• Auslassen (optionaler) DNS-Server in statischer IP-Konfiguration repariert
• Fehlermeldungen und Parse-Geschwindigkeit von Payloads der HTTP-/MQTT-API verbessert
• Alt-Text des WLAN-RSSI-Werts repariert
• Verbindung zu NTP-Servern mit kurzem Hostnamen/IP repariert
• Auslassen des zweiten NTP-Servers erlaubt
• Logausgaben des Lastmanagements mit deaktiviertem mDNS behoben
• Konfigurations-Migration von Prä-2.0.0-Firmwares repariert
• Zurücksetzen der Konfiguration und Ladevorgänge repariert
• Zeitzonen-Datenbank aktualisiert
• Löschen noch nicht gespeicherter Benutzer repariert
• (nur WARP1) Phasen- und Details-Ansicht des Stromzählers versteckt falls nicht verfügbar

Download: WARP 2.0.9 bzw. WARP2 2.0.11

Das ist prinzipiell möglich, hat aber im Moment zwei Probleme:

1. Müssen wir dafür die Möglichkeit haben Netzwerk-Interfaces zu brücken. Das hatte ich vor einer Weile getestet, hatte aber nur so halb funktioniert: https://github.com/Tinkerforge/esp32-firmware/issues/14
2. Hat der Access Point im Moment das Problem, dass die Kommunikation zwischen Clients (also wenn du z.b. deinen Tesla und ein Handy im Netz der Wallbox hast und zwischen den beiden Daten hin- und herschickst) extrem langsam ist. Das könnte die gebrückten Interfaces auch betreffen. https://github.com/espressif/arduino-esp32/issues/6706

Eine "echte" App wird es erstmal nicht geben. Das hat zu wenig Mehrwert dafür, dass wir dann zwei Plattformen (iOS und Android) maintainen müssen. Eine PWA bzw. Schritte in die Richtung (wie das genannte Metatag) sollten wir in irgendeiner Weise umsetzen. Habe dafür mal ein Issue aufgemacht: https://github.com/Tinkerforge/esp32-firmware/issues/183

Wenn du prinzipiell das Web Interface noch erreichst, kannst du http://10.0.0.1/recovery (10.0.0.1 ersetzen durch IP oder Hostname der Wallbox) versuchen. Da gibt es einen "Force Reboot"-Button.

Leider noch nicht. Wir haben letzte Woche das OCPP-Test-Tool bekommen, damit teste ich gerade die Implementierung durch. Das dauert leider etwas, weil ich mehr mit dem Tool kämpfe (proprietäre Software halt) als dass ich Tests ausführe.

Firmware: WARP2 2.0.10

• Provisionierungsmodus repariert

Download: WARP2 2.0.10

On 11/26/2022 at 1:47 PM, poohnet said:

Beim Zurücksetzen des OCPP-Status bin ich dann auch noch über einen bösen Bug gestolpert, denn dieser scheint in der aktuellen Version nun einem Factory-Reset gleichzukommen. Jedenfalls war anschließend meine gesamte Konfiguration inkl. aller aufgezeichneter Ladevorgänge weg... 😢

Das ist natürlich fatal, kann ich hier aber nicht reproduzieren. Kannst du das nochmal ausprobieren?

On 11/26/2022 at 1:47 PM, poohnet said:

Wenn man nämlich eine Ladung über die eCarUp-App startet und diese anschließend wieder beendet, ohne zuvor EVCC freigegeben zu haben (also letztendlich gar nicht lädt), dann bleibt der Ladevorgang in der App weiterhin aktiv und WARP bekommt wieder keine Heartbeats mehr

Das müsste wieder der Bug sein, den ich eCarUp gemeldet habe: Mein StopTransaction.req wird nicht bestätigt und dann läuft der Zustand auf der WARP und bei eCarUp auseinander. Ich muss da nochmal mit Wireshark draufgucken, das Timing sieht bei dir interessant aus. Da du das auch mit SteVe erzeugen kannst, ist das natürlich noch seltsamer. Sehe ich mir mal an.

Habe den Fix gleich in OCPP-Beta 3 gepackt.

3 hours ago, poohnet said:

Wenn ich das Protokoll richtig interpretiere, dann war die Zeit zwischen dem Verbinden des Fahrzeugs und dem Start der Ladung über die eCarUp-App zu lang, sodass nach dem Status "Preparing" schon ein "Finishing" geschickt wurde

Das stimmt, das ist aber okay. Die Wallbox wartet nur eine gewisse Zeit auf ein NFC-Tag, bevor sie nach Finishing geht. Aus Finishing kannst du aber mit einem Tag (oder RemoteStartTransaction, also z.B. per App) wieder nach Preparing gehen. Das passiert in deinem Fall auch, nur dass RemoteStartTransaction sofort nach Transaction geht weil das Kabel auch angesteckt ist.

Folgendes ist aber sehr interessant: Beim Übergang nach Transaction sollte ein StartTransaction.req geschickt werden, das passiert aber nicht. Das ist auf meiner Seite kaputt. Ich sehe mir das nochmal in Ruhe an (Änderungen an dem Zustands-Automaten sind immer etwas heikel).

19 hours ago, wuesten_fuchs said:

Das war aber für obigen Fehlerfall aber auch so, da hatte ich nur die Logzeilen "unterschlagen":

Ah das erklärt warum ich das falsch interpretiert habe.

Jedenfalls: evse/start_charging (und auch /stop_charging) haben sich anders verhalten als der Taster. Du konntest damit unabsichtlicherweise eine zukünftige Ladung starten, ohne dass ein Auto angeschlossen ist. Das ist in WARP 2.0.8 bzw. WARP2 2.0.9 gefixt. Gib bitte Bescheid, falls du das Problem dann immer noch hast)

Aktualisiert bitte alle mal auf WARP 2.0.8 bzw. WARP2 2.0.9. Das Problem sollte damit weg sein. (FYI hier der Commit, der den Bug behebt: https://github.com/Tinkerforge/esp32-firmware/commit/675387f331678918176ece325fdbf83416a33ae9)

Die entsprechende Ladestromgrenze steht auf "clear_on_disconnect": true, das ist auch korrekt. In der Stromgrenze steht aber max_current 32000, so als ob jemand start_charging aufgerufen hat.

Ich habe nochmal kurz die API getestet, folgendes ist mir aufgefallen: Wenn kein Auto angeschlossen ist, Auto-Start aus ist und du den Taster drückst, dann passiert nichts, so wie man das erwarten würde. Das Webinterface lässt dich dann auch nicht auf Start klicken. Die API kannst du aber aufrufen und dann wird in die Ladestromgrenze des Auto-Starts 32000 geschrieben. Das ist inkonsistent und passt auch nicht zur Dokumentation (da steht "Ein Aufruf dieser Funktion ist äquivalent zum Starten über den Taster an der Wallbox"). Fixen wir mit der nächsten Firmware.

Eigentlich hat evse/stop_charging aber das selbe Problem, d.h. wenn das auch durchgekommen ist, hätte am 20.11. morgens die Stromgrenze wieder auf 0 gesetzt werden müssen. Eventuell Netzwerk-Probleme?

12 hours ago, deepflash said:

Da habe ich festgestellt, dass es auf der anderen Seite schön wäre, wenn man auf der Web-UI von der Wallbox alle verbundenen Modbus-Geräte angezeigt bekommen könnte. Wäre das möglich?

Es sieht so aus als wäre das leider nicht so einfach. Die Modbus-Implementierung, die wir verwenden hat die Informationen zwar intern, aber wir können die von außen nicht einfach abfragen. Ich habe mal ein Issue aufgemacht, dass wir entscheiden müssen, ob man "schlimme Dinge" programmieren möchte, um das auszulesen: https://github.com/Tinkerforge/esp32-firmware/issues/176

On 11/15/2022 at 8:50 PM, kmfrank said:

Gibt es eine Möglichkeit oder Einstellung den Ladevorgang nach dem Ende vom Stromfluß im Ladelog beendet und bei Ladebeginn neu startet?

Aktuell geht das nicht. Ich habe mal ein Issue dafür aufgemacht: https://github.com/Tinkerforge/esp32-firmware/issues/175 Wir müssen aber prüfen, ob das umsetzbar ist.

Für den maximal verfügbaren Strom ist nicht nur der Strom an den Wallboxen relevant, sondern auch wie die Zuleitungen angeschlossen sind  D.h. wenn du z.b. jede Wallbox mit 16 A abgesichert hast, und dein Hausanschluss aber nur mit 3x40A abgesichert ist, dann darfst du den maximalen Ladestrom höchstens auf 40A (eher weniger, du hast ja eventuell noch andere Verbraucher) einstellen. 64 A sind nur dann sicher, wenn deine Verkabelung (bis zu dem Punkt wo sich die einzelnen Wallbox-Zuleitungen auftrennen) das erlaubt.

On 11/16/2022 at 7:44 PM, thesaintbev said:

was passiert wenn nur eine Box lädt?

Dann lädt sie nur mit 16 Ampere. Alle aktiven Stromgrenzen (die der Dip Schalter, die des Typ-2-Kabels, des Lastmanagements usw.) werden von der Wallbox nie überschritten.