ThomKa

@rtrbt @mattsches Vielen Dank für's Mitlesen und direktem Reagieren mit Anpassung und aktualisierter Firmware. Ich denke gegen Donnerstag, spätestens am Wochenende die neue FW einspielen zu können. Dann melde ich mich. @deepflyer911 Musst Du wissen. Mattsches mit Feedback zu versorgen finde ich auch wichtig ;-)

Sorry, stimmt natürlich... Das ist kein PhaseSwitcher Thema. Da habe ich es mir zu einfach gemacht. Umso mehr Dankeschön für Eure Antworten 👍. Ich geh' mal suchen 😉

Wie sieht bei Euch eigentlich das LadeLog aus?..? Obwohl mein Enyaq ab ~1300 durchgängig angestöpselt war und der Ladevorgang gegen 1830 wegen Erreichens des Ziel-SoC-70% abgeschlossen war, fanden danach immer wieder neue Ladevorgänge statt... Müsste 1 Ladevorgang nicht eigentlich von 1300 bis 1830 laufen?? Müsste der Ladevorgang nicht abhängig von "connected" / "disconnected" sein? Ich weiß, dass das LOG nicht derart relevant ist. Ich möchte nur die Logik verstehen und bin der Mainung, dass hier etwas nicht durchgängig ist und alles irgendwie zusammenhängt...

Tja, das wäre schön. Die einzigen states die es gibt sind Und daraus lässt sich leider kein "Ladeende" ablesen. Den aktuellen SoC bekomme ich natürlich. Dann muss ich die Ladegrenzen halt bei mir festlegen und dagegen prüfen. Immer dass die WEconnect-API auch verfügbar ist. Da bekleckert sich der Konzern wirklich nicht mit Ruhm 🧐. Das ist es bei mir (noch) nicht. Mit Entriegeln des Ladesteckers, vom Enyaq aus, fiel auch das Relais ab. Da hat also nix geklebt. Ich beobachte das mal weiter. Habe es auch nur zufällig gesehen, da ich zum Ladeende gerade am Rechner saß.

Moin zusammen, ich hätte da mal 2 Fragen... Woran kann ich erkennen, dass ein Ladevorgang seitens des BEVs beendet wurde, weil der Ziel-SoC erreicht wurde? Ich finde dazu weder in den VW-Connect-, noch in den WARP-Datenpunkten etwas passendes. Und wie kann es zu solch einem Status kommen? Der Ladevorgang ist vom ENYAQ gegen 1750 beendet worden, da SoC-70% erreicht wurden. Und dennoch ist 1ne Phase aktiv?..? Muss ich mir Gedanken machen 😉. Beste Grüße, Thomas

Moin zusammen 🫡, möchte mich erst mal herzlich für Eure Unterstützung bedanken 🙌💪💪. Dank Eurer Hilfe und der tollen Lösung von Matthias, lädt mein Enyaq nun problemlos, den dritten Tag in Folge rund 15%. Das sieht dann, an einem heutigen seeehr wolkigen Tag, mal so aus: Im aktuellen Betriebsmodus "PVonly" wird der PV-Überschuss und PV-BAT-Leistung kompensiert. So dient die PV-BAT nur kurz als BEV-Ladepuffer. Der Modus "PVonly_BEVmin" mit einer Mindestladeleistung von z.B. 2500W bindet die PV-BAT natürlich mehr ein, führt dazu aber zu deutlich ruhigeren Umschaltzyklen. Jetzt geht es in die nächste Runde. Die gesamten Bedarfe der Verbraucher sind mit der PV-BAT-Kapazität, den Forecast-Werten dem zu erreichenden BEV-SoC zur Abfahrtszeit abzugleichen und die Ladeleistung zu planen. Bestenfalls unter Berücksichtigung der günstigen Stunden im TIBBER-Tarif ;-) Das ist das tolle am Ganzen. Es hört nie auf und es geht immer noch was 😁. Ich freu mich drauf und auch darauf Euch wieder zu kontaktieren, wenn ich mir mal wieder selbst im Weg stehe. Ganz liebe Grüße, Thomas

