rtrbt

Noch etwas einfacher: Du kannst dir im Webinterface eine Automatisierungsregel anlegen, die bei Drücken des Fronttasters eine MQTT-Nachricht schickt. Dann muss das Script nur noch auf das entsprechende MQTT-Topic subscriben und wenn eine Nachricht ankommt einen Befehl auf die Tesla-API rausschicken.

Firmware: WARP (1,2,3) Fernzugriffs-Alpha Details hier:

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.

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.

You've placed the package in a directory that apt can't read as the user _apt (apt usually downloads as a separate user for security purposes) See for example here: https://askubuntu.com/a/908825 Since this does not work as _apt, apt retries "downloading" the package as root.

EBUSY could mean that the HAT Bricks device tree overlay did not load correctly (We use the overlay to be able to use gpiochip4 7) Please run gpioinfo and post the output here.

Die zweite CP-Trennung wenn das Auto nicht reagiert ist in WARP2 2.3.0 enthalten. Fehlte aber in den Changelogs, habe ich gerade hinzugefügt. Die Logs sehen wirklich seltsam aus. Der 3 -> 2 Wechsel muss von deinem Auto verursacht werden (wenn die Wallbox, der Energy Manager oder EVCC blockieren würden, dann wäre es ein 3 -> 1 Übergang), es sei denn durch die Test/Beta-Firmwares stehen sich Energy Manager und Wallbox gegenseitig im Weg. Aktualisiere sicherheitshalber mal Wallbox und Energy Manager auf 2.4.0 bzw. 2.1.0. Weißt du noch, ob das Auto nach dem 2->3 Übergang um 10:42:48,215 weitergeladen hat? (Kannst du eventuell noch im Ladetracker sehen) Bzw. als Gegentest: Wenn du das Auto das nächste Mal voll geladen hast (sodass die Wallbox im "Ladebereit"-Zustand, also 2 ist), zieh es mal ab, warte ein paar Sekunden, stecke es wieder an und achte darauf, ob das Schütz nochmal kurz schaltet und dann wieder abschaltet.

Firmware: WARP Energy Manager 2.1.0 SMA Speedwire als Stromzähler-Datenquelle hinzugefügt Modbus TCP als Stromzähler-Datenquelle hinzugefügt Liste unterstützter Stromzähler Unterstützung von MQTTS und MQTT über WS(S) hinzugefügt HTTP-Automatisierungsbedingung hinzugefügt Weitere Zoomstufen für den Plot des Ladeverlaufs hinzugefügt Buttons für Phasenumschaltung zur Statusseite hinzugefügt, wenn externe Steuerung aktiviert ist Modal für WLAN-Scan-Ergebnisse hinzugefügt SunSpec: Unterstützung mehrerer Geräte im selben Registersatz hinzugefügt SunSpec: Unterstützung mehrerer Instanzen des selben Models in einem Gerät hinzugefügt SunSpec: Boot-Scan-Robustheit verbessert SunSpec: Skalierung des Leistungsfaktors repariert SunSpec: Unterstützung für DER-Modelle 701, 713 und 714 hinzugefügt SunSpec: Kompatibilität mit SolarEdge- und Sungrow-Wechselrichtern verbessert SunSpec: Robustheit der Gerätesuche verbessert WiFi Enterprise: EAP-TLS-Verbindungen mit Client-Key repariert DSZ15DZMOD-Unterstützung der veralteten Stromzähler-API repariert Automatische Kanalauswahl des WLAN-Access Points repariert Anzeige aktiver Phasen bei negativem Phasenstrom repariert Min+PV-Lademodus mit umkonfiguriertem Minimalstrom repariert Automatische Skalierung nicht gestapelter Graphen repariert Behoben, dass PV-Lademodus nach einem drei- zu einphasig Wechsel den Ladevorgang gestoppt hat Lastmanagement: Spielraum des Phasenstroms verdoppelt wenn exakt eine Wallbox lädt Modulname zu Ereignislog-Nachrichten hinzugefügt Menüstruktur des Webinterfaces überarbeitet Label/Inhaltsteilung auf Status- und Unterseiten vereinheitlicht Platzhalter eingefügt, wenn Zeit der Echtzeituhr nicht gestellt ist Anzeige deaktivierter Automatisierungsbedingungen und -aktionen hinzugefügt Sichtbarkeit eines leeren Leistungsgraphen repariert Sichergestellt, dass Energiebilanz-Graphfarben bei Neuladen des Webinterfaces gleich bleiben Möglichkeit zum Reaktivieren des 802.11b-Modus für besseren WLAN-Empfang hinzugefügt NTP-Serverkonfiguration über DHCP repariert Behoben, dass auf der Statusseite 0 W als Leistungsaufnahme angezeigt wurde, wenn keine Daten verfügbar sind Behoben, dass MQTT als deaktiviert angezeigt wurde, wenn noch kein Verbindungsversuch erfolgt war Behoben, dass WLAN-Scan nicht als fertig angezeigt wurde, wenn kein WLAN gefunden wurde Automatisches Neuladen des Web Interfaces bei Firmware-Versionsänderung behoben Voreingestellte NTP-Server aktualisiert NTP-Synchronisierungsgeschwindigkeit erhöht Sichergestellt, dass gerade bezogene NTP-Zeit nicht mit möglicherweise schlechterer RTC-Zeit überschrieben wird Robustheit des Web-Servers verbessert Übersetzungen verbessert Unterstützte Länge von HTTP-Request-Headern auf 2 Kilobyte erhöht Download: WARP Energy Manager 2.1.0

