Jump to content

rtrbt

Administrators
  • Gesamte Inhalte

    1.543
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    150

Posts erstellt von rtrbt

  1. https://github.com/Tinkerforge/dbus-warp-charger die hohe CPU-Load sollte gefixt sein. Stellt sich raus das Script hat alle 250ms 9 HTTP-Requests gemacht, das war etwas viel. Es gibt jetzt in der config.ini den Wert UpdateInterval, der angibt wie oft die Daten aktualisiert werden, mit default 1 (=Sekunden). Außerdem macht ein Update nur noch die Hälfte an Requests und die Auto-Start-Logik war kaputt, das sollte jetzt auch passen.

  2. Das steht leider nicht direkt auf der API, sondern das Webinterface baut den Text zusammen. Im Endeffekt musst du evse/slots auswerten. Jeder Slot dessen Wert gleich dem Minimalwert ist, ist einer der vom Webinterface aufgelistet werden würde. Die Namen der Slots findest du z.B. hier: https://github.com/Tinkerforge/esp32-firmware/blob/586496e0e54e6ab4c4fa5e9efe5e6e9877dae3ff/software/web/src/modules/evse_common/translation_de.tsx#L123-L139 (da steht ein TODO an der API-Dokumentation, weil die Slotnamen fehlen, das hat leider noch keiner geschafft einzubauen)

  3. On 3/22/2025 at 7:37 PM, cord said:

    Komisch ist der unterschiedliche Energiebezug zw. warp2 und test, die sich um die 0,038kWh Einspeiseenergie unterscheiden, obwohl beide als Wirkenergie (Bezug) als Summe über L1-L3 definiert sind.

    Das liegt vermutlich daran, dass deine WARP2 als Energiewert (für Ladetracker usw.) noch den Bezugs + Einspeisungswert verwendet. Der wird dann auch im Modbus Register 2004 ausgegeben. Details hier: https://www.tinkerforge.com/de/blog/new-features-in-warp2-221-and-wem-202/ (letzte Zwischenüberschrift)

    Du kannst jetzt entweder stattdessen Register 2160 lesen oder wie im Blogpost beschrieben einmal die aufgezeichneten Ladevorgänge löschen, dann wechselt die Wallbox auf den Bezugswert. (Oder das "offizielle" Registerset aus der Testfirmware verwenden)

  4. On 3/24/2025 at 7:36 AM, EMike said:

    D.h. die Daten von Stromzählern auf die ich vom WARP3 Charger auch zugreifen kann, werden nur gelesen und nicht gespeichert?

    Genau, die werden nur im RAM gehalten.

    On 3/24/2025 at 7:36 AM, EMike said:

    Wie lange hält der Speicher für die Ladevorgänge beim WARP3?

    7680 Ladevorgänge lang. Da war die Idee, dass selbst eine sehr gut genutzte Wallbox (10 Ladevorgänge am Tag) mehr als 2 Jahre aufzeichnen können soll. Wenn die 7680 Ladevorgänge erreicht sind, wird der erste Block (256 Ladevorgänge) weggeworfen, damit neue aufgezeichnet werden können.

    • Thanks 1
  5. On 3/12/2025 at 9:45 AM, EMike said:

    Also via Smartphone und GoogleChrome auch kein Problem und Webinterface optimiert für mobile Nutzung?

    Ja.

    On 3/12/2025 at 9:45 AM, EMike said:

    Gibt es hierzu irgendwo eine Demo, Screenshots oder gar eine Doku?

    Ich wollte schon die Screenshots von warp-charger.com verlinken, aber in der Tat sind die alle nicht im Handy-Modus. Guck alternativ mal hier: https://play.google.com/store/apps/details?id=com.tinkerforge.warp Das ist unsere App, die aber 1:1 das Webinterface durchreicht (Sinn der App ist, dass du von außerhalb deines Heimnetzes auf die Wallbox zugreifen kannst. Ist komplett optional, aber ganz praktisch)

    Von den Screenshots werden wir ein paar zu den Impressionen packen, danke für den Hinweis!

    Demo-Webinterface ist angedacht (siehe https://github.com/Tinkerforge/warp-charger/issues/31), aber noch nicht implementiert.

    • Like 1
  6. Das Webinterface sollte mit allen modernen Browsern problemlos funktionieren, ansonsten ist das ein Bug, den wir fixen müssen. Es gibt ein paar Einschränkungen bei Safari, die wir nicht oder nur mit sehr viel Aufwand fixen können:

    Ansonsten wäre mir im Moment nichts bekannt.

    Es gab immer mal kleinere Bugs bei Nischenbrowsern wie z.B. dass der DuckDuckGo-Browser auf Android eine ganze Weile lang keine Debug-Reports herunterladen konnte: https://github.com/duckduckgo/Android/issues/1010#issuecomment-1006492456 das ist inzwischen aber gefixt.

  7. Ich habe gerade versucht dein Problem mit den Zugangsdaten zu reproduzieren, bei mir funktioniert es aber auf einer frischen WARP3 mit Firmware 2.7.6 einen Nutzer anzulegen, dann auf 2.7.3 downzugraden und mich dann einzuloggen. Hattest du Test-Firmwares aus dem Forum laufen und wenn ja, welche?

    Edit: Ich frage das, weil der Login in der Tat kaputt war, aber nur in einem Firmware-Stand, den du nicht gehabt haben solltest, soweit ich den Thread hier nachgelesen habe.

  8. On 3/6/2025 at 8:53 PM, till said:

    Aber nun kam die 2.7.6 raus, ich vermute damit erledigt sich das testen der Nightly, der? Die Release notes lesen sich so also der fix da schon drin ist.

    Genau, der Fix ist in 2.7.6 schon drin.

    On 3/7/2025 at 7:52 AM, nagi said:

    Was ich jetzt gerne hätte: Einphasig laden bis max. konfigurierter Ladestrom, dann Umschaltung auf dreiphasig wenn sowohl der max. konfigurierte einphasige Ladestrom als auch die 3*6=18A für die Dauer des Wolkenfilters überschritten sind.

    Fast genau so funktioniert das Lastmanagement schon: Es wird erst dann auf dreiphasig umgeschaltet, wenn das 1. notwendig ist und 2. vermutlich nicht sofort wieder auf einphasig gewechselt werden muss.

    1. bedeutet, dass nur umgeschaltet wird, wenn das Lastmanagement feststellt, dass es den PV-Überschuss nicht einphasig los wird.
    2. bedeutet, dass der PV-Überschuss mindestens für die Dauer des Wolkenfilters der dreiphasige Minimalstrom gewesen sein muss.

    Die Details sind noch etwas komplizierter, du kannst dir https://docs.warp-charger.com/docs/tutorials/charge_management_details

    mal ansehen, wenn du möchtest. Das ist leider schon wieder etwas veraltet (weil die Änderungen für Wallboxen in verschiedenen Lademodi noch nicht berücksichtigt sind), die Grundlagen stimmen aber noch.

  9. Versuch mal direkt

    console.log(data.response.data)

    anstatt von

    const test = Buffer.from( data.response.data )
    console.log( test )

    data.response.data ist schon ein Array von Buffern. Ich bekomme

    [ <Buffer 00 00>, <Buffer 00 01>, <Buffer ff ff>, <Buffer ff ff> ]

    wenn ein Auto angesteckt ist, also einen Buffer pro Register mit je 2 Byte drin. Du müsstest dann noch herausbekommen, wie man aus jeweils zwei Buffern eine 32-Bit-Zahl macht.

  10. Nur um das offensichtliche auszuschließen: Du hast unter Schnittstellen -> Modbus TCP mindestens den Lesezugriff aktiviert und die WARP Charger-Registertabelle ausgewählt? Bekommst du im Ereignislog eine Ausgabe in der Art von "modbus_tcp_srvr  | client connected: peer_address=123456789 port=47496"?

    On 3/4/2025 at 10:15 PM, guidoBln said:

    Ja, genau das habe ich vor.

    Sorry, ich bin verwirrt. Du hast vor die Holding oder die Input Register zu lesen?

  11. Das Problem sollte eigentlich mit WARP(1) 2.7.3 und WARP2/3 2.7.4 behoben sein. Falls du diese Firmware (oder neuer) schon hast, dann müsste ich versuchen, das hier zu reproduzieren. Das ist etwas schwierig, weil ich dafür die genauen (also die unveränderten Bytes der) Nutzernamen benötige.

    Dafür brauche ich von dir drei Dateien:

    1. Einen Debug-Report (kannst du unter System->Ereignislog herunterladen)
    2. Die Nutzernamen-Datei. Die kannst du herunterladen indem du mit dem Browser auf z.B. http://warp3-AbC/users/all_usernames gehst (warp3-AbC musst du auf deine Wallbox anpassen)
    3. Die getrackten Ladevorgänge im Binärformat. Die kannst du unter http://warp3-AbC/charge_tracker/charge_log herunterladen

    Die drei Dateien schickst du am besten per Mail an erik@tinkerforge.com oder als PM im Forum an mich.

×
×
  • Neu erstellen...