Jump to content

rtrbt

Administrators
  • Gesamte Inhalte

    1.401
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    127

Posts erstellt von rtrbt

  1. Kurzes Update: Ich habe den Prozess etwas vereinfacht, du kannst jetzt Firmwares einbetten, indem du die .zbin-Datei in den Ordner des Moduls legst. Die prepare.py erstellt daraus beim Bauprozess den Header, der reinkompiliert wird.

    Falls du deine Änderungen in ein eigenes Modul auslagerst, musst du dir die prepare.py aus einem der Module klauen, die Firmwares einbetten, also aus EVSE (2.0), NFC oder SDM72DM.

  2. 23 minutes ago, mattsches said:

    Eine Codeänderung müsste ich dann im EVSE-Repo vornehmen. Stimmt das so?

    Das stimmt soweit.

    Du musst die Firmware dann bauen, dann sollte in evse-bricklet/software/build eine evse-bricklet-firmware.zbin rausfallen. Das ist im Endeffekt eine Zip-Datei. Darin gibt es die evse-bricklet-firmware.bin, das ist die eigentliche Firmware. Die kannst du mit xxd -i evse-bricklet-firmware.bin > evse_firmware.h in den Header umwandeln. Wichtig! Bevor du das machst, mach den Header auf und kopiere die ersten 8 Zeilen raus, lass dann xxd laufen, paste die 8 Zeilen wieder und passe die Versionsnummer an.

    Die Wallbox-(lies ESP-)Firmware ist so gebaut, dass sie beim booten vom EVSE die installierte Firmware-Version ausliest, und wenn das eine andere ist als die, die in der ESP-Firmware eingebettet ist, diese überflasht. Wenn du also die Versionsnummer erhöhst, wird das EVSE automatisch umgeflasht.

    Du hast aber folgende Alternativen:

    1. Lass die Versionsnummer so, bette deine Firmware ein und drück dann nach dem ersten Booten im Webinterface unter Ladecontroller -> Low-Level-State auf neu flashen
    2. Wenn du [wallbox_ip]/hidden_proxy/enable aufrufst, kannst du dich mit dem Brick Viewer auf die Wallbox verbinden und das EVSE wie jedes andere Bricklet auch flashen. Da _musst_ du dann aber die Versionsnummer so lassen, wie sie in der eingebetteten Firmware ist, weil die Wallbox ansonsten die eingebettete Firmware wieder drüber flasht.
  3. Moin,

    Ich habe das mal sinnvoller gelöst: Die pio_hooks installieren die Javascript-Abhängigkeiten jetzt automatisch, falls sie fehlen, das Authentication-Modul macht das jetzt genauso.

    11 hours ago, mattsches said:

    Zuvor hatte ich mit dem Setup-Skript für die Build-Umgebung meine Probleme.

    Damit meinst du die für Bricklet-Firmwares? Die brauchst du für die Wallbox-Firmware selbst nicht. (Es sei denn du willst am Ladecontroller selbst Änderungen vornehmen) Edit: Vergiss das, habe gerade den anderen Thread gesehen ;)

  4. Moin Martin,

    Ich gehe mal davon aus, dass das -246°C sind, das ist der kleinste Wert, den das PTC-Bricklet messen kann. Ich kenne einen Fall bei dem das Problem dann war, dass eine der Steckverbindungen (Sensor -> Bricklet -> HAT -> Pi) nicht ganz saß und genau das Problem auftrat. Eventuell kann sich @KlausGünther an Details erinnern, bzw. ob das Problem bei ihm nochmal aufgetaucht ist.

    Ich hätte ansonsten folgenden Fragenkatalog:

    • Welche Brick Daemon-Version hast du laufen? (steht im Log ganz oben)
    • Wie lange hält der Fehler an?
    • Hat sich das Problem von alleine gelöst, oder musstest du irgendetwas tun?
    • War das bei allen Bricklets gleichzeitig?
    • Wie sieht der Aufbau aus? Also was misst du für Temperatur-Bereiche, ist das "outdoor" usw.

    Poste am besten auch mal die Graphen und ein Brick Daemon-Log.

    Grüße,
    Erik

  5. 14 hours ago, fow0ryl said:

    Habe die Firmware 1.0.2 installiert. Damit ist der ominöse AP verschwunden. :) Vielen Dank dafür.

    Gut zu hören!

    14 hours ago, fow0ryl said:

    Bei der Seite "Firmware Aktualisierung" fällt mir jetzt auf, das Firmwareversion (1.0.2-615ea785) und Konfigurationsversion (1.0.1-613f0f54) unterschiedlich sind.
    Vielleicht kann mich diesbezüglich noch jemand aufschlauen ...

    Das sollte ich eventuell dokumentieren. Die Konfigurationsversion ist immer die Version, mit der die Wallbox-Konfiguration zum ersten Mal geschrieben wurde (nach Auslieferung bzw. nach einem Reset auf Werkszustand). Stand jetzt ist die Version unwichtig, falls ich aber irgendwann brechende Änderungen machen muss, kann ich dann sauber migrieren.

  6. 18 hours ago, PatrickM said:

    Nun klappt es auch über die reine LAN-Verbindung ohne parallele WLAN-Verbindung: Ich habe die IP-Konfiguration der LAN-Verbindung auf statische IP umgestellt. Damit scheint sich die Verbindung schneller aufzubauen.

    Aus meiner Sicht bestätigt sich damit Deine o.g. Vermutung. 

    Das deckt sich soweit mit den Tests, die ich hier gemacht habe.

    Soweit du mit statischen IPs leben kannst, würde ich da erstmal nicht mehr Zeit investieren. Ich habe sowieso vor in nächster Zeit die ganze MQTT-Implementierung durch eine andere zu ersetzen, deshalb würde es sich nicht lohnen das weiter zu debuggen, solange MQTT grundlegend funktioniert.

    19 hours ago, PatrickM said:

    Aber nun wird ein Fehler des mDNS responder "Error setting up mDNS responder!" ins Log geschrieben, den habe ich vorher nicht gesehen.

    Das ist ein bekanntes Problem, ich bin aber bisher noch nicht dazu gekommen es zu fixen.

  7. 1 hour ago, Krystman said:

    Du hast nicht auch zufällig den Deckel mit abgezogenem Button auf der Werkbank liegen beim testen, oder? ;-)

    :D Die Idee hatte ich auch, aber dann würden im Log nicht die ganzen Verbindungsversuche aufschlagen.

    Ich wühle mich gleich nochmal durch die MQTT-Bibliothek, in der Hoffnung herauszufinden, wo es bei dir hakt. Schonmal als Teaser: Jedes "Connecting to MQTT broker" sollte danach einen Fehler und/oder ein "Disconnected" mit Fehlercode erzeugen (das sind in der Firmware Callbacks aus der MQTT-Bibliothek). Da das nicht passiert, muss irgendetwas in der Bibliothek verquer sein. Auffällig ist, dass die Box relativ lange braucht, um einen IP zu beziehen:

    5407        Ethernet connected
    8376        Had to configure softAP ip 1 times.
    10377       Soft AP started.
    10377           SSID: warp2-WFk
    10377           hostname: warp2-WFk
    10730           IP: 10.0.0.1
    10849       Connecting to MQTT broker
    12568       Ethernet MAC: A8:03:2A:31:66:2F, IPv4: 192.168.12.24, Full Duplex, 100 Mbps
    12569       Ethernet got IP address: 192.168.12.24.
    12580       Network connected. Stopping soft AP
    70861       Connecting to MQTT broker

    Das dauert so lange, dass der erste Verbindungsversuch passiert, wenn die LAN-Verbindung noch nicht besteht. Eventuell kommt da das Routing durcheinander und versucht über den Soft-AP zu gehen, obwohl der ja gestoppt ist.

    Ich melde mich nochmal, wenn ich mehr weiß.

  8. Moin Christoph,

    Hast du die Wallbox bei der Installation der Zuleitung und dem Anschluss des LAN-Kabels jeweils ohne die Frontplatte betrieben? Das wäre die beste Erklärung warum die Konfiguration verloren gegangen ist. Zur Erklärung:

    Bei WARP 1 war es so, dass einer der Buttons auf dem ESP selbst einen Factory Reset (lies: ein Formatieren der Konfigurationspartition) auslöst. Das klappt bei WARP 2 so nicht, weil auf dem selben Signal wie der Button der Ethernet-Takt liegt. Deshalb hatte ich als Alternative dazu eingebaut, dass wenn man die Wallbox bestromt und der Taster in der Frontplatte gedrückt ist, der Reset ausgeführt wird.

    Das führt jetzt dazu (ganz ehrlich: da habe ich einfach nicht dran gedacht), dass der Reset ausgelöst wird, wenn du die Wallbox ohne die Frontplatte betreibst.

    Für die nächste Firmware-Version setzen wir den Factory Reset anders um, voraussichtlich muss man dann den ESP aus der (unbestromten!) Wallbox ausbauen, an einen PC anschließen und den Reset per Brick Viewer machen. Ist komplizierter, aber im Normallfall sollte der Reset ja unnötig sein.

    Danke für's melden!
    Erik

     

  9. Moin Alex,

    11 hours ago, Alex 75 said:

    Kann man eigentlich (ohne große Umprogrammierungen etc.) anstelle des SDM630 auch einen Shelly 3EM in der Warp oder in der Unterverteilung verwenden und die Werte über das WLAN auslesen und funktioniert dann noch das Warp 2 Lastmanagement?

    Warp 2 unterstützt nur den SDM630. Das Lastmanagement funktioniert aber ohne Zähler, da es nur Maximalströme vorgibt, ob das Fahrzeug diesen Strom dann auch zieht ist ein anderes Problem. D.h. wenn du anderweitig den Shelly 3EM in deine Unterverteilung baust und in dein WLAN bekommst, müsste das funktionieren.

    11 hours ago, Alex 75 said:

    Kann das Lastmanagement der Warp 2 auch Fremdwallboxen wie die cfos steuern, so dass der Hausanschluss nur mit maximal 34kW belastet wird?

    Stand jetzt nicht.

    Ich hatte mir das Thema OCPP vor ein paar Monaten angesehen, habe es aber aufgrund der Komplexität erstmal hinten angestellt. OCPP-Unterstützung (dann voraussichtlich OCPP 1.6 JSON) wird irgendwann kommen, ich kann dir aber nicht versprechen wann. (Nur dass es dieses Jahr nichts mehr wird, das Jahr ist ja nicht mehr lang, die TODO-Liste aber schon ;) )

    Aufgrund dessen wie OCPP funktioniert, sind die Wallboxen dann aber nur "Clients", werden also von einem OCPP-Server gesteuert, den du dann auch bräuchtest. Das ist aber bei den cfos-Boxen genauso soweit ich das spontan gelesen habe.

  10. On 9/29/2021 at 10:02 AM, ThomasH said:

    Habe ich es jetzt richtig verstanden dass die Verbesserungen beim Ladecontroller in der 1.2.4 eigentlich schon drin wären (zumindest für die VW ID)?

    Korrekt.

    On 9/29/2021 at 10:02 AM, ThomasH said:

    Wird es dann so sein dass mit 1.2.5 sowohl der neue Web Server als auch die Verbesserung beim Ladecontroller inkludiert wären?

    Das wird voraussichtlich die 1.3.0, aber ja darin sind sowohl die aktuelle Ladecontroller-Firmware, als auch der neue Web-Server und das Lastmanagement.

    • Like 1
  11. Moin Patrick,

    Mir ist absolut unklar, warum deine Box in den Zustand gekommen ist. Zur Erklärung: Username und Passwort, sowie ein Flag ob der Login aktiviert ist, werden im Flash der Wallbox gespeichert. Das Firmware-Update ändert an diesen Daten nichts. Selbst wenn jetzt z.B. das Speichern der Datei schiefgegangen ist, würde die Wallbox die Standardeinstellungen laden, bei denen der Login natürlich aus ist.

    Damit du erstmal wieder auf die Wallbox zugreifen kannst, müsstest du die Einstellungen zurücksetzen.

    On 9/24/2021 at 4:51 PM, Sinus76 said:

    Ein Rücksetzen per Stromlos & Taste bringt keine Besserung.

    Das ist wie man WARP 2 zurücksetzt, bei WARP 1 musst du die Frontplatte abnehmen und den IO0-Button 10 Sekunden gedrückt halten. Siehe hier: https://www.warp-charger.com/documents/WARP_Betriebsanleitung.pdf (Seite 10)

  12. Moin,

    Das sieht nach dem klassischen VW-Ladeproblem aus: Wenn das Auto von "Ich bin hier" auf "Ich will laden" umschaltet, springt der Widerstandsmesswert kurz extrem hoch, was die Wallbox als "Das Auto ist nicht mehr angeschlossen" interpretiert. Wir haben in der Firmware 1.2.3 dafür den ID.3-Modus eingebaut, der auf die Änderung träger reagiert.

    Welche Firmware hast du laufen? Falls es nicht 1.2.4 ist, teste mit der aktuellen nochmal (Findest du hier). Wenn das Problem dann immer noch auftritt, erstell bitte nochmal ein Ladelog. Du musst die Konfigurationen übrigens nicht rauslöschen: Passwörter können über das Webinterface nicht ausgelesen werden, d.h. du leakst höchstens deinen WLAN-Namen und den Hostnamen der Box (die kannst du natürlich gerne löschen, aber alles, was mit evse/ anfängt könnte hilfreich zum Debuggen sein ;) )

    Grüße,
    Erik

  13. Kurze Bestandsaufnahme:

    52 minutes ago, Jhonny said:

    Heute lud das Auto nicht mehr, weil die wallbox laut web Interface keine Verbindung hatte

    Damit meinst du, dass die Wallbox auf der das Lastmanagement läuft, die zweite Wallbox nicht mehr erreichen konnte. An welcher von beiden hattest du das Auto angeschlossen? (Das Lastmanagement schaltet sicherheitshalber alle Boxen ab, wenn eine nicht erreicht werden kann) Warst du auch auf dem Webinterface der anderen Box? War da etwas suspekt, hast du eventuell Ereignis-Logs?

    54 minutes ago, Jhonny said:

    Irgendwas kam allerdings an, da die Status Led anging.

    Das heißt, dass der Ladecontroller selbst noch lebt und nur der ESP32 auf dem das Webinterface läuft Probleme macht (oder die Kommunikation zwischen den beiden oder zwischen den Wallboxen)

    56 minutes ago, Jhonny said:

    Ich habe daraufhin die wallbox vom Strom getrennt und wieder aktiviert, dann ging es wieder.

    Dann können wir schonmal Netzwerkprobleme ausschließen (es sei denn die Wallbox selbst hat nicht bemerkt dass sie nicht mehr im WLAN ist o.Ä.)

    58 minutes ago, Jhonny said:

    Das Verhalten konnte an meinen beiden Warp Pro nachstellen.

    Mir ist unklar, was du damit meinst. Hast du es mehr als einmal geschafft, dass das Lastmanagement blockiert und es ist egal welche Box du neustartest, damit es wieder funktioniert?

    59 minutes ago, Jhonny said:

    Läuft mit der Zeit irgendein Speicher voll und daher arbeitet die ab nicht mehr ordentlich?

    Hoffentlich nicht ;) Ich halte ein reines Speicherleck für unwahrscheinlich, da würde es bei dir nicht > einen Monat problemlos laufen, soviel RAM hat der ESP nicht.

     

    Falls du das Problem nochmal erzeugen kannst würde mich folgendes interessieren:

    • Kannst du das Webinterface beider Wallboxen noch erreichen?
    • Falls ja: Ein Ereignis-Log und einen Debug-Report beider Wallboxen (im Debug-Report ist u.A. auch der aktuelle Zustand des Lastmanagers)
    • Wie lange bleibt der Zustand so? Reicht es eine Box neuzustarten damit es wieder funktioniert?

    Wir haben hier einen Lastmanagement-Verbund aus vier Wallboxen, der lief aber meines Wissens noch nie länger als zwei bis drei Wochen, weil man immer irgendwelche Dinge testet. Ich bin aber nächste und übernächste Woche im Urlaub und habe meinem Kollegen mal bescheid gesagt, dass er aufpassen soll, dass niemand die Boxen neustartet. Ich habe mir die aktuelle RAM-Auslastung der vier Boxen notiert, für den Fall, dass es wirklich ein Speicherleck ist. Eventuell wissen wir dann Anfang Oktober mehr.

×
×
  • Neu erstellen...