-
Gesamte Inhalte
1.391 -
Benutzer seit
-
Letzter Besuch
-
Tagessiege
127
Posts erstellt von rtrbt
-
-
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.
-
19 hours ago, tasdevil13 said:
Das passierte eben auch beim Update von 2.0.9 auf 2.0.11. Das mit der URL http://10.0.0.1/recovery kannte ich noch nicht, werde ich aber beim nächsten Mal probieren.
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
- 1
-
1 hour ago, Fabix said:
letzte Woche
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.
- 1
-
Siehe hier
-
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?
-
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.
- 1
-
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 :)
-
Prinzipiell implementiert haben wir die MQTT-Auto-Discovery, ist aber noch nicht veröffentlicht. Kommt in den nächsten Wochen.
-
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.
-
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.
-
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); //[...] }
-
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.
-
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.
- 1
-
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
- 1
-
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
- 1
-
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.
- 1
Daten des Accelerometer Bricklet 2.0 in Txt oder CSV speichern
in Anfängerfragen und FAQ
Geschrieben
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