alestrix

Moin! In der Bedienungsanleitung, der GUI und der API Referenz habe ich keinen Hinweis auf eine Exportfunktion der WARP Konfig gefunden. Zwar finden sich einige Infos im Debug Log, das man an der GUI herunterladen kann oder man kann sich aus http://warp/debug_report viele Infos ziehen, aber da sind auch viele nicht-config Infos enthalten. Und das Problem des Wiedereinspielens ist damit auch nicht gelöst. Das Beste, was ich bisher hinbekommen habe ist ein curl --silent http://warp/debug_report | jq 'to_entries | map(select(.key | test(".*/config$"))) | from_entries' > config.json und aus dem JSON sollte sich auch recht leicht wieder ein oder mehrere API Calls basteln lassen. Aber da fehlen dann - neben wahrscheinlich noch weiteren Daten - die ganzen `evse/.*enabled` Werte. Wie kann ich die Konfig von der Box abziehen? Und wie würde man diesen Export dann z.B. nach einem Werksreset wieder einspielen? Danke! Alex

Danke noch für die Info, habe dem API-Zähler die ID 1 gegeben - jetzt habe ich auch verstanden, was mit "Stromzähler für Berechnungen im Zusammenhang mit Ladevorgängen" gemeint ist ;-) (habe mal einen Formulierungsvorschlag per PR gesendet). D.h., wenn ich noch einen weiteren API Zähler "0" anlege und dem regelmäßig die Werte vom Wallbox-Stromzähler übermittle, dann funktionieren auch so Dinge wie Energielimit? EDIT: Überwacht die Zählerüberwachung den Wallbox- oder den Netzanschluss-Zähler? Falls letzteres, sollte er doch eigentlich aktiv bleiben können, da Tasmota ja alle paar Sekunden die Werte vom Hausanschluss meldet. Und falls der Wert ausbleibt, ist ein Runterschrauben auf einen konservativen Wert ja nichts Verkehrtes, oder? Ah, nein, hab's mit dem Watchdog verwechselt. Ich nehme an, der Watchdog bezieht sich auf den Netzanschlusszähler, die Zählerüberwachung auf den Wallboxzähler? /EDIT Vielen Dank für das Angebot! Leider bin ich mir unsicher, ob es überhaupt möglich ist, das CP-Trenn-Bricklet und den externem 1p3p Schütz zum Zusammenspiel zu bewegen. Bisher sehe ich da noch keine Möglichkeit, da die Box ja nicht weiß, dass/wie sie den Schütz per API steuern kann. VG Alex

Hallo, erst mal sorry, dass ich so lange nicht geantwortet habe wo Ihr mir so viel Input gegeben habt. Im August sollte ich jetzt wieder etwas mehr Zeit für das Hobby haben... Ja. Es war im coredump enthalten, der am Ende des debug-logs als base64 encodeter String enthalten war. Ich habe mir mal ein paar Debug logs hier im Forum angesehen aber nirgends war ein coredump angehängt. K.A. warum der bei mir dabei war. Auf den Dump von damals habe ich gerade keinen Zugriff, aber wenn ich mir jetzt noch mal einen frischen ziehe, dann sehe ich das Passwort ab 0x5438. Also als One-Liner: sed -n '/base64,/,${s/.*base64,//;p}' debug-report-warp-TH5-2024-08-03T17-49-56-460.txt | base64 -d | xxd -u -s 0x5438 -l 32 Was die CP Trennung von @poohnet angeht, so muss ich mir das entsprechende GitHub Projekt noch etwas genauer anschauen, schrecke aber ein wenig davor zurück, da ich noch nie SMD Bauteile verlötet habe. Außerdem weiß ich noch nicht, wie ich meinen vorhandenen externen 1p/3p Schütz (per MQTT und HTTP ansteuerbar) in das Ganze einbinden würde. Wahrscheinlich werde ich das vorerst mal nur in einer Minimalversion "für Arme" umsetzen und per NFC-Regel ein externes Skript triggern, das den Schütz umschaltet (nach einer Prüfung, dass das Auto auch getrennt ist). Dann kann ich zumindest vor dem Ladevorgang entscheiden, ob ich 1- oder 3-phasig laden möchte. Frage an @rtrbt/@MatzeTF: Genügt es, nach dem Schalten einmal per charge_manager/available_phases die Phasenzahl zu setzen, damit die Berechnung des Ladestroms für das PV-Überschussladen passt? Wenn man die Phasenzahl an der GUI ändert, wird man ja immer aufgefordert, die Box neu zu starten. Oder wird damit die Einstellung ständig im Flash geändert was schlecht für die Langlebigkeit ist? Was wäre dann ein geeigneterer API Aufruf? Ah, wenn man's weiß, dann ist es nachvollziehbar 😉. Warum denn dieser (gefühlte) Designbruch? Für den Ladevorgang begrenzende oder verhindernde Umstände gibt es ja jeweils einen eigenen evse-"Slot". Was ist denn der Hintergrund, den Check, ob das Auto ladebereit angeschlossen ist, in zwei vorhandenen Slots mit unterzubringen statt einen eigenen dafür zu spendieren? Viele Grüße Alex

