ThomKa

Hi @mattsches, habe heute, noch mit v 2_6_1_670fa329, eine mehrfach unterbrochene PV-Überschuss-Ladung vorgenommen, die einwandfrei funktionierte. Die v 2.6.1+67149d8a habe ich jetzt eingebunden und melde mich wieder. Muss ich immer wieder gerne ausdrücken! Ich find es unglaublich klasse, dass Deine Lösung und Dein Code so erstklassig und stabil funktioniert, und wir dadurch eine super Wallbox bekommen haben. 1a @mattsches. Vielen Dank.

hi @mattsches, wieder mal vielen Dank für Deine Mühe und investierte Zeit. Das Update wurde soeben aufgespielt. Ich melde mich in ein paar Tagen, sobald wieder Ladevorgänge anstanden. Viele Grüße, Thomas

Wow, klasse. Ich bin gespannt. Ich hatte einige Probleme unseren Tesla zu laden. Der brach am Anfang immer ab und ich konnte nicht erkennen warum. Mal schauen, ob es mir den neuen Stand anders ist. Bin aber erst übernächste Woche wieder zu Hause. Sandhausen melde ich mich dann gerne zurück. Schon mal vielen Dank für Deine Mühe 👍

Hi, habe noch V3.5 und das wird wohl auch so bleiben. Wer 3.5 hat bekommt vorerst kein 3.7. Scheint aber ein bekanntes Problem zu sein, wenn Du mal hier schauen möchtest. Vielleicht hilft der Trick mit der Sicherung... @mattsches Läuft ja alles 1a 🤗, dennoch die Frage nach einer aktuellen Version. Hast Du noch irgendwas nachgezogen? Viele Grüße, Thomas

Guten Morgen und vielen Dank für Euer Feedback. Die Kosten sehe ich wirklich zweitrangig, da damit ein Alleinstellungsmerkmal geschaffen wäre. Alleine stimme ich zu, dass "der Masse" schwerlich zu vermitteln sein dürfte. Somit hoffe ich auf eine zukünftige Umsetzung. Euer Team und der WARP waren uns sind auf jedenfall die richtige Entscheidung.Hätte ich die Qualifikation, hätte ich das Jobangebot direkt angenommen🤗. Viele Grüße, Thomas

Hallo zusammen, auch wenn der Thread shcon etwas pausiert hat, würd eich gerne eine Abwandlung zur Diskussion stellen. Es geht mir nicht um bidirektionales Laden, sondern nur um einen ganz kleinen Teil der ISO 15118 zu nutzen. Wie ich es bislang verstanden habe, ist in der ISO auch die Kommunikation über den CP-Pin geregelt. Und Teil dieser Kommunikation ist der Austausch des Fahrzeug SoC. Dass diese Information (beim AC Laden) ausschließlich über die Hersteller-Portale zur Verfügung gestellt werden, ist gelinde ausgedrückt suboptimal... Gerade des VW-Portal mit seiner wiederholten Unverfügbarkeit, häufigen Änderungen und absolut unzureichender Kommmunikation, lassen den direkten Abgriff des Fahrzeug SoC schmerzlich vermissen. Gibt es seitens TF bereits Ideen den SoC über den CP Pin unter Anwendung des entsprechenden Protokolls auszulesen? Oder schließt sich eine Umsetzung aus, da es mit den im Einsatz befindlichen Protokollen kollidieren würde? Würde mich freuen, wenn noch jemand auf den alten Thread antwortet oder mir einen passenden empfehlen könnte - ich hhate leider keinen gefunden... Viele Grüße, Thomas

N'abend 😁. Ist bereits eingespielt. Mal weiter vielen Dank. Hatte übrigens 0 Probleme mit der letzten Version. Herzliche Grüße, Thomas

Hi Matthias. Ich hänge mit allem hinterher. Nun ist die neue FW auch bei mir aktiv. Melde mich dazu wenn es relevant ist. Danke Dir und einen schönen Sonntag. Gruß, Thomas

Vielen Dank für Eure Anpassungen. 2.1.90.2 ist jetz aktualisiert. Grüße an Euch Alle ;-)