Firmware: ESP32 Ethernet Brick 2.0.3 Hier klicken für das (sehr lange) Changelog Download: ESP32 Ethernet Brick

Firmware: ESP32 Brick 2.0.3 Hier klicken für das (sehr lange) Changelog Download: ESP32 Brick

Firmware: ESP32 Ethernet Brick 2.0.3 Click here for the (very long) changelog Download: ESP32 Ethernet Brick

Firmware: ESP32 Brick 2.0.3 Click here for the (very long) changelog Download: ESP32 Brick

Firmware: WARP 2.4.0, WARP2 2.4.0 und WARP3 2.4.0 (nur WARP1) PV-Überschussladen hinzugefügt SMA Speedwire als Stromzähler-Datenquelle hinzugefügt Modbus TCP als Stromzähler-Datenquelle hinzugefügt Liste unterstützter Stromzähler (nur WARP2/WARP3) Maximale Anzahl konfigurierter Stromzähler auf 5 erhöht Weitere Zoomstufen für den Plot des Ladeverlaufs hinzugefügt SunSpec: Unterstützung für DER-Modelle 701, 713 und 714 hinzugefügt SunSpec: Kompatibilität mit SolarEdge- und Sungrow-Wechselrichtern verbessert SunSpec: Robustheit der Gerätesuche verbessert Möglichkeit zum Reaktivieren des 802.11b-Modus für besseren WLAN-Empfang hinzugefügt NTP-Serverkonfiguration über DHCP repariert Behoben, dass auf der Statusseite 0 W als Leistungsaufnahme angezeigt wurde, wenn keine Daten verfügbar sind Unnötige Wartezeit bei Doppelklick zum Wechsel des Lademodus behoben EVSE-LED-API und Automatisierungs-Aktion repariert, (nur WARP3) Farbauswahl hinzugefügt Behoben, dass MQTT als deaktiviert angezeigt wurde, wenn noch kein Verbindungsversuch erfolgt war Fehlenden Modbus-TCP Discrete Input für (noch nicht implementierte!) CP-Trennung hinzugefügt Behoben, dass WLAN-Scan nicht als fertig angezeigt wurde, wenn kein WLAN gefunden wurde (nur WARP3) Gemeldete Schützzustand-Fehlercodes repariert (Durch Update auf Ladecontroller-Firmware 2.2.4) (nur WARP2/WARP3) Sichergestellt, dass Stop über Front-Taster das Laden blockiert, wenn Wallbox im Zustand “Ladebereit” ist (Durch Update auf Ladecontroller-Firmware 2.2.4) (nur WARP3) Sichergestellt, dass PV-Überschussladen nicht sofort auf dreiphasig wechselt, wenn der Ladecontroller gerade auf einphasig gewechselt ist, weil das Fahrzeug nur einphasig lädt (Durch Update auf Ladecontroller-Firmware 2.2.4) (nur WARP2/WARP3) OCPP: Zeitstempel von MeterValues-Nachrichten vereinheitlicht Automatisches Neuladen des Web Interfaces bei Firmware-Versionsänderung behoben Voreingestellte NTP-Server aktualisiert NTP-Synchronisierungsgeschwindigkeit erhöht Sichergestellt, dass gerade bezogene NTP-Zeit nicht mit möglicherweise schlechterer RTC-Zeit überschrieben wird Robustheit des Web-Servers verbessert Übersetzungen verbessert Modbus-TCP-Dokumentation verbessert (nur WARP2/WARP3) Unterstützte Länge von HTTP-Request-Headern auf 2 Kilobyte erhöht Download: WARP 2.4.0 bzw. WARP2 2.4.0 bzw. WARP3 2.4.0

