rtrbt

Firmware: WARP1 2.8.16, WARP2 2.8.17, WARP3 2.8.17, WARP Energy Manager 2.4.15, WARP Energy Manager 2.0 1.3.15 Hinzugefügt, dass alle Wallboxen gestoppt werden, wenn PV-Überschussladen oder dynamisches Lastmanagement notwendige Zählerwerte nicht mehr empfangen (Nur WARP2, WARP3, WARP Energy Manager, WARP Energy Manager 2.0) Sichergestellt, dass LAN-Verbindung immer vor WLAN-Verbindung bevorzugt wird Warnung hinzugefügt, falls sich Webinterface- und Browser-Sprache unterscheiden Optionale Scrollbar zu breiten Tabellen hinzugefügt Unterstützung der Netzphasenspannungs- und Frequenzwerte von RCT Power Wechselrichtern hinzugefügt Leistungswerte von Fronius Stromzählern, die Lasten messen, invertiert Netzenergiewerte einiger Goodwe Wechselrichter repariert Behoben, dass SMA Speedwire-Pakete nach wenigen Minuten nicht mehr empfangen wurden Behoben, dass Fernzugriff unter noch unbekannten Umständen für immer blockierte Behoben, dass Fernzugriff versucht hat, zwei Verbindungen parallel aufzubauen Behoben, dass Fehlermeldungen verloren gingen, wenn Firmware-Updates über den Fernzugriff installiert wurden Behoben, dass Fernzugriff nicht deaktiviert wurde, wenn das Geräte serverseitig gelöscht wurde, während es offline war Robustheit von Webserver und Web Sockets gegen Verbindungsabbrüche verbessert (Nur WARP Energy Manager 2.0) Speichern der Displaykonfiguration repariert Download: WARP1 2.8.16 bzw. WARP2 2.8.17 bzw. WARP3 2.8.17 bzw. WARP Energy Manager 2.4.15 bzw. WARP Energy Manager 2.0 1.3.15

Das ist ein bekanntes Problem, wird mit der nächsten Firmware behoben, die eventuell morgen erscheint.

Nach einem reinen Neustart kann ich das hier nicht reproduzieren. Ein Softwareupdate sollte eigentlich nur gehen, während kein Auto angesteckt ist. Wenn du das Auto danach wieder ansteckst, bekommst du die Willkommensladung, danach sollte der Ladevorgang aber wieder stoppen. Wenn du nochmal erzeugen kannst, dass der Ladevorgang dann weiter läuft, zieh von dem Zustand bitte auch einen Debug-Report, dann sollten wir rausbekommen, was los ist.

Die Auto-Discovery ist von uns aus als "einfaches" Interface gedacht, deswegen ist eher reduziert, was von alleine auftaucht. Ich gebe dir aber recht, dass der Lademodus eine sinnvolle Erweiterung wäre. Wir benutzen im Moment einen Generator für die Auto-Discovery-Payloads, in dem es leider nicht ganz einfach ist, den Lademodus hinzuzufügen. Ich habe das mal an das entsprechende Issue angefügt: https://github.com/Tinkerforge/esp32-firmware/issues/398

Ladevorgänge über OCPP sind immer nur erlaubt, wenn das CS sie freigibt. Das Profil setzt nur Ladelimits, erlaubt aber nicht das Laden. Du hast zwei Optionen: Wenn das Auto angeschlossen ist (das sollte dein CS über die StatusNotification.reqs mitbekommen) schickst du ein RemoteStartTransaction.req mit einem beliebigen idTag (alternativ kannst du den auch blind alle 10 Sekunden oder so schicken) Du motivierst die Wallbox dazu, dass sie versucht sich zu autorisieren. Das kannst du "von Hand" tun indem du ein Tag an die Box hältst, oder du klickst dir eine Automatisierungsregel, die wenn ein Auto angesteckt wird, ein Tag vortäuscht, z.B. so: Die Box schickt dann einen Authorize.req an deine CS, den du dann bestätigen musst Edit: Hm @MatzeTF hat auch recht, die manuelle Ladefreigabe hat nichts mit OCPP zutun, die solltest du deaktivieren.

