PHP Modul zum Einbinden einer Go-eCharger Wallbox

[egonkernien]

Hy Coyote
Der ist mir nur zu teuer weil ich den als besseren steuerbaren Ladeziegel verwenden würde.
Wenn ich den im neuen Haus mit 22 kW verwenden würde sieht das schon anders aus…
Schönen Gruß
Egon

[Coyote]

Kleine Anmerkung:
Ich hatte 2 GO-E mit je 22kW genehmigt, bin dann aber auf die 11kW gewechselt (weil ich die V3 haben wollte und die 11kW gerade gefördert wurden ).
Ich habe die 22kW nie vermisst, weil
a) meine PV keine 11kW Überschuss liefert und
b) es eh kaum Fahrzeuge gibt, die mehr als 11 kW abnehmen (ja, Tesla, Zoe, …)

Ich denke auch, das du evtl. mit 22kW bei der Genehmigung Probleme kriegen könntest.
Aus diesem Grund: 22kW Verkabelung vorsehen, aber ansonsten reichen 11kW locker aus.

[flip98]

Hallo, zuerst einmal vielen Dank für das tolle Modul!
Ich habe es seit ein paar Wochen im Einsatz, das Überschußladen hat nach der Einrichtung auch direkt perfekt funktioniert.

Jetzt habe ich leider das Problem, dass es nicht mehr funktioniert, der Aufruf von „GOeCharger_SetCurrentChargingWatt“ führt zu keiner Reaktion der Box. Ich bin mir nicht bewußt, etwas geändert zu haben.

Ich habe dann die Debug-Funktion aktiviert, dort erscheint der Eintrag:
„setCurrentChargingWattWithMinimumAmperage: Semaphore blocked processing“. Außerdem taucht im Symcon Statusprotokoll ungefähr einmal am Tag folgender Eintrag auf:
„27.10.2023, 12:23:58 | TimerPool | go-eCharger (GOeChargerTimer_UpdateTimer): Warten auf Skriptresultat fehlgeschlagen. Bitte den Spezialschalter ‚ThreadCount‘ erhöhen, um das Problem zu umgehen!“

Hat das schonmal jemand gehabt und weiß, was ich tun kann? Threadcount steht auf 50, das müsste doch reichen?

Vielen Dank für Hinweise!

[Coyote]

Sicher, das sich nichts geändert hat?

IPS Version? Go-E Charger Firmware aktualisiert?

[flip98]

nein, alles unverändert. Ich habe aber inzwischen noch ein bisschen gesucht und im ThreadMonitor einen Thread gefunden, der seit mehreren Tagen angescheinend hing (mein Überschuss-Steuerungs-Skript). Dann habe ich den Symcon-Prozess abgeschossen, normal stoppen ging leider nicht mehr, und jetzt läuft wieder alles wie vorher.
Komisch… sorry für den Fehlalarm und vielen Dank für die schnelle Rückmeldung!

Kann die o.g. TimerPool-Fehlermeldung damit was zu tun haben? Ist die „normal“?

[da8ter]

Hallo Zusammen,

ich erstelle gerade eine Status HTMLBox für meinen go-e Charger für die neue Visu. Die würde ich hier natürlich veröffentlichen wenn fertig. Gebt mir gerne bei Interesse Feedback was ihr da noch abgebildet haben möchtet oder Verbesserungsvorschläge…

Version 0.1 ist verfügbar und kann gerne getestet werden
Feedback bitte hier geben:

HTMLBox Wallbox (Go-E Charger) BETA

Hallo zusammen, nachfolgend eine erste Testversion der HTMLBox Kachel für den go-e Charger (Kann auch für andere Wallboxen eingesetzt werden) Seid bitte gnädig mit mir, für mich sind das Übungen um meine Programmierskills etwas aufzubessern… [wallbox_kachel] Version 0.1 Punkt 1: Anleitung im Script lesen! Die Box läuft über den Websocket und die RPC-Api. Die Daten werden also ohne Reload nahezu in Echtzeit aktualisiert. Das Bild ist animiert. Für den go-e Charger werden Bilder mitgeliefert…

