go-echarger als mqtt-device - meine Konfig

[Waldmensch]

Wenn ich mir den GoE direkt auf der Konsole des mosquito subscribe, sehe ich alle 5 sekunden eine valide message. Das MQTT2 Device aktualisiert ebenfalls alle 5 Sekunden. Ist json2nameValue wine Standardfunktion, oder muss es ch die noch irgendwo in myUtiös einbauen?

[Beta-User]

Wenn ich mir den GoE direkt auf der Konsole des mosquito subscribe, sehe ich alle 5 sekunden eine valide message.

Der Weg Charger->mosquitto funktioniert also.

Das MQTT2 Device aktualisiert ebenfalls alle 5 Sekunden.

Den Satz verstehe ich nicht: Du meinst das alte MQTT_DEVICE, oder?

Ist json2nameValue wine Standardfunktion, oder muss es ch die noch irgendwo in myUtiös einbauen?

json2nameValue() kommt aus fhem.pl und sollte auf jeder halbwegs akutellen Installation vorhanden sein. FHEM ist aktuell, nehme ich an? (version MQTT2_.*)

Zeigst du bitte mal ein list von dem MQTT2_CLIENT?
(Dessen CID/ClientId (oä.) sollte unterschiedlich sein zu dem, was du bei 00_MQTT verwendest).

[LR66]

Bei mir ging es sofort mit MQTT2-Server in default-Einstellungen & das in der App vom goE so eingegeben. Dann erscheint der Charger automatisch als Device mit angehängter Nummer (durch das autocreate). Im Device kann man dann auch das template für go-ECharger wählen und versuchen ein dauerhaftes Device daraus zu machen (Entfernung Nummer in readinglist genaueres s. Hilfe & dann rename), die readings gem. Api sind implementiert. Der payload-Befehl amx (statt amp, ohne speichern im Flash) sollte ggf angepasst werden. Gelegentlich Fehlermeldungen

Code Auswählen Erweitern

: ERROR: Unhandled packet CONNACK, disconnecting m2s_192.168.0...
2021.05.04 21:39:32 1: ERROR: Unhandled packet PUBREL, disconnecting m2s_192.168.0.....
2021.05.04 21:45:12 1: ERROR: Unhandled packet CONNACK, disconnecting m2s_192.168.0....
2021.05.04 22:06:39 1: ERROR: Unhandled packet PUBREL, disconnecting m2s_192.168.0.....

[Beta-User]

Bei mir ging es sofort mit MQTT2-Server [...]

Das ist ja nett gemeint, aber in diesem Fall soll die Einbindung über einen externen Server laufen .

An sich sollte es da keine größeren Unterschiede geben, nur dass eben autocreate nicht (so einfach) genutzt werden kann, wenn diverses anderes Zeug über den Server geht...

[Waldmensch]

Die Alten MQTT versuche sind gelöscht, es gibt nur noch den MQTT2 Ansatz

Ich bekomme alle 5 Sekunden events von den Userreadings aus dem MQTT2 Device. Daher gehe ich davon aus, dass die Messagequeue GoE->Mosquito->MQTT2_CLIENT->MQTT2_DEVICE funktioniert

Code Auswählen Erweitern

