rtrbt

Der Charge Tracker benutzt die nicht zurücksetzbaren Werte. D.h. du brauchst die 209 wenn du seit Firmware 2.2.0 mindestens einmal die aufgezeichneten Ladevorgänge gelöscht hast. Falls du noch ältere Ladevorgänge hast, benutzt der Charge Tracker den Wert 213 Energy Active LSum ImExSum statt ... Import, also die Summe aus Import und Export. Das hatten wir in 2.2.0 geändert, aber damit in den Ladelogdateien kein Sprung entsteht, passiert der Wechsel erst wenn die Ladevorgänge einmal geleert werden. Siehe hier: https://www.tinkerforge.com/de/blog/new-features-in-warp2-221-and-wem-202/ (ganz unten) Wichtig, weil du das so geschrieben hast: 209 usw. sind nicht direkt Indices in meters/0/values, sondern am Index an dem in meters/0/value_ids die 209 steht, steht in /values der entsprechende Wert.

Direkt geht das nicht. Du kannst aber über MQTT ein NFC-Tag vortäuschen: https://www.warp-charger.com/api.html#nfc_inject_tag Wenn OCPP dieses Tag kennt, sollte dann ein Ladevorgang beginnen.

Im Moment geht das nicht so einfach. Wir haben aber vor zukünftig das Format der aufgezeichneten Ladevorgänge nochmal zu ändern. Dabei würde ich pro Ladevorgang ein Flag vorsehen, dass angibt, dass er gelöscht ist. Siehe hier: https://github.com/Tinkerforge/esp32-firmware/issues/329

Immer gerne. Ich bin gespannt ob's hilft.

Teste mal diese WARP2-Firmware: Wenn das Auto nach der 4-Sekunden-Trennung nicht aufwacht, trennen wir jetzt nochmal für 30 Sekunden. Damit sollte es nicht mehr notwendig sein, dass du die Trennung des WEMs verlängerst. Hier hat jemand ein ähnliches Problem:https://github.com/evcc-io/evcc/issues/12480 warp2_firmware-NIGHTLY_2_2_1_65dca55f_2aa5b51ad4b2067_merged.bin

Das ist sehr seltsam. Kannst du das nochmal machen und dabei ein Ladeprotokoll ziehen? (Also Auto normal laden lassen, dann Protokoll starten, dann Auto abziehen und warten, dass auf 2, aber nicht auf 0 gewechselt wird)

Gefixt, danke für den Hinweis!

This won't work. Android smartphones periodically change the NFC tag ID. The only way to change this (as far as I know) is to use some kind of NFC card emulation app that (depending on your smartphone) will only work if you root your phone. See for example here: https://stackoverflow.com/questions/19764476/host-based-card-emulation-with-fixed-card-id We've thought about not using a tag's ID but instead the first payload page (see here: https://github.com/Tinkerforge/esp32-firmware/issues/90) but nobody had the time to implement this yet.

Sorry, ich hatte überlesen, dass du ein selbst-signiertes Zertifikat hast. Wenn du die Firmware mit dem Certs Back- und Frontend-Modul kompilierst, dann kannst du auf dem Webinterface das selbst-signierte Zertifikat hochladen und für die MQTT-Verbindung auswählen. Ohne das Certs-Modul wird nur das eingebettete Zertifikatsbundle verwendet. Das ist eine Sammlung von Root-Zertifikaten, mit denen der ESP Verbindungen zu Servern mit "echten" (also nicht selbst-signierten) Zertifikaten aufbauen kann: https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-reference/protocols/esp_crt_bundle.html

@Makee Da du ja eine eigene Firmware baust: Ich habe den MQTTS-Support gerade gepusht. Sollte jetzt einfach funktionieren.