Viele Grüße
Stephan

[Schuggi]

Hallo Coyote,
seit ein parr Wochen verwende ich das Modul.
Heute sind mir ein paar Threads aufgefallen, die schon länger hängen.
Daraufhin hab ich mir genauer Infos zu den Threads ausgelesen.
Hier das Ergebnis:

seit 28.792777777778h aktiv
Array
(
    [ThreadID] => 24
    [ExecuteCount] => 29015
    [ExecutionMin] => 0
    [ExecutionAvg] => 0
    [ExecutionMax] => 119188
    [StartTime] => 1699447363
    [Sender] => PHPModule
    [FilePath] => Timer: GOeChargerTimer_UpdateTimer
    [ScriptID] => 0
    [PeakMemoryUsage] => 4194304
    [MemoryCleanups] => 20
)

seit 45.849444444444h aktiv
Array
(
    [ThreadID] => 25
    [ExecuteCount] => 9700
    [ExecutionMin] => 0
    [ExecutionAvg] => 0
    [ExecutionMax] => 29397
    [StartTime] => 1699385959
    [Sender] => PHPModule
    [FilePath] => Timer: GOeChargerTimer_UpdateTimer
    [ScriptID] => 0
    [PeakMemoryUsage] => 6291456
    [MemoryCleanups] => 4
)

seit 39.523055555556h aktiv
Array
(
    [ThreadID] => 77
    [ExecuteCount] => 16775
    [ExecutionMin] => 0
    [ExecutionAvg] => 0
    [ExecutionMax] => 21051
    [StartTime] => 1699408734
    [Sender] => PHPModule
    [FilePath] => Timer: GOeChargerTimer_UpdateTimer
    [ScriptID] => 0
    [PeakMemoryUsage] => 4194304
    [MemoryCleanups] => 28
)

Die scheinen alle von deinem Modul zu kommen.
Kannst du dir das bitte einmal anschauen?

Gruß Schuggi

[Coyote]

Wo hast du die Threads gefunden? In der PHP Information?

Ich habe 2 GO-eCharger V3, welche ich alle 10 Sek. abrufe. Letzter Reboot meines Systems (IPS 6.2!!!) ist über eine Woche her und ich habe keinen hängenden Thread dort.

Der UpdateTimer ist der einzige Timer, den das Modul verwendet. Passen die Zeitstempel
1699385959 | Tue Nov 07 2023 19:39:19 GMT+0000
1699408734 | Wed Nov 08 2023 01:58:54 GMT+0000
1699447363 | Wed Nov 08 2023 12:42:43 GMT+0000
irgendwie zu bestimmten Ereignissen bzgl. deines Systems oder besser dem GO-eCharger (Ladestart/stop)?

[Schuggi]

Nachdem ich gesehen habe, das bei mir einige Threads schon länger (teils mehrere Tage) hängen, hab ich die Threadinfos ausgelesen und gesehen, das die alle von deinem Modul kommen. Mit der Zeit werden es immer mehr. Vor ein paar Tagen ist mein IPS auch hängengeblieben.
Das hatte ich in der Vergangenheit schon öfter.

So hab ich das ausgelesen:

PHP Informationen ohne Hinweise auf Skript

Führ mal folgenden Code aus. Dann bekommst du raus, woher das Problem kommt. <?php $threadList = IPS_GetScriptThreadList(); $threadUsed = 0; $ti = time(); foreach ($threadList as $t => $i) { $thread = IPS_GetScriptThread($i); if ($thread['StartTime'] == 0) { continue; } $threadUsed++; if(($ti-$thread['StartTime'])>60) { echo "\nseit ".(($ti-$thread['StartTime'])/3600)."h aktiv\n"; Print_R($thread); } }

Mein go-e (Gemini Flex) hab ich vor einer Woche das letzte mal verwendet.
Es gibt aber auch noch ein weiteres System (evcc) das auf den Go-e zugreift. (den Status liest)

[Coyote]