2021.05.21 16:53:00 4 : MQTT2_DEVICE_Parse: MQTT2_goecharger go-eCharger/023547/status => { json2nameValue($EVENT) }
2021-05-21 16:53:00 MQTT2_DEVICE MQTT2_goecharger Stecker_Kabel: -1
2021-05-21 16:53:00 MQTT2_DEVICE MQTT2_goecharger temperature: 0
2021-05-21 16:53:00 MQTT2_DEVICE MQTT2_goecharger energy_total: 0
2021-05-21 16:53:00 MQTT2_DEVICE MQTT2_goecharger energy_akt: 0
2021.05.21 16:53:05 4 : MQTT2_DEVICE_Parse: MQTT2_goecharger go-eCharger/023547/status => { json2nameValue($EVENT) }
2021-05-21 16:53:05 MQTT2_DEVICE MQTT2_goecharger Stecker_Kabel: -1
2021-05-21 16:53:05 MQTT2_DEVICE MQTT2_goecharger temperature: 0
2021-05-21 16:53:05 MQTT2_DEVICE MQTT2_goecharger energy_total: 0
2021-05-21 16:53:05 MQTT2_DEVICE MQTT2_goecharger energy_akt: 0
2021.05.21 16:53:10 4 : MQTT2_DEVICE_Parse: MQTT2_goecharger go-eCharger/023547/status => { json2nameValue($EVENT) }
2021-05-21 16:53:10 MQTT2_DEVICE MQTT2_goecharger Stecker_Kabel: -1
2021-05-21 16:53:10 MQTT2_DEVICE MQTT2_goecharger temperature: 0
2021-05-21 16:53:10 MQTT2_DEVICE MQTT2_goecharger energy_total: 0
2021-05-21 16:53:10 MQTT2_DEVICE MQTT2_goecharger energy_akt: 0
2021.05.21 16:53:20 4 : MQTT2_DEVICE_Parse: MQTT2_goecharger go-eCharger/023547/status => { json2nameValue($EVENT) }
2021-05-21 16:53:20 MQTT2_DEVICE MQTT2_goecharger Stecker_Kabel: -1
2021-05-21 16:53:20 MQTT2_DEVICE MQTT2_goecharger temperature: 0
2021-05-21 16:53:20 MQTT2_DEVICE MQTT2_goecharger energy_total: 0
2021-05-21 16:53:20 MQTT2_DEVICE MQTT2_goecharger energy_akt: 0

List vom MQTT2 Client

Code Auswählen Erweitern

Internals:
   BUF       
   CFGFN     
   DEF        localhost:1883
   DeviceName localhost:1883
   FD         37
   FUUID      60a797f5-f33f-d6b4-504e-425be4fbd5f1e694
   NAME       GoEClient
   NR         639744
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   GoEClient
   lastMsgTime 1621608304.52933
   nextOpenDelay 5
   READINGS:
     2021-05-21 13:22:29   state           opened
Attributes:
   room       MQTT2_device

So ganz neu ist FHEM nicht, da ich mich bei Updates schon ein paar mal in die Nesseln gesetzt habe und komplett neu aufsetzen musste: NCARS

Code Auswählen Erweitern


File               Rev   Last Change

00_MQTT2_CLIENT.pm 19463 2019-05-25 13:02:46Z rudolfkoenig
10_MQTT2_DEVICE.pm 19262 2019-04-25 07:50:19Z rudolfkoenig

[Beta-User]

Aua, das ist doch "ziemlich alt" (bezogen auf die MQTT2-Welt)... Du müsstest mal schauen, was zum Thema json2nameValue() in deiner fhem.pl zu finden ist. Tendenziell müsste da was im log zu finden sein, und wenn du updates scheust, dann wäre es ggf. den Versuch wert, nur die Funktion gegen den aktuellen Code auszutauschen.

(Ich würde aber mal ein update wagen, vorher ein backup und CUL_HM (+ggf. WeekdayTimer, falls du noch Heating_Control hast) ausklammern, das ist ein spezielles Thema, falls du das im Einsatz haben solltest).

[rudolfkoenig]

Du müsstest mal schauen, was zum Thema json2nameValue() in deiner fhem.pl zu finden ist.

json2nameValue kam mit 17140 rein, sie wird also vorhanden sein.
Allerdings haben wir seitdem etliche Bugs entfernt und die Funktion deutlich erweitert, laut svn blame entstand etwa ein drittel der Funktion nach 19463.

[Beta-User]

"Wir" ist lustig...

Von Interesse scheint v.a. das toJSON-Kombabilitätsthema zu sein, da wurde um den Dreh rum was ergänzt.

Aber (@waldmensch) ernsthaft: Dauerhaft ohne updates (oder irgendwelche Frickeleien) ist m.E. ein nogo, wenn man halbwegs aktuelle Hardware haben will (v.a. aus der MQTT-Welt, aber nicht nur). Früher oder später fliegt dir die Murmel um die Ohren (anzunehmen, dass es mit dem OS auch so ist, dass das irgendwann outdated ist), und da würde es m.E. Sinn machen, mal einen update-Plan zu machen oder zumindest bestimmte Teile parallel in einer neueren Infrastrukur zu betreiben. Ist zwar schön, dass FHEM zuverlässig auch so vor sich hin läuft, aber "irgendwann" holt einen sowas ein...

(MQTT ist btw. ein probates Mittel, um einen gewissen Abstraktionslayer einzuschieben).

[Waldmensch]

