deepflyer911

@mattsches auch mit dem soc modul funktioniert die Version 2.1.5 ohne Probleme. Läuft mit 31%cpu Last sauber vor sich hin.

@mattsches herzlichen Dank für deine schnellen Mühen. Habe die Version ohne SOC installiert und läuft bislang ohne Aussetzter. @MatzeTF richtig, nutze iobroker. Allerdings war das "status senden bei Verbindung" in meiner mqtt Instanz bereits deaktiviert. Dennoch scheint ja der mqtt browser probleme verursacht zu haben, wenn das die einzige substantielle Änderung von 2.1.4 auf 2.1.5 ist?!

@mattsches nach dem Neustart geht es mit rund 65k bytes los. Diese sinken innerhalb kurzer Zeit ab. Wenn der Wert unter 51k bytes fällt kommt der Neustart. Größter freier Block ist dann um die 45k.

@MatzeTF angefügt der aktuelle Report. Habe seit 16:59 keinerlei änderungen vorgenommen. wo hat die Box denn eine USB Schnittstelle? debug-report-warp-SMq-2023-09-26T18-15-43-290.txt

Ergänzung Bug Report debug-report-warp-SMq-2023-09-26T16-59-24-748.txt

@MatzeTF anbei der Debug Report während des typischen Verhaltens. Die IP der Wallbox und des MQTT Servers sind statisch im Netzwerk festgelegt. debug-report-warp-SMq-2023-09-26T16-56-50-876.txt

Habe gerade nochmal reingeschaut, im Reiter debug wird der counter "Zeit seit Neustart" bei jedem Verlust des mqtt bzw der Synchronisation zurück gesetzt. Damit erscheint es mir so, als ob die Wallbox neustarten würde. Passt aber irgendwie nicht, da es innerhalb einer halben sekunde passiert. So fix startet die Box nicht...

@mattsches hatte zuvor die letzte Version der 2.0 von dir im Einsatz. War es 2.0.8? Hattest du etwa im April gedroppt. Den Zwischenschritt auf die 2.1 hatte ich nicht installiert.

@mattsches hab die neuste Version aufgespielt. Was unmittelbar auffällt, dass er nur schwierig eine Zeitsynchronisation hin bekommt. Zudem verliert er alle paar Sekunden den Kontakt zum mqtt server. Zeitgleich wird mir im Browser kurz angezeigt, dass die Verbindung zur Wallbox verloren ist. So als ob das WLAN kurz unterbrochen wäre. ENtsprechendes zeigt er auf der Oberfläche der Wallbox aber nicht an. Wenn er die Zeit synchronisiert hat, bricht gleichzeitig die Verbindung zu mqtt ab und die Synchronisation geht verloren. Mit jedem Abbruch wird die verfügbare Ladeleistung genullt. Habe aktuell kein Auto zum Laden da, fürchte aber, dass da keine Ladung zustande kommt.

@mattsches macht es Sinn diesen stand zu nutzen, wenn die vorherige Version ohne Probleme funktioniert?

@ThomKa dass das Auto voll ist, sollte dir die app von skoda melden. Das angeblich eine Phase aktiv bei 7w Leistung ist verdächtig. Hast du ein Multimeter um am Stecker zu checken ob Spannung anliegt? Nicht das dein Schalter, wie bei mir kleben geblieben ist...

Hey @ThomKa Versuch es mal mit den angefügten kalibrierungswerten. Auch wenn es bereits eine Weile her ist, meine ich darin lag der Schlüssel damit der enyaq mit niedriger Spannung die Ladung startet. calibration.json

Jenseits 4kw weil du die Box mit 22kw betreibst und der enyaq intern auf 2phasen umschaltet. Das der enyaq nicht startet hatte ich ganz zu Anfang auch, damals noch ohne phasenumschaltung. Da musste ich eine Logdatei an tinkerforge schicken und die haben mir neue Werte für den ladekontroler geschickt. Ich schau heute Abend mal was bei mir da hinterlegt ist.

Von @mattsches richtig bemerkt, der enyaq kann nur 11kw. Solltest du eine 22er Warp haben, kann ich nur empfehlen diese auf 11kw laufen zu lassen. Der enyaq hat die Möglichkeit, mehr als 16a auf einer Phase zu verarbeiten, da er selbstständig die zweite Phase in seinem Ladegerät hinzu nimmt. Ob das wirklich gut ist, bezweifel ich. Eine Ursache muss der Defekt an meinem on board Lader ja haben.... Meine Box läuft jetzt als 11er. Dadurch schaltet er entsprechend früher hoch auf 3 Phasen und prügelt nicht 6-7kw über eine Phase...

Auch wenn es dein Problem nicht löst, wozu spielst du manuell an der Charging power rum?