Guten Morgen zusammen. Nachdem ich artig mitgelesen habe, kann ich vielleicht etwas beitragen... Bei den letzten Ladevorgängen passierte es zwei mal, dass die Ladung (11kW EPEX) für ca 30 - 180 Sekunden startete, also die Schütze anzogen und dann der Ladevorgang beendet wurde. Am FZG erfolgte zu dieser Zeit kein Eingriff. Beheben konnte ich dies nur durch einen Neustart der WARP. Auch hatte ich mal die Ladestati zwecks Pushover-Information ausgewertet. Allerdings kam mir die Abfolge der Stati "durcheinander" vor. Deswegen werte ich aktuell nur noch den Fehlerstatus "4" aus. Und dieser tritt sporadisch auf. Gerade heute Nacht, wo zur 21ten Stunde und zur 1ten Stunde geladen wurde. Der ENYAQ war dazu seit ca 2020 angeschlossen. Um 2101 wurde acP auf 11000 W gesetzt, um 2201 auf 0 W, um 0101 wieder auf 11000 und um 0143 war der ZielSoC erreicht, womit acP wieder auf 0 gesetzt wurde. Um 2202 trat der Status "4" auf. Wenn ihr mir genauer sagt, was ich wie und wann an Logs erzeugen soll, unterstütze ich gerne mit allen Informationen. So zum Jahresausklang möchte ich mich bei Euch allen für Euer Engagement und investierte Zeit bedanken. Ich weiß dies sehr zu schätzen und bin froh, dass wir den Umbau auf @mattsches Initiative/Voraussetzungen durchgeführt haben. Sofern wir uns erst im nächsten Schaltjahr "hören", wünsche ich Euch einen tollen Jahreswechsel und alles Gute 🍀👍. Herzliche Grüße, Thomas

Ladeskript für "EPEX laden": zuerst benötigst Du die EPEX Preisdaten von heute und morgen, die ich mir jeweils gegen 13:30 über TIBBER abhole. Diese liegen dann im Format vor, wie angefügt. Die Preise liegen bei mir in den DPs 0_userdata.0.Tibber.Stundenpreise_heute und 0_userdata.0.Tibber.Stundenpreise_morgen Danach arbeitet das Skript "EPEX Laden" wie folgt: es wird direkt auf Änderungen der Vorgabewerte geprüft/reagiert es wird direkt auf Änderungen der Ladefreigabe geprüft/reagiert mit jeder Änderung der Vorgabewerte oder Ladefreigabe erfolgt ein Abbruch eines laufenden Ladevorgangs, eine neue Kalkulation eines neuen Ladevorgangs und der Start eines neuen Ladevorgangs FKT2 ist die zentrale Funktion und ruft die weiteren FKTs 3-5 auf. Alle zusammen kalkulieren den Ladevorgang anhand der benötigten Energiemenge und der günstigsten EPEXpreise. FKT6 prüft, ob die aktuelle Stunde eine der günstigen EPEXstunden ist und übermittelt dann 0_userdata.0.Warp.BEV.BEV_cP_max an WARP. Ist es keine günstige Stunden wird "0" an WARP übergeben. Wenn es seitens des vorgelagerten Skripts "WARP_Ladezentrale" zum Ladestatus "LV_stoppen" kommt, wird auch im Skript "EPEX laden" alles gestoppt und das Skript belastet den Raspi nicht weiter. Eine ausführlichere Beschreibung der DPs findest Du im ioB-Forum unter https://forum.iobroker.net/topic/68266/bev-mit-epex-börsen-strom-laden. Aber bitte nur den Abschnitt "2. Datenpunkte" betrachten. Die anderen Ausführungen passen nicht mehr zu angefügten Skript. Damit hast Du alle Informationen und meinen aktuellen Stand. Die PV-Überschuss-Ansteuerung habe ich noch nicht auf das vorgelagerte Skript "WARP_Ladezentrale" umgeschrieben, also noch nicht drunter gehängt. Deshalb ist es hier nicht weiter erwähnt. Alles weitere wie immer gerne auf Rückfrage 🫡 2023-11-06_TIBBERpreise_today.json 2023-11-06_TIBBERpreise_tomorrow.json 2023-11-06_WARP_EPEX_laden.json