Es hat leider etwas gedauert, bis wir ein CM5 + das IO-Board dazu bekommen haben, aber das ist in der Tat kaputt. Teste bitte einmal die Version im Anhang: (Am besten mit sudo apt install ./brickd_2.4.8+snapshot~192475e_arm64.deb installieren, dann wird dir auch util-linux-extra installiert, was notwendig ist damit die Echtzeituhr des HATs benutzt werden kann) brickd_2.4.8+snapshot~192475e_arm64.deb

Versuch mal auf http://warp2-22sX/nfc/reset zu gehen. (Du bekommst dann nur eine weiße Seite) Du siehst, dass das funktioniert, wenn dann im Ereignis-Log 10 Sekunden lang viele Meldungen der Form "2025-12-19 11:13:39,114 | nfc | Failed to get tag ID 0, rc: -2" auftauchen. Wenn die Box danach wieder auf NFC-Tags reagiert (nimm am besten ein "altes" zum Testen), dann war das nur ein Software-Problem. Wäre dann ein Fall für @borg .

Firmware: WARP1 2.8.14, WARP2 2.8.15, WARP3 2.8.15, WARP Energy Manager 2.4.13, WARP Energy Manager 2.0 1.3.13 Absturz in Lastmanagement-Initialisierung behoben Download: WARP1 2.8.14 bzw. WARP2 2.8.15 bzw. WARP3 2.8.15 bzw. WARP Energy Manager 2.4.13 bzw. WARP Energy Manager 2.0 1.3.13

Firmware: WARP1 2.8.13, WARP2 2.8.14, WARP3 2.8.14, WARP Energy Manager 2.4.12, WARP Energy Manager 2.0 1.3.12 Unterstützung für weitere Modbus-TCP-Geräte hinzugefügt: Zähler der Janitza UMG Serie, Huawei Smart Logger 3000 Auslesen der Batteriekapazitätswerte für Alpha ESS-, Hailei- und Sungrow-Wechselrichter hinzugefügt Summe der MPPT-Leistungswerte des Fronius GEN24 Plus über SunSpec repariert WireGuard- und Fernzugriffs-MTU konfigurierbar gemacht Hinzugefügt, dass sich über Fernzugriff nicht zweimal eingeloggt werden muss Behoben, dass Fernzugriff nicht den Server-Hostnamen neu aufgelöst hat Große Anfragen über Fernzugriff repariert Kompatibilität des Lastmanagers mit Fahrzeugen, die den Ladevorgang abhängig vom verfügbaren Strom starten oder stoppen, verbessert (Nur WARP1, WARP2, WARP3) Hinzugefügt, dass der Ladevorgang automatisch freigegeben wird, wenn alle Automatisierungsregeln, die diesen blockiert haben, entfernt wurden (Nur WARP1, WARP2, WARP3) Behoben, dass Buttons zum Lademoduswechsel bei einer lastgemanageten Wallbox nicht angezeigt wurden, wenn diese zuvor als Lastmanager für nur sich selbst konfiguriert war (Nur WARP1, WARP2, WARP3) Behoben, dass "Lademoduswechsel anfordern"-Automatisierungsregeln nicht korrekt gespeichert wurden (Nur WARP Energy Manager 2.0) Erweitertes Logging des Heizungsmoduls entfernt. Logs werden in Debug-Report geschrieben. (Nur WARP Energy Manager 2.0) Sichergestellt, dass nicht direkt nach einem Neustart in teuren Stunden geheizt wird (Nur WARP2, WARP3, WARP Energy Manager, WARP Energy Manager 2.0) Anzeige der MAC-Addressen und BSSIDs zu den LAN- und WLAN-Unterseiten hinzugefügt (Nur WARP1) Anzeige der MAC-Addresse und BSSIDs zu den WLAN-Unterseiten hinzugefügt Behoben, dass der Modbus-TCP-Client geteilte Verbindungen nicht neu verbunden hat Hostnamen- und IP-Adress-Validierung verbessert Bedienbarkeit des Webinterfaces bei vielen konfigurierten Wallboxen/Zählern verbessert Zeitzonendatenbank aktualisiert (Nur WARP2, WARP3) Sichergestellt, dass CP nicht getrennt bleiben kann, wenn während der Trennung der erlaubte Ladestrom geändert wird (durch Update auf Ladecontroller-Firmware 2.2.19) Download: WARP1 2.8.13 bzw. WARP2 2.8.14 bzw. WARP3 2.8.14 bzw. WARP Energy Manager 2.4.12 bzw. WARP Energy Manager 2.0 1.3.12

