go-echarger als mqtt-device - meine Konfig

[Mitch]

@Rudi: wie Beta-User schreibt, ich hole alle 60 sek. die Werte und will nur ein Event, falls sich etwas geändert hat.

Wäre es denn grundsätzlich von Vorteil auf MQTT zu gehen?

[Beta-User]

Hmm, schwierig. Tendenziell würde ich annehmen, dass MQTT
- leichtgewichtiger ist und gut programmierte Geräte den Verkehr auf Änderungen beschränken. Klares Plus.
- Dann ist MQTT als Kommunikationsprotokoll gemacht für "schwierige Fälle" und per se weniger anfällig gegen Störungen, Verbindungsabbrüche etc. (ob MQTT2_SERVER das alles in vollem Umfang kann, müßte Rudi beantworten, gehe aber mal davon aus, dass die Grundzüge jedenfalls passen).

Es ist halt "was anderes" und von daher müßtest du dich in die "Spezialitäten" etwas eindenken, was aber kein Hexenwerk ist, v.a. dann nicht, wenn du sowieso MQTT irgendwo anders verwendest/verwenden willst. (Das wird immer mehr, kommt also früher oder später vermutlich sowieso).

Ansonsten vermutlich: Geschmackssache...

[Mitch]

MQTT ist kein Neuland 

Wie gesagt, hatte auch den Charger schon über MQTT angebunden, war sogar Betatester der FW.
Was mit nicht gefallen hat, es gibt keine Einstellungsmöglichkeiten.
Das Ding schickt im Sekundentakt Werte. (Das ist auch etwas, was mit beim ebusd nicht gefällt, da kann man aber wenigstens nur geänderte Werte schicken lassen).

Vielleicht schau ich mir es nochmal an.
Wie du schreibst, es wird immer mehr in die Richtung gehen.

[rudolfkoenig]

Als weitere Alternative haetten wir noch JsonMod, fuer den Fall, dass man noch nicht unsicher genug ist

[Beta-User]

...deswegen hatte ich geschrieben: "gut programmierte Geräte schicken...". Das ständige Aktualisieren beliebiger Werte ist iMo ein bug, den man dem Hersteller ggf. um die Ohren hauen sollte (bitte nicht betreffend ebus, da reicht vermutlich ein ganz höflicher Hinweis an den wirklich netten Autor, der sich auch erst in das Thema hat eindenken müssen )...

In der MQTT-Welt gibt es einen Mechanismus: "last will". Nutzt der Programmierer des Geräts den, braucht er nicht ständig alles mögliche in die Welt brüllen, nur um zu sagen "bin noch da" und kann das Prinzip der Datenvermeidung besser beherzigen... (sonst brauchen wir alle irgendwann einen Mainframe-Rechner, nur um das bißchen Hausautomatisierung abzufackeln .

Als weitere Alternative haetten wir noch JsonMod, fuer den Fall, dass man noch nicht unsicher genug ist

Jup, aber da gibt es noch keinen Freiwilligen für attrTemplates (und afaik auch noch nicht die Funktionalität?).

[Mitch]

...bitte nicht betreffend ebus, da reicht vermutlich ein ganz höflicher Hinweis an den wirklich netten Autor, der sich auch erst in das Thema hat eindenken müssen )...

Ich weis, hatte mit ihm schon ein paar mal Kontakt. 

[Beta-User]

Bei mir waren es nicht ein paar Mal, sondern nur eine kurze Phase, als es um die Entwicklung der attrTemplate zum ebus an sich ging. Da waren wir alle noch am Üben , aber der Kontakt war bei allen Widrigkeiten (ich keine Ahnung von den Geräten und deren Funktion und nur ein diffuses Gefühl, wohin das gehen soll, er hat sich da geduldig Zeit genommen, das irgendwie zu errätseln, was ich denn vielleicht meinen könnte...).

[Waldmensch]

Auch wenn im Thread länger nichts geschrieben wurde, vielleicht kann jemand helfen. Ich habe ein MQTT device angelegt, welches das JSON Objekt zuverässig vom Mosquito bekommt. Wie gewöhlich bei meinen Tasmota Devices, würde ich nun gern mit expandJSON die Readings erzeugen. Bei Tasmota funktioniert das zuverlässig. Beim go-E passiert gar nichts. Ich habe bei raw DEV mal angehangen, und eine Message, die alle 5 Sekunden im Eventmonitor kommt. Sieht jemand einen Fehler? Wie gesagt, das MQTT device bekommt alle 5 Sekunden ein neues Reading DATA, nur expandJSON scheint nichts zu tun.