@borg Erstmal vielen Dank für Deine umgehende Antwort 💪. Anbei das LOG, wie von Dir beschrieben. Hoffe es passt so ;-). Beste Grüße, Thomas evse-debug-log-warp-TJ3-2023-07-18T16-14-03-062.txt

@MatzeTF Danke für den Hinweis. Kein Update ohne Backup 🫡😉 Bringt mich aber zu der Frage... Wie komme ich zu einer spezifischen Kalibrierung meiner WARP?

@deepflyer911 haben Deinen Thread mit dem TF-Support gefunden. Weiß aber nicht, ob es für mich passt. Ich warte mal was Du dazu noch findest. Andere Frage: Bei reinem PV-Überschuss-Laden... Gebt Ihr den available_charging_power 1:1 weiter - also auch, wenn der Wert unter z.B. 1,38kW liegt? Und lasst damit die WARP komplett alleine regeln? Oder andersrum gefragt... Wenn mein Enyaq mindestens 2,5kW Ladeleistung haben möchte, sollte ich dann available_charging_power erst weitergeben, wenn der PV-Überschuss diesen Wert überschreitet und vorher die Werte auf 0 setzen?

Guten Morgen und danke Euch für Eure Antworten 👍. Nach den Leistungsschwellen fragte ich, weil ich auch Leistungen jenseits von 4,14kW mit nur 1ner aktiven Phase hatte... Screenshot folgt demnächst. Die Umschaltzeiten sind mir bewusst und ja auch gut in den Masken nachzuvollziehbar. Wollte nur sicher gehen... Ja, habe eine 22kWh-Warp und auch den Schützdefekt von @deepflyer911 in Erinnerung. Bei 12kWh zeigt der Enyaq eine interne Ladeleistung von 11kWh an. Es ist also nur das Herausfinden des oberen Wertes. Als untere Ladeleistung müssen z.B. mindestens 2,5kWh übergeben werden, weil der Enyaq ansonsten auf Fehler geht... Dies also, obwohl die Werte oberhalb der 1,37kWh liegt. Dass die Wert-Änderung für das FZG zu abrupt sein könnte, hatte ich auch schon vermutet. Leider habe ich seitens des FZG keine tiefergehenden Logs gefunden. Daher fragte ich nach Eurer Einschätzung. Muss mal schauen was ich damit jetzt anfange, denn auch eine DICKE und GROßE Wolke kann die Leistung schnell und stark einbrechen lassen. Und mir kam es so vor, dass genau dies, an einem der letzten sehr wechselhaften Nachmittagen, der Fall war. Da hatte ich nämlich auch Ladeabbrüche... Habe erstmal die Timer auf 300 gesetzt. Komme damit zwar nicht mehr so oft in 3-phasigen Betrieb, aber dafür keine Abbrüche mehr 🤗. Habt einen guten Wochenstart und bleibt gesund. Gruß, Thomas

Ich habe noch nicht die gesamte Ansteuerung der WARP programmiert, so dass mir auffiel, dass bei 12kW Ladeleistung die PV-Bat rund 5kW lieferte, der weitere Teil von der PV kam und der verbleibende Rest eingekauft wurde. Um das für die nötigen 1,5h Ladezeit auszuschließen, reduzierte ich auf 7kW. ... Achso... Den Wert habe ich seitens meines iob gesetzt... In der WARP selbst hatte ich es nur versucht, NACHDEM die Ladung abbrach.