Interessant. Ich verwende UpdateTimer, welche das regelmäßige Abrufen steuern. Diese Timer werden nur verändert (also gestartet/Intervall geändert/gestoppt), wenn man die Einstellungen des Moduls verändert oder das Laden startet oder stoppt.
Warum es mehrere dieser Timer-Threads mit dem gleichen Timer Ident („GOeChargerTimer_UpdateTimer“) gibt, erklärt sich mir nicht

Das parallele Lesen des anderen Systems sollte eigentlich keine Auswirkungen haben.

Danke für das Skript. Bei mir gibt es zwar ca. 30 Threads, aber keiner, der zu einer Ausgabe (>60 sek.) führt.

Auf welcher IPS Version bist du? Und steht im Modul-DebugLog etwas Interessantes (z.B. bzgl. Semaphoren)?

[Schuggi]

Ich hab die aktuelle IPS Version. Ich hab gerade gesehen, das deine CURL-Aufrufe ohne Timeout ausgeführt werden. Eventuell ist das ja das Problem. Setzt man den nicht, so steht der auf Unendlich.

[flip98]

Ich habe das gleiche Problem, folgende Meldungen erzeugt der Integrity Check:

[Schuggi]

@flip98

„27.10.2023, 12:23:58 | TimerPool | go-eCharger (GOeChargerTimer_UpdateTimer): Warten auf Skriptresultat fehlgeschlagen. Bitte den Spezialschalter ‚ThreadCount‘ erhöhen, um das Problem zu

Das geht doch in die gleiche Richting!

[Nall-chan]

@Schuggi

Eventuell ist das ja das Problem. Setzt man den nicht, so steht der auf Unendlich.

Nicht nur eventuell… das IST das Problem
Gleiches Problem gab es auch bei anderen Modulen.
Michael

[Coyote]

Schaue ich mir morgen an und behebe es.

Was mich interessieren würde: Warum ist es bei mir in der 6.2 kein Problem ?

Glücklicher Einzelfall? Änderungen in >6.3?

[Nall-chan]

Wesentliche Änderung war die 6.0 als das Script Laufzeitlimit wegfiel.
Was es sonst noch sein kann, aber schwer nachzuvollziehen, ist die in PHP vorhandene CURL Umsetzung. Eventuell ist das Verhalten je nach PHP Version oder auch je nach dem zugrunde liegenden OS anders.
Michael

[Coyote]

Beta V2.2.1 des Moduls ist im Store (Curl Timeout)

Feedback willkommen

[flip98]

vielen Dank! Sieht bisher gut aus bei mir…

[Coyote]

V2.2.1 ist nun Stable (Beta geschlossen)

[whiggy]

Hallo,
ich bin derzeit am testen von SetCurrentChargingWatt und der Implementierung in den Energie Optimierer. Soweit klappt alles schon sehr gut. Jedoch verhält sich go-e am Ende einer Ladung für mich nicht nachvollziehbar. Das Script wird zyklisch aktualisiert.
Ausgangslage: Umsetzung von Sofortladen wenn die PV-Anlage keine Leistung abgibt. SOC soll Variante wird mit SOC ist Variante verglichen (SOC soll ist in Symcon vorgegeben und nicht vom Fahrzeug) und die Ladung wird ggf. gestartet.

Start der Ladung: Der Wert 11000 (11kw) wird an eine Variable übergeben. Diese holt sich SetCurrentChargingWatt über GetValue und stößt den Ladevorgang mit 11 Kw an. Das alles klappt ohne Probleme.
Ende der Ladung (SOC soll = SOC ist): Der Wert 0 (0kw) wird an eine Variable übergeben. Diese holt sich SetCurrentChargingWatt über GetValue und stoppt den Ladevorgang.

Nun passiert folgendes: Der Ladevorgang wird gestoppt. Nach einigen Sekunden fängt go-e für ca. eine Minute an einphasig zu laden. Im Anschluss wird der Ladevorgang endgültig gestoppt. Ich frage mich, wie dieses Verhalten zustande kommt. SetCurrentChargingWatt ist definitiv „0“