Easee Home (Laderoboter / Wallbox) anbinden

[CGR]

Hallo,

heute hat die Easee-Cloud Schwierigkeiten. Offenbar führt das zu Problemen mit dem Modul, denn mein FHEM stürzte mit schöner Regelmäßigkeit alle 60 Sekunden ab, bis ich das EaseeCloud-Device gelöscht habe.

Freundlicherweise hat FHEM folgende Fehlermeldungen notiert:

Code Auswählen Erweitern


2022.10.30 12:56:12 1: PERL WARNING: "my" variable @a masks earlier declaration in same scope at ./FHEM/98_EaseeWallbox.pm line 1016, <$fh> line 490.
2022.10.30 12:56:12 3: EaseeWallbox_Define myWallbox: called
2022.10.30 12:56:13 2: EaseeWallbox_Define myWallbox: Starting timer with interval 60
2022.10.30 12:56:26 1: PERL WARNING: Use of uninitialized value $retVal in concatenation (.) or string at ./FHEM/98_EaseeWallbox.pm line 246.
2022.10.30 12:56:26 1: PERL WARNING: Use of uninitialized value $number in numeric eq (==) at ./FHEM/98_EaseeWallbox.pm line 1312.
Your datetime does not match your pattern. at ./FHEM/98_EaseeWallbox.pm line 1304.


Vielleicht hilft das weiter, um für zukünftige Probleme mit der Easee-Cloud vorzusorgen?

Danke und viele Grüße
Christian

Hallo nochmal,

falls außer mir noch jemand dieses Modul benutzt und es ebenfalls immer für einen FHEM-Absturz sorgt: bei mir war die Absturzursache die Zeile, die die Fehlermeldung

Code Auswählen Erweitern


Your datetime does not match your pattern. at ./FHEM/98_EaseeWallbox.pm line 1304.


hervorgerufen hat.
Es läuft nun wieder, nachdem ich in Zeile 1302 von 98_EaseeWallbox.pm das "%z" am Ende des Patterns gelöscht habe, so dass die Zeile nun lautet:

Code Auswählen Erweitern


pattern  => '%Y-%m-%dT%H:%M:%S'


Vielleicht hilft es jemandem.

Viele Grüße
Christian

[SimonHipp]

Ich habe das Problem auch, sobald das Modul eingebunden ist, steht FHEM komplett und staret alle paar Minuten neu.
Hat hierfür jemand bereits eine Lösung, auch per belegt 100% CPU-Last.

Danke und Grüße

[SimonHipp]

Nach der oben genannten Korrektur des Moduls, hat sich jetzt mein FHEM soweit beruhigt, jedoch nun immer der folgende Fehler:

Code Auswählen Erweitern

Error on EaseeWallbox_WriteToCloudAPI. Missing charger_id. Please ensure basic data is available.

Grüße
Simon

[CGR]

Das Reading ,,charger_id" existiert aber?

[SimonHipp]

Das Reading ,,charger_id" existiert aber?

Jep, das ist da enthält auch einen Wert.
Das mit den 100% Auslastung hing nicht am Modul, sondern an einem Update vom Ubuntu, ist nun wieder wech.
Danke!

[Sirel]

Hallo zusammen,
seit ich das Modul bei mir installiert habbe, startet sich der PI regelmäßig neu.

Im Log erhalte ich folgende Fehlermeldungen:

Code Auswählen Erweitern


022.12.18 23:19:00 1: PERL WARNING: Use of uninitialized value $retVal in concatenation (.) or string at ./FHEM/98_EaseeWallbox.pm line 246.
2022.12.18 23:19:01 1: PERL WARNING: Use of uninitialized value $number in numeric eq (==) at ./FHEM/98_EaseeWallbox.pm line 1312.


davor hatte ich noch diesen Fehler:

Code Auswählen Erweitern

2022.12.18 23:18:52 1: PERL WARNING: "my" variable @a masks earlier declaration in same scope at ./FHEM/98_EaseeWallbox.pm line 1016, <$fh> line 78.

Ich habe beide Varianten (mit und ohne Seriennummer) probiert, bei haben das gleiche Fehlerbild.

