rtrbt

Das Lastmanagement zwischen den Wallboxen ist auf maximal 10 limitiert. D.h. eine Wallbox kann sich selbst und bis zu 9 andere managen. Wenn du mehr brauchst, kannst du beispielsweise einen OCPP-Server einsetzen (OCPP ist gerade am Ende der Beta-Phase) oder künftig (lies: nicht bei Release) wird das auch über den WARP Energy Manager möglich sein.

Seltsam. Kannst du, falls du die Recovery-Seite erreichst das nächste Mal einen Debug-Report herunterladen und hier posten? Vielleicht sehen wir dann mehr.

Es gibt hier: https://github.com/Tinkerforge/cases die FreeCAD-Dateien der Gehäuse. Das Gehäusedesign ist aber für einen Laser-Cutter gemacht, d.h. Platten zum zusammenstecken. Alternativ gibt es Step-Modelle jedes Bricks/Bricklets auf dessen Hardwaredokumentationsseite, falls du dir ein eigenes Gehäuse designen willst: https://www.tinkerforge.com/de/doc/Hardware/Bricklets/Bricklets.html

Github sagt vorgestern 14:10 :P Ich wollte dir gestern noch schreiben, aber das macOS-Update auf dem Firmen-Mac hatte sich etwas gezogen. Ist jetzt da, die Bugs sollten gefixt sein.

Siehe hier

Moin, Du kannst der Wallbox ein https://www.tinkerforge.com/de/shop/bricklets/real-time-clock-v2-bricklet.html nachrüsten. Damit wird die Systemzeit automatisch gesetzt wenn du das Webinterface mit deinem Handy aufmachst und durch die Batterie auf den Bricklet auch über System-Neustarts erhalten. Dafür brauchst du noch ein 7p-7p-Kabel (6cm reichen, das Bricklet wiegt praktisch nichts, das kannst du einfach in die Box hängen) Bist du schon auf >= 2.0.9? Dann sollte genau das nicht mehr auftreten. Falls du das mit 2.0.9 aufwärts noch erzeugt bekommst: Kannst du dann http://10.0.0.1/recovery noch erreichen?

Nein, das IO-16 Bricklet unterstützt nur Signale mit 3,3 bzw. 5 Volt. Für Eingangsspannungen bis 36V kannst du das Industrial Digital In Bricklet verwenden: https://www.tinkerforge.com/de/doc/Hardware/Bricklets/Industrial_Digital_In_4_V2.html#industrial-digital-in-4-v2-bricklet

Moin, Versuche bitte einmal den NFC-Leser zurückzusetzen. Das kannst du am einfachsten mit einem Browser tun, indem du http://warp2-abcd/nfc/reset aufrufst. (warp2-abcd durch den Hostnamen oder die IP deiner Wallbox ersetzen). Da erscheint nur eine leere Seite, aber der NFC-Reset wird dann ausgelöst. Falls das nicht hilft, kannst du noch versuchen die ganze Wallbox einmal vom Strom zu trennen.

Das ist gut. Dann können wir seltsame Steuerungsversuche von EVCC ausschließen. Ist der Rechner mit dem du das Ladeprotokoll aufzeichnest auch im WLAN? Eventuell war das Problem in dem Moment, dass der Rechner kurz keinen Empfang hatte. Rein technisch muss das Auto die Ladung starten: Das funktioniert so, dass die Wallbox dem Auto (über ein PWM-Signal) mitteilt wie viel Strom gerade erlaubt ist und das Auto auf das Signal einen Widerstand anlegt. Je nach Größe des Widerstands will das Auto laden (880 Ω) oder nicht (2700 Ω). Den Widerstand zurückzumessen ist aber bei WARP1 und VWs knifflig, deshalb u.A. die Nachkalibrierung die wir bei dir gemacht hatten. Wir müssen jetzt im Endeffekt mit dem Ladeprotokoll rausfinden, ob das Auto wirklich zwischen den zwei Widerstandswerten wechselt oder ob die Messung nicht sauber passt und deshalb in der Situation z.B. ganz knapp über bzw. unter dem Schwellwert liegt den wir als Grenze zwischen 880 Ω und 2700 Ω verwenden und die Wallbox deshalb nur glaubt, dass das Auto laden will. Immer gerne :)