Die beiden Module updaten reicht sicher nicht, wenn die toJSON Funktion im FHEM.pl steckt. Bei bisherigen Updates hat es mit regelmäßig bei den FS20 und im TabletUI ,,eingeschlagen" (Nicht gut für den WAF, wenn alle 3 Tablets in der Wohnung nicht mehr anzeigen was sie sollen). Die Hauptsächlichen ,,Dinge" laufen mittlerweile über MQTT (alt) und Tasmota. Die komplette FHEM Installation wird nächtens auf ein NFS Laufwerk als Backup kopiert. Habe das aus Raspi Zeiten beibehalten, weil ich ein paar mal SD Karten verloren hab.
Dann werde ich mal die Backups prüfen und ein Update angehen.

[Muschelpuster]

Moin zusammen,

hat schon jemand mit der Hardware V3 und der Firmware 0.51.1 MQTT aktivieren können? Ich kann das zwar einschalten und auch die MQTT-URL anpassen aber nach dem Speichern ist bei erneutem Aufruf der Einstellungen wieder die Default-URL hinterlegt.

[Sany]

Hallo Muschelpuster,

habe die selbe Hardware/App-Konfig wie Du, und stehe in Kontakt mit go-e:
Die MQTT-Adresse wird momentan nicht gespeichert, ist ein Bug und soll in der nächsten Version der App (in Kürze) gefixt sein.

Es gilt also auf die nächste App-Version zu warten, dort im Changelog sollte die Korrektur des Bugs erkennbar sein.

Falls Name/Passort für den MQTT Broker erforderlich dann so eintragen:

Code Auswählen Erweitern

mqtt://username:password@server:port

Bin gespannt, wann die App rauskommt....


Gruß

Sany

[Muschelpuster]

Danke Sany,

das habe ich fast befürchtet 
Alternativ kann man natürlich auch einen statischen DNS-Record für die Default-Adresse machen, welcher auf FHEM zeigt. Aber das kann Onkel Fritz ja nicht.
Oder man nimmt das Modul von LR66...
Na ja, Go-e hat jetzt noch ein Ticket dazu 

Niels

[Sany]

die WebApp ist übrigens auch noch nicht kompatibel zur Hardware v3. Das soll auch noch kommen, aber es wurde kein Datum genannt. Und zur API v2 gibts noch keine Dokumentation.

Das ist zwar alles etwas seltsam, aber für mich gerade nicht sooo wichtig. Die Box wurde halt im Zuge meiner PV installiert, ich hab aber nicht mal n Kabel, geschweige denn ein eAuto

Irgenwann demnächst werden die ihre Software aktualisieren und dann kommt das Teil ins fhem, zu späteren Nutzung.

[Muschelpuster]

Die MQTT-URL bekommt man eingestellt, auch wenn der Support sagt, dass das nicht geht 
1. HTTP-API V2 aktivieren
2. http://go-e-ip/api/set?mcu=%22mqtt://MQTT-IP:1883%22 im Webbrowser der Wahl abfeuern
Und schon schlagen die MQTT-Meldungen auf 
Ein Blick auf die Uhr verrät mir aber, dass ich jetzt nicht mehr schaue, ob diese mit den bisherigem Format übereinstimmen 

Niels

[Sany]

Guten Morgen,

vielen Dank für den Tipp. Habs mal probiert, aber wieder gelöscht. Warum?
1. mein MQTT2 Server ist per Username/Passwort abgesichert. Wenn ich den Befehl im Browser absetzte, mit den Credentials, dann stehen diese nachher im Klartext in der App.
2.

Und schon schlagen die MQTT-Meldungen auf

Das ist sehr wörtlich zu nehmen: da kamen hunderte Meldungen an, das angelegte Device (autocreate) hatte ca 220 Readings angelegt die öfter als sekündlich übertragen wurden. Selbst mit event-on-change-reading .* wurde immer noch soviel Last im System erzeugt, dass diverse andere MQTT2-Devices sich peu-à-peu abgemeldet haben. Im Log sind innerhalb 12 min ca 22000 Messages aufgezeichnet worden.
Ich hab das jetzt erst mal alles wieder rausgenommen. Jetzt ist wieder Ruhe.
Im Moment habe ich keine Zeit, mich damit intensiv zu beschäftigen. Ich warte erst mal ab, was an Updates von go-e kommt und wenn es passt werde ich die "Forschungen" wieder aufnehmen.

Gruß


Sany