Hi Matze, vielen Dank für die Rückmeldung zu so später Stunde! 😃 Den Test werde ich machen, sobald das Auto da ist (morgen Abend) und dann wieder die Sonne scheint (Samstag ☀️). Mein Verständnis ist aber, dass bereit jetzt ohne angeschlossenes Fahrzeug im Lademodus "Schnell" das Lastmanagement nicht auf "Blockiert" stehen dürfte. Als Trockenübung habe ich jetzt mal ohne Auto per inject_tag zwischen zwei NFC Tags hin- und her geschaltet, an der Blockierung bei "Lastmanagement" und "Benutzer/NFC" hat das aber nichts geändert. 0,057 | | **** TINKERFORGE WARP CHARGER V2.4.0+665589EC **** 0,058 | | 325K RAM SYSTEM 298500 HEAP BYTES FREE 0,068 | | READY. 0,069 | main | Last reset reason was: Software reset via esp_restart. 0,286 | tools | Mounted data partition. 81920 of 3538944 bytes (2.3 %) used 0,577 | api | WARP Charger config version: 2.2.0 (warp) 0,577 | esp32_brick | ESP32 Brick UID: TH5 1,029 | evse_common | Continuing to use sum of imported and exported energy for charge tracker. 1,030 | evse_common | Remove tracked charges to switch to imported energy. 1,265 | ntp | Set timezone to Europe/Berlin 1,731 | meters | Meter in slot 0 declared 1 values. 1,998 | charge_tracker | Found 1 record: first is 1, last is 1 2,050 | charge_tracker | Last charge record size is 3168 (3168, 0) 2,427 | power_manager | Raising guaranteed power to 1840 based on minimum charge current set in charge manager. 2,566 | device_module | NFC Bricklet found. Enabling NFC support. 2,998 | network | mDNS responder started 3,373 | wifi | Connecting to rtlwrmft-IoT 3,380 | charge_manager | Available phases: 1 3,382 | device_name | This is warp-TH5 (warp-TH5), a WARP Charger Pro 22kW +NFC 3,398 | power_manager | Pausing energy updates because power value is not available yet. 6,014 | wifi | Connected to rtlwrmft-IoT, BSSID 82:8A:20:8A:2E:F6 6,912 | charge_manager | Seen all chargers. 7,541 | wifi | Got IP address: 192.168.8.216/24. Own MAC address: 10:52:1C:89:56:AC 9,424 | power_manager | Resuming energy updates because power value is now available. 9,425 | power_manager | Seen all chargers. 9,436 | power_manager | wants_on decision changed to 1 9,436 | power_manager | Immediate switch-on during start-up period, power available: 7360, current available: 32000 2024-07-19 02:36:01,948 | ntp | NTP synchronized at 16,423 2024-07-19 02:36:08,912 | mqtt | Connected to broker. 2024-07-19 02:36:16,361 | automation | Running rule #2 2024-07-19 02:36:16,362 | automation | Running rule #3 2024-07-19 02:36:16,363 | power_manager | Switched mode 0->0 2024-07-19 02:36:42,364 | automation | Running rule #1 2024-07-19 02:36:42,365 | power_manager | Switched mode 0->2 2024-07-19 02:36:42,479 | power_manager | wants_on decision changed to 0 2024-07-19 02:36:42,479 | power_manager | Immediate switch-off after changing modes, power available: -382, current available: 0 2024-07-19 02:36:48,169 | automation | Running rule #2 2024-07-19 02:36:48,171 | automation | Running rule #3 2024-07-19 02:36:48,172 | power_manager | Switched mode 2->0 2024-07-19 02:36:48,327 | power_manager | wants_on decision changed to 1 2024-07-19 02:36:48,327 | power_manager | Immediate switch-on after changing modes, power available: 7360, current available: 32000 Bei den Regeln handelte es sich um das Setzen des PV Modus (#1) bzw Schnell Modus (#3) und das Setzen des Ladestroms (#2), jeweils getriggert durch das NFC-Tag. Wenn ich die NFC-Regeln bei der Automatisierung rauslösche, findet sich keine Info über das inject-Event im Ereignislog (hört mit der mqtt connect Meldung auf). Komplettes Log mit coredump liefere ich dann mit, wenn ich den Test mal mit Auto mache - kann den Anhang dann eigentlich jeder runterladen? Wie ich gesehen habe, ist das WiFi Passwort im coredump enthalten. Und warum steht da eigentlich beim device_name "WARP Charger Pro"? Ich habe ganz sicher keinen in der WB eingebauten Stromzähler. Viele Grüße Alex PS: 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. PPS: Wie aufwendig wäre es, die CP Trennung bei der WARP1 nachzurüsten?

