rtrbt

Firmware: WARP 2.1.0 und WARP2 2.1.0 In den nächsten Tagen folgt ein Blogpost über die neuen Firmwares. (nur WARP2) OCPP-Unterstützung hinzugefügt (OCPPJ 1.6 Core und Smart Charging Profile) PDF-Export für Ladetracker hinzugefügt CSV-Export des Ladetrackers in "Excel-Kompatibel" und "nach RFC4180" aufgeteilt Menüstruktur des Webinterfaces neu organisiert Ladecontroller-Unterseite in Ladestaus und Ladeeinstellungen unterteilt Auto-Start in manuelle Ladefreigabe umbenannt und in Ladeeinstellungen verschoben Lastmanagement-Protokoll durch neue, vorwärts-kompatible Version ersetzt Alle Wallboxen eines Lastmanagement-Verbunds müssen auf Firmware 2.1.0 oder höher aktualisiert werden! Implementierung des Stromzähler-Graphen ausgetauscht Übersetzungen verbessert Watchdog als Schutz gegen hängende Firmware hinzugefügt Behoben, dass WLAN-Verbindungskonfiguration nicht gespeichert werden konnte, wenn nur das gewählte Netzwerk geändert wurde Behoben, dass Zahländerungen nicht angewandt wurden, wenn per Enter-Druck im Zahl-Eingabefeld gespeichert wurde Enter-Druck in Modalfenstern repariert Prüfung auf reservierte, Broad- und Multicast-IPs in Lastmanager-Konfiguration hinzugefügt Behoben, dass Lastmanagement-Fehlerdauer nicht anstieg, wenn keine gesteuerte Wallbox antwortet Behoben, dass Start- und End-Datumsauswahl nicht die Zeitzone des Nutzers berücksichtigt hat Labelbreite auf der Statusseite auf kleinen Bildschirmen angepasst Standard-NTP-Server für höhere Zuverlässigkeit geändert Behandlung der RTC-Zeit im Fehlerfall repariert "Charged Energy"-Register im Keba-Emulationsmodus repariert API-Fehlermeldungen verbessert Ermöglicht, dass mehr als eine API-Fehlermeldung geschickt werden kann Validierung der Benutzerkonfiguration repariert Behoben, dass NFC-Tag ausgewählt werden musste, wenn exakt ein Tag erkannt wurde Behoben, dass immer Login-Seite angezeigt wurde, falls beim Prüfen des Anmeldestatus ein Timeout auftrat Behoben, dass Benutzerkonfiguration bzw. -API bis zu einem Neustart gesperrt wurde Verschränkte Stromgrenzenbeschränkungen in der Lastmanager-Konfiguration behoben WLAN-Verbindungsaufbau beschleunigt Boost-Modus hinzugefügt (durch Update auf Ladecontroller-Firmware 2.1.6 (WARP1) bzw. 2.1.9 (WARP2)) (nur WARP2) Fahrzeug-Weckruf hinzugefügt (durch Update auf Ladecontroller-Firmware 2.1.9) (nur WARP2) CP-Trennungs-API finalisiert (durch Update auf Ladecontroller-Firmware 2.1.9) Sichergestellt, dass Schütz nicht unter Last geschaltet wird, wenn das Fahrzeug den Ladevorgang stoppt (durch Update auf Ladecontroller-Firmware 2.1.6 (WARP1) bzw. 2.1.9 (WARP2)) (nur WARP2) Behoben, dass bei einer Notabschaltung wegen DC-Fehler zusätzlich ein Schützfehler gemeldet wurde (durch Update auf Ladecontroller-Firmware 2.1.10) (nur WARP2) Behoben, dass Stromzählereinstellungen kontinuierlich geschrieben wurden (durch Update auf Ladecontroller-Firmware 2.1.10) (nur WARP2) Ausgabe des letzten Stromzählerwerts repariert (durch Update auf Ladecontroller-Firmware 2.1.10) Download: WARP 2.1.0 bzw. WARP2 2.1.0

Gut möglich, dass der Adapter nur für Mode 1 gedacht ist: https://de.wikipedia.org/wiki/IEC_62196 bzw. (https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Signalisierung)

Das ist übrigens eine der API-Änderungen von Firmware-Version 2. Details dazu hier :https://www.tinkerforge.com/de/blog/new-features-and-changes-in-warp2-firmware-200/

Alternativ kannst du eine der Wifi Extensions als Access-Point konfigurieren und sowohl den Laptop, als auch die anderen Stapel als Clients darauf verbinden.

Das ist an der Stelle im Webinterface schlecht formuliert. Im Moment kannst du die Ladefreigabe in der Tat nur per NFC-Tag erteilen.

DIrekt über dem Low-Level-Zustand kannst du ein Ladeprotokoll ziehen. Mach das mal wie folgt und poste es hier: Bei Ladeprotokoll auf Start klicken. Browser-Fenster nicht schließen! Auto anstecken ggfalls. NFC-Tag an die Box halten usw. ~ 30 Sekunden warten (damit das Auto eine Chance hat anzufangen zu laden) Auf Stop + Download klicken

Zieh mal einen Debug-Report von der Wallbox (findest du unter System->Ereignis-Log) und lade ihn hier hoch.

Nachträglich ändern geht über einen Trick zumindest während der Ladevorgang läuft: Du kannst den Ladevorgang mit dem ersten Tag stoppen und dann mit einem anderen Tag wieder starten (das geht auch über die API mit nfc/inject_tag_start und _stop). Wenn du also eine Auto-Erkennung hast, dann könntest du drei Tags benutzen. Eins zum Erkennen des Autos und sobald du weißt, welches Auto lädt, eins der beiden anderen Tags. Die Reihenfolge ist dann Auto anstecken Ladevorgang mit Tag 1 ("unbekanntes Auto") freigeben Auf die Auto-Erkennung warten Ladevorgang mit Tag 1 stoppen Ladevorgang mit Tag 2 oder Tag 3 (je nachdem was die Auto-Erkennung sagt) starten

Moin, Zieh bitte mal einen Debug-Report von der Box (unter System->Ereignis-Log). Eventuell sehen wir da mehr.

Falls du writetable benutzt, kannst du auch festlegen, dass angehangen werden soll: https://in.mathworks.com/help/matlab/ref/writetable.html#mw_ebe3afac-7551-491c-8210-41c3c5393141 z.B. mit writetable(deineTabelle,'datei.csv','WriteMode','Append')

Den musst du selbst auseinandernehmen. Das Format ist hier: https://www.warp-charger.com/api.html#charge_tracker_charge_log dokumentiert.

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