Über das Smart Charging Profile läuft die Steuerung im Sinne von der Netzbetreiber kann damit den Ladestrom einstellen. Trotzdem funktioniert OCPP so, dass ein Ladevorgang zwingend mit einem NFC-Tag freigegeben werden muss. Ob ein Tag berechtigt ist entscheidet der OCPP-Server (lies: dein Netzbetreiber). Ich spekuliere jetzt mal, dass das den typischen Stadtwerken egal ist, wer an einer privaten Wallbox lädt und sie deshalb einfach bei jedem Tag den Ladevorgang freigeben. Da wir die OCPP-Implementierung kontrollieren, könnten wir natürlich einen Modus einbauen, der die ganze NFC-Freigabe überspringt und ggfalls ankommende RemoteStopTransaction-Anfragen des Servers ignoriert. Damit könnten die Stadtwerke nur noch den Ladestrom kontrollieren, aber nicht mehr einen Ladevorgang komplett stoppen. Das wäre aber nicht nach OCPP-Spezifikation (und man müsste es erst implementieren). Laut der PDF (Seite 10/11) geht das nicht: "Voraussetzung für die Anbindung von kommunikationsfähigen Ladestationen an das zentrale Verwaltungssystem ist die Anbindung der Ladesteuerung an das Mobilfunknetz [...] ergeben sich folgende Möglichkeiten: (1) Verfügt die Ladeeinrichtungen über einen SIM-Karten Slot, kann die Stromnetz Hamburg GmbH bzw. der entsprechende CPO eine SIM-Karte in die Ladestation einlegen und die notwendige Konfiguration der Datenverbindung vornehmen (2) Verfügt die Ladeeinrichtung über keinen SIM-Karten-Slot, kann ersatzweise ein UMTS Router nahe der Ladestation (am Zählerplatz im Haus) errichtet werden und in diesen die SIM-Karte einlegt werden. Der Router dient dabei als Gateway für den Verbindungsaufbau" Ob die das wirklich so strikt auslegen, wie es da steht ist natürlich unklar.

Das ist korrekt. Der Zähler misst nur eine Teilmenge der Werte, die wir über Modbus melden können. Das ist 1:1 die "veraltete" Stromzähler-API, deren all_values-Liste die Werte eines SDM630 sind. Werte, die der DSZ15DZMOD nicht lesen kann bekommst du als NaN zurückgegeben. Edit: Das siehst du auch in der all_values-Dokumentation: Das Beispiel ist von einem SDM72V2, der auch nicht alle Werte eines SDM630 ausgibt. Deshalb sind im Beispiel hier: https://docs.warp-charger.com/docs/mqtt_http/api_reference/meter/#meter_all_values_warp1 manche Werte null. (in JSON werden NaN als null ausgegeben)

Benutze dann am besten einen anderen MQTT-Broker, als den, den es für ioBroker gibt. Der von ioBroker macht nur Probleme, siehe z.B. oder https://github.com/evcc-io/evcc/issues/13590

Genau. Die Idee ist, dass wenn du zwei Wallboxen hast und an einer lädt ein Auto langsam, weil z.B. der Akku voll wird, dass der überschüssige Strom zur anderen Wallbox verteilt werden kann. Deshalb geben wir (natürlich nur wenn die entsprechende Box einen Zähler hat) einem Auto nur dessen Strombezug + 3 Ampere, damit es mehr Strom anfordern kann.

Hast du die Wallbox in EVCC als WARP oder WARP3 konfiguriert? (https://docs.evcc.io/docs/devices/chargers#warp-charger-pro bzw.https://docs.evcc.io/docs/devices/chargers#warp3-charger-pro ) Wenn du noch die alte Variante (also als WARP) hast, kannst du entweder auf WARP3 umstellen, oder du trägst von Hand den Wert von "topic" nochmal bei "energymanager" ein. Mehr macht das WARP3-Template auch nicht und die Phasenumschaltungs-API ist absichtlich die selbe zwischen WARP2 + WARP Energy Manager und WARP3.

Laut Log hat der ID.4 das Problem jetzt nicht mehr. Der gemessene CP-Widerstand steigt zwar etwas, das ist aber noch okay. (Der Schwellwert zwischen C und B liegt bei 1790). Den erlaubten Ladestrom habe ich durch 10 geteilt, damit man im Diagramm was sieht. Hast du das schnelle Schützschalten nur wenn du <= 7 A erlaubst und dann den ID.4 ansteckst? Dann könnte es sein, dass der ID.3-Modus nicht mehr richtig funktioniert. Hast du mit deinem Boost ungefähr hier etwas geändert: https://github.com/Tinkerforge/evse-bricklet/blob/1892e31a648db0700fc45a944992ddc9f9077730/software/src/iec61851.c#L202 bzw. https://github.com/Tinkerforge/evse-bricklet/blob/1892e31a648db0700fc45a944992ddc9f9077730/software/src/ads1118.c#L230 ? Zieh am besten noch ein Ladeprotokoll von der Situation mit dem Schütz-Tick-Tock. Vielleicht sehen wir da mehr.

Eventuell benutzt EVCC den korrekten Energiewert, aber auf dem WARP Charger siehst du noch den Import+Export-Wert. Wir hatten das kürzlich geändert, weil sich herausstellte, dass man je nach Situation (z.B. 1- vs 3-phasiges Laden) einen minimalen Export (~0,1%) misst. Details stehen in diesem Blogpost ganz unten:https://www.tinkerforge.com/de/blog/new-features-in-warp2-221-and-wem-202/

Das Problem ist, dass die LAN-Verbindung abggerissen ist. Danach versucht die Wallbox weiterhin Lastmanagement-Pakete zu verschicken, da die aber nicht übertragen werden können, stauen sie sich auf der Wallbox auf. Irgendwann ist der Sendebuffer voll und dann entstehen die "Failed to send state: Not enough space (12)"-Meldungen. Das ist nicht kritisch, aber etwas unschön, dass das Ereignis-Log damit zugemüllt wird. Eventuell können wir das etwas sauberer behandeln. Der Ladevorgang wurde nach 30 Sekunden unterbrochen, da die Wallbox den Lastmanager nicht mehr erreichen konnte. Damit in dieser Situation keine Überlast erzeugt wird, versucht ein Lastmanager alle Wallboxen zu stoppen, wenn die Verbindung zu mindestens einer unterbrochen ist _und_ alle Wallboxen stoppen den Ladevorgang von sich aus, wenn 30 Sekunden lang keine Daten vom Lastmanager empfangen wurden.

Für die Nachwelt: Hat sich geklärt: https://github.com/evcc-io/evcc/issues/13590 war das Problem.

Das ist gut möglich. Starte mal ein Ladeprotokoll und gehe dann von 16A bis 6A alle 10-15 Sekunden ein Ampere runter. (Am besten ohne deinen dynamischen Boost-Modus ;) ) Ich würde erwarten, dass du dann im Protokoll beim gemessenen CP-Widerstand siehst, dass er nach steigt, wenn der erlaubte Strom sinkt. Wenn du das für ID.4 und Zoe machst, können wir nochmal nachkalibrieren.

Das muss ich mir nochmal in Ruhe ansehen, komme aber gerade nicht dazu. Ich melde mich nächste Woche nochmal.

Noch eine Ergänzung dazu: Wenn die Wallbox das erste Mal einen Zähler sieht, aktiviert sie die Zählerüberwachung. Danach sind Ladevorgänge nur noch möglich, wenn der Zähler ausgelesen werden kann. D.h. wenn jemand den Zähler ausbaut ö.Ä. blockiert die Wallbox das Laden. Die Zählerüberwachung kannst du im Webinterface deaktivieren, falls du deine WARP3 Pro auf eine Smart downgraden willst, oder der Zähler wirklich kaputt ist.