go-echarger als mqtt-device - meine Konfig

[Muschelpuster]

Ja, ich bin mit dem MQTT vom go-e auch gerade überhaupt nicht glücklich. Nun hat meine Büchse genug Power um das zu verdauen, aber irgendwann ist auch Ende und ich will die Power nicht für so grottige umgesetzte MQTT-Schnittstellen verschwenden.
Zu allem Übel gibt es ja noch die Readings 0-X die mehrfach belegt sind und so munter ihre Werte wechseln. Wobei das ist sicher ein Thema für die MQTT-Experten hier, denn das sind Inhalte von Arrays. Die müssten also eher als Arrayname.X angelegt werden und nicht stumpf als X.
Ich tendiere gerade stark zum JsonMod um die Daten via HTTP-API V2 zu lesen und zu visualisieren. Das Lesen mit dem Anlegen aller Werte als Readings klappt einwandfrei, auch bei den Arrays. Nun mangelt es auch nur an der Zeit und der Erfahrung das vernünftig zu visualisieren. Ich kann auch schon die Stromstärke über die API einstellen, es ist aber mal wieder ein steiniger Weg für mich.

Niels

[Beta-User]

Es gäbe da auch noch (zu finalisierenden) myUtils-Code, um die Event-Flut ggf. einzudämmen...

[Sany]

um die Event-Flut ggf. einzudämmen...

go-e sollte seine Firmware so schreiben, dass diese Flut erst gar nicht entsteht. Es geht hier um eine "Steckdose" für ein e-Auto, da wird kein sicherheitskritisches Atomkraftwerk überwacht.

Also Meldungen bei Änderungen, zyklisch (alle x minuten?) ein paar Statusmeldugen, das reicht völlig. Und eben noch die Gegenrichtung um der Box Befehle zu schicken.
Das scheint aber alles noch "in Entwicklung" zu sein, evtl. kann man da ja Hinweise geben.

[Beta-User]

...bin da völlig bei dir und kann auch nicht nachvollziehen, was der Autor sich dabei denkt...

[Sany]

@Niels:
hast Du schon mal go-e-IP/api/status aufgerufen, bei eingeschalteter API v2?
Schon da wird man erschlagen mit allen möglichen Daten. Sogar eine Liste der umliegenden WLAN-Netze.
Ich hab go-e mal über mein Experiment heute früh informiert und darum gebeten, die MQTT Datenflut auf sinnvolle Daten und Intervalle zu "verkleinern".

Bin mal gespannt.

[Muschelpuster]

hast Du schon mal go-e-IP/api/status aufgerufen, bei eingeschalteter API v2?

Ja, da habe ich mich mal etwas umgeschaut. Das habe ich mit dem JsonMod gemacht, dann ist das nicht mehr so unübersichtlich

Um diesen Thread nicht zu torpedieren habe ich die Ergebnisse meiner Tätigkeit mal in einen eigenen Thread gepackt: https://forum.fhem.de/index.php/topic,122285.0.html

Niels

[Beta-User]

Es gäbe da auch noch (zu finalisierenden) myUtils-Code, um die Event-Flut ggf. einzudämmen...

Fyi: Aus gegebenem Anlass habe ich dann mal die letzte Version der myUtils-File aus https://forum.fhem.de/index.php/topic,115620.msg1099706.html#msg1099706 ins svn/contrib eingecheckt und ein (hoffentlich) dazu passendes attrTemplate "neu" (unter Berücksichtigung des zusätzlichen Setters, den @PeMue in https://forum.fhem.de/index.php/topic,122285.msg1169116.html#msg1169116 angedeutet hat.

Stark anzunehmen, dass da noch ein paar Enden (setter/Readings) nicht so recht zusammenpassen...
Kurz: das ist alles noch etwas experimentell, und falls jemand was zur Verbesserung beitragen kann/mag: gerne!

[isy]

Moin,
da ich jetzt auch eine GO-E habe hänge ich mich mal hier dran, auch wenn länger nichts geschrieben wurde.
Die Box feuert jede Sekunde, ich habe daher die Einbindung über mqtt erstmal deaktiviert.
VG Helmut

[Prof. Dr. Peter Henning]

Es gibt eine neue Unterkategorie zu Wallboxen, "FHEM - Energiemanagement und Energieerzeugung" -> Wallboxen.

