Jump to content

rtrbt

Administrators
  • Gesamte Inhalte

    1.388
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    127

Posts erstellt von rtrbt

  1. Hm, das hatte ich befürchtet. Im Anhang die Variante, bei der wir den Widerstandspeak beim Übergang von "Auto will Strom" nach "Auto will keinen Strom" ignorieren.

    Da ich optimistisch bin, dass das jetzt funktioniert, habe ich dir die Firmware in zwei Varianten angehangen: Teste erstmal mit der warp_firmware_2_1_2... Das ist wie gehabt eine WARP1 2.1.2-Firmware mit den Bugfixes zusätzlich drin. Falls das funktioniert, kannst du dann auf die warp_firmware_2_1_3... wechseln. Dann hast du die ganzen Neuerungen aus 2.1.3 und die Bugfixes oben drauf. Sonst müsstest du auf der 2.1.2+ bleiben, bis wir irgendwann 2.1.4 veröffentlichen.

    warp_firmware_2_1_2_64a2be5b_57432b34a765d3f__merged.bin warp_firmware_2_1_3_64a2bae8_49abde32bf9c00e_merged.bin

  2. On 6/29/2023 at 11:33 AM, heppth said:

    Keine MeterValues-Messages:
    Von anderen Wallboxen bin ich es gewohnt, dass während des Ladevorgangs MeterValues-Messages eintreffen. Allerdings erscheinen keine MeterValues-Messages. (Zähler ist nachträglich verbaut, alle Werte werden in der WebUI angezeigt)

    Das ist in der Tat seltsam. Ich kann das hier auch nachstellen. Die Default-Einstellung ist, dass Meter.Active.Import.Register (lies: der Stromzählerwert) alle 60 Sekunden geschickt werden soll. Das funktioniert bei mir aber erst, wenn ich einmal ein ChangeConfiguration schicke, dass MeterValuesAlignedData auf den Wert konfiguriert (und dann neustarte weil ChangeConfiguration mit RebootRequired antwortet). Ich debugge das und melde mich nochmal.

    On 6/29/2023 at 11:33 AM, heppth said:

    Kein automatischer Start:
    In den Ladeeinstellungen ist "Manuelle Ladefreigabe" deaktiviert. Weiterhin ist in der Benutzerverwaltung "Lade­freigabe" deaktiviert. Daher ging ich davon aus, dass die Wallbox nach dem Einstecken/Bootvorgang sofort mit dem Laden anfängt. Dies ist aber nicht der Fall. Ich benötige noch eine RemoteStartTransaction-Message

    Das ist im Moment korrekt. Statt einer RemoteStartTransaction-Message kannst du auch ein NFC-Tag an die Wallbox halten. Dann schickt sie ein Authorize.req an den Server und wenn der das Tag autorisiert, beginnt der Ladevorgang.

    Nach der OCPP-Spezifikation gibt es keine Möglichkeit einen komplett unautorisierten Vorgang zu starten, solange eine Verbindung zum Server besteht (also einen der weder vom Server durch eine Authorize.conf bestätigt, oder durch ein RemoteStartTransaction angefordert wurde). Das ist aber ein Modus, den wir gegebenfalls noch nachlegen wollen, gerade mit dem Gedanken, dass später ja auch Netzbetreiber Wallboxen per OCPP steuern wollen, ich da aber im Moment nicht davon ausgehe, das man denen eine Liste von NFC-Tags geben kann/muss.

    On 6/29/2023 at 11:33 AM, heppth said:

    ChargePointMaxProfile:
    Der OCPP-Server soll der Wallbox vorgeben, wie schnell sie lädt. Wenn eine SetChargingProfile-Message mit TxDefaultProfile geschickt wird, reagiert die Wallbox sofort und passt den Ladestrom an. Eine Message mit ChargePointMaxProfile scheint die Wallbox allerdings zu ignorieren. Wie ist hier der Stand?

    Das funktioniert in meinem Test. Bekommst du im Ereignis-Log Ausgaben, wenn du das Profile schickst? Bzw. spätestens alle 5 Minuten wertet die Wallbox alle konfigurierten Profile neu aus. Der Output ist dann z.B.:

    2023-06-29 14:42:55,042  Evaluating charging profiles
    2023-06-29 14:42:55,043      ChargePointMaxProfiles[1] applied.
    2023-06-29 14:42:55,043      Connector 1
    2023-06-29 14:42:55,053      Profile evaluation done. Distributing limit
    2023-06-29 14:42:55,054      Currents distributed:
    2023-06-29 14:42:55,064         ConnID  Allowed Phases  MinRate
    2023-06-29 14:42:55,064         0       12.000  3       0.000
    2023-06-29 14:42:55,075         1       12.000  3       0.000
    2023-06-29 14:42:55,075      Next check: 2023-06-29T20:00:00Z
    2023-06-29 14:42:55,085  
    2023-06-29 14:42:55,086  Setting connector 1 limit to 12000

    (Ich habe testweise ein ChargePointMaxProfile installiert, dass den Strom von 8 bis 20 Uhr UTC auf 12 Ampere limitiert)

    Bekommst du ähnliche Ausgaben?

    • Like 1
  3. On 6/29/2023 at 1:44 PM, gustavpaula said:

    Was genau ein "Ladestromslot" ist, weiß ich nicht. Habe ICH den Ladestromslot so gesetzt?

    Sorry, zwei Wörter für's gleiche. Ein Slot ist eine Ladestromgrenze, so wie du sie im Ladestatus siehst. Den Slot hast nicht du so gesetzt.

    On 6/29/2023 at 1:44 PM, gustavpaula said:

    Wer/wie/was hat den Ladeslot fälschlicherweise falsch markiert?

    Das war die große Frage. Inzwischen habe ich es rausgefunden: Der Slot ist ursprünglich bei WARP1 und WARP2 falsch konfiguriert gewesen. Bei WARP2 haben wir das mit Firmware 2.1.2 schon gefixt gehabt, aber bei WARP1 hatten wir übersehen, dass das selbe Problem existiert.

    Ich habe das jetzt für WARP1 auch gefixt, neue Firmware ist im Anhang.

    warp_firmware_2_1_2_649d74a0_4e2c6ba61f00eb4__merged.bin

  4. Okay, ich glaube ich habe jetzt verstanden, was da passiert. Da das kompliziert ist habe ich das ganze mal geplottet (mein Excel-Foo ist nicht gut deshalb einfach drei Graphen untereinander) und annotiert.

    image.png

    Du hast folgende Reihenfolge erzeugt:

    • 10 Ampere erlaubt, Auto ist voll (das ist der Anfang des Graphen)
    • Strom auf 6 Ampere reduziert. Das beeinflusst bei WARP1 die CP-PE-Widerstandsmessung, was man im 3. Graph sieht (Rote 1)
    • Auf Stop geklickt (Blaue 1, Rote 2) -> Wir melden dem Auto über das PWM auf CP, dass kein Strom verfügbar ist -> Das PWM geht auf 100% -> Der Widerstand geht wieder etwas hoch.
    • Auf Start geklickt. (Blaue 2) Es scheint so zu sein, dass der VW immer wieder anfängt zu laden, wenn das PWM zwischenzeitlich aus war, selbst wenn er voll ist.
    • Das Auto will laden und setzt deshalb den Widerstand runter (Rote 3)
    • Wir schalten das Schütz (Blaue 3)
    • Nach 45 Sekunden bemerkt der VW, dass er voll ist. (Blaue/Rote 4) Er will deshalb den Widerstand wieder auf die 2,7kOhm setzen, macht das aber in der VW-Weise, die bei WARP1 Sprünge in der Messung erzeugt.
    • Der gemessene Widerstand springt auf einen so hohen Wert, dass wir glauben, das Auto ist abgezogen (Blaue 5, Rote 5)
    • Jetzt der interessante Teil: Einer der Ladestromslots, nämlich der für das Energie/Zeitlimit wird von 32A auf 0A (also blockieren) gesetzt. Das passiert vermutlich direkt durch den Ladecontroller, weil dieser Ladeslot fälschlicherweise bei dir so markiert ist, dass der Ladecontroller ihn auf 0 A setzen soll, wenn ein Auto abgezogen wird. (Gelbe 1)
    • ~ 250ms später setzt der ESP den Slot wieder zurück auf 32 A (Gelbe 2)
    • Der gemessene Widerstand hat sich wieder gefangen, wir messen ~2.7kOhm -> Das Auto ist angesteckt aber will nicht laden (Rote 6, Blauer Übergang von 6 zu 7.)
    • Den Übergang habe ich nochmal beim nächsten Block orange eingekreist, weil man da gut sieht wie es erst kurz auf 2.7kOhm springt, dann etwas abfällt (weil wir wieder das PWM starten) und dann auf ~800 Ohm fällt (weil das Auto Strom anfordert)
    • Jetzt geht es im Endeffekt von vorne los, das Auto "lädt" wieder 45 Sekunden (Blaue 8 bis 9)

    Das heißt es kommen folgende Probleme zusammen:

    • Der VW schaltet die Widerstände so um, dass wir diesen Peak in der Messung sehen.
    • Das Zeit/Energielimit geht davon aus, dass der entsprechende Ladeslot nicht beim Abziehen eines Autos geleert wird, setzt das aber nicht explizit. Aus irgendeinem Grund ist bei dir dieser Slot aber so konfiguriert, dass geleert wird. Hattest du eventuell mal eine andere Beta-Firmware, Test-Firmware oder einen der Forks laufen?
    • Durch das Nullen des Ladeslots ist die Zeit, die der VW sehen kann, dass wir keinen Strom zur Verfügung stellen so lang, dass er dann glaubt er müsste wieder anfangen zu laden, wenn Strom verfügbar ist.

    Ich baue dir heute Nachmittag noch eine Testfirmware, bei der ich den Bug fixe, dass der Ladeslot zurückgesetzt wird. Im Idealfall reicht das schon, weil dann der VW nach den 45 Sekunden und der Abschaltung nicht wieder anfängt zu laden. Falls das weiterhin passiert, müssen wir (lies @borg ) in der Ladecontroller-Firmware das Timing etwas anpassen um mit dem Peak in der Messung umgehen zu können.

  5. Damit es erstmal wieder bei dir funktioniert, zwei Optionen:

    1. Entweder aktualisiere den Energy Manager auf 1.0.6 (und bleib bei der Wallbox auf 2.1.3)
    2. Oder (mit Wallbox-Firmware 2.1.3): Deaktiviere in den Ladeeinstellungen die Zählerüberwachung und gehe dann wieder auf 2.1.2. Das müsste funktionieren.

    Zur Erklärung: Wir haben mit der Wallbox-Firmware 2.1.0 das Lastmanagement-Kommunikationsprotokoll so umgestellt, dass es vorwärts kompatibel ist. D.h. wenn wir neue Daten hinzufügen sollte eigentlich sowohl das Setup "alter Lastmanager (egal ob Energy Manager oder Wallbox); neue gesteuerte Wallbox", als auch das Setup "neuer Lastmanager; alte gesteuerte Wallbox" funktionieren. Das scheint bei dir nicht der Fall zu sein. Werden wir uns in Ruhe ansehen.

    Das Downgrade der Wallbox-Firmware funktioniert bei dir nicht, weil du eine Wallbox mit Zähler hast. In 2.1.3 haben wir die Zählerüberwachung hinzugefügt, die automatisch aktiviert wird, wenn ein Stromzähler gefunden wird. Das funktioniert wie viele andere Module über eine eigene Ladestromgrenze. Wenn du jetzt auf 2.1.2 downgradest, dann bleibt diese Ladestromgrenze aktiv, die Firmware kennt sie aber nicht mehr, deshalb wird der Ladevorgang nie freigegeben. Das ist der Grund, warum wir bei 2.1.3 im Changelog "Sichergestellt, dass Downgrades (auf diese Firmware oder neuer) funktionieren, selbst wenn künftig neue Ladestromgrenzen hinzugefügt werden" haben. Ab 2.1.3 werden alle unbekannten Ladestromgrenzen (also solche, die Überbleibsel eines Up- und dann Downgrades sind) deaktiviert, damit das Laden wieder funktioniert.

  6. Firmware: WARP 2.1.3 und WARP2 2.1.3

    • Zählerüberwachung hinzugefügt
    • (nur WARP1) Nutzer- und NFC-Tag-Limit auf 16 erhöht
    • (nur WARP1) Energie-Limit-Einstellung auf Dropdown-Box umgestellt
    • (nur WARP2) Automatischen Test des DC-Fehlerstrom-Schutzmoduls mindestens alle 24 Stunden und nach Ende eines Ladevorgangs hinzugefügt (durch Update auf Ladecontroller-Firmware 2.1.13)
    • (nur WARP2) Sichergestellt, dass aktive CP-Unterbrechung nicht durch Lastmanagement oder API-Aufrufe gestört wird (durch Update auf Ladecontroller-Firmware 2.1.13)
    • Lastmanagement: Effizienz verbessert, wenn gesteuerte Wallbox über einen Stromzähler verfügt, der Phasenströme misst. (WARP2 Pro oder WARP1 mit nachgerüstetem SDM630 oder SDM72 V2).
    • Lastmanagement: Hinzugefügt, dass Hostnamen von nicht mehr erreichbaren Wallboxen neu aufgelöst werden
    • Lastmanagement: Duplizierte und springende Einträge in den Scan-Ergebnissen zu kontrollierender Wallboxen behoben
    • Lastmanagement: Behandlung von niedrig priorisierten Wallboxen behoben
    • Lastmanagement: Hinzugefügt, dass Wallboxen, die weniger als den erlaubten Minimalstrom unterstützen als niedrig priorisiert behandelt werden
    • Lastmanagement: Performance bei genau 10 gesteuerten Wallboxen verbessert
    • (nur WARP2) Button zum Testen des DC-Fehlerstrom-Schutzmoduls hinzugefügt
    • Zuletzt gesehenes NFC-Tag zu Modbus-TCP-Registern hinzugefügt
    • Front-Taster-LED-Steuerung über API und Modbus-TCP-Register hinzugefügt
    • (nur WARP2) API zum Steuern des konfigurierbaren Ausgangs hinzugefügt
    • Unbekannten Benutzer aus der Limitierung auf 16 Benutzer ausgenommen
    • NetBIOS-Unterstützung entfernt
    • Zeitzonen-Datenbank aktualisiert
    • DNS-Cache-Größe erhöht
    • Modbus-TCP-Dokumentation verbessert
    • Lokalisierung von Gleitkommazahlen im Webinterface repariert
    • (nur WARP2) Robustheit der IP-Konfiguration bei 10MBit LAN-Verbindungen verbessert
    • Anzeige von Ladecontroller-Firmware- und Hardware-Version hinzugefügt
    • Sichergestellt, dass Downgrades (auf diese Firmware oder neuer) funktionieren, selbst wenn künftig neue Ladestromgrenzen hinzugefügt werden
    • Repariert, dass sporadisch Einträge in APIs fehlten
    • Repariert, dass die Benutzerfreigabe bei einem Neustart der Wallbox, während der Ladevorgang pausiert ist, verloren ging
    • Reparatur von Ladelog-Einträgen, bei denen entweder der Start- oder End-Zählerwert fehlt, hinzugefügt
    • Absturz, wenn NFC-Logik für mehr als eine Sekunde blockiert wurde, behoben
    • NFC-Tag-Detektionsschwelle auf 2 Sekunden angehoben
    • Prüfung auf überlappende Netzwerkbereiche bei IP-Konfiguration von  LAN (nur WARP2), WLAN und WireGuard hinzugefügt
    • Übersetzungen verbessert
    • Sofortigen Start des WLAN Access Points hinzugefügt, falls keine WLAN-Verbindung konfiguriert und (nur WARP2) kein Ethernet-Kabel verbunden ist
    • Sichtbarkeit der Nulllinie in Graphen verbessert
    • Race Condition während des Starts des Webservers behoben
    • Race Condition während des Starts des MQTT-Clients behoben
    • Crash bei gleichzeitigen Zugriffen von mehreren APIs behoben
    • Webinterface-Fehler durch falsche Reihenfolge von Websocket-Nachrichten behoben
    • Websocket-Verbindungsabbrüche durch zu große Stromzählerwerte behoben
    • Ladeprotokolllänge auf (letzte) 20000 Zeilen begrenzt
    • Springende Y-Achse in Graphen bei Doppelklick behoben
    • Alle 48h-Graphen auf mindestens 1500 Watt skaliert
    • Ereignis-Log-Meldungen überarbeitet
    • Falsche Berechnung der 48-Stunden-Werte des Stromzähler-Graphen, falls Messwerte schneller als alle 500 ms ankommen, behoben

    Download: WARP 2.1.3 bzw. WARP2 2.1.3

  7. Firmware: WARP Energy Manager 1.0.6

    • Status-Ansicht zur Tagesansicht der Energiebilanz hinzugefügt
    • Lastmanagement: Effizienz verbessert, wenn gesteuerte Wallbox über einen Stromzähler verfügt, der Phasenströme misst. (WARP2 Pro oder WARP1 mit nachgerüstetem SDM630 oder SDM72 V2).
    • Lastmanagement: Hinzugefügt, dass Hostnamen von nicht mehr erreichbaren Wallboxen neu aufgelöst werden
    • Lastmanagement: Duplizierte und springende Einträge in den Scan-Ergebnissen zu kontrollierender Wallboxen behoben
    • Lastmanagement: Behandlung von niedrig priorisierten Wallboxen behoben
    • Lastmanagement: Hinzugefügt, dass Wallboxen, die weniger als den erlaubten Minimalstrom unterstützen als niedrig priorisiert behandelt werden
    • Lastmanagement: Performance bei genau 10 gesteuerten Wallboxen verbessert
    • Race Condition während des Starts des MQTT-Clients behoben
    • Crash bei gleichzeitigen Zugriffen von mehreren APIs behoben
    • Websocket-Verbindungsabbrüche durch zu große Stromzählerwerte behoben
    • Übersetzungen verbessert
    • Firmware-Aktualisierungen blockiert, wenn am Energy Manager ein Schütz und an einer kontrollierten Wallbox ein Fahrzeug angeschlossen ist
    • Reihenfolge der gestapelten Graphen in der Tagesansicht der Energiebilanz repariert
    • Falsche Berechnung der 48-Stunden-Werte des Stromzähler-Graphen, falls Messwerte schneller als alle 500 ms ankommen, behoben
    • Debug-Protokolllänge auf (letzte) 20000 Zeilen begrenzt
    • Springende Y-Achse in Graphen bei Doppelklick behoben

    Download: WARP Energy Manager 1.0.6

  8. On 6/22/2023 at 11:39 PM, bm-3 said:

    Found unknown meter type 0x0. Assuming this is a SDM72DM.

    Wenn du so weit kommst, ist das ein gutes Zeichen: Die Modbus-Kommunikation läuft schon mal.

    Die SDM-Zähler haben alle ein Register, dass den Zählertyp angibt. Damit detektiert die Wallbox automatisch, was für einen Zähler du angeschlossen hast.

    Das Problem ist jetzt, dass es diese ältere Version des SDM630 gibt, die nicht den "erwarteten" Zählertyp in dem Register stehen hat, sondern einfach 0. Bei der WARP2 gehen wir davon aus, dass das dann ein alter SDM630 sein muss. Bei der WARP1 können wir das nicht so machen, weil es möglicherweise auch alte Versionen des SDM72DM (V1) gibt, die auch 0 zurückgeben. Deshalb muss eine WARP1 bei einem unbekannten Zähler annehmen, dass das ein SDM72DM (V1) ist.

    Du kannst das jetzt reparieren, indem du den Zählertypen von Hand auf SDM630 überschreibst. (Das ist eine persistente Konfiguration -> Musst du nur einmal machen) Dafür gibt es leider keinen Knopf im Webinterface (Habe mal ein Issue angelegt, dass wir den hinzufügen: https://github.com/Tinkerforge/esp32-firmware/issues/255).

    Um das von Hand zu machen, musst du auf die recovery-Seite der Wallbox gehen, je nachdem ob du per Hostname oder IP auf das Webinterface gehst unter http://warp-xyz/recovery  oder http://10.0.0.1/recovery (Hostname oder IP musst du durch deine ersetzen). Dann unter API in die Textbox folgendes einfügen:

    {"method":"PUT", "url":"/meter/type_override_update", "payload":2}

    und auf Call API klicken. In der Textbox darunter sollte dann eine 200 erscheinen.

    Danach auf dem normalen Webinterface unter System->Firmware-Aktualisierung einmal auf neu starten klicken. Dann sollte der SDM630 korrekt erkannt werden.

    Edit: API angepasst für WARP(2) >= 2.1.3

  9. On 6/20/2023 at 5:36 PM, roquestrongo said:

    Konntest du die ESP Resets (Softreset) in meinem Ladelog nachvollziehen ? Ist das normal das der WARP2 / der ESP Beim Laden neustartet?

    Das fehlte in @borgs Antwort. Der ESP startet nicht neu. Das Ladelog funktioniert wie folgt: Wenn du Start klickst, wird sofort ein Debug-Report gezogen, also die Konfiguration und das Ereignis-Log hintereinander. Danach werden die ganzen Daten gesammelt, bis du Stop klickst, dann wird nochmal ein Debug-Report gezogen. Die Idee ist, dass wir dann sehen können, welche Konfigurations-/Zustandsänderungen und welche Ereignislog-Nachrichten aufgetaucht sind, während die Daten gesammelt wurden.

    Der Neustart, den du da siehst, ist vor dem Start des Ladelogs passiert. und zwar ~ 3 Minuten. Wenn "Software reset via esp_restart" als  "reset reason" angegeben wird, dann ist das typischerweise ein Neustart, den man aktiv ausgelöst hat, z.B. durch eine Konfigurationsänderung im Webinterface.

    Interessant ist, dass der Ladecontroller auch neugestartet ist, und zwar ~ 15 Minuten vor dem Start des Ladelogs. Hattest du die Wallbox vom Strom getrennt, oder die Firmware aktualisiert?

    Die GPIOs sind in Ordnung. Prinzipiell hast du da den Effekt, dass für's Webinterface die GPIOs nur alle 250 ms abgefragt werden, da aber teilweise deutlich hochfrequentere Prozesse ablaufen, z.B. PWMs. Dann ist praktisch zufällig, ob du High oder Low siehst.

    Quote
    1. erste Zeile/erste und zweite Reihe: "current configuration 0" und "motor fault"
    2. zweite Zeile/vierte Reihe: "CP-PWM"
    3. dritte Zeile/vierte Reihe: "CP Separation" 
    4. vierte Zeile/dritte und vierte Reihe: "contactor check before" und "contactor check behind"
    5. fünfte Zeile/vierte Reihe: "LED"
    1. Motor fault ist okay, der Ladecontroller unterstützt theoretisch, dass man eine Dose statt einem angeschlagenen Kabel anbringt. Da das nicht der Fall ist, wird der Pin nicht angesteuert.

      Current configuration 0 einer der Pins mit denen die Schiebeschalter gelesen werden, die auf dem Ladecontroller verbaut sind. Mit den Schaltern wird eingestellt, wie viel Strom das Zuleitungskabel erlaubt. Der Pin (und current configuration 1) können jeweils low, high, oder open, also nicht verbunden, sein. Beim Start des Ladecontrollers legt er einen Pull-Down- und danach einen Pull-Up-Widerstand an um die drei Fälle zu unterscheiden und damit die Stellung der Schalter zu bestimmen. Das der Pin bei dir springt ist erwartet: Du hast eine 16-Ampere-Zuleitung, das wird auf den Schaltern ausgedrückt, indem beide in der Open-Position sind. Der Ladecontroller hat nach dem Start die Pull-Up/Down-Widerstände wieder weggenommen, d.h. es ist auch zufällig welcher Wert da gelesen wird (aber auch egal, eben weil sie nur beim Start ausgewertet werden)
    2. Das CP-PWM läuft mit 1000 Hz. Manchmal siehst du dann high, manchmal low
    3. Auf dem CP-Trennungspin habe ich im Log und im Video nichts gesehen. Da kannst du eventuell folgendes beobachten: Wenn das Auto 30 Sekunden, nachdem die Wallbox das Laden erlaubt (Zustand Ladebereit), nicht reagiert, machen wir eine CP-Trennung um ggfalls. die Ladeelektronik aufzuwecken. Dann sollte der Pin einmal umspringen und vier Sekunden später zurück. Danach sollte der Wert stabil sein.
    4. Wenn das Schütz geschaltet ist, pendeln die beiden GPIOs mit der Netzfrequenz (50 Hz)
    5. Die LED atmet während des Ladevorgangs, was durch ein PWM erzeugt wird. Manchmal siehst du dann gerade das PWM high, manchmal low.
  10. On 6/18/2023 at 9:54 AM, gustavpaula said:

    Jetzt hab ich noch eine Frage: Wäre es nicht sinnvoll, dass das Laden auf Stop geht, wenn das Auto mal sagt "ich bin voll!" und dann manuell wieder gestartet werden muss?

    Schonmal unabhängig vom Rest: Nein, das würde dazu führen, dass wenn sich ein Auto leer steht, nicht nachgeladen wird. Außerdem gibt es Autos (die Teslas z.B. wenn ich mich richtig erinnere), die im Winter ihre Heizung aus Wallbox-Strom betreiben können.

    Wir hatten dieses Verhalten mit dem Lastmanagement mal ausversehen implementiert und dann aber geändert. Siehe hier:

     

  11. Zu der manuellen Ladefreigabe: Das hieß in älteren Firmware-Versionen Auto-Start. Wir haben das geändert und auf die Unterseite gepackt, weil es die meisten Nutzer eher verwirrt hatte.

    Jetzt ist aber die ganze Benennung noch verwirrender. Das müssen wir besser machen.

    Dazu noch grundlegend: Die manuelle Ladefreigabe (ex Auto-Start) als Ladestromgrenze ist wie folgt belegt:

    • Der Taster an der Wallbox blockiert (bei WARP1 immer, bei WARP2 konfigurierbar)
    • Wenn du auf der Statusseite auf Stop klickst, blockiert die Ladestromgrenze, wenn du auf Start klickst, gibt sie frei
    • Wenn du die manuelle Ladefreigabe auf der Ladeeinstellungsseite aktiviert hast, dann wird blockiert, wenn ein Auto abgezogen wird (d.h. du musst den ersten Start manuell freigeben)
    On 6/18/2023 at 10:32 AM, gustavpaula said:

    Man hätte aber irgendwie erwartet, dass wenn ich ein Limit für den nächsten Ladevorgang setze auf der Statusseite, dieses Limti wieder gelöscht wird, wenn ich den Ladevorgang manuell gestoppt habe. Anstatt dessen wird die verbleibende Zeit einfach weiter runter gezählt, selbst wenn der Ladevorgang gestoppt worden ist. Die Logik versteh ich nicht.

    Das ist auch ein Fall von schlechter Benennung: Der Knopf heißt "Stop", er blockiert aber nur die "manuelle Ladefreigabe"-Stromgrenze. Ein Ladevorgang beginnt (im Bezug auf die Zeit/Energielimits und den Ladetracker usw.) wenn du das Auto ansteckst und endet, wenn du es abziehst. (Ausnahme: Wenn du die NFC bzw. Benutzerfreigabe benutzt, dann beginnt der Ladevorgang erst wenn du ein Tag an die Wallbox hältst)

     

  12. Das geht.

    Damit ich das richtig verstehe: Willst du den Zähler neben dem WARP Charger lassen, oder willst du ihn in die Wallbox einbauen? Im ersten Fall kannst du die Teile einfach bestellen, in Fall zwei, schreib stattdessen eine Mail an info@tinkerforge.com mit einem Verweis auf diesen Post und deiner Adresse usw. Dann legen wir dir eine Bestellung auf Rechnung an.

    In jedem Fall brauchst du dafür:

    Wenn du den Zähler neben dem WARP Charger lässt:

    • Ein möglicherweise langes 3-adriges Verbindungskabel zwischen Zähler und RS485-Bricklet. In den Posts unten hat jemand ein Cat-7-Kabel benutzt.
    • Ein Befestigungskit für das RS485-Bricklet: https://www.tinkerforge.com/de/shop/mounting-kit-12mm.html (kannst du auch beim RS485-Bricklet mit auswählen)

    und du musst dann ein Loch ins Gehäuse bohren um das Kabel durchzuführen und 4 Löcher in den Berührschutz um das RS485-Bricklet zu befestigen.

    Wenn du den Zähler in den WARP Charger einbaust:

    • Den Berührschutz für einen WARP Charger Pro. Bei dem sind die Ausschnitte andere, damit der Zähler reinpasst. Den gibt's nicht im Shop, deshalb müsstest du uns dafür die Mail schreiben.
    • Ein Verbindungskabel zwischen Zähler und RS485-Bricklet. Davon haben wir noch welche hier, würden wir dir dann mit reinlegen.

    Das prinzipielle Vorgehen ist:

    • Wallbox stromlos machen
    • Frontdeckel abnehmen, dabei auf das Fronttaster- und Erdungskabel achten
    • Berührschutz ausbauen
    • 4 Löcher reinbohren oder ESP-Brick auf den neuen Berührschutz setzen
    • Die DIP-Schalter auf dem RS485-Bricklet auf Half-Duplex terminated schalten (1, 2, 3 auf ON; 4 auf OFF)
    • RS485-Bricklet mit dem ESP-Brick verkabeln (Es ist egal an welchen Port du das Bricklet anschließt) und auf dem Berührschutz befestigen
    • Loch in die Gehäusewand bohren oder den Klemmenblock ausbauen, stattdessen den Zähler einbauen und verkabeln
    • Zähler mit RS485-Bricklet verbinden: A+ an RX+, B- an RX-, G an GND (siehe auch den Stromlaufplan hier:https://www.warp-charger.com/documents/WARP_Stromlaufplan.pdf)
    • Berührschutz einbauen
    • Frontdeckel aufsetzen und zuschrauben

    In der Software musst du nichts ändern. Das RS485-Bricklet sollte, wenn die Wallbox startet, automatisch gefunden werden.

    Hier haben das schon ein paar Nutzer gemacht:

     

  13. Das sind ja zwei Probleme hintereinander:

    1. Bringt das dritte Tag anscheinend den NFC-Leser durcheinander -> Ich sehe mir den zweiten debug-report gleich an und schreibe dir dann noch was dazu. Im Idealfall können wir das hier reproduzieren und dann hoffentlich fixen.

    2. Wenn der NFC-Leser kurz hängt oder neu startet, kommt die Wallbox-Firmware damit nicht zurecht und crasht. -> Das habe ich behoben, d.h. selbst wenn der NFC-Leser crasht läuft die Wallbox weiter. Der Fix wird in der nächsten Firmware (voraussichtlich Ende der Woche) enthalten sein.

  14. MQTT ist kein Umweg, sondern der offiziell unterstützte Weg, einen WARP Charger mit EVCC zu verbinden. Deshalb dokumentieren sowohl wir, als auch EVCC das so.

    Wenn du über OCPP oder Modbus gehen willst (vermutlich mit dem Hintergedanken, dass du dann keinen MQTT-Broker aufsetzen musst?), dann kannst du das tun.

    Für Modbus-TCP musst du:

    Für OCPP musst du auch EVCC entsprechend konfigurieren, siehe hier: https://docs.evcc.io/docs/devices/chargers#ocpp-16j-kompatible-wallbox-mit-smart-charging-profil

    Die OCPP-Implementierung von EVCC ist aber nur das absolute Minimum (eben weil es nur ein Fallback ist, wenn keine sinnvollere Anbindung existiert), als wir das hier mal getestet hatten, hat das nicht 100%ig überzeugend funktioniert. Siehe z.B. hier: https://github.com/evcc-io/evcc/issues/5055#issuecomment-1305359228

  15. On 6/14/2023 at 2:31 PM, gustavpaula said:

    Wieso OpenHAB regelmäßig eine Nachricht schickt, die aber für euch zu groß ist und was das für Konsequenzen hat (und wer nun das "Problem" hat: die WB oder OpenHAB) ist mir nicht klar. D.h. OpenHAB versucht, last_charges zu schreiben? Oder vllt. ist das auch EVCC?

    Das Problem ist nicht die zu große Nachricht, die wird sowieso ignoriert, eben weil sie a) zu groß ist und b) auf ein Topic geht, dass nicht geschrieben werden darf.

    Ich vermute aber, dass openHAB mehr bzw. alle Topics der Wallbox beschreibt, unter anderem auch evse/stop_charging und evse/start_charging o.Ä.

    EVCC ist das vermutlich nicht.

    • Thanks 1
  16. Deaktiviere mal testweise die MQTT-Kommunikation. Mir ist im Log gerade aufgefallen, dass diese Meldungen

    MQTT: Ignoring message with payload length 2526 for topic warp/SzQ/charge_tracker/last_charges. Maximum length allowed is 2048.

    auch ~alle 45 Sekunden erscheinen und zwar genau zwischen dem Ab- und Anschalten. Das ist an sich schon komisch, weil charge_tracker/last_charges ein State ist, was heißt, dass last_charges von außen sowieso nicht geschrieben werden darf. Die Längenprüfung ist davor, deshalb sehen wir das jetzt im Log, anstatt dass die Nachricht einfach ignoriert wird.

    Etwas zusammengekürzt:

    2023-06-13 13:29:56,780  Charger state changed from 3 to 0
    2023-06-13 13:29:57,167  MQTT: Ignoring message[...]
    2023-06-13 13:29:58,914  Charger state changed from 0 to 2
    2023-06-13 13:30:44,023  Charger state changed from 3 to 0
    2023-06-13 13:30:44,751  MQTT: Ignoring message[...]
    2023-06-13 13:30:46,169  Charger state changed from 0 to 2
    2023-06-13 13:31:31,306  Charger state changed from 3 to 0
    2023-06-13 13:31:32,449  MQTT: Ignoring message[...]
    2023-06-13 13:31:33,495  Charger state changed from 0 to 2

    Kann es sein, dass openHAB regelmäßig (oder z.B. bei Reconnect?) alle MQTT-Topics schreibt, die es findet? Ich weiß das ioBroker das Problem hat, siehe z.B. hier:

    Das hat im Extremfall dazu geführt, dass ioBroker die Wallbox andauernd neugestartet hat, weil es andauernd auf die /reboot-API geschrieben hat :D

×
×
  • Neu erstellen...