Device:

Code Auswählen Erweitern

defmod stadtweg.GoE MQTT_DEVICE
attr stadtweg.GoE DbLogExclude .*
attr stadtweg.GoE IODev myBroker
attr stadtweg.GoE event-on-update-reading .*
attr stadtweg.GoE room MQTT
attr stadtweg.GoE subscribeReading_DATA go-eCharger/xxxxxxxx/status

expandJson

Code Auswählen Erweitern

defmod ejDATA expandJSON stadtweg.GoE:DATA:.\{.*\}

Eventmonitor:

Code Auswählen Erweitern

2021-05-21 09:30:04 MQTT_DEVICE stadtweg.GoE DATA: {"version":"B","tme":"2105210930","rbc":"11","rbt":"902601139","car":"2","amp":"6","err":"0","ast":"0","alw":"1","stp":"0","cbl":"20","pha":"63","tmp":"0","tma":[18.13,17.63,17.50,18.00],"amt":"32","dws":"28923","dwo":"0","adi":"1","uby":"0","eto":"1230","wst":"3","txi":"2","nrg":[221,222,213,1,60,61,60,13,13,12,0,401,100,100,100,2],"fwv":"040.0","sse":"023547","wss":"iot24","wke":"****************","wen":"1","cdi":"0","tof":"101","tds":"1","lbr":"49","aho":"3","afi":"7","azo":"0","ama":"16","al1":"10","al2":"16","al3":"20","al4":"24","al5":"32","cid":"255","cch":"65535","cfi":"65280","lse":"0","ust":"0","wak":"","r1x":"2","dto":"0","nmo":"0","sch":"AAAAAAAAAAAAAAAA","sdp":"0","eca":"0","ecr":"0","ecd":"0","ec4":"0","ec5":"0","ec6":"0","ec7":"0","ec8":"0","ec9":"0","ec1":"0","rca":"04C8727A","rcr":"","rcd":"","rc4":"","rc5":"","rc6":"","rc7":"","rc8":"","rc9":"","rc1":"","rna":"","rnm":"","rne":"","rn4":"","rn5":"","rn6":"","rn7":"","rn8":"","rn9":"","rn1":"","loe":0,"lot":0,"lom":0,"lop":0,"log":"","lon":0,"lof":0,"loa":0,"lch":0}                                               


[Beta-User]

[Spekulationsmodus ein]
Probleme mit den (völlig überflüssigen! und) leeren json-Keys?

Falls es daran liegt und du bei MQTT-"classic" bleiben willst: nimm MQTT_GENERIC_BRIDGE (mit "expression", das erzeugt beim Auspacken auch nur eine Event-loop) oder notfalls (!) ein notify) und ein dummy und packe den JSON mit json2nameValue() aus, das sollte das "können".

Besser/einfacher wäre vermutlich ein MQTT2_CLIENT+M2D...
[Spekulationsmodus aus]

Ergänzend:

Code Auswählen Erweitern

attr stadtweg.GoE event-on-update-reading .*ist mAn. keine "vorbildliche" Idee bei so einem "Spammer"-Device.

[Waldmensch]

Das update-on-event habe ich nur drin,
um sicherzugehen (Fehlersuche), dass das expandJSON wirklich getriggert wird. Wenn ich MQTT2 verwende, kann ich Mosquitto nicht verwenden. Ich will aber auch, das andere Geräte auf den Go-E subscriben können. Stichwort Phasenumschaltung, Wartezeit bis kein Strom mehr fließt. Das will ich direkt in Tasmota Rules abfackeln, Sodas FHEM nur den 1/3 Phasen umschalt Impuls geben muss und der Rest vom Tasmota Device selbst gemanaged wird. (Ladung deaktivieren, warten bis kein Strom mehr fließt, GoE Schütz trennen und wieder verbinden.) Das will ich nicht von FHEM aus machen.

[Beta-User]

Den Einwand mit Mosquitto verstehe ich nicht. Vorschlag war MQTT2_CLIENT (parallel!) zu 00_MQTT (für den Rest) zu verwenden (= beide hören auf den Mosquitto), und (nur) die Daten von diesem einen Device dann als MQTT2_DEVICE auszugestalten. Es gibt btw. auch eine myUtils dazu, die (afaik zumindest halbwegs) sinnvoll zwischen Daten unterscheidet, die triggern sollen und anderen, die man nur eher gelegentlich aktualisieren will...

[Waldmensch]

Ich war bis dato der Meinung, das MQTT2 einen eigenen Broker abbildet, den man dann im goE angeben muss. Wenn das nicht so ist, schau ich mit das nochmal an.

[Beta-User]

Es gibt 2 IO Module:
MQTT2_SERVER bildet einen eigenen "Broker" ab, das hier vorgeschlagene MQTT2_CLIENT ist die "modernere" Konkurrenz zu 00_MQTT (und kann u.a. SSL).

[Waldmensch]

Okay, Habe einen MQTT2 Client angelegt und ein MQTT2 Device nach Vorschlag im ersten Beitrag. Auch hier scheint das JSON parsing nicht zu klappen.

Code Auswählen Erweitern

2021-05-21 13:39:41 MQTT2_DEVICE MQTT2_goecharger Stecker_Kabel: -1
2021-05-21 13:39:41 MQTT2_DEVICE MQTT2_goecharger temperature: 0
2021-05-21 13:39:41 MQTT2_DEVICE MQTT2_goecharger energy_total: 0
2021-05-21 13:39:41 MQTT2_DEVICE MQTT2_goecharger energy_akt: 0

Code Auswählen Erweitern

defmod MQTT2_goecharger MQTT2_DEVICE
attr MQTT2_goecharger DbLogExclude .*
attr MQTT2_goecharger IODev GoEClient
attr MQTT2_goecharger readingList go-eCharger/023547/status:.* { json2nameValue($EVENT) }\
go-eCharger/023547/ip:.* { json2nameValue($EVENT) }
attr MQTT2_goecharger room MQTT2_DEVICE
attr MQTT2_goecharger setList Laden_EIN:noArg go-eCharger/023547/cmd/req alw=1\\
Laden_AUS:noArg go-eCharger/023547/cmd/req alw=0\\
Ampere:selectnumbers,1,1,22,1,lin go-eCharger/023547/cmd/req amp=$EVTPART1\

attr MQTT2_goecharger stateFormat Status: Stecker_Kabel P_akt: energy_akt V1: nrg_1 V2: nrg_2 V3: nrg_3
attr MQTT2_goecharger userReadings Stecker_Kabel  { if(ReadingsVal("MQTT2_goecharger","car","") eq "1") { return "Bereit" } \
elsif (ReadingsVal("MQTT2_goecharger","car","") eq "2") { return "Fzg laedt" }\
elsif (ReadingsVal("MQTT2_goecharger","car","") eq "3") { return "Warte auf Fzg" }\
elsif (ReadingsVal("MQTT2_goecharger","car","") eq "4") { return "Laden beendet" }\
else { return -1 } }, \
temperature { ReadingsVal("MQTT2_goecharger","tmp",0) }, \
energy_total { ReadingsVal("MQTT2_goecharger","eto",0)*0.1 }, \
energy_akt { ReadingsVal("MQTT2_goecharger","dws",0)*2.77 }
attr MQTT2_goecharger verbose 5

[Beta-User]

An json2nameValue() liegt es nicht, wenn ich das hier manuell publishe, werden die Readings angelegt und sind dann nach einem Browser-Refresh sichtbar. Klingt eher danach, als würde die Verbindung M2C <-> mosquitto nicht klappen - warum auch immer. (credentials?)

Kurz-Kurs noch für Neueinsteiger in M2D: Für die Umbenennungen usw. nutzt man besser jsonMap, und (ganz allgemein:) für userReadings sind trigger zu empfehlen (bei "all-in-one"-Aktualisierungen wie hier nicht so wichtig, aber das kann man kaum vorher wissen...).
Der Beitrag mit der letzten myUtils-Fassung zu dem Charger ist der hier: https://forum.fhem.de/index.php/topic,115620.msg1099706.html#msg1099706. Leider wollte den Ball wohl niemand so recht aufgreifen, ist aber echt "interessant", das Ding (besser gesagt: schlampig programmierte MQTT-Schnittstelle, man muss viel "reparieren"...).