Hallo Zusammen, nun mal 1 Situation, die mich die letzten Tage beschäftigt... Vielleicht könnt Ihr mir Tipps geben, an welcher Stelle ich eine Analyse starten kann. Beginn: Laden mit festen Vorgabewert = 12000W und anschließender Reduzierung auf 7000W ... available_charging_power = 12000 --> Stecker einstecken --> Ladevorgang startet ... Reduzierung der available_charging_power = 7000 --> Auto geht auf rot und in der Warp sieht es wie im Video aus. 2023-07-16_18h31_29.mp4 ... deaktiviere ich AUTOSTART --> stoppe über den Button --> geben dann vorgeschlagene 10.149A frei --> und starte den Ladevorgang über den Button --> beginnt der Ladevorgang direkt problemlos ... sende ich die available_charging_power = 7000 erneut, bricht der Ladevorgang direkt wieder ab... Dazu noch eine Frage? Ab wieviel W schaltet der PhaseSwitcher von 1- auf 3-phasig und wieder zurück? Danke Euch und Gruß, Thomas

Hi Zusammen, obwohl jetzt bei mir die MQTT-Verbindung zuverlässig steht und der WARP-Adapter auch funktioniert, fand ich die Adressierung direkt über HTTP als einfacher. Deshalb wollte ich diesen Weg nutzen. Im IOB Forum wurde heute eine Lösung dazu vorgeschlagen, die zuverlässig funktioniert. Grundsätzlich hatte der iob nämlich bislang keine Möglichkeit einen PUT abzusetzen, sondern nur GET-Requests. Jetzt gibt es auch dazu eine Lösung 😉. ... wobei ich einfach hätte NodeRed nehmen können... Aber da stand ich mal wieder wie der Ochs vorm Berg 🧐 Dann werde ich die nächsten Tage mal die Kommunikation zur WARP komplett auf HTTP drehen.Danke Euch für Euren Input und die vielen Informationen die ich damit kennenlernen durfte. Beste Grüße, Thomas PS: ein paar Besonderheiten beim Laden meines BEVs und generelle Fragen habe ich noch. Da melde ich mich nochmal. Aber die Warp mit Deiner Lösung @mattsches funktioniert, wie sie soll👍. Immer noch großes Kino 🙌

Hallo @mattsches, mit postman bekomme ich den Wert mittlerweile auch gesetzt. Hättest Du noch einen Tip für die Umsetzung im Blockly exec Baustein? Oder über den JavaScript Baustein . Da kann ich aber leider nicht das Script erstellen... Oder eine andere Lösung, wie ich das unter blockly angesteuert bekomme? Ich breche mir echt die Finger... Danke Dir und Gruß, Thomas

Ok. Erst mal direkt umgestellt 👍

Hi @poohnetund danke für Deine Antwort. Nach meinem Post habe ich den Ladevorgang mit PV-Überschuss mit Min-2500W noch mal gestartet. Dies erfolgte 2-phasig und wurde für ca 2 1/2h fehlerfrei durchgeführt, um dann mit kurzer Unterbrechung auf 1-phasig umzuschalten. "CP-Trennung" muss ich mir mal anlesen und für den ENYAQ rausbekommen. Aber wie passt das zusammen, wenn es jetzt reibungslos klappte? Oder denke ich zu einfach? Gruß, Thomas

HalliHallo, endlich is'ser da unser Enyaq und ein paar "Ladeversuche", um die Logik zu verstehen und die ersten beiden Ladungen sind gelaufen 👍. Und wie kann es anders sein 😉, die ersten Fragen tauchen auf... Könntet Ihr mir bitte erklären, warum ein Ladevorgang nicht wieder von selbst startet, wenn eine Phasenschaltung erfolgt ist? Aktuell sieht das so aus: Auch ein Freigeben der Stromstärke unter "externe Steuerung" ändert den Status nicht. Erst nach Entriegeln und Neustecken des Ladesteckers startet der Ladevorgang mit der gewünschten Ladeleistung und Phasenanzahl. Ich würde das gerne analysieren und eingrenzen, um es besser zu verstehen, weiß aber noch nicht auf welche Werkzeuge ich zurückgreifen soll. Wozu dient denn die Freigabe der Stromstärke unter "externe Steuerung"? Wenn die Phasenumschaltung läuft und automatisch schaltet, wird dort immer wieder ein Wert angezeigt, der NICHT freigegeben ist. Funktionieren tut es dann ja trotzdem... Ich hoffe, ich lerne schnell und gehe Euch nicht allzu sehr auf die Nerven🫡