Moin! Vorgeplänkel/Was bisher geschah Da ich endlich wieder ein vernünftiges Leasingangebot gefunden habe, steht ab morgen wieder eine Zoe vor meiner Haustür. Darum habe ich heute meine liebe WARP Smart der ersten Stunde wieder in Betrieb genommen und die aktuellste Firmware aufgespielt. Erst mal muss ich sagen wie begeistert ich bin von den zusätzlichen Funktionen, die auch die gute alte WARP1 dazu bekommen hat. Insbesondere die Automatisierungen (habe das NFC Bricklet eingebaut, da ist Automatisierung ideal) und die Anbindung externer Datenquellen ist ein gutes Feature - die Einbindung meines Tasmota Stromzählers als API-Stromzähler in der WARP war blitzschnell erledigt. Die Schwierigkeit Da die WARP ja nun die Werte von Netzbezug/Netzeinspeisung zur Verfügung hat, war der logische nächste Schritt, auch das PV-Überschussladen direkt in der WARP (habe früher dazu evcc genutzt) zu konfigurieren. Dazu muss man zwangsweise das Lastmanagement aktivieren - interessanterweise nicht unter "Lastmanagement", sondern unter "Wallboxen" zu finden 🤔. Das hat aber zur Folge, dass die Ladung dauerhaft blockiert ist - im Ladestatus steht nun hinter "Lastmanagement" immer "Blockiert". Ursache? Ich kann mir vorstellen, dass es daran liegt, dass die WARP1 Smart keinen internen Stromzähler hat, die Lastmanagementlogik aber zwingend einen solchen verlangt. Das macht ja auch beim "echten" Lastmanagement Sinn, wenn das LM aber nur deswegen eingeschaltet wird, weil PV-Überschussladen genutzt werden soll, dann ist eine solche stringente Regel eigentlich nicht mehr notwendig. Was tun? Ich könnte mich jetzt nach zwei Jahren Pause wieder versuchen in evcc einzudenken, eine Lösung mit möglichst wenigen externen Abhängigkeiten, die also nur die WARP und den Stromzähler involviert, ist aber eigentlich immer zu bevorzugen. Daher meine Bitte: Kann die stringente Anforderung, für PV-Überschussladen einen eingebauten Zähler zu benötigen, fallen gelassen bzw. deaktivierbar gehalten werden? Alternativen/Feedback Die Möglichkeit, per API Daten an die WARP zu pushen, ist schon ein guter Anfang, aber eine Kombination aus HTTP GET mit json query als "pull" Lösung würde weitere Möglichkeiten bieten - z.B. das Auslesen eines bereits vorhandenen externen Wallbox-Stromzählers (der Name "Stromzähler" im Menü unter "Energiemanagement" ist übrigens nicht eindeutig - es könnte der am Netzübergabepunkt sein, einer vor der Hausbatterie, oder ein Stromzähler direkt vor der Wallbox). Auch wäre eine (ausgehende) API zur Anbindung eines externen Schützes zur 1p3p Umschaltung ein Use Case, den sicherlich nicht nur ich hätte. Danke & viele Grüße Alex PS: Noch etwas Seltsames: Wenn ich in der Benutzerverwaltung "Verlangt eine Freigabe des Lade­vorgangs durch einen Benutzer zum Laden (z.B. per NFC-Tag)" aktiviere und dann ein NFC-Tag an den Leser heranhalte (bzw. injecte), das einem Nutzer zugewiesen ist, dann steht im Ladestatus weiterhin "Blockiert" bei "Benutzer/NFC". Wo ist der Denkfehler?

Einphasiges Laden geschieht immer über den L1 Kontakt des Typ 2 Steckers: https://de.wikipedia.org/wiki/IEC_62196_Typ_2#Ladebereiche Der Kontakt ist wiederum mit genau einer Phase Deiner Hausinstallation verbunden.

Was den Ethernet-Blitzschutz angeht, hab ich das bei mir hinterm DSL Modem eingebaut, d.h. es trennt das Modem, das direkt am APL hängt, von der restlichen LAN-Installation wie Router, Switche, etc.: https://www.omg.de/ubiquiti-networks/ethernet-surge-protector/ubiquiti-ethernet-surge-protector/a-13479 Ob's was bringt, kann ich mangels Notwendigkeit nicht sagen (und bin ehrlich gesagt auch nicht scharf drauf 😉).