Ladeskript für adhoc oder FAST laden: Damit Du die Einbindung/Abhängigkeit des vorgeschalteten Scripts "WARP Ladezentrale" mit den beiden Ladefreigaben "LV_starten" / "LV_stoppen" besser einschätzen kannst, findest Du angefügt das sehr kurze Skript zum "adhoc" oder "FAST" laden. Dieses und die anderen "nachgelagerten" Skripte steuern eigentlich nur die Höhe der verfügbaren Ladeleistung "available charging Power" (acP) zwischen "0" bis 0_userdata.0.Warp.BEV.BEV_cP_max. Die Überwachung/Festlegung des Lade-Beginns/Endes erfolgt vorgelagerten Script. 2023-11-06_WARP_adhoc_FAST_laden.json

Vorgelagertes Skript zur Ladesteuerung: @deepflyer911 Anbei folgende Informationen zum Nachvollziehen: Beim Script WARP_Ladezentrale handelt es sich um das zentrale Script, hinter dem obigen Screenshot. Dieses erteilt/entzieht die Ladefreigabe und prüft dabei, ob ein BEV an-/abgestöpselt wurde oder ist, ob der gewünschte SoC_Ziel erreicht wurde, und ob sich zwischendurch Vorgabewerte geändert haben. Im Script läuft ein zentrales Intervall, welches die Prüfungen wiederkehrend ausführt. Für den Fall, dass kein BEV angestöpselt ist oder der SoC_Ziel erreicht ist, wird die Intervalldauer verlängert, um den RaspberryPI nicht unnötig zu belasten. Im Fall eines Ladevorgangs erfolgt die Überprüfung dann wieder mit kürzerer Intervalldauer. Das Script vergibt über den Datenpunkt 0_userdata.0.Warp.Ladevorgang.LV_Status die Ladefreigabe "LV_starten" oder entzieht diese "LV_stoppen". Der Datenpunkt wird von den nachgelagerten Scripts ausgelesen. Die eigentliche Ansteuerung der WARP übernehmen dann die nachfolgenden Skripte. Angefügt findest Du dann noch die dazugehörigen Datenpunkte, alle unter dem Pfad 0_userdata.0.Warp.... Kann sein, dass da auch ungenutzte DPs drin sind. Da habe ich noch nicht komplett aufgeräumt 😉 Im nächsten Post stelle ich Dir das Script zum "EPEX laden" und zum "adhoc laden" bereit. Diese starten dann nachranging und abhängig vom DP 0_userdata.0.Warp.Ladevorgang.LV_Status. PS: Zum Nachvollziehen des Ablaufs einfach mal die ganzen DEBUGs aktivieren. Dann zeigt sich Ablauf und Abhängigkeiten ganz schnell. 2023-11-06_WARP_Ladezentrale_Datenpunkte.json 2023-11-06_WARP_Ladezentrale.json

@deepflyer911 dann schau einfach mal im IOB Thread: https://forum.iobroker.net/topic/66839/blockly-baustein-für-http-put. Vielleicht möchtest Du die Umsetzung auch direkt in NodeRed vornehmen, wie es am Ende aufgezeigt ist 😉. Für die zentrale Steuerung hinter obigen Screenshot habe ich mittlerweile ein eigenes Skript erstellt. Alle anderen Ladearten "adhoc", "EPEX" oder "PVÜS" orientieren sich an der Ladefreigabe dieses Skripts. Das ist aber noch nicht in einem Forum beschrieben. Ich stelle Dir was zusammen und Du kannst dann mal schauen, was Du verwenden möchtest, oder was Dir hilft.1

@deepflyer911 @mattsches sagt mal ihr 2.. Da hatte doch ?..? damals dazu geschrieben, dass die MQTT Umsetzung im iob "ungünstig" sei... @deepflyer911möchtest du das mit dem "http post" aus dem iob nicht mal ausprobieren und dafür MQTT am WARP deaktivieren? Der Aufwand dürfte für Dich eher gering sein. Ich könnte Dir die blockly Logik geben. Sofern Du es nicht über blockly lösen möchtest, kannst Du sicher das JS Pendant daraus ableiten