Und ja: Nach dem ersten Test meiner neuen go-e mit MQTT habe ich das schnellstens wieder deaktiviert - irrwitzige Datenflut, die kein Mensch braucht.

LG

pah

[Beta-User]

Und ja: Nach dem ersten Test meiner neuen go-e mit MQTT habe ich das schnellstens wieder deaktiviert - irrwitzige Datenflut, die kein Mensch braucht.

Habe zwar keine solche Box, aber dass das kompletter Unfug ist, wie das da umgesetzt ist, hatten wir ja schon direkt zu Beginn hier mal angesprochen.

Falls du - als "qualifizierter Kunde" - mal irgendwann Zeit findest, dich beim Hersteller darüber zu beschweren wäre das klasse!

[isy]

Ich hatte den Support vor 1 1/2 Jahren mal diesbezüglich angeschrieben und man hat auch schnell reagiert.
Man wolle den Datenverkehr über MQTT nicht einschränken.

Nachtrag. Ich hatte nach einem Parameter für Sende-Intervalle gefagt und nach Filterung auf bestimmte Felder.

[Prof. Dr. Peter Henning]

Ich habe so den Verdacht, dass das irgendwie mit deren eigener Hardwarebox zur Überschussladung in Zusammenhang steht.

LG

pah

[Beta-User]

Ich habe so den Verdacht, dass das irgendwie mit deren eigener Hardwarebox zur Überschussladung in Zusammenhang steht.

LG

pah

Meinst du? Braucht die alle Sekunde die SSID?!?

Glaube eher, da hat man "den Lehrling" mal machen lassen, ohne im genauere Anweisungen zu geben, dann gesehen, dass es funktioniert und es dabei belassen... Jedenfalls glaube ich nicht, dass sich da irgendjemand wirklich einen Kopf gemacht hat (außer vielleicht, wie man das Problem löst, irgendwie schnell diese Art Schnittstelle bereitzustellen).

[Guzzi-Charlie]

Hallo zusammen,

nachdem ich nun einen zweiten go-eCharger installiert habe wollte ich diesen genauso wie den Ersten per MQTT in FHEM integrieren. Leider funktioniert das Ganze überhaupt nicht. Obwohl ich in den erweiterten Einstellungen des go-eChargers "MQTT API aktivieren" eingeschaltet UND IP/Port meines RasPi eingetragen habe liefert der Charger keine Daten/hat er nicht (wie üblich) automatisch ein MQTT-Device angelegt.

Ich habe nun schon alle möglichen Einstellungen im Einstellungsmenü des go-eChargers ausprobiert (inkl. die "alte" v1-API aktiviert, aber Alles ohne Erfolg.

• Der alte go-eCharger ist eine HW-Version V2
• Der neue go-eCharger ist ein "Gemini" HW-Version V4

Aufgefallen ist mir der etwas unterschiedliche Aufbau der MQTT-Parametrierung in den Einstellungen:

• beim V2
  ==> MQTT-Server: "192.xxx.xxx.xxx"
  ==> Port: "1883"
  ==> Benutzername: ist leer
  ==> Passwort: ist leer
• beim V4
  ==> alles in einer Zeile "MQTT://Benutzer:PW@192.xxx.xxx.xxx:1883"
  ==> im FHEM MQTT2-Server ist keine authentification eingerichtet, deshalb ist für Benutzer/PW nichts eingetragen. Eingetragen habe ich "192.xxx.xxx.xxx:1883"
  ==> aber das "MQTT://" läßt sich nicht entfernen. Nach dem Speichern ist es trotz Löschung wieder da.

Kann das evtl. die Ursache sein?

Wenn Jemand eine Idee hat was das Problem ist bzw. wie man es lösen kann, dann immer her damit.

DANKE

[Prof. Dr. Peter Henning]

Kann ich nicht nachvollziehen. Ich habe auch einen V4, mit der Beta-Firmware 56.1. Die Verbindung über MQTT hat auf Anhieb funktioniert - ich habe sie wegen der gigantischen Datenflut aber gleich wieder deaktiviert. Und zwar mit genau den gleichen Einträgen.

Kann das evtl. die Ursache sein?

Nein, definitiv nicht. Der Präfix mqtt:// definiert nur das Protokoll, das hier gefahren wird (eben MQTT).

LG

pah