Du hast zwei Möglichkeiten: 1. Kannst du die ganze Standardfirmware ignorieren und dir einen "normalen" Arduino-Sketch schreiben. Dokumentation dafür findest du hier: https://www.tinkerforge.com/de/doc/Software/API_Bindings_uC_HAL_Arduino_ESP32_Brick.html bzw. für den ESP32 Ethernet Brick hier:https://www.tinkerforge.com/de/doc/Software/API_Bindings_uC_HAL_Arduino_ESP32_Ethernet_Brick.html Das ist für den Anfang einfacher, du musst aber die Netzwerk- und MQTT-verbindungen von Hand aufbauen oder dir eine MQTT-Bibliothek suchen. 2. Kannst du dir die ESP-Firmware erweitern, dafür haben wir hier: https://www.tinkerforge.com/de/doc/Tutorials/Tutorial_ESP32_Firmware/Tutorial.html#tutorial-esp32-firmware ein Tutorial. Du müsstest im Endeffekt das Mqtt-Modul reinkompilieren (bei den custom_backend_modules und custom_frontend_modules jeweils zu der Liste hinzufügen) und dir ein eigenes Modul schreiben, dass die Sensoren ausliest und die Daten in eine API schreibt. Das ist im Tutorial Phase 2. APIs werden sowohl für die Kommunikation mit dem Webinterface über HTTP, als auch für MQTT verwendet. Das sollte also automatisch funktionieren. Der restliche Teil der Implementierung ist dann relativ ähnlich zu dem Arduino-Sketch den du dir in Variante 1 geschrieben hättest. In beiden Fällen benutzt du die C/C++-Bindings für Mikrocontroller für die Kommunikation mit den Bricklets (wir haben für jedes Bricklet Beispiele!), der Teil sollte also mehr oder weniger identisch aussehen.

Das geht prinzipiell, indem du dir mehrere Regeln mit der selben Bedingung erstellst. Ist nicht super-hübsch, funktioniert aber. Das wiederum geht mit der aktuellen Implementierung nicht. Wir haben das erstmal einfach gehalten, für Use-Cases wie eine Zeitschaltung o.Ä. Prinzipiell immer, ich kann aber nicht versprechen, dass wir die dann auch umsetzen ;)

Firmwares: WARP 2.2.1, WARP2 2.2.1 und WARP Energy Manager 2.0.2 HTTP-API-Fehler bei schlechter Verbindungsqualität behoben Zeitzonen-Datenbank aktualisiert (nur WARP2) Repariert, dass DC-Fehler sporadisch auslöste (durch Update auf Ladecontroller-Firmware 2.2.2) SunSpec: Herstellerspezifische Modelle werden nicht mehr als unbekannt angezeigt SunSpec: Hängenden Scan unter spezifischen Fehlerbedingungen behoben SunSpec: Hinzugefügt, dass Scan abgebrochen wird, wenn Browser-Tab geschlossen wird (nur WARP Energy Manager) Hinzugefügt, dass externe Phasensteuerungsanforderungen über Neustarts hinweg erhalten bleiben (nur WARP2) OCPP: LED-Steuerung hinzugefügt (nur WARP2) OCPP: Antworten auf Server-Anfragen repariert (nur WARP2) OCPP: Anzeige abgelehnter NFC-Tags zum Status hinzugefügt (nur WARP2) OCPP: Wiederherstellung von Transaktionsnachrichten über Neustarts hinweg repariert (nur WARP2) OCPP: Meldung falscher Zählerstände bei Transaktionsende über Neustarts hinweg repariert Download: WARP 2.2.1 bzw. WARP2 2.2.1 bzw. WARP Energy Manager 2.0.2

Nur um das auszuschließen: Hast du Sonderzeichen im Kennwort, die in der Shell escapt werden müssen? Du kannst es testweise mal auf "password" o.Ä. ändern.

Kurzes Update dazu: Das Problem scheint ja zu sein, dass der Energy Manager nach einem Neustart blockiert, bis EVCC einmal einen Phasenwechsel anfordert. Das haben wir auf unserer Seite behoben, nach einem Neustart des WEM bleibt die letzte Phaseneinstellung erhalten. Kommt mit Firmware 2.0.2.

Machen wir alles schon: https://github.com/Tinkerforge/evse-bricklet/blob/1892e31a648db0700fc45a944992ddc9f9077730/software/src/ads1118.c#L194