@mattsches Hi. Wärst Du bitte so gut und würdest bitte Deine http Post Zeile mal zeigen. Ich breche mir die Finger... Ich kann zwar einen State per HTTP abfragen, schaffe es aber nicht einen Wert zu setzen/ändern.

Hi, nee noch nicht. Morgen holen wir unser Auto ab. Dann geht es los. Bei dem ESP32ethernet geht es auch gar nicht um den LAN Anschluss oder das Protokoll. Die Tinker-Entwickler haben angemerkt, dass Sie nicht mehr alle Weiterentwicklungen für die WARP1 zur Verfügung stellen werden können, da der RAM des ESP32 nicht mehr ausreicht. Bei der WARP2 kommt der ESP32ethernet zum Einsatz, der auch mehr RAM mitbringt.

@mattsches Erst mal vielen Dank für Deine fortwährende Pflege👏 Mich würde interessieren, wie Ihr zu der Erweiterung durch Einsatz des Ethernet-Bricklet steht? Aus den Update-Infos habe ich gefunden... https://www.tinkerforge.com/de/blog/new-functions-for-warp-charger-and-warp-energy-manager/ Dazu findet sich auch ein eigener Blog unter Damit könnte unsere WARP1 auch weiterhin an neuen Entwicklungen teilhaben... Gruß, Thomas

@deepflyer911 habe ich auch gelesen, aber nicht (mehr) verstanden. Wenn Du noch ein paar Details dazu geben könntest, wäre das wunderbar ;-). Wenn Du die Zeit nicht findest ist es auch kein Beinbruch. Dann Kämpfe ich mich durch. Dachte nur Deinen Lösungsansatz aufgreifen zu können.

@deepflyer911 Moinsen 🌞☔🌞. Ich dachte Du hättest Dich komplett vom Pi verabschiedet und würdest eine gänzlich andere Lösung einsetzen. Mal zurück in die Vergangenheit... Hattest Du nicht meinen Vorschlag zur Übergabe available_charging_power angepasst? Könntest Du Deinen Code-Ausschnitt dazu mal posten oder kurz beschreiben? Ich erinnere mich ungefähr an "... wenn die WARP dann lädt, wird der Wert available_charging_power reduziert und das Ganze schaukelt sich dann ständig hoch und runter...", oder so ähnlich.

@deepflyer911 und über was steuerst Du dann die WARP an?

@mattsches Vielen Dank für Deine Antwort. Werde es mal mit dem HTTP PUT probieren. Eigentlich reicht dies aus. Die restlichen Werte für Grafana kann ich über den WARP Adapter ziehen. Dann könnte ich auch auf mqtt verzichten... Du hast mich natürlich neugierig gemacht 😁... Magst Du uns mal 'ne Info zu Deinem Ladestandsmodul geben 😉

Das wäre ja gar kein Problem. Wenn der letzte Wert verbleibt, dann passt das schon. Ich meine eher die Frage an @mattsches, ob sich vom ursprünglichen Objektstand Verbesserungen ergeben haben, bzgl MQTT, zu denen es nützlich wäre diese zu mergen..?..? Grundsätzlich scheint mein WLAN-Signal an der WARP zu gering zu sein, so dass es zu längeren Paketlaufzeiten kommt. Und dabei wird dann die MQTT-Session am iob geschlossen und muss erst wieder neu initiiert werden. Meine Hoffnung ist halt, dass es außer einer besseren Anbindung auch SW-Stellschrauben gibt bzgl Timing und Handling. @mattsches wäre es Dir möglich ein wenig Zeit für eine Prüfung auf aktuelle Objekte einzubringen? Oder könntest Du Deinerseits von Deiner Erfahrung berichten? Wäre echt großartig 😉