Jump to content

rtrbt

Administrators
  • Gesamte Inhalte

    1.544
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    150

Posts erstellt von rtrbt

  1. On 8/17/2024 at 4:53 PM, Henrik said:

    Failed to deserialize: Payload was empty. Please send valid JSON

    Laut Fehlermeldung sieht die Wallbox keinen Payload, was seltsam ist. Wie schickst du den HTTP-Request oder die MQTT-Nachricht?

    On 8/17/2024 at 4:53 PM, Henrik said:

    2) Wenn ist diesen Parameter in der WebGUI ändern will (Manual charge release, inhaltlich umgekehrte Logik, aber egal), dann muss einmal ein Reboot durchgeführt werden. Muss ich hier etwas über die Schnittstelle bedienen, oder geht das automatisch?

    Der Auto-Start (bzw. manual charge release im Webinterface; ist übrigens umgekehrt, weil anscheinend die Nutzer so weniger verwirrt sind) ist eine der wenigen Einstellungen, die sofort greifen, das weiß aber das Webinterface nicht. D.h. wenn du nur den verstellst, kannst du dir den Neustart sparen. Jede Änderung des Auto-Starts wird aber in den Flash des Ladecontrollers geschrieben, du solltest den Wert also nicht zu oft schreiben (z.B. stündlich ist okay, sekündlich nicht), damit der Flash nicht abgenutzt wird.

  2. Per Mudbus kannst du den Ausgang nicht steuern. Eventuell fügen wir ein Register dafür hinzu, habe dafür ein Issue angelegt:https://github.com/Tinkerforge/esp32-firmware/issues/362

    Über HTTP und MQTT kannst du den Ausgang steuern, indem du true oder false auf evse/gp_output schreibst: https://docs.warp-charger.com/docs/mqtt_http/api_reference/evse#evse_gp_output_warp2

    • Thanks 1
  3. Das kann ich dir gerade nicht erklären und @MatzeTF ist im Urlaub. Die Einschränkung wird aber nur im Webinterface geprüft, d.h. über die API können wir 25 Ampere einstellen:

    Geh mal auf die Recovery-Seite deiner Wallbox (z.B. http://warp3-AbCd/recovery oder http://10.0.0.1/recovery falls du im AP der Wallbox bist) und füge da bei API ins obere Eingabefeld folgendes ein:

    {"method":"PUT","url":"/power_manager/dynamic_load_config","payload":{"enabled":null,"meter_slot_grid_currents":null,"current_limit":25000,"largest_consumer_current":null,"safety_margin_pct":null}}

    und klicke auf "Call API". Im unteren Feld sollte dann eine 200 erscheinen und wenn du im Webinterface nachsiehst sollte der Hausanschluss auf 25 A stehen.

    Wenn du die anderen Einstellungen auf der Lastmanagement-Unterseite änderst musst du danach wieder den Hausanschluss über die Recovery-Seite setzen. Das Webinterface erlaubt es ja nicht Werte < 32 A zu speichern.

  4. On 7/28/2024 at 10:58 AM, dg3fbl said:

    Entweder ich habe es im Modbus noch nicht gefunden, oder es gibt sie nicht?

    Die gibt es in der Tat im Moment nicht, kommt aber möglicherweise in der Zukunft. Die Tag-Injection per Modbus hat ein paar Fallstricke, deshalb haben wir sie noch nicht implementiert. Ich habe aber mal ein Issue angelegt: https://github.com/Tinkerforge/esp32-firmware/issues/359

    • Like 1
  5. Wenn du schon ein NFC-Tag zur Ladefreigabe verwendest, dann stoppe den Ladevorgang lieber über die nfc/inject_tag_stop API aus: https://docs.warp-charger.com/docs/mqtt_http/api_reference/nfc#nfc_inject_tag_stop_warp3

    Wenn du per MQTT external_current auf 0 setzt, dann musst du auch per MQTT wieder freigeben (oder im Webinterface unter Wallbox -> Ladestatus von Hand die Stromgrenze zurücksetzen)

    Wenn du mit einer NFC-Tag-Injection über MQTT stoppst, dann kannst du den nächsten Ladevorgang einfach wieder mit deinem Tag starten.

  6. Moin,

    @MatzeTF und ich haben in den letzten Monaten das Lastmanagment grundlegend überarbeitet. Der Lastmanager kann jetzt:

    • Dynamisches Lastmanagement: Der Lastmanager stellt sicher, dass der Netzanschluss nicht überlastet wird, auch wenn andere (ungesteuerte) Verbraucher den Hausanschluss dynamisch belasten.
    • PV-Überschussladen: Der Lastmanager stellt sicher, dass nur der PV-Überschuss verwendet wird, um Fahrzeuge zu laden.
    • Statisches Lastmanagement: Der Lastmanager stellt sicher, dass die gemeinsame Zuleitung des Wallbox-Verbunds nicht überlastet wird.

    Und das alles mit bis zu 32 Wallboxen. Insbesondere sollte jetzt auch das PV-Überschussladen mit mehreren Wallboxen deutlich besser funktionieren. Details zur Funktionsweise finden sich hier: https://docs.warp-charger.com/docs/warp_charger/new_charge_management

    Im Moment funktioniert das neue Lastmanagement nur mit Wallboxen: Es kann nicht auf dem WARP Energy Manager verwendet werden und auch keine Wallboxen über einen WARP Energy Manager Phasenumschalten. Beide Punkte werden wir bis zur fertigen, also nicht-Beta-Veröffentlichung noch fixen.

    Die Konfiguration sollte für das statische Lastmanagement und das PV-Überschussladen unverändert weiter funktionieren, damit das dynamische Lastmanagement verwendet wird, muss es unter Energiemanagement -> Lastmanagement konfiguriert werden.

    Falls das Lastmanagement nicht wie erwartet funktioniert, oder seltsame Entscheidungen trifft, können die Informationen der Lastmanagment-Debug-Unterseite hilfreich sein. Dort kann unter anderem ein Lastmanagement-Log heruntergeladen werden, dass aufschlüsselt, was in der letzten ~ Stunde passiert ist. Falls Probleme auftreten können wir diese mit dem Log hoffentlich nachvollziehen.

    Wir freuen uns auf euer Feedback!

    Edit: Veraltete Firmware entfernt.

     

  7. Firmware: WARP Energy Manager 2.1.2

    • Unterstützung für weitere Modbus-TCP-Geräte hinzugefügt: Alpha ESS SMILE, Shelly Pro (3)EM
    • Sungrow-Registertabelle repariert
    • Laden im “schnell”-Modus erlaubt, selbst wenn PV-Überschuss-Zähler noch keine Werte geliefert hat
    • Lastmanagement-Startphase repariert
    • Repariert, dass Webserver für immer gehangen hat, wenn Laden der Energiebilanzdaten fehlgeschlagen ist
    • Hinzugefügt, dass Netzwerkverbindungen vor Neustart geschlossen werden
    • Hinzugefügt, dass manche Stromzählerwerte aus anderen berechnet werden, falls sie nicht vom Zähler gemeldet werden
    • Repariert, dass manche MQTT-Fehler nicht im Ereignis-Log angezeigt wurden

    Download: WARP Energy Manager 2.1.2

  8. Firmware: WARP 2.4.1, WARP2 2.4.1 und WARP3 2.4.1

    • Unterstützung für weitere Modbus-TCP-Geräte hinzugefügt: Alpha ESS SMILE, Shelly Pro (3)EM
    • Sungrow-Registertabelle repariert
    • Laden im “schnell”-Modus erlaubt, selbst wenn PV-Überschuss-Zähler noch keine Werte geliefert hat
    • Lastmanagement-Startphase repariert
    • Modbus-TCP-Registertabellen-Dokumentation verbessert
    • Repariert, dass Webserver für immer gehangen hat, wenn Laden der Energiebilanzdaten fehlgeschlagen ist
    • Hinzugefügt, dass Netzwerkverbindungen vor Neustart geschlossen werden
    • Überschreiben des Energie-Limits repariert
    • Hinzugefügt, dass manche Stromzählerwerte aus anderen berechnet werden, falls sie nicht vom Zähler gemeldet werden
    • Repariert, dass manche MQTT-Fehler nicht im Ereignis-Log angezeigt wurden
    • Berechnung der Belegungsanzeige des Ladetrackers repariert
    • Titel des Ladelog-PDFs repariert
    • Erzeugung des Ladelog-PDFs beschleunigt
    • Überlauf der Stromzählerwerte behoben
    • (Nur WARP1) CP/PE-Messung verbessert (durch Update auf Ladecontroller-Firmware 2.1.10)

    Download: WARP 2.4.1 bzw. WARP2 2.4.1 bzw. WARP3 2.4.1

    • Like 1
  9. Hast du unter Wallbox -> Einstellungen die "Status-LED-Steuerung" aktiviert? Das sollte für Automatisierungsregeln nicht notwendig sein, könnte aber dazu führen, dass die Regel ignoriert wird. Wie genau sieht deine Automatisierungs-Regel aus? Siehst du im Ereignislog "Running rule #[zahl]" wenn du auf das MQTT-Topic schreibst?

  10. On 7/19/2024 at 3:09 AM, alestrix said:

    Wie ich gesehen habe, ist das WiFi Passwort im coredump enthalten

    Du meinst im Debug-Report? Das WiFi-Passwort (wie auch alle anderen Passwörter usw.) sollte durch null ersetzt sein. Wenn das nicht der Fall ist, sag bitte auf jeden Fall Bescheid, das müssten wir sofort fixen.

    On 7/19/2024 at 3:09 AM, alestrix said:

    Und warum steht da eigentlich beim device_name "WARP Charger Pro"?

    Das liegt vermutlich daran, dass du einen Stromzähler mit der ID 0 (in der Stromzähler-Konfiguration im  Webinterface heißt das generisch "Nummer") hinzugefügt hast. Der wird von der Wallbox als der "interne" Zähler betrachtet und z.B. für den Ladetracker verwendet. Die Wallbox weiß von sich aus nicht, ob sie eine Smart oder Pro ist, sondern wenn ein Zähler mit ID 0 auftaucht, dann betrachtet sie sich selbst als Pro.

    Damit der Ladetracker jetzt nicht die Daten deines Hausanschlusses aufzeichnet kannst du entweder die Nummer des Zählers auf 1 ändern, oder von Hand https://docs.warp-charger.com/docs/mqtt_http/api_reference/evse#evse_meter_config_warp1 auf 1 schreiben. Dafür gibt es leider noch keine UI. In beiden Fällen solltest du dann noch unter Wallbox -> Einstellungen die Zählerüberwachung deaktivieren, die dürfte sich scharfgeschaltet haben, wenn die Box sich einmal als Pro erkennt.

    On 7/19/2024 at 3:09 AM, alestrix said:

    Wenn ich "Verlangt eine Freigabe des Lade­vorgangs durch einen Benutzer zum Laden (z.B. per NFC-Tag)" ausschalte und verschiedene Tags verschiedenen Usern mit unterschiedlichen Strombegrenzungen zuweise und dann die verschiedenen Tags injecte, ändert sich kein einziger der 15 Laststromgrenzen-Werten, die Strombegrenzungen bei den Usern haben also keinerlei Auswirkung.

    Das ergibt Sinn, du hast das Feature damit ja ausgeschaltet. Wenn du keine NFC-Freigabe willst, aber trotzdem per NFC den Ladestrom kontrollieren, dann musst du das per Automatisierungs-Regel erschlagen.

    On 7/19/2024 at 3:09 AM, alestrix said:

    Wie aufwendig wäre es, die CP Trennung bei der WARP1 nachzurüsten?

    Das ist möglich, aber involviert etwas Bastelei. @poohnet hat einen Fork der WARP-Firmware mit CP-Trennung für WARP1 und die entsprechende Hardware-Modifikation hier:

    hier: https://github.com/poohnet/esp32-firmware

    und hier:

    Die letzte Version des Forks  ist aber 2.2.1, d.h. da fehlen dir dann die PV-Überschuss-Features

  11. On 7/1/2024 at 11:08 PM, 1biOnSCoMe said:

    Kann man die grundsätzlich in den Griff bekommen oder sind sie irgendwie in der Hardware begründet?

    Prinzipiell kann der Access Point des ESPs deutlich schneller sein. Im Issue, dass Matze verlinkt hat, hatte ich damals ~ 20Mbit/s gemessen, wenn auf dem ESP eine minimalistische Firmware läuft, die nur den Access Point öffnet und sonst nichts tut.

  12. Quote
    [...]
    gpiochip4 - 54 lines:
        [...]
        line   7:      "GPIO7"   "spi0 CS1"  output   active-low [used]
        line   8:      "GPIO8"   "spi0 CS0"  output   active-low [used]

    There's the problem: Your HAT Brick's firmware is outdated. The easiest way to fix this is to use an older Raspberry Pi (every version up to and including a Pi 4 will work). Plug the HAT on the old Pi, install Brick Daemon there, connect to the Pi with Brick Viewer and update the HAT Firmware to 2.0.4. Then plug the HAT back onto the Pi 5 and boot it, gpioinfo should then report both those lines as unused and Brick Daemon should be able to start.

    If you don't have another older Pi available, we have to build a patched version of Brick Daemon for you.

  13. Du redest von der ESP32-Firmware? Die hat in der Tat eine Konfigurationspartition mit mehr oder weniger normalem Dateisystem.

    Du kannst dir z.B. hier abgucken wie man JSON-Daten liest und schreibt (du kannst mit diesem Weg auch beliebigen Text/Binärdaten lesen und schreiben):

    https://github.com/Tinkerforge/esp32-firmware/blob/dfcc160df3355c46f561ea1a48ecb9c9e173d69a/software/src/config_migrations.cpp#L65

    Wenn du dir den Inhalt der Partition ansehen willst, kannst du im software-Ordner (also neben z.B. esp32.ini) eine Datei namens default_wifi.json mit folgenden Inhalt anlegen:

    {
        "debug_fs_enable": "true"
    }

    und das Debug-Backend-Modul reinkompilieren. Dann kannst dich unter http://esp32-abcd/debug/fs/ durch das Dateisystem klicken.

     

    Es gibt noch die einfachere Variante (falls dir JSON reicht), dass du eine API definierst und die als persistentConfig speicherst. Das funktioniert grob wie im Tutorial: https://www.tinkerforge.com/de/doc/Tutorials/Tutorial_ESP32_Firmware/Tutorial.html#phase-3-kommunikation-frontend-zu-backend

    nur dass du statt api.addState und .addCommand stattdessen api.restorePersistentConfig zum Laden aus dem Flash und api.addPersistentConfig zum Registrieren der API verwenden musst.

    api.addPersistentConfig ist optional, du kannst auch (gerade wenn du dein Setup im Code modifizieren und speichern willst) nur api.restorePersistentConfig zum Laden und api.writeConfig zum Speichern benutzen.

×
×
  • Neu erstellen...