Wir arbeiten dran :D Das ist okay. Wie viel das Auto tatsächlich zieht, beeinflusst die Messung nicht. Relevant ist nur, dass das Auto prinzipiell lädt bzw. für die anderen beiden Debug-Protokolle, dass es voll ist und nicht laden möchte.

An den Energy Manager direkt kannst du von Eastron den SDM630, SDM630-MCT-V2, SDM72-V2, von Eltako den DSZ15DZMOD und von YTL den DEM4A anschließen. Außerdem kannst du alle SunSpec-kompatiblen Zähler über eine Netzwerkverbindung auslesen.

Dann war die Kalibrierung für den e-up vermutlich zu stark. Damit wir dir eine bessere Kalibrierung erstellen können, müsstest du einmal alle relevanten Fälle wie folgt protokollieren: 16 A Ladestrom einstellen Ladeprotokoll starten Auto anschließen Warten bis es lädt in 1-Ampere-Schritten bis auf 6 A runtergehen, dazwischen immer ~ 20 bis 30 Sekunden warten. Wenn du dich den 6 A näherst, kann es sein, dass du dann das Schütz-Ping-Pong triffst. Das ganze machst du mit dem e-up wenn er laden möchte, dann nochmal mit dem e-up wenn er voll ist und beides auch mit dem Hyundai. Das sollten also vier Protokolle werden, mit denen wir dir dann (hoffentlich! hat aber bisher immer geklappt) eine Kalibrierung erstellen können, bei der alles funktioniert.

Kein Problem. energy_manager_firmware_2_0_1_65b77317_7046d2627114a44_merged.bin

Firmware: WARP Energy Manager 2.0.1 Alte Stromzähler-API repariert Download: WARP Energy Manager 2.0.1

Die Änderungen der Beta sind in der Energy Manager Firmware 2.0.0 btw. der Wallbox Firmware 2.2.0 enthalten. Achtung: Beim Update von der Beta-Firmware auf WEM 2.0.0 muss eventuell die Schützkontrolle neu auf externe Steuerung (EVCC) konfiguriert werden! Beim Update von 1.0.8 auf 2.0.0 passiert das automatisch.

Ich hatte gestern nicht mehr daran gedacht, im Beta-Thread noch einen Hinweis darauf zu posten, sorry. Benutzt du EVCC mit dem Energy Manager? Dann musst du ggfalls ein paar Tage warten, wir mussten Teile der API ändern, die von EVCC verwendet werden. Habe die Entwickler schon informiert. Falls du irgendetwas eigenes mit der externen Steuerung machst: wem/xyz/energy_manager/external_control_update heißt jetzt wem/xyz/power_manager/external_control_update weil wir das Modul aufgeteilt haben. Steht auf der Liste: https://github.com/Tinkerforge/esp32-firmware/issues/218

