Jump to content

rtrbt

Administrators
  • Gesamte Inhalte

    1.391
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    127

Posts erstellt von rtrbt

  1. Moin,

    3 minutes ago, tasdevil13 said:

    Daher fehlt in der Regel die Einstellung der Systemzeit und damit eine sinnvolle Ladehistorie.

    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)

    9 minutes ago, tasdevil13 said:

    Alle paar Wochen, wenn z.B. wieder ein Update der Software ansteht, lade ich das Fixpack auf mein Handy, gehe in die Tiefgarage und verbinde mich zum WLAN der Box (=geht), aber dann antwortet der Webserver nicht mehr. Keine Verbindung möglich.

    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?

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

    • Thanks 1
  3. 22 hours ago, gustavpaula said:

    Nein, so wie ich die evcc Doku verstehe, wird ein Fahrzeug nur in der evcc.yaml Datei konfiguriert, wenn es die Möglichkeit gibt, den Ladezustand der Batterie abzufragen. Das geht beim e-up nur über das VW webinterface und kostet unverschämt, hab ich nach dem ersten kostenlosen Jahr nicht verlängert.

    Das ist gut. Dann können wir seltsame Steuerungsversuche von EVCC ausschließen.

    22 hours ago, gustavpaula said:

    Ok, dann muss ich als nächsten versuchen, rauszu bekommen, warum es zu Verbindungsabbrüchen kommt.

    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.

    22 hours ago, gustavpaula said:

    Ja, nach Kalibrierung (in einem anderen thread) kann evcc alle Ladeströme von 6-16A sauber durchfahren.

    Diese 45s Ladungen treten ja auf, nachdem der e-up die in seiner Konfiguration (per VW App) eingestellten 80% erreicht hat. D.h. eigentlich gibt es gar keinen Ladebedarf mehr. Ich verstehe auch noch nicht, wer diese 45s Ladungen initiiert, das Auto oder evcc oder die WB von sich aus??

    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.

    22 hours ago, gustavpaula said:

    Danke für eure Hartnäckigkeit! ;-)

    Immer gerne :)

  4. On 1/4/2023 at 6:32 PM, gustavpaula said:

    So, jetzt ist das "Problem" doch wieder aufgetreten, und zwar wenn ich vorher mit EVCC Modus "Min+PV" geladen hatte und beim Erreichen der 80% (eingestellt in der Ladekonfiguration im e-up!) nicht in EVCC auf OFF gestellt hatte.

    Hm das ist eine interessante Kombination aus Einstellungen. Hast du den e-up in EVCC konfiguriert?

    On 1/4/2023 at 6:32 PM, gustavpaula said:

    Kann man das Ladeprotokoll noch irgendwie ausführlicher erstellen, dass man auch sieht, WARUM sich Charger State dauernd ändert?

    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.

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

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

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

     

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

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

    • Like 1
  10. 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

    • Like 1
  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
×
×
  • Neu erstellen...