Go-eCharger via Cloud (REST-API) anbinden

BerndArnold · 19 Juli 2020, 12:31:04

Hallo zusammen,
an anderen Stellen gibt es ja schon MQTT-Module für den go-eCharger oder das 46_goECharger [1]. Ich habe hier allerdings die Situation, dass ich von Fhem aus nicht direkt mit dem go-eCharger kommunizieren kann. Ich habe mich deshalb für die REST-API Schnittstelle entschieden, um die Daten auszulesen.
Habe schon gesucht, aber anscheinend gibt es da kein Modul für genau diesen Zweck. Der Hersteller hat zum Glück die API sehr gut dokumentiert.

Zum Definieren kopiert man die Moduldatei zu den anderen und legt dann das Device so an:
define DEVICENAME GoEChargerCloud TOKEN

TOKEN findet ihr auf dieser Chipkarte, die beim go-eCharger mit dabei war.

Das Modul ist sehr rudimentär. Refresh-Intervall ist fix auf 300 Sekunden eingestellt.

Das "set" geht bis jetzt leider gar nicht. Da möchte ich z. B. mal darüber steuern, wenn genug PV-Strom vom Dach kommt, dass das Ladegerät automatisch freigeschaltet wird bzw. abgeschaltet wird, wenn Wolken am Himmel sind. Manuell geht das so: curl 'https://api.go-e.co/api?token=XXXXXXXXX&payload=alw=0' schaltet das automatische Laden ab. Das möchte ich mal als set DEVICE allow_charging false integrieren.

Meine Modulkenntnisse sind sehr eingerostet, habe ich gemerkt. Bitte haut es mir nicht zu sehr um die Ohren

Das Auswählen von verschiedenen set-Einstellungen ist nicht möglich. Fehlerhandling fehlt wohl auch. Im Screenshot seht ihr, welche Werte schon ausgelesen werden: Ampere-Zahl, Datum/Zeit laut dem eCharger, die bereits geladene Energie und die aktuelle Leistung, die über alle 3 Phasen geht und der Ladestatus vom Auto.
Mein "großes Vorbild" ist da das 76_SMAPortal.pm von DS_Starter (Grüße an dieser Stelle

), weil es die Credentials versteckt (bei meinem Modul sieht man den Token), ne Auswahl der verschiedenen set-Möglichkeiten bietet, die aktuelle Version unter FVERSION zeigt und auch nen ordentlichen Hilfetext hat.

Im Moment kann ich leider da nicht allzuviel dran machen, aber ich wollte jetzt den ersten Schritt machen und es mal mit euch teilen. Gebt mir gerne Feedback hier. Natürlich interessiert es mich auch, ob ihr da überhaupt Verwendung/Interesse hättet.

Update 02.08.2020: das neuere Modul findet ihr im Thread https://forum.fhem.de/index.php/topic,112980.msg1075840.html#msg1075840.

Viele Grüße
Bernd

[1] https://forum.fhem.de/index.php/topic,110282.0.html

DS_Starter · 19 Juli 2020, 14:39:02

Hallo Bernd,

ich habe keinen go-eCharger und kann es nicht ausprobieren.
Aber ein Tipp von mir. Da du eine API hast, mit einem Token arbeitest und nicht auf krude Login-Mechanismen setzen musst, werfe den BlockingCall raus und nimm statt dessen die HttpUtils (Funktion HttpUtils_NonblockingGet).

Das eignet sich viel besser für deinen Einsatz, ist genauso nicht blockierend wie BlockingCall, hat aber nicht dessen Nachteile (Speicherduplizierung).
Als Vorbild kann dir dann mein SSCam dienen (z.B. die Funktion camOp).
Zur Verwendung von HttpUtils gibt es auch einen guten Wiki-Eintrag.

Du stehst noch ganz am Anfang und kannst noch schnell den Umbau weg von BlockingCall vornehmen.

Ansonsten will gut Ding Weile haben. Ich sitze auch tage/wochenlang an einem Modul um hinterher festzustellen wie es besser zu machen wäre und baue alles wieder anders.

LG,
Heiko

BerndArnold · 02 August 2020, 16:26:24

Hallo,

danke für dein Feedback, Heiko. Ich war die letzten Wochen etwas außer Gefecht gesetzt, deshalb konnte ich da nicht weiter dran werkeln.