Ich bin kein Elektriker, aber meines Wissens müssen bei 3-phasigen Verbrauchern die Sicherungsautomaten der drei Phasen gekoppelt sein. D.h. wenn eine fliegt, müssen die anderen auch unterbrechen. Ich würde eher Phasen 2 & 3 per zusätzlichem Lasttrennschalter oder Schütz zu- und wegschalten.

Wenn ich mal ein bisschen träumen dürfte wären das meine Weihnachtswünsche: - Es wird in der Firmware ein Relais-Bricklet als weitere Möglichkeit der CP-Trennung unterstützt (für die WARP1 Besitzer) - Die CP-Trennung wird über die API zugänglich gemacht Eine entsprechende Steuersoftware vorausgesetzt, könnten damit all jene, die sich schon früh eine WARP gekauft und einen Schütz im Schaltschrank haben, ebenfalls eine 1p3p Umschaltung nutzen.

Darf ich fragen, welches Fahrzeug Du hast? Angeblich soll z.B. die Zoe auf so etwas recht empfindlich reagieren (daher mein Kommentar zur CP Trennung).

Aus dem Firmware v2 Changelog: > Repariert, dass Passphrase bei Verbindung zu anderem Access Point mit selber SSID nicht verlangt wird Bedeutet das, dass ein Roaming zu einem anderen AP des selben Netzes (Site mit mehreren APs und Controller) nur noch mit erneuerter Eingabe des Passworts möglich ist? EDIT: Bevor die Fragen kommen, ob ich eine mobile Wallbox betreibe :-) - nein, es geht darum, dass die Wallbox über einen anderen AP in Reichweite verbunden bleibt, wenn der erste aufgrund von Konfigurationsänderungen oder Firmware-Updates über einen kurzen (oder manchmal auch nicht so kurzen) Zeitraum nicht erreichbar ist.

Ich habe die WARP 1 Smart und kann genau diese Fälle (per externem Schütz) abbilden. Die Logik, wann man umschalten darf, wird aber natürlich nicht von der WARP selbst abgedeckt. Ob und wie der Energy Manager das über einen (Fremd)Schütz übernehmen kann, weiß ich nicht. Ich nehme mal an, dass die WARP 2 einen API Endpunkt für die CP Trennung anbieten wird. Wobei Du bei einer "kleinen PV Anlage" wahrscheinlich gar keine 1p3p Umschaltung während des Ladens benötigen wirst.

Je nachdem, was sie sich alles zur Anmeldung vorlegen lassen, bekommen sie das schon mit. Ich würde auch nicht empfehlen, dem Netzbetreiber etwas vorzulügen, da zieht man im Konfliktfall nur den Kürzeren. Aber vielleicht lassen sie sich ja darauf ein, dass OCPP vorhanden sein wird, sobald sie ihr Zugangsgateway (oder wie auch immer man das dann nennt) bei Dir installiert haben. Sollte die Box bis dahin kein OCPP unterstützen, würde sie die Betriebserlaubnis am MEGA Anschluß verlieren. Viele Grüße Alex PS: Ich bin kein Elektriker, sondern nur interessierter PV- und Wallbox-Nutzer. Daher alles was ich hier schreibe bitte immer gut hinterfragen und mit einer Prise Salz genießen. :-)

Ach ja: warp/charge_tracker/current_charge {"user_id":2,"meter_start":null,"evse_uptime_start":482012286,"timestamp_minutes":27466259,"authorization_type":3,"authorization_info":{"tag_type":0,"tag_id":"CA:FE:AF:FE"}} Soll die user_id wirklich der numerische Index sein oder sollte hier nicht eher der Benutzername rein?

Moin! Nein, das habe ich im Log nicht gesehen. Als ich mit der neuen Beta das gleiche Verhalten gesehen habe, bin ich stutzig geworden. Dann ist mir bewusst geworden, dass das ja nur mit angestecktem Fahrzeug funktioniert. Nach Beseitigung des Layer 8 Fehlers lief es dann wie es soll. Ich möchte es jetzt allerdings mit der alten Beta nicht nochmal nachtesten. Mir ist noch folgendes Verhalten aufgefallen: In meiner WARP sind zwei Tags mit unterschiedlichen Stromgrenzen hinterlegt. Ein inject_tag mit dem ersten setzt die Benutzergrenze auf den konfigurierten Wert. Ein nachfolgendes inject_tag mit dem anderen Tag ändert nichts mehr an der Benutzergrenze. Ich muss erst die Benutzerauthorisierung aus- und wieder anschalten, dann nimmt die WARP das zweite Tag an. Ich nehme an, ein Ab- und Anstecken des Fahrzeugs hätte wahrscheinlich den gleichen Effekt gehabt. Ob es sich mit echten Tags am RFID Leser genauso verhält, konnte ich nicht testen. Grüße Alex