Kann jemand damit etwas anfangen und mir sagen, wie ich das beheben kann?

Vielen Dank und Grüße,
Max

[CGR]

Hallo Max,

die Perl-Warnungen sind meiner Vermutung nach nicht weiter schlimm. Hast Du auch eine solche Meldung im Log?

Code Auswählen Erweitern

Your datetime does not match your pattern. at ./FHEM/98_EaseeWallbox.pm line 1304.

Dann hilft evtl. mein Hinweis weiter oben.

Viele Grüße
Christian

[strategy]

Hallo zusammen,

Sorry das ich so lange abgetaucht gewesen bin. Aber ich hatte sehr viel um die Ohren und wenn dann doch mal ein wenig Zeit da war gehört die der Familie

Scheinbar hat Easee die API ein wenig verändert und die Genauigkeit der gelieferten Uhrzeitwerte reduziert.
Stellt an sich kein Problem dar, denn beim Charger braucht wohl keiner die Millisekunden. Aber das hat tatsächlich ein Problem beim Parsen nach sich gezogen. Ich habe den Code jetzt entsprechend angepasst und damit sollte das Modul auch wieder normal funktionieren.

Zudem habe ich einige kleinere Fehler beim Logging mit einem hohen Verbose Level behoben, sodass jetzt auch wieder eine saubere Diagnose möglich sein sollte.

Auch habe ich nach einigen Feedback jetzt die Variante für mehrere Charger in den Standard überführt. Leider kann ich die Variante nicht testen, daher bin ich an der Stelle immer auf Eure Hilfe angewiesen.

@Christian:
Deine Anforderung steht als nächstes auf meinem Zettel...

@Europe:
Kannst du bitte die neue Version installieren und mir ggf. Auszüge mit verbose = 5 als PN schicken.
Ich kann das wie gesagt leider nicht nachstellen...

Gruß,
Matthias

[strategy]

@Christian:

Ich habe jetzt das Thema *Dynamic Current* eingebaut. Findet sich im Github Repository.
Über das normale Update (manuell oder zyklisch) wird jetzt zum einen ein neues Reading

Code Auswählen Erweitern

circuit_id angelegt und dann readings:

Code Auswählen Erweitern


dynamicCurrent_phase1
dynamicCurrent_phase2
dynamicCurrent_phase3


Alle Werte werden mit dem zyklischen Update aktualisiert...

Wenn du jetzt einen Wert setzen möchtest, kannst du das über set dynamicCurrent machen.
Dabei musst du die 3 Phasen setzen und kannst darüber hinaus die TTL setzen. TTL ist sonst 0.

Code Auswählen Erweitern


set myWallbox dynamicCurrent <phase1:double> <phase2:double> <phase3:double> (<TTL:integer>)
set myWallbox dynamicCurrent 5.5 8 20
set myWallbox dynamicCurrent 5.5 8 20 15


Ich habe damit gerade ein wenig rumgespielt, aber da mein Auto geladen war, war nicht viel mit ausprobieren.
Aber wenn du in der Mobile App auf die Ampere Anzeige klickst, wird dir das Dynamische Limit angezeigt. Und ich meine auch die Ladeleistung wurde angepasst, was aber bei jeder Änderung eine Unterbrechung des Ladevorgangs zur Folge hatte.

Ich freu mich auf deinen Bericht und alle Verbesserungsideen...

Gruß,
Matthias

[CGR]

Guten Morgen Matthias,

das hört sich super an, ein vorgezogenes Weihnachtsgeschenk! Danke!

Ich werde es bei nächster Gelegenheit ausprobieren und dann eine Rückmeldung geben. Es kann aber sein, dass das erst im neuen Jahr klappt.

Dankenochmal und viele Grüße
Christian

[CGR]

Hallo nochmal,
soweit ich das sehe, funktioniert es wie gewünscht. Danke, Matthias!
Jetzt brauche ich nur etwas mehr Sonne.
Viele Grüße
Christian

[strategy]

Die Sonne würde ich auch nehmen.
Produziert bei mir zwar keinen Strom aber ist gut fürs Gemüt

