go-echarger als mqtt-device - meine Konfig

[Guzzi-Charlie]

Guten Morgen,

vielen Dank für die schnelle Antwort.

Ich habe Gestern Abend noch gesehen, daß der go-eCharger wohl tatsächlich doch eine Verbindung zu FHEM aufgebaut hatte. Es wurde nämlich ein FHEM-Server angelegt der auch im Status "connected" war. Das war mir erst aufgefallen als ich auf der Suche war warum mein FHEM auf einmal ziemlich am "Anschlag" lief. Es wurde nur kein Device angelegt. Das hatte ich zuvor schon versuchsweise als Kopie meines V2 Chargers manuell angelegt. Das hatte aber auch nicht funktioniert. Daraufhin habe ich MQTT beim V4 wieder abgeschaltet und das manuell angelegte Device gelöscht.

Heute Morgen habe ich das Ganze nochmal nachvollzogen und das Gleiche Verhalten bestätigt: Ein FHEM MQTT-Server wurde angelegt und FHEM offensichtlich wieder mit Daten überflutet, aber wieder kein Device automatisch angelegt. Danach habe ich MQTT des V4 wieder abgeschaltet.

Beim V2 habe ich die Datenmenge auf ca. 10 relevante Daten per "event-on-change-reading" eingeschränkt. Das ging aber beim V4 nicht weil es ja kein Device gab.

Über welche Schnittstelle/API haben Sie denn den go-eCharger eingebunden?

[Beta-User]

Guten Morgen,

vielen Dank für die schnelle Antwort.

Ich habe Gestern Abend noch gesehen, daß der go-eCharger wohl tatsächlich doch eine Verbindung zu FHEM aufgebaut hatte. Es wurde nämlich ein FHEM-Server angelegt der auch im Status "connected" war. Das war mir erst aufgefallen als ich auf der Suche war warum mein FHEM auf einmal ziemlich am "Anschlag" lief. Es wurde nur kein Device angelegt. Das hatte ich zuvor schon versuchsweise als Kopie meines V2 Chargers manuell angelegt. Das hatte aber auch nicht funktioniert. Daraufhin habe ich MQTT beim V4 wieder abgeschaltet und das manuell angelegte Device gelöscht.

Heute Morgen habe ich das Ganze nochmal nachvollzogen und das Gleiche Verhalten bestätigt: Ein FHEM MQTT-Server wurde angelegt und FHEM offensichtlich wieder mit Daten überflutet, aber wieder kein Device automatisch angelegt. Danach habe ich MQTT des V4 wieder abgeschaltet.

Beim V2 habe ich die Datenmenge auf ca. 10 relevante Daten per "event-on-change-reading" eingeschränkt. Das ging aber beim V4 nicht weil es ja kein Device gab.

Über welche Schnittstelle/API haben Sie denn den go-eCharger eingebunden?

Jeder der charger hat ein eigenes Prefix? (Also unterschiedliche topics?

Ansonsten bitte einfach beim Hersteller wegen der besch.... Schnittstelle beschweren!

[Prof. Dr. Peter Henning]

Ich habe das über HTTPMOD angebunden. Geht hervorragend und ist viel besser steuerbar:

https://forum.fhem.de/index.php?topic=136856.0

Der finale Code für das HTTPMOD-Device ist dort noch ein wenig verstreut, weil ich derzeit noch etwas experimentieren muss (WallBox habe ich, Auto noch nicht).

Beim V2 habe ich die Datenmenge auf ca. 10 relevante Daten per "event-on-change-reading" eingeschränkt. 

Das ist aber in die Tasche gelogen, weil die Daten natürlich trotzdem beim MQTT-Server ankommen und verarbeitet werden. Außerdem das WLAN ziemlich stark belasten.

Ansonsten bitte einfach beim Hersteller wegen der besch.... Schnittstelle beschweren!

Nutzt nichts, ist in anderen Foren schon mehrfach gemacht worden. Der Hersteller beharrt darauf, MQTT-Daten im Sekundentakt zu versenden. Die steuern offenbar auf eine komplexe Infrastruktur mit mehreren Wallboxen, Speichern und Erzeugern zu. Und wollen natürlich ihren eigenen "Controller" vermarkten.

LG

pah

P.S.: Dieser Thread sollte ebenfalls in die neue Kategorie "Wallboxen" verschoben werden.

[Beta-User]

Der Hersteller beharrt darauf, MQTT-Daten im Sekundentakt zu versenden. Die steuern offenbar auf eine komplexe Infrastruktur mit mehreren Wallboxen, Speichern und Erzeugern zu. Und wollen natürlich ihren eigenen "Controller" vermarkten.

So bescheuert wie das umgesetzt ist, wird das m.E. auf diese Weise  nicht klappen... Hoffen wir, dass die das auch noch merken und die verantwortliche Person ersetzen.

[Guzzi-Charlie]

Jeder der charger hat ein eigenes Prefix? (Also unterschiedliche topics?

Ja, haben einen unterschiedlichen Prefix

Die Eventflut habe ich ja bei meinem V2 go-eCharger mittels "event-on-change-reading" drastisch eingeschränkt, aber trotzdem belastet die Flut der ankommenden Daten doch wahrscheinlich den RasPi erheblich, zumal ich ja noch ca. 110 weitere MQTT-Devices, sowie nochmal ca. genauso viele andere Devices (Modbus, EC3000, IEC1107, HmIP, AVM-DECT, E-Autos, Hausspeicher, Tibber, etc.) habe die Daten liefern. Das treibt meinen RasPi 4 schon ganz schön an seine Grenzen.

Ich werde es also mal mit alternativen Wegen versuchen.

Danke nochmal für die schnellen Antworten.

[Guzzi-Charlie]

So, ich habe den neuen go-eCharger (Gemini) nun auch über HTTPMOD eingebunden. Funktioniert auf den ersten Blick schon so wie es soll UND verursacht keine Datenflut. Das eigentlich schöne an MQTT, daß man normalerweise für die Einbindung nichts tun muß hat ja diesmal mit dem Gemini nicht funktioniert, warum auch immer. Mit dem go-eController hat es es allerdings auf Anhieb funktioniert diesen per MQTT mit FHEM zu verbinden.

In Anbetracht der Tatsache der horrenden Datenflut (von dann jetzt drei go-e Geräten) habe ich mich aber entschieden den go-eController ebenfalls per HTTPMOD einzubinden. Das werde ich die nächsten Tage angehen. Dazu schreibe ich dann im Thema https://forum.fhem.de/index.php?topic=136856.0 etwas. Auch meinen alten V2 werde ich wohl auf HTTPMOD oder das alte fhem-Modul umstellen um noch etwas mehr Last von meinem RasPi zu nehmen.

Da (oder vielleicht später auch in einem separaten Thema) werde ich dann auch etwas zu den Themen automatisches Überschußladen, V2H, etc. schreiben.