Ich nutze den iobroker. Der Adapter der dort für die warp angeboten wird funktioniert ohne Probleme. Das Skript welches den Überschuss berechnet und setzt habe ich im Ursprung ja vom @ThomKa.

Cp Trennung ist kein Problem, das benötigt der enyaq nicht. Aber bitte unbedingt nur1 oder 3 phasig laden! Alles andere kann teuer werden!!!!

Ah okay, soweit habe ich mich mit dem Thema nicht beschäftigt.

@ThomKa sehe ich für mich keinen Mehrwert. Die WLAN Verbindung steht stabil. Daher brauche ich keine kabelgebundene Verbindung. Dieses OCPP kenne ich nicht, vermisse es daher auch nicht ;-) Hast du zwischenzeitlich die ersten kw/h an Überschuss ins Auto geladen?

@ThomKa hab mir das nochmal angeschaut, soweit ich mich erinnere hattest du deine Logik zum Überschuss laden dahingehend aufgebaut, dass du den Wert der Netzeinspeisung als Wert Überschuss neu gesetzt hast. Dadurch, dass die volle Einspeisung zum Laden abgegriffen wird, ist die Einspeisung bei der nächsten Abfrage 0. Dies setzt deine Logik als neuen Wert Überschuss neu. Daraus ergibt sich, dass die Ladung beendet wird. Dieses Spiel wiederholt sich. Ich habe es dahin gehend gelöst, dass ich den Wert für Überschuss neu aus der Subtraktion von der aktuellen Ladeleistung der Wallbox und dem Wert der Einspeisung ins Netz ermittel. Subtraktion aus dem Grund, weil mir der Fronius für die Einspeisung einen negativen Wert auswirft. Mit dieser Logic schöpfe ich die komplette Einspeisung ab und reduziere die Ladeleistung für den Fall, dass ein Netzbezug erfolgt. Klappt grundsätzlich ganz gut. @mattsches mit welchen Werten für die Verzögerung der Über/Unterschreitung der Schwelle und Dauer des aktuelle Zustandes arbeitest du erfolgreich? Habe derzeit 300sec für Unterschreitung, 60 sec für Überschreitung. 300sec für Mindestdauer und 30sec Pause für Umschaltung. Hatte heute bei wolkigem Wetter viele Schaltungen aber zugleich auch viel "Verlust" weil die sonnigen Abschnitte nicht abgegriffen wurden.

@ThomKa schau ich heute Abend noch mal. Hatten wir aber via pn drüber kommuniziert.

@ThomKa über MQTT von einem raspberry auf dem iobroker läuft.

Evcc hatte ich vorher in Nutzung. Schon ein sehr geniales Stück Technik. Nur leider unterstützt es die phasenumschaltung nicht, daher liegt der raspberry jetzt auf Eis. 😎

Das passt doch dann schon ganz gut. Wenn die MQTT Verbindung failed wird der letzte Wert welcher empfangen wurde von der warp weiter benutzt. Dies kann dazu führen, dass mit mehr Power geladen wird, als tatsächlich noch vom Dach kommt. Entsprechend wird das Fehl durch Hausspeicher oder netzbezug ausgeglichen. Alternative wäre, wenn die warp bei fehlender MQTT Verbindung die Ladung nach Zeitablauf x unterbricht. Gefiehle mir aber nicht so gut, da dies die schaltzahl erhöht. Besser wäre, wenn die Verbindung stabilisiert wird. 😜 Mir fehlt dafür aber das know how. Ggf hat @mattsches dafür einen Lösungsansatz?!

Grüße Tom, Respekt für deine Geduld! Die rote Leuchte kenne ich nur, wenn der Stecker eingesteckt wird, nach 60sec noch kein Ladevorgang seitens der Box gestartet wurde, weil zu wenig Überschuss vorhanden. Wenn die Parameter zum überschussladen erreicht sind und die Box den Ladevorgang beginnt, geht der enyaq auf grün und nimmt den Strom ab. Was mich wundert, dass du scheinbar manuell die phasenzahl schaltest?! Hab ich noch nicht gemacht oder probiert. Noch ein Tipp, lass den Phasenumschalter nur zwischen 1 und 3 Phasen schalten! Mit zwei kann der enyaq Probleme bekommen. Abbrüche der MQTT Verbindung habe ich auch beständig. Baut sich aber auch immer wieder auf, so dass ggf mal etwas Strom aus dem Hausakku gezogen wird, falls die pv Produktion nicht mehr zur Ladestärke passt. Daher aktuell kein dramatisches Problem. Schau mal wie es sich bei dir anlässt wenn das Auto da ist. Überschuss ist aktuell ja ausreichend vorhanden, um etwas zu experimentieren ...