Ich habe mein Modul jetzt komplett verworfen und das /usr/local/fhem/FHEM/46_GoECharger.pm von Lutz (Danke @LR66) hergenommen und soweit umgebaut, dass es läuft. Vorteil: sein Modul ist wesentlich schöner aufgebaut als meines, Lutz hat schon viel vorgearbeitet und ich konnte es mit minimalen Anpassungen gegen die Cloud-API umbauen.

Das set ... geht jetzt auch

Leider weiß ich nicht, wie ich die PM-Datei von meinem ersten Beitrag wegbekomme...

Im Anhang hier ist jetzt das aktuelle. Bitte beachten: das hat jetzt den gleichen Namen wie das von Lutz. Ist unschön, ich weiß. Muss ich noch ändern

Das Define ist nun so:

Code Auswählen

define DEVICENAME GoECharger TOKEN

(Originalmodul siehe Anhang in https://forum.fhem.de/index.php/topic,110282.0.html)

Viele Grüße
Bernd

LR66 · 02 August 2020, 16:53:50

Ich musste erstmal grübeln, was den Unterschied ausmacht: Du hast keinen direkten LAN-/IP-Zugang zu Deinem Charger? D.h. er hängt in einem fremden LAN? Interessanter Fall und Lösung... damit dann wohl sogar die Universellere?
Schön, wenn mein LAN-/-IP-gebundenes Modul ein wenig beitragen konnte.
Viele Fhem User mit go-ECharger scheint es nicht zu geben oder die meisten nutzen die gute App dazu (was aber nicht so gut steuern und loggen lässt).
Viele Grüße,
Lutz

BerndArnold · 02 August 2020, 16:58:36

Hallo Lutz,
vielen Dank für deine Antwort

Ja genau, das ist der Unterschied. Sorry, hatte ich jetzt nicht mehr explizit erwähnt. Mein Fhem kann nicht direkt mit dem go-eCharger kommunizieren, deshalb der Umweg über die Cloud.

Hm, universeller würde ich jetzt nicht sagen. Ich kann mir vorstellen, dass manche bewusst auf die Cloud verzichten und die direkte Anbindung bevorzugen.

Viele Grüße
Bernd

DS_Starter · 02 August 2020, 17:06:23

Hallo Bernd und Lutz,

das sieht wirklich schon gut aus, besonders die Verwendung von HttpUtils.
Habe noch einen Tipp.
Ihr verwendet (wie es bisher Standard ist/war) das main Package. Dann müsst ihr aufpassen dass Variablen nicht durch einen dummen Zufall überschrieben werden. Ich meine damit z.B. diese hier gleich am Anfang:

Code Auswählen


my %goevar;
my $reading_keys_json_allkeys='';
my $reading_keys_json_default='';
my $reading_keys_json_minimal='';
my $reading_keys_json;
my $maxamp=16;


my $icodef= ...

Um die Gefahr zu verringern setze auch "GoECharger_" vor jede Variable (z.B. $GoECharger_icodef) wie bei den subs oder noch besser ein eigenes Package verwenden, worauf hingearbeitet wird. Dann braucht man diese Prefixe nicht.

Ich bin selbst auch dabei alle meine Module auf ein eigenes Package umzustellen. Ist halt eine Menge Arbeit wenn das Modul alt/groß und gewachsen ist.
76_SMAPortal ist bereits auf Packages umgestellt (package FHEM::SMAPortal). Kannst du abgucken.

Grüße,
Heiko

BerndArnold · 02 August 2020, 17:18:35

Hallo Heiko,
vielen Dank auch für dein Feedback! Das mit dem "package FHEM::...) werde ich mal versuchen

Viele Grüße
Bernd

BerndArnold · 03 August 2020, 20:06:17

So sieht das ganze im FTUI visualisiert aus

Einmal der Status, wenn das Auto verbunden ist, aber über den eCharger die Ladung nicht aktiviert wurde.
Zweites Bild: Auto lädt
Drittes Bild: das gleiche, nur ein paar Sekunden später; inklusive Vergleich mit der App vom go eCharger.

satprofi · 18 Oktober 2020, 09:40:25

jetzt auch über MODBUS steuerbar

https://github.com/goecharger/go-eCharger-API-v1/blob/master/go-eCharger%20Modbus%20TCP%20API%20v1%20DE.md

BerndArnold · 18 Oktober 2020, 11:32:14

Danke für die Info, satprofi.

Habe auf deren Homepage geguckt, ob sie dazu einen Blogartikel haben, bin aber nicht fündig geworden. Das PDF wird nur auf der Download-Seite verlinkt.