Ich habe eine Änderung an der Implementierung vorgenommen (Breaking Change) und hätte gerne ein Feedback von Euch.
Nachdem demnächst meine Preisgarantie auf Strom ausläuft beschäftige ich mich gerade intensiver (soweit man bei der limitierten Zeit von Intensiv sprechen kann) mit meinen Verbräuchen. Dazu gehört in nicht unerheblichem Maß das Auto.
Dazu baue ich derzeit eine Statistik aller messbaren Verbraucher und bin über eine spannende Erkenntnis gestolpert.

Und zwar gibt es in der aktuellen Implementierung des Moduls ja zwei Serien von Readings für die Verbrauchswerte:

Code Auswählen Erweitern

daily_xx_power
daily_xx_cost
monthly_xx_power
monthly_xx_cost die meiner Erwartung nach jeweils die Werte der des aktuellen sowie der vergangenen Tage bzw. Monate liefern sollten. Bei meinen bisherigen Prüfungen hatte ich auch immer das Gefühl die Werte würden stimmen, allerdings habe ich auch täglich geladen.
Bei genauem hinschauen ist mir nun folgendes aufgefallen:

• Die Werte sind nicht für alle vorangegangenen Tage. Wurde einen Tag nicht geladen, wird dieser in der API auch nicht zurückgegeben und die Anzeige in FHEM ist entsprechend verschoben. Habe ich z.B. gestern nicht geladen findet sich im Reading mit der -1 nicht etwa eine Null, sondern der Wert von vorgestern. Die Daten sind also nicht konsistent.
• Die aktuelle Session wird in der Statistik gar nicht berücksichtigt. Sprich wenn ich mein Auto angeschlossen und vollständig geladen habe, der Stecker aber noch im Fahrzeug steckt wird dieser komplette Verbrauch in den entsprechenden Readings nicht berücksichtigt. Es fehlt also etwas

[li]Beim ziehen des Steckers wird die Session beendet und der Verbrauch wird sichtbar. Allerdings wird der Verbrauch immer dem aktuellen Tag gutgeschrieben. Wenn ich also das Fahrzeug abends anstecke und über nacht lade, wird der komplette Verbrauch dem Folgetag zugeschlagen, auch wenn ein Großteil oder alles bereits am Vortag verbraucht worden ist. Das bringt meine Statistiken arg durcheinander, vor allem wenn man es mit dem eigenen Stromzähler abgleicht. Dieses Phänomen ist übrigens auch in der Easee App auf dem Iphone zu beobachten.
[/li][/list]

Daher habe ich jetzt die API auf eine andere Schnittstelle umgestellt. Diese basiert auf dem internen Stromzähler der Easee Box. Die Box meldet stündlich den aktuellen Zählerstand und auf der Basis lässt sich dann ein echter Verbrauch ermitteln. Aus meiner Sicht sind diese Daten deutlich genauer, bzw. passen besser zu meinem Anwendungsfall. Da die aktuelle Session erst nach abkoppeln des Fahrzeugs erfolgt sind die Daten meiner Meinung nach auch aktueller auch wenn nur stündlich eine Aktualisierung erfolgt.

Im GitHub habe ich im Branch session_history die Services ausgetauscht wie oben beschrieben. Ich teste diese Implementierung auch gerade selbst.
Würde mich freuen wenn Ihr mir ein Feedback zu der Idee geben würdet und auch ein Feedback zur Funktion.

Gruß,
Matthias

[Mitch]

Hallo,

kann man mit dem Modul auch eine Ladung frei geben und sperren?
Gibt es eine Doku dazu?

Vielen Dank!

[CGR]

Was meinst Du mit ,,eine Ladung"?

[Mitch]

Naja, halt frei schalten, wie z.B. mit dem RFID Chip. Autorisieren.

Ich mache das aktuell mit einem Go-eCharger so, dass wenn ich Zuhause bin, die Wallbox automatisch auf Laden geht, ich also immer das Auto anstecken kann.
Wenn ich nicht zu Hause bin, ist keine Ladung möglich.