rtrbt
-
Benutzer seit
-
Letzter Besuch
Posts erstellt von rtrbt
-
-
On 7/28/2026 at 2:05 PM, msi said: Bei 63A fliegt die Hauptsicherung raus, dann nehme ich das mal.
...und es funktioniert, das Auto lädt. Problem scheint gelöst!
Möglicherweise hattest du dann einfach bisher immer PV-Überschuss, wenn du laden wolltest.
On 7/28/2026 at 2:05 PM, msi said: Kann man das der Warp3 irgendwie beibiegen, bei "Min+PV" zu bleiben?
Stell am besten den Standardlademodus auf "Unverändert", dann nimmt die Wallbox nach dem Neustart den Lademodus, den du davor auf der Statusseite ausgewählt hattest.
-
Ich vermute, dass du das Lastmanagement falsch konfiguriert hast:
Du hast das dynamische Lastmanagement aktiviert (d.h. die Wallbox überwacht die Phasenströme am Netzanschluss),
hast als maximalen Strom am Netzanschluss 16 A konfiguriert (das scheint mir sehr wenig zu sein)
und als Strombedarf des größten Einzelverbrauchers (damit ist nicht die Wallbox sondern der größte andere Verbraucher gemeint!) ebenfalls 16 A angegeben.
Damit erlaubst du der Wallbox nur dann zu laden, wenn am Netzanschluss maximal 0,4 Ampere Bezug gemessen werden (in der Berechnung gehen noch 40% erlaubte Überlast ein, die wir in 30 Sekunden wegregeln können, deshalb die krumme Zahl). Im Endeffekt also nur wenn gerade PV-Überschuss da ist, egal welchen Lademodus du wählst.
-
On 7/20/2026 at 11:57 AM, autolader said: Muss man an der Warp4 eine Taste drücken, damit der Ladevorgang startet oder reicht das Einstecken des Ladekabels und dann wird mit einem Standard-Ladeprogramm begonnen? Ich brauche keine Auto- oder Personenidentifizierung, ich bin der alleinige Nutzer der Wallbox, von Ausnahmen (Besuchern) die kostenlos laden dürfen mal abgesehen.
In der Werkseinstellung funktioniert das genau so. Auto anstecken und los gehts.
On 7/20/2026 at 11:57 AM, autolader said: Gibt es eine Empfehlung für die Position der Wallbox/Warp4 relativ zur Ladebuchse am Auto? Also in der Form: X Meter vor/hinter der Ladebuchse
Das ist an sich egal, wenn die Ladebuchse näher bei der Wallbox ist, musst du natürlich weniger Kabel abwickeln.
-
1
-
-
Wenn 50five OCPP 1.6J unterstützt (wovon ich ausgehe, das ist die häufigste Variante vom Protokoll), spricht technisch nichts dagegen. Ich finde ad-hoc aber keine Dokumentation von 50five bzgl. OCPP.
(Kurzer Rant) Erfahrungsgemäß sind OCPP-Backend-Betreiber etwas schwierig und erlauben oft nur Wallboxen, die auf einer "Kompatibilitätsliste" stehen, obwohl OCPP ein offenes Protokoll ist. Das ist ungefähr so, als ob eine Webseite nur bestimmte Handy-Hardware erlauben würde.
-
On 7/23/2026 at 8:01 PM, CptHildi said: Ich könnte mir vorstellen (noch nicht ausprobiert), daß der gleiche Fehler auch bei einer (via externer Steuerung über Modbus) erzwungenen Ladung der Batterie auftritt (ich weise via Modbus den WR an, den Akku mit X Watt zu laden, WB sieht die Ladeleistung und schlägt sie dem momentanen Wert zu - der WR kann aber ggf. nicht mehr abgeben, da nicht mehr PV zur Verfügung steht und es entsteht wieder ein Grid-Bezug in Höhe der Batterie-Ladeleistung...).
Ja, das würde dann vermutlich passieren.
On 7/23/2026 at 8:01 PM, CptHildi said: Ich kann nachvollziehen, daß Euer Algorithmus auf den Batteriebezug schaut, um den (vermeintlichen) Überschuß zu erkennen und der WB somit die entsprechende Leistung zuschlägt. Aber daß der Zähler am Grid gar nicht auf 0 geregelt wird, scheint dabei dann außen vor gelassen zu werden. Ohne Batterie-Steuerung funktioniert die Überschußsteuerung (nur über den Grid-Zähler) ja hervorragend. Vielleicht müßtet Ihr auch mit einer aktiven Batteriesteuerung den Grid-Zähler weiter berücksichtigen?
Tun wir, es wird immer genau ein Wert auf 0 geregelt:
Wenn die Batterie bevorzugt wird, dann ist das der Wert des Grid-Zählers. D.h. wir verbrauchen nur den PV-Überschuss, den die Batterie nicht nimmt.
Wenn die Batterie nicht bevorzugt wird, dann ist das Grid-Zähler - Batteriezähler. D.h. wir nehmen der Batterie den Strom weg, den wir als PV-Überschuss betrachten. Im Fall, dass der Batterieüberschuss sich dann nicht zum Grid verschiebt (weil der Wechselrichter am Limit ist), ist das kaputt.
Die gute Nachricht ist: Ich hatte beim Schreiben dieses Posts eine Idee, wie wir das eventuell einfach reparieren können und damit auch den Fall der erzwungenen Batterieladung. Ich bin aber nicht der lokale Regelungstechnikexperte, also will ich nicht zu viel versprechen :D
-
On 7/18/2026 at 4:15 AM, Markus S said: Meine Schwetster nutzt die Wallbox für ihren Firmenwagen und nutzte den E-Mail Versand des Ladetrackers, welcher auch nicht funktioniert, ich gehe davon aus, dass hier auch die Remoteverbindung genutzt wird.
Korrekt. Ist die Mail jetzt, da die Remoteverbindung wieder funktioniert, rausgegangen?
-
Da ist die Dokumentation leider schneller als die Firmware: Die MQTT-Discovery für den Energy Manager ist fast fertig™ und sollte es ins nächste oder spätestens übernächste Firmware-Release schaffen.
-
1
-
-
Der Text ist etwas knapp formuliert aber korrekt. Es geht konkret darum, dass die WARP3/WARP4 (nur Pro, weil wir dafür die Zählerwerte brauchen) automatisch auf einphasig umschaltet (also das L2/L3-Schütz abfallen lässt), wenn sie feststellt, dass das Auto nur einphasig lädt. Die Idee ist, dass das 1. bei unserem Lastmanagement hilft und 2. gerade im Sommer die Wärmeentwicklung in der Wallbox deutlich reduziert.
EVCC kommt mit dem Feature nicht klar, weil es davon ausgeht, dass eine (beliebige) Wallbox nicht von sich aus umschaltet. Deshalb war es eine ganze Zeit lang so, dass man, damit EVCC funktioniert im Wallbox-Webinterface unter Wallbox -> Einstellungen den "Automatischen Phasenwechsel" deaktivieren musste.
Im Zuge der Umstellung der EVCC-WARP-Anbindung von MQTT auf WebSockets (hier: https://github.com/evcc-io/evcc/pull/26970 ) wurde aber eingebaut, dass EVCC selbst diese Einstellung umschreibt, damit der Nutzer das nicht manuell machen muss.
-
On 7/22/2026 at 1:00 PM, CptHildi said: oder (wahrscheinlicher) aber dem Wert der Überschußleistung der PV gegenüber der Maximalleistung des WR (10 kW) entsprechen - ich habe Werte von knapp über 11 kW PV-Leistung in der SMA-App gesehen. Daher scheint der WR die überschüssige Leistung an den Haus-Akku abzuführen (was erstmal gut ist, somit geht er nicht in die Leistungsbegrenzung / De-Rating).
Das ist genau das Problem:
Dein Wechselrichter kann maximal 10 kW wechselrichten
Dein Batteriespeicher ist DC-seitig am Wechselrichter angeschlossen. D.h. wenn der Wechselrichter (wie bei dir ab 12:28:30) in sein 10 kW-Limit läuft, dann geht der restliche DC-Strom (1,3 kW) in den Batteriespeicher
Das PV-Überschussladen ist darauf konfiguriert, dass (wenn der Batterie-SoC > 50% ist) die Wallboxen zu bevorzugen sind, d.h. wir betrachten den Batteriebezug als Überschuss, den wir ins Auto bekommen wollen
Dem Auto werden also 1,3 kW mehr erlaubt, als notwendig wäre um den Netzzähler auf 0 zu bekommen
Der Wechselrichter kann diese 1,3 kW nicht liefern, weil er am Limit läuft
-> Es werden 1,3 kW aus dem Netz gezogen
Das ist also ein Modellierungsproblem bei uns: Damit das PV-Überschussladen mit dem Fall umgehen kann, müssten wir wissen, dass
Die Batterie DC-seitig am WR angeschlossen ist und
wenn das der Fall ist, dann müssen wir die Maximalleistung des Wechselrichters kennen
Ich finde leider den Thread nicht mehr, in dem @MatzeTF schonmal darüber gestolpert ist (und er ist im wohlverdienten Urlaub). Eventuell gibt es da einen Hack, der dir hilft.
-
2026-07-18 19:23:43,402 | ethernet | Disconnected 2026-07-18 19:23:43,404 | ethernet | Was connected for 1296 seconds. 2026-07-18 19:23:47,402 | ethernet | Connected: 100 Mbps, Full Duplex 2026-07-18 19:23:47,915 | ethernet | Got IP address: 192.168.178.106/24, GW 192.168.178.1 2026-07-18 19:27:49,403 | ethernet | Disconnected 2026-07-18 19:27:49,404 | ethernet | Was connected for 241 seconds. 2026-07-18 19:27:51,402 | ethernet | Connected: 100 Mbps, Full Duplex 2026-07-18 19:27:51,912 | ethernet | Got IP address: 192.168.178.106/24, GW 192.168.178.1 2026-07-18 19:34:17,403 | ethernet | Disconnected 2026-07-18 19:34:17,404 | ethernet | Was connected for 385 seconds. 2026-07-18 19:34:19,402 | ethernet | Connected: 100 Mbps, Full Duplex 2026-07-18 19:34:19,911 | ethernet | Got IP address: 192.168.178.106/24, GW 192.168.178.1 2026-07-18 19:45:49,403 | ethernet | Disconnected 2026-07-18 19:45:49,404 | ethernet | Was connected for 689 seconds. 2026-07-18 19:47:49,403 | ethernet | Lost IP address. 2026-07-18 19:49:49,404 | ethernet | Lost IP address. 2026-07-18 21:14:53,402 | ethernet | Connected: 100 Mbps, Full Duplex 2026-07-18 21:14:53,910 | ethernet | Got IP address: 192.168.178.106/24, GW 192.168.178.1Im Log sehe ich, dass die LAN-Verbindung sehr oft verloren geht und dann (außer beim letzten Mal) nach zwei Sekunden wiederkommt. Kann es sein, dass eins der Kabel zwischen Fritzbox und Wallbox schlecht sitzt oder einfach defekt ist? Möglicherweise auch ein Switch o.Ä.?
-
On 7/19/2026 at 10:00 AM, stefan12345352 said: Hallo, gab es für das Problem damals eine Lösung? Ich habe aktuell ein ähnliches Phänomen: Die Wallbox ist sporadisch nicht erreichbar. Meistens hilft es nur, die Box kurz stromlos zu machen, oder eine Zeit (ca. 1-24h) zu warten.
Wenn du die Wallbox gerade erreichen kannst, lade mal einen Debug-Report (unter System->Ereignis-Log) herunter und hänge ihn hier an.
-
Hier gibt es übrigens eine Anleitung zum Einrichten und Schreiben eines API-Zählers: https://docs.warp-charger.com/de/docs/interfaces/mqtt_http/examples#api-z%C3%A4hler-f%C3%BCr-pv-%C3%BCberschuss
-
1
-
-
Bist du dir 100%ig sicher, dass das Kabel nicht abgezogen wurde? Ich sehe im Log nicht welchen Tag du meinst, aber z.B. am 08.07. wurde das Auto relativ oft abgezogen:
2026-06-23 15:53:10,205 | users | Charger state changed from 2 to 0 2026-06-25 17:59:47,424 | users | Charger state changed from 0 to 2 2026-06-26 10:03:07,881 | users | Charger state changed from 2 to 0 2026-07-02 13:39:34,867 | users | Charger state changed from 0 to 2 2026-07-02 15:23:54,013 | users | Charger state changed from 3 to 0 2026-07-02 17:01:57,961 | users | Charger state changed from 0 to 2 2026-07-02 18:02:24,027 | users | Charger state changed from 3 to 0 2026-07-04 08:58:43,785 | users | Charger state changed from 0 to 2 2026-07-04 12:23:09,982 | users | Charger state changed from 2 to 0 2026-07-04 19:57:12,178 | users | Charger state changed from 0 to 2 2026-07-06 07:48:51,083 | users | Charger state changed from 1 to 0 2026-07-07 10:19:50,162 | users | Charger state changed from 0 to 2 2026-07-07 11:38:27,598 | users | Charger state changed from 3 to 0 ---(Ab hier der 08.07)--- 2026-07-08 15:16:52,567 | users | Charger state changed from 0 to 2 2026-07-08 18:43:07,784 | users | Charger state changed from 3 to 0 2026-07-08 18:43:48,882 | users | Charger state changed from 0 to 1 2026-07-08 18:44:08,018 | users | Charger state changed from 3 to 0 2026-07-08 18:44:25,124 | users | Charger state changed from 0 to 1 2026-07-08 20:24:35,299 | users | Charger state changed from 3 to 0 2026-07-08 20:27:53,471 | users | Charger state changed from 0 to 2 2026-07-08 23:51:28,793 | users | Charger state changed from 1 to 0 2026-07-08 23:51:48,907 | users | Charger state changed from 0 to 2 2026-07-08 23:57:49,254 | users | Charger state changed from 1 to 0 2026-07-08 23:57:52,371 | users | Charger state changed from 0 to 1 2026-07-09 00:05:36,724 | users | Charger state changed from 1 to 0Edit: Charger-State 0 ist "kein Auto angesteckt" D.h. in dem Log-Ausschnitt sind alle Absteck (... to 0) und Ansteck (from 0...)-Vorgänge zu sehen
-
Firmware: WARP1 2.12.1, WARP2 2.12.1, WARP3 2.12.1, WARP4 2.12.2, WARP Energy Manager 2.8.1, WARP Energy Manager 2.0 1.7.1
(Nur WARP4) ISO 15118-Kompatibilität mit Hyundai Inster verbessert
(Nur WARP4) Melden des iso_15118-Features für bessere Kompatibilität mit EVCC hinzugefügt
(Nur WARP4) Lesen/Schreiben des ISO 15118-PIBs robuster gemacht
(Nur WARP4) Behandlung der Übergänge zwischen ISO 15118 und IEC 61851 verbessert
Berechnung fehlender Zählerwerte auf ein- und zweiphasige Stromzähler erweitert
CPU-Idling hinzugefügt um Leistungsaufnahme um 3 bis 10% zu reduzieren
(Nur WARP2, WARP3, WARP4, WARP Energy Manager, WARP Energy Manager 2.0) Maximale Zertifikat(sketten)-größe auf 10179 Bytes erhöht
(Nur WARP1) Maximale Zertifikat(sketten)-größe auf 4352 Bytes erhöht
(Nur WARP2, WARP3, WARP4, WARP Energy Manager, WARP Energy Manager 2.0) "Zuletzt gesehen"-Wert von nicht-lokal gesehenen NFC-Tags repariert
(Nur WARP2, WARP3, WARP4, WARP Energy Manager, WARP Energy Manager 2.0) Sichergestellt, dass Löschen eines Benutzers auch dessen NFC-Tags löscht
Umbenennen des unbekannten Benutzers repariert
(Nur WARP2, WARP3, WARP4) Behoben, dass Trennen der OCPP-Verbindung manchmal für immer blockierte
(Nur WARP1, WARP2, WARP3, WARP4) Ladelog-Filter "kontrollierte Wallboxen" repariert
"Fernzugriff schließen" für kommende iOS-App 2.0.0 repariert
(Nur WARP4) Fahrzeugweckruf in Kombination mit ISO 15118 repariert (durch Update auf Ladecontroller-Firmware 2.2.24)
Download: WARP1 2.12.1 bzw. WARP2 2.12.1 bzw. WARP3 2.12.1 bzw. WARP4 2.12.2 bzw. WARP Energy Manager 2.8.1 bzw. WARP Energy Manager 2.0 1.7.1
-
On 7/7/2026 at 8:36 PM, Unknown said: Ich aktiviere nur das Skript mit den oben beschriebenen Parametern, weiter mache ich nichts. Habe in der Doku auch nichts dazu gefunden, dass ich die Funktionen extra aufrufen muss
Musst du auch nicht. Eigentlich solltest du auf weatherpi/callback/outdoor_weather_bricklet/SEM/station_data bzw. /sensor_data die Daten bekommen. Wenn ich mich richtig erinnere bekommst du aber nur ein Paket alle 45 Sekunden, öfter schicken die Sensoren/Stationen nicht.
Laut Log wurde um 13:55:40,153 einmal station_data ge-publisht, d.h. das funktioniert soweit.
On 7/7/2026 at 8:36 PM, Unknown said: Was müsste ich denn tun, um get_station_identifiers gezielt aufzurufen?
Du musst dich erst auf weatherpi/response/outdoor_weather_bricklet/SEM/get_station_identifiers subscriben, damit du die Antwort nicht verpasst und dann auf weatherpi/request/outdoor_weather_bricklet/SEM/get_station_identifiers eine leere Nachricht publishen. Im Endeffekt das gleiche Vorgehen wie in folgendem Beispiel get_color:
https://www.tinkerforge.com/de/doc/Software/API_Bindings_MQTT.html#requests-und-responses
-
Firmware: ESP32 Brick 2.2.0, ESP32 Ethernet Brick 2.2.0
Unterstützung von TLS 1.3 hinzugefügt
Hinzugefügt, dass die meisten Konfigurationen ohne Neustart geändert werden können
Statusinformationen zu vielen Unterseiten hinzugefügt
Status-Widget hinzugefügt
Dark Mode zum Webinterface hinzugefügt
Logo auf kleinen Bildschirmen zentriert
Gerätesuche-Dialoge vereinheitlicht
Sichergestellt, dass bei Neustart über die System-Unterseite auch alle Bricklets neugestartet werden
Hinzugefügt, dass Teile einer API mit einem URL-Suffix gelesen und geschrieben werden können
WLAN-Verbindungsaufbau beschleunigt
WLAN-Netzwerksuche beschleunigt
(Nur ESP32 Brick) Anzeige der MAC-Addresse und BSSIDs zu den WLAN-Unterseiten hinzugefügt
(Nur ESP32 Ethernet Brick) Anzeige der MAC-Addresse und BSSIDs zu den Ethernet- und WLAN-Unterseiten hinzugefügt
Behoben, dass automatische Kanalwahl des WLAN-Access Points den ersten WLAN-Verbindungsversuch gestört hat
Hostnamen- und IP-Adress-Validierung verbessert
Erkennung von Netzwerkadress-Fehlkonfigurationen erweitert
Sichergestellt, dass Netzwerkschnittstellen nicht aus Versehen deaktiviert werden können
Robustheit von WireGuard verbessert
Sichergestellt, dass Debug-Report niemals WireGuard-Keys enthält
Schlüsselgenerierung zur WireGuard-Unterseite hinzugefügt
WireGuard-MTU konfigurierbar gemacht
Crashes, die durch (neu-)verbinden von WireGuard verursacht wurden, behoben
Robustheit von Webserver und Web Sockets gegen Verbindungsabbrüche verbessert
Crash repariert, der auftrat, wenn während eines Neustarts ein weiterer HTTP-Request empfangen wurde
Login-Dialog für Firefox und Chrome auf iOS repariert
Fortschrittsanzeige des Firmware-Updates verbessert
Sichergestellt, dass ein nicht funktionaler Web Server zu einem Rollback auf die letzte Firmware führt
Bei unerwarteten Neustarts wird eine Warnung angezeigt
Warnung hinzugefügt, falls sich Webinterface- und Browser-Sprache unterscheiden
Absturz in der allgemeinen Konfigurationsbehandlung behoben
mDNS-Spam behoben
(Nur ESP32 Ethernet Brick) Ethernet-Initialisierung beschleunigt
(Nur ESP32 Ethernet Brick) Sichergestellt, dass LAN-Verbindung immer vor WLAN-Verbindung bevorzugt wird
(Nur ESP32 Ethernet Brick) Priorisierung der Netzwerk-Interfaces repariert
Übersetzungen verbessert
Zeitzonen-Datenbank aktualisiert
Download: ESP32 Brick bzw. ESP32 Ethernet Brick
-
-
Firmware: WARP1 2.12.0, WARP2 2.12.0, WARP3 2.12.0, WARP4 2.12.0, WARP Energy Manager 2.8.0, WARP Energy Manager 2.0 1.7.0
(Nur WARP2, WARP3, WARP Energy Manager, WARP Energy Manager 2.0) Hinzugefügt, dass die Benutzer- und NFC-Tag-Konfiguration ohne Neustart geändert werden kann
(Nur WARP1) Hinzugefügt, dass die Benutzer-Konfiguration ohne Neustart geändert werden kann
Ladezustand zu den auch im eingeklappten Zustand angezeigten Stromzählerwerten hinzugefügt
(Nur WARP2, WARP3, WARP Energy Manager, WARP Energy Manager 2.0) Fehlende Behandung des effektiven Lademodus bei Batteriesteuerung mit benutzerdefinierten Modbus-TCP-Tabellen hinzugefügt
(Nur WARP Energy Manager, WARP Energy Manager 2.0) Behoben, dass Wallboxen nicht in der Energiebilanz angezeigt wurden
(Nur WARP Energy Manager) Migration des Zugangsdaten-Moduls zur Benutzerverwaltung repariert
(Nur WARP2, WARP3, WARP Energy Manager, WARP Energy Manager 2.0) Crash bei einem sich nicht wiederholenden Batteriemodus behoben
Behandlung des Lastmanagements von Fahrzeugen, die durch einen Phasenwechsel aufwachen, verbressert
Robustheit von Modbus/TCP gegen nicht wohlgeformte Pakete verbessert
(Nur WARP2, WARP3, WARP Energy Manager, WARP Energy Manager 2.0) Anzeigename des SunSpec-Modells 160 verbessert
Fehlermeldung, wenn Firmware-Aktualisierung beschädigt ist, verbessert
(Nur WARP2, WARP3, WARP Energy Manager, WARP Energy Manager 2.0) Robustheit von EEBus verbessert
(Nur WARP4) Initiales Release
Download: WARP1 2.12.0 bzw. WARP2 2.12.0 bzw. WARP3 2.12.0 bzw. WARP4 2.12.0 bzw. WARP Energy Manager 2.8.0 bzw. WARP Energy Manager 2.0 1.7.0
-
Das ist alles Spekulation, aber ich würde ja hoffen, dass das Gateway EEBus sprechen kann.
-
On 6/18/2026 at 1:14 PM, prtgadmin said: Wir würden gerne einen Automatismus am Manager einstellen, wenn NFC-Tag XX an einer der Säulen erkannt wird, der Lademodus für diese Wallbox auf Schnell umstellt wird. Dies würden wir gerne an Manager verwalten, nicht an den Ladesäulen.
Das funktioniert im Moment leider nicht. Das Problem ist nicht, dass die Tags nicht an den Lastmanager übertragen werden, du kannst aber keine Automatisierungsregeln anlegen, die sich auf die gemanageten Wallboxen beziehen.
Eventuell legen wir das irgendwann nach, das kann ich aber nicht versprechen.
Bis dahin kannst du die Regeln nur auf den einzelnen Wallboxen anlegen.
-
Das hätte eigentlich funktionieren sollen. Hattest du davor die Beta installiert? Zieh mal einen Debug-Report, dann sehen wir, was los ist.
-
FYI: Das oben ist die Pro, die Smart hat deutlich mehr Platz links:
(Finde gerade ad-hoc kein höher aufgelöstes Bild)
-
Ganz so einfach ist es leider nicht, Wallbox und Energy Manager sind keine Linux-PCs sondern Mikrocontroller. Der Scan wird aber irgendwann kommen.
-
1
-
-
WARP3 - Verbindung mit Auto funktioniert nicht. Ladevorgang bleibt bei "Warten auf Freigabe" stecken
in WARP Charger / Energy Manager
Geschrieben
Hm, das kann ich hier nachstellen. Fixen wir mir der nächsten Firmware, sorry.