Sorry, unsere Dokumentation ist an der Stelle etwas veraltet. Versuch mal direkt eine Lademodus-Zahl auf [dein-topic-prefix]/charge_manager/charge_modes_update/[null-basierter index der Wallbox] zu schreiben. Also z.B. an das Topic warp3-abcd/charge_manager/charge_modes_update/3 eine 0 schicken sollte bewirken, dass die 4. Wallbox in der Konfiguration in den Lademodus 0, also "schnell" wechselt. Das kann ich reproduzieren, habe ich gerade gefixt. Firmware-Update kommt hoffentlich diese Woche noch.

Kauf dir lieber eine WARP3. Je nachdem was für eine PV-Anlage du hast, brauchst du möglicherweise keine Zusatzhardware, siehe hier: https://docs.warp-charger.com/docs/compatible_devices/devices

Das ist unerwartet, im Befehl von Matze sind die eckigen Klammern ja enthalten. Wenn du eine aktuelle Firmware hast, dann kannst du alternativ auch auf http://<WARP-IP>/meters/1/update/0 die Zahl direkt schreiben, also ohne die eckigen Klammern.

Um deine ursprüngliche Frage zu beantworten: Es gab früher die Möglichkeit, die externe Steuerung zu deaktivieren. Das haben wir entfernt, weil jedes Gerät, dass (wenn du die externe Steuerung aktiviert hättest) den Ladevorgang steuern kann, auch die API, die die externe Steuerung aktiviert oder deaktiviert, aufrufen kann. Das hatte also wenig Mehrwert. Außerdem hatten wir extrem viele Support-Anfragen, weil Nutzer vergessen hatten die externe Steuerung zu aktivieren.

Im Moment "soll" das so sein. Wir tracken technisch gesehen eher die Standzeit, als die Ladezeit: Es wird der Zeitpunkt aufgezeichnet zu dem ein Auto angesteckt wird (oder du dich per NFC-Tag autorisierst) und der Zeitpunkt zu dem das Auto wieder abgezogen wird. Das Problem daran, die echte Ladezeit zu tracken ist, dass die ggfalls. zerstückelt ist, z.B. wenn das Ladeziel erreicht wird und du es danach verändest. Manche Autos stoppen den Ladevorgang auch kurz, wenn du die Zentralverriegelung aufmachst. Stand- und Ladezeit separat zu tracken wurde sich schon gewünscht, z.B. hier: https://github.com/Tinkerforge/esp32-firmware/issues/175 Das wartet noch auf andere technisch notwendige Umräumungen, z.B. https://github.com/Tinkerforge/esp32-firmware/issues/329

Das ging eventuell in den letzten Firmware-Releases etwas unter: Prinzipiell können die aktuellen Versionen (seit 03.11.) der Firmware monatlich die Abrechnung per Mail schicken. Das läuft im Moment über den Fernzugriffs-Server, den wir als Mail-Relay benutzen. Kann unter Wallbox -> Ladetracker eingerichtet werden,