Prinzipiell implementiert haben wir die MQTT-Auto-Discovery, ist aber noch nicht veröffentlicht. Kommt in den nächsten Wochen.

Hm das ist eine interessante Kombination aus Einstellungen. Hast du den e-up in EVCC konfiguriert? Das sollte ausführlicher sein. Ich befürchte, dass durch die WLAN-Verbindungsprobleme das eigentliche Ladeprotokoll verloren gegangen ist. Im Log sind nur der Header und Footer jeweils bestehend aus Debug-Report und Event-Log und dazwischen nur der Header des Ladeprotokolls (der hier: millis,STATE,iec61851_state,charger_state,contactor_state,contactor_error,allowed_charging_current,error_state,lock_state,HARDWARE CONFIG,jumper_configuration,has_lock_switch,evse_version,LL-State,led_state,cp_pwm_duty_cycle,charging_time,time_since_state_change,uptime,ADC VALUES,CP/PE,PP/PE,VOLTAGES,CP/PE,PP/PE,CP/PE (High),RESISTANCES,CP/PE,PP/PE,GPIOs,Input (0),Output (1),Motor Input (2),Relay (3),Motor Fault (4) Danach sollten eigentlich CSV-Zeilen kommen, die die ganzen Ladecontroller-Infos entsprechend des Headers enthalten und das alle 50 ms. (Das ist dann das eigentliche Ladeprotokoll) Da du einen VW hast: Kannst du im Moment sauber mit 6 Ampere laden? Deine Wallbox ist schon einmal kalibriert, aber eventuell müssen wir da nochmal nachjustieren. Eventuell interagiert da auch gerade VW-Verhalten, der Ladestop bei 80%, die Kalibrierung und EVCC ungünstig.

Prinzipiell gibt es paar Limitierungen, die du beachten musst, wenn du viele LEDs ansteuerst. Siehe z.B. hier: https://www.tinkerforge.com/de/doc/Hardware/Bricklets/LED_Strip_V2.html#feste-aktualisierungsrate Spezifisch für die WS2811 bist du bei max. 800 kbit/s (laut Datenblatt hier: https://cdn-shop.adafruit.com/datasheets/WS2811.pdf) D.h. die Beispiel-Rechnung im ersten Link ist auf deine LEDs übertragbar, damit kommst du also auf rund 50 Hz bzw. 20 ms Frametime. Die Übertragung zwischen deinem PC und den LED Strip Bricklet schafft (siehe auch der erste Link) max 20000 (RGB) bzw. 15000 (RGBW) LED-Werte pro Sekunde. D.h. maximal ~ 30 Hz, wenn du Vollbilder schickst. Da kannst du viel optimieren, wenn du nur Teile des Bildes pro Frame aktualisierst.

Jein. CP-Trennen per API funktioniert, aber wir haben noch nicht dokumentiert, wie. Das gibt uns im Moment noch die Freiheit, die API zu ändern, falls das notwendig ist. Falls du die aktuelle Beta-Firmware benutzen willst: Da ist die API evse/control_pilot_disconnect bzw. ..._update. true trennt CP, false verbindet wieder. Bei älteren Firmwares gibt es evse/control_pilot_configuration bzw. ..._update. Als configuration musst du eine Zahl übergeben: 0 trennt CP, 1 verbindet CP, 2 verbindet CP und aktiviert den automatischen Modus wieder (das ist der Standardwert!). Der automatische Modus tut in den alten Firmwares aber nichts, das ist in der aktuellen Beta in den "Fahrzeug-Weckruf" aufgegangen.

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); //[...] }

Firmware WARP2 2.0.93 Details hier:

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.

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. 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: 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 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