Sorry für die späte Antwort, musste erst das Firmware-Release fertig bekommen. Ziemlich genau die Version habe ich auch getestet und hier funktionierts. Wir haben aber von einem anderen Kunden ähnliche Probleme gemeldet bekommen mit anderen Browsern und Betriebssystemen. Da muss irgendetwas auf Wallboxseite kaputt sein. Kurz zur Erklärung, was überhaupt bei dem Ping-Pong passiert: Die Wallbox misst einen Widerstand (CP/PE), der vom Auto angelegt wird. Wenn kein Auto angeschlossen ist, ist das "unendlich", wenn ein Auto angeschlossen ist, aber (noch) keinen Strom anfordert sinds 2700 Ω, wenn das Auto Strom anfordert 880 Ω. Details hier: https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Signalisierung Aufgrund dessen, wie die Signalisierung funktioniert, wird der Widerstand immer nur in einem kurzen Zeitfenster gemessen, die Länge davon hängt vom erlaubten Ladestrom ab. Bei 6 A ist die Messung deshalb maximal schlecht: Vor der Kalibrierung hat deine Box immer irgendwas zwischen 1700 und 1800 Ω gemessen, da liegt aber genau die Grenze für die Wallbox. Insgesamt sah das dann so aus: (Rot mit rechter Achse der Widerstand, Blau mit linker Achse der Ladezustand. 1 ist "Auto will keinen Strom, Schütz nicht geschaltet", 2 ist "Auto will Strom, Schütz geschaltet") Die Kalibrierung, die wir dir gegeben haben schiebt deshalb den gemessenen Wert etwas nach Unten, er landet dann bei ~ 1300 Ω Das sieht soweit gut aus. Du hast da aber auch 16 A freigegeben, teste sicherheitshalber bei Gelegenheit nochmal mit 6 A. Ich glaube, da hattest du einfach Pech mit dem NFC-Tag: Im Debug-Report sehe ich, dass genau als das Auto anfangen wollte zu laden, die Nutzerfreigabe blockiert hat: Der Ladevorgang lief kurz, dann hast du vermutlich das Tag nochmal drangehalten, das stoppte den Ladevorgang und später hast du wieder freigegeben und es wurde weitergeladen. Während des ganzen Ladevorgangs hat EVCC auf 6 A limitiert. Das ist das Minimum, was die Wallbox dem Auto kommunizieren kann. D.h. wenn du im Auto 5 A einstellst, muss die Wallbox trotzdem 6 A erlauben und das Auto zieht dann halt weniger. Nein, das sollte soweit funktionieren. EVCC gibt dir bei Min+PV ja mindestens 6 A + was an Überschuss da ist und das Auto sollte dann alles verwenden, wenn du es auf 32 A gestellt hast. D.h. jetzt ist alles gut? :D

Firmware: WARP Energy Manager 2.0.0 Blogpost über die neuen Features, sowie aktualisierte API-Dokumentation folgen in Kürze. API-Änderungen; möglicherweise sind Anpassungen an Software die mit der Wallbox interagiert notwendig! API des energy_manager-Moduls in energy_manager und power_manager aufgeteilt Automatisierung hinzugefügt Unterstützung für WPA Enterprise (EAP-TLS, EAP-PEAP und EAP-TTLS) hinzugefügt Stromzähler-Implementierung überarbeitet: meters-API und Unterstützung von bis zu sieben Stromzählern hinzugefügt Auslesen von SunSpec-Stromzählern und -Wechselrichtern hinzugefügt Konfigurierbaren API-Stromzähler hinzugefügt Unterstützung der Eltako DSZ15DZMOD und YTL DEM4A Stromzähler hinzugefügt Zurücksetzbare Energie-Import- und -Export-Werte hinzugefügt Fehlenden "Durchschnittliche Spannung gegen Neutralleiter"-Messwert des SDM72v2 hinzugefügt Maximum der (lastgemanagten) Wallboxen auf 32 erhöht Berechnung der verfügbaren Leistung im "Schnell"-Modus repariert Wolkenfilter repariert Übersetzungen verbessert MQTT-Performance verbessert WLAN-Access-Point-Performance, falls gleichzeitig eine WLAN-Verbindung aufgebaut wird, verbessert Fehlermeldungen in Eingabefeldern verbessert Unterstützung von TLS-Versionen vor 1.2 entfernt Hinzugefügt, dass WLAN-Access-Point bei instabiler WLAN-Verbindung länger geöffnet bleibt Sichergestellt, dass zum WLAN-AP mit der besten Empfangsqualität verbunden wird Subnetz-Konfiguration des WLAN-Access-Points repariert Sichergestellt, dass Lastmanagement erst Strom verteilt, wenn alle gesteuerten Wallboxen erreichbar sind Sichergestellt, dass WLAN-HT40-Modus immer deaktiviert bleibt Web-Interface-Labels die fehlende IDs referenzieren entfernt Änderung eines konfigurierten TLS-Zertifikats repariert Funktion des Zurück-Buttons bei Aufruf des Webinterfaces repariert Tastatureingabe in Datumsfeldern repariert Zeitzonen-Datenbank aktualisiert Repariert, dass Watchdog des verfügbaren Stroms des Lastmanagements permanent auslöste Sichergestellt, dass Analyse-Subplots nur dann versteckt werden, wenn keine Daten in beiden vorliegen Download: WARP Energy Manager 2.0.0