MAX Thermostate und MQTT - Readings und Steuerung über FHEM verfügbar machen

[Beta-User]

Da ich mich damit noch nicht auseinandergesetzt habe: was sind die Probleme / wo liegen die Schwierigkeiten beim Einsatz von MQTT_GENERIC_BRIDGE?

Das würde mich auch interessieren....

Meine Beobachtungen und eigenen, schon länger zurückliegenden Eindrücke:
- Bei der Installation wird "externer support" benötigt (afaik nur "libmodule-pluggable-perl"). Leider scheinen "Gelegenheitsnutzer" schon mit solchen Kleinigkeiten Schwierigkeiten zu haben, obwohl man (@debian&Derivaten) nicht mal cpan braucht, um es zu installieren. Wofür das Perl-Modul (@MQTT2-IO) überhaupt gebraucht wird, ist mir unklar (wir hatten dazu mal einen Thread mit hexenmeister).
- Die Fülle der Optionen und Ebenen, die man bei MGB hat/beachten kann/muss ist groß; eigentlich muss man bei der Konfiguration schon wissen, wie das "große Ganze" am Ende ausschauen soll. Für Einsteiger und Wenig-Nutzer vermutlich ein Ding der Unmöglichkeit, insbesondere, weil die vorhandenen Beispiele noch zu Zeiten entstanden sind, als es noch keine MQTT2-IO's gab (und sich daher das autocreate/bridgeRegexp-"Problem" noch nicht stellte).
- die Syntax ist eigentlich nicht besonders schwierig, aber die Kombinationsmöglichkeiten vielfältig...

Daher hatte ich auch versucht, hier ein paar Leute zu motivieren, sowas wie eine "Standardlösung" darzustellen, auf die  man dann ggf. einfach verweisen  könnte oder sogar einen Satz an attrTemplate bereitstellen, der mit dieser "Standardlösung" kompatibel wäre.

Was das Zusammenspiel von MGB und den MQTT2-IO's anbelangt, ist m.E. die "Schwierigkeit" das Thema "autocreate" (siehe z.B. auch https://forum.fhem.de/index.php/topic,117537.0.html). Der "typische User" scheint das aktiv haben zu wollen, und muss daher dann eine passende bridgeRegexp setzen (und das eben an einem MQTT2_DEVICE und nicht an MQTT2-IO oder der MGB). Dieser Zusammenhang ist aber "schwierig" und auch nicht besonders prominent dokumentiert. Eine "Lösung" könnte sein, dieses Attribut (oder was ähnliches) auch an MGB zuzulassen und dort zu dokumentieren.

Hier kam dann irgendwie indirekt noch der Wunsch raus, "FHEM-Syntax" als Payload zu verwenden, oder zumindest was verwandtes, aber das ist m.E. "kein richtiges MQTT". Für mich gehören Device und Readingname in den Topic, allenfalls hat der Readingname was in einem JSON verloren... Mag aber sein, dass das nur eine Einzelmeinung ist.

Vielleicht noch ein paar weitere Anmerkungen:
Es gibt einen "Mega-Thread" zur Entwicklung der MGB. MAn. ist es so, dass alle, die sich damit (zumeist in der alten MQTT-Welt) beschäftigt haben, insgesamt sehr zufrieden waren.
hexenmeister hat auch ein paar Analysen zur Performance gemacht und kundgetan, dass das Ding keine große Last verursacht. Ich kann das zwar nicht bestätigen, habe aber auch keinen Grund, das anzweifeln.
Auch von daher sollte man m.E. eher den Weg verfolgen, die User in der sinnvollen Anwendung der MGB zu unterstützen, und das ggf. irgendwie noch zu vereinfachen, als noch einen Weg zu bauen.

[Wzut]

@Beta-User & Rudi, noch ist ja nichts in Stein geneißelt. Ich bin zu allen Schandtaten bereit von daher ist es schön so eine Disskusion vorher zu führen statt nachher wenn schon zig Arbeitsstunden / Freizeit sinnlos darin versenkt sind. Die Betonung liegt auf sinnlos, der Zeit Aufwand ist mir relativ egal.
Ich bin nunmal seit 9 Tagen in der glücklichen Lage viel Zeit in die Rubrik "Jugend forscht" stecken zu können.

Zum Thema Schwierigkeiten mit MGB :
Ich persönlich blicke bei dem Ding heute noch immer nicht durch und frage mich wirklich wie das der normal User mal ebenso auf die Reihe bekommt.
Es mag u.a. aber auch daran liegen das ich mich bisher mit dem gesammten Thema MQTT wenig bis sehr wenig befasst habe, da es bis jetzt einfach "fast" keinen Grund gab.

Sehr postiv fand ich damals als meine erste Gosund-Tasmotas zum Einsatz kam :
MQTT2_SERVER aufgesetzt und als nächstes diesen in der Tasmota Config bekannt gemacht. Erstes Telegramm kommt , autocreate legt ein MQTT2_Device an, da mittels attrTemplate das passende Template aus der Liste gesucht, angewendet, fertig !
Alle Werte da und schalten konnte ich auch sofort via Mausklick, so muß das sein ohne großartig über Topics oder abgedrehte RegEx Attribute nachdenken zu müssen.
D.h. auf diesem primitiv Stand stehe ich quasi heute noch und daher kommt auch die Vorstellung wenn MQTT für MAX dann sollte das für den User genauso einfach einzurichten sein.

[Beta-User]

[...] und daher kommt auch die Vorstellung wenn MQTT für MAX dann sollte das für den User genauso einfach einzurichten sein.

Ich sehe in MQTT eher eine Art weiterer "middleware-Lösung", um Hardware zu abstrahieren, und finde von daher eigentlich, dass der Weg sein sollte MAX->FHEM als allgemeinen HW-Abstraktionslayer, und von da aus dann weiter mit dieser MQTT-middleware, ähnlich wie das heute bei Sprachsteuerungslösungen schon ist: die interessieren sich nicht mehr für die zugrundeliegende Hardware, sondern die stellen fest: OK, in FHEM habe ich einen Thermostat (oder einen Fensterkontakt, oder...), also schaue ich nach bestimmten Readings (z.B. measured-temp oder desired-temp), die ich lesen und schreiben kann und interessiere mich keinen Deut dafür, was das eigentlich für interessante Hardware ist".

Genauso _kann_ es bei MGB auch sein, wenn wir es schaffen, die Variablen in der Topic-Struktur soweit zu vereinheitlichen, dass man es für 80% "einfach so" (per Attribute ? => attrTemplate) nachrüsten kann. MGB ist mit den Variablen (angefangen bei $base) mAn. flexibel genug, um hier ausreichend viel Freiheit zu lassen. Dann könnte man z.B. in attrTemplate feststellen, welche Hardware hinter einem "Thermostat" steckt, und dann die Attribute passend zu MAX oder ZWave oder HMCCUDEV oder... setzen (ähnlich wie das heute die Sprachsteuerungs-attrTemplate machen, es gibt dann eben ein angepasstes MQTT-bridge-Mapping).

Bei Tasmota hast du halt den "Vorteil", dass die Topic-Struktur und die Payloads schon festgelegt sind, bei "FHEM als allgemeiner MQTT-Client" ist das (noch) nicht der Fall. Ob es wünschenswert wäre, hier einen praxistauglichen Standard zu setzen, ist gerade die Frage; ich würde das tendenziell bejahen, wobei die Antwort in Teilen evtl. auch davon abhängt, wie denn die "Standard-Gegenstelle" eigentlich die Daten am liebsten haben will (Sende- und Empfangsseite)...

Vielleicht würde es Sinn machen, "Jugend forscht" mal mit FHEM<=>MQTT(2)<=>homeassistant zu betreiben (wenn ich das richtig im Kopf habe, finden das viele als Visualisierungslösung klasse), und ergänzend dazu MGB intensiver kennenzulernen?

[rudolfkoenig]

Ich habe jetzt die MQTT_GENERIC_BRIDGE (aka MGB) Doku gelesen.

Soweit ich sehe, ist MGB flexibel, was die Umwandlung zwischen FHEM und MQTT betrifft, aber das commandref ist definitiv nicht anfaengerfreundlich, und das was ich in der Wiki gefunden habe, mAn nur eine Einleitung ist. Weiterhin problematisch fuer Anfaenger ist die Abhaengigkeit vom alten MQTT Modul, und damit von weiteren cpan Modulen.

Fuer das hier diskutierte Problem fehlt ein "mqttExecute" Attribut, damit man keine zusaetzlichen Komponenten wie notifiy/etc verwenden muss.

Fuer mich stellt sich die Frage, ob wir den MGB Modulautor motivieren koennen, die Problempunkte anzugehen (vmtl. waeren Patches foerderlich), wir eine neue Implementierung vorziehen (ohne Ballast), oder wir es so lassen, wie es ist

[Beta-User]

Fuer mich stellt sich die Frage, ob wir den MGB Modulautor motivieren koennen, die Problempunkte anzugehen (vmtl. waeren Patches foerderlich), wir eine neue Implementierung vorziehen (ohne Ballast), oder wir es so lassen, wie es ist

Meine Einschätzung dazu: hexenmeister hatte den Wunsch gerne aufgegriffen, MGB mit den MQTT2-IO's kompatibel zu machen und dürfte kein Problem haben, Vorschläge zur Verbesserung der Doku und/oder Integration aufzugreifen. Soweit ich mich entsinne, war es eher der Modulautor der MQTT2-IOs, der zurückhaltend war, was die  Sonderbehandlung bestimmter Client-Module anging; hier liegt - soweit ich mich entsinne bzw. das ggf. überhaupt halbwegs verstanden habe auch die tiefere Ursache für das, was erst diese Klimmzüge rund um autocreate verursacht ...

Fuer das hier diskutierte Problem fehlt ein "mqttExecute" Attribut, damit man keine zusaetzlichen Komponenten wie notifiy/etc verwenden muss.

Bin immer noch nicht überzeugt, dass man sowas wie direkte FHEM-Befehle übermitteln können sollte und sehe das eher als potentielle Sicherheitslücke.

Ich habe jetzt die MQTT_GENERIC_BRIDGE (aka MGB) Doku gelesen.

Soweit ich sehe, ist MGB flexibel, was die Umwandlung zwischen FHEM und MQTT betrifft, aber das commandref ist definitiv nicht anfaengerfreundlich, und das was ich in der Wiki gefunden habe, mAn nur eine Einleitung ist. Weiterhin problematisch fuer Anfaenger ist die Abhaengigkeit vom alten MQTT Modul, und damit von weiteren cpan Modulen.

Die Doku ist m.E. nur verständlich, wenn man den "Beispiel-Thread" daneben legt, und selbst, wenn man weiß, nach was man eigentlich sucht, ist es schwierig.

Ich habe daher nicht nur die Doku gelesen, sondern mal versucht, einfach zwei meiner Thermostate zu "vermqtten", nämlich je einen CUL_HM und einen ZWave.

Hier mal das write-up dazu (Kommandos in FHEM über "das grüne Plus"):

Code Auswählen Erweitern

defmod MGB1 MQTT_GENERIC_BRIDGE mqttGB1
attr MGB1 room Steuerung->Test

ergab zunächst

Code Auswählen Erweitern

Cannot load module MQTT_GENERIC_BRIDGE
=> Linux-Konsole

Code Auswählen Erweitern

sudo apt-get install libmodule-pluggable-perl

Neuer Versuch => Cannot load module MQTT_GENERIC_BRIDGE
shutdown restart + defmod MGB1 MQTT_GENERIC_BRIDGE mqttGB1 + attr MGB1 room Steuerung->Test
=> Executed everything, no errors found.

Doku sagt, man kann Variablen für die Sende- und Empfangsrichtung getrennt festlegen, also:

Code Auswählen Erweitern

attr MGB1 globalDefaults sub:base={"FHEM_main/MQTT2FHEM/$device"} pub:base={"FHEM_main/FHEM2MQTT/$device"} pub:qos=0 sub:qos=2 retain=0

(EDIT: code korrigiert)

Erfolgskontrolle auf der Linux-Konsole

Code Auswählen Erweitern

mosquitto_sub -t FHEM_main/# -h <hostname server> -v

Dann die Attribute an die beiden Thermostate (Merke: die sind für beide Typen identisch, dem ZWave habe ich ein userReadings für measured-temp verpaßt!):

Code Auswählen Erweitern


attr Thermostat_Schlafzimmer_Clima mqttGB1Publish desired-temp|measured-temp:topic={"$base/$name"}
attr Thermostat_Schlafzimmer_Clima mqttGB1Subscribe desired-temp:stopic={"$base/$name"}
attr ZWave_THERMOSTAT_20 mqttGB1Publish measured-temp|desired-temp:topic={"$base/$name"}
attr ZWave_THERMOSTAT_20 mqttGB1Subscribe desired-temp:stopic={"$base/$name"}

Damit Kommandos trotz autocreate an MGB weitergegeben werden, brauchen wir zum einen eine passende bridgeRegexp. Die kommt an ein eigenes Device dafür:

Code Auswählen Erweitern

define MQTT2_MGB1_bridgeRegexp MQTT2_DEVICE
attr MQTT2_MGB1_bridgeRegexp IODev MQTT2_FHEM_Server
attr MQTT2_MGB1_bridgeRegexp bridgeRegexp FHEM_main/MQTT2FHEM/.*:.* ""
attr MQTT2_MGB1_bridgeRegexp room Steuerung->Test


Dann kann man schon publishen, hier mit mosquitto_pub, was bedeutet, dass man ZWINGEND den -i-Parameter verwenden muss, also z.B.:

Code Auswählen Erweitern

mosquitto_pub -h <hostname server> -i testing -t FHEM_main/MQTT2FHEM/ZWave_THERMOSTAT_20/desired-temp -m 19

... und schon kommt das an bzw. der Verkehr sieht auf der mosquitto_sub-Seite so aus:

Code Auswählen Erweitern

FHEM_main/FHEM2MQTT/Thermostat_Schlafzimmer_Clima/desired-temp 21.0
FHEM_main/FHEM2MQTT/Thermostat_Schlafzimmer_Clima/measured-temp 20.3
FHEM_main/FHEM2MQTT/ZWave_THERMOSTAT_20/measured-temp 16.91
FHEM_main/MQTT2FHEM/ZWave_THERMOSTAT_20/desired-temp 19
FHEM_main/FHEM2MQTT/ZWave_THERMOSTAT_20/desired-temp 19
FHEM_main/MQTT2FHEM/Thermostat_Schlafzimmer_Clima/desired-temp 20
FHEM_main/FHEM2MQTT/Thermostat_Schlafzimmer_Clima/desired-temp 21.0
FHEM_main/FHEM2MQTT/Thermostat_Schlafzimmer_Clima/measured-temp 20.3
FHEM_main/FHEM2MQTT/Thermostat_Schlafzimmer_Clima/desired-temp 20.0
FHEM_main/FHEM2MQTT/Thermostat_Schlafzimmer_Clima/desired-temp 20.0
FHEM_main/FHEM2MQTT/Thermostat_Schlafzimmer_Clima/desired-temp 20.0
FHEM_main/FHEM2MQTT/Thermostat_Schlafzimmer_Clima/desired-temp 20.0
FHEM_main/FHEM2MQTT/Thermostat_Schlafzimmer_Clima/desired-temp 20.0
FHEM_main/FHEM2MQTT/Thermostat_Schlafzimmer_Clima/measured-temp 20.3
.

Ergo: Wenn man's im Zusammenhang sieht und weiß, nach was man sucht, geht es, aber es gibt ziemlich viele  kleine und größere Fallstricke, über die man stolpern kann...

Hier nochmal (bis auf M2Server) alle Definitionen im Zusammenhang:

Code Auswählen Erweitern

define MGB1 MQTT_GENERIC_BRIDGE mqttGB1
attr MGB1 IODev MQTT2_FHEM_Server
attr MGB1 globalDefaults sub:base={"FHEM_main/MQTT2FHEM/$device"} pub:base={"FHEM_main/FHEM2MQTT/$device"} pub:qos=0 sub:qos=2 retain=0
attr MGB1 room Steuerung->Test

define MQTT2_MGB1_bridgeRegexp MQTT2_DEVICE
attr MQTT2_MGB1_bridgeRegexp IODev MQTT2_FHEM_Server
attr MQTT2_MGB1_bridgeRegexp bridgeRegexp FHEM_main/MQTT2FHEM/.*:.* ""
attr MQTT2_MGB1_bridgeRegexp room Steuerung->Test

define Thermostat_Schlafzimmer_Clima CUL_HM 12345604
attr Thermostat_Schlafzimmer_Clima userattr weekprofile
attr Thermostat_Schlafzimmer_Clima alias HK Schlafzimmer
attr Thermostat_Schlafzimmer_Clima devStateIcon {devStateIcon_Clima($name)}
attr Thermostat_Schlafzimmer_Clima group Heizung
attr Thermostat_Schlafzimmer_Clima icon hm-cc-rt-dn
attr Thermostat_Schlafzimmer_Clima model HM-CC-RT-DN
attr Thermostat_Schlafzimmer_Clima mqttGB1Publish desired-temp|measured-temp:topic={"$base/$name"}
attr Thermostat_Schlafzimmer_Clima mqttGB1Subscribe desired-temp:stopic={"$base/$name"}
attr Thermostat_Schlafzimmer_Clima peerIDs 00000000,
attr Thermostat_Schlafzimmer_Clima room Schlafzimmer,Steuerung->Heizung,Steuerung->Test
attr Thermostat_Schlafzimmer_Clima tempListTmpl Schlafzimmer
attr Thermostat_Schlafzimmer_Clima webCmd desired-temp
attr Thermostat_Schlafzimmer_Clima weekprofile Schlafzimmer
attr Thermostat_Schlafzimmer_Clima widgetOverride desired-temp:knob,min:4.5,max:31.5,angleArc:180,width:40,height:40,fgColor:#FF9900,bgColor:#CCCCCC,step:0.5,lineCap:round,angleOffset:225

define ZWave_THERMOSTAT_20 ZWave abc123def45
attr ZWave_THERMOSTAT_20 IODev zwaveme
attr ZWave_THERMOSTAT_20 alias Thermostat
attr ZWave_THERMOSTAT_20 classes ZWAVEPLUS_INFO ASSOCIATION ASSOCIATION_GRP_INFO VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY PROTECTION SENSOR_MULTILEVEL SWITCH_MULTILEVEL THERMOSTAT_MODE THERMOSTAT_SETPOINT BATTERY CONFIGURATION ALARM POWERLEVEL SECURITY SECURITY_S2 TRANSPORT_SERVICE SUPERVISION FIRMWARE_UPDATE_MD
attr ZWave_THERMOSTAT_20 group Heizung
attr ZWave_THERMOSTAT_20 icon temp_control
attr ZWave_THERMOSTAT_20 mqttGB1Publish measured-temp|desired-temp:topic={"$base/$name"}
attr ZWave_THERMOSTAT_20 mqttGB1Subscribe desired-temp:stopic={"$base/$name"}
attr ZWave_THERMOSTAT_20 room Abstellkammer,Steuerung->Test
attr ZWave_THERMOSTAT_20 userReadings energySaveHeating:setpointTemp.+energySaveHeating {ReadingsNum($name,"setpointTemp",0)}, \
heating:setpointTemp.+heating {ReadingsNum($name,"setpointTemp",0)}, \
thermostatMode:setpointTemp.+ {ReadingsVal($name,"setpointTemp",0)=~m/(heating|energySaveHeating)/;; $1?$1:undef},\
valve:reportedState.+(dim.[0-9.]+|off) {my $val = ReadingsVal($name,'state',0);; return 0 if $val eq "off";; ReadingsNum($name,"state",0)}, \
desired-temp:(setpointTemp.+heating|thermostatSetpointSet.*|.*tmEnergySaveHeating|.*tmHeating) {ReadingsAge($name,'setpointTemp',100) > 0 ? ReadingsNum($name,'thermostatSetpointSet',0) : ReadingsAge($name,'state',100) > 0 ? ReadingsNum($name,'setpointTemp',0) : ReadingsVal($name,'state',"unknown") eq "tmEnergySaveHeating" ? ReadingsNum($name,'energySaveHeating', 18) : ReadingsVal($name,'state',"unknown") eq "tmHeating" ? ReadingsNum($name,'heating', 22) : undef }, \
thermostatSetpointSet:desired-temp.* { ReadingsNum($name,'desired-temp',0) },\
measured-temp:temperature.* { ReadingsNum($name,'temperature',0) }
attr ZWave_THERMOSTAT_20 vclasses ALARM:8 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 BATTERY:1 CONFIGURATION:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:1 POWERLEVEL:1 PROTECTION:1 SECURITY:1 SECURITY_S2:1 SENSOR_MULTILEVEL:5 SUPERVISION:1 SWITCH_MULTILEVEL:1 THERMOSTAT_MODE:3 THERMOSTAT_SETPOINT:3 TRANSPORT_SERVICE:2 VERSION:2 ZWAVEPLUS_INFO:2

[Wzut]

euch ist schon klar das wir nun höllisch aufpassen müssen das der hier zuständige Moderator nicht einschreitet, denn mit der MGB Diskussion wird das IMHO hier langsam OT und ich bin mir relativ sicher das hexenmeister das hier niemals mitbekommt

@Beta-User , kann sein das ich mich nun wieder "falsch" ausdrücke ( die "Krücke" war kein negatives Wort sondern die Beschreibung einer Hilfe ohne die etwas nicht möglich ist und nicht eine schlechte Notlösung )

In deinem Beispiel legtst du ein MGB und ein MQTT2_Device an um sowohl senden als auch empfang abzudecken.
Wir verstehe einfach nicht was an meiner Lösung statt zwei nur ein Device, halt ein MQTT2_CLIENT einzusetzen nun wirklich schlechter ist.

Code Auswählen Erweitern

define myMQC MQTT2_CLIENT 192.168.0.1:1800
attr myMQC autocreate no
attr myMQC clientId TESTINSEL
attr myMQC rawEvents MAX
attr myMQC subscriptions MAX/#
Es gibt in FHEM halt oft mehr als einen Weg und eine Diskussion ob nun notify besser als DOIF ist würden wir doch auch nicht führen, das isr jedem User je nach Geschmack auch selbst überlassen. D.h. ich will mit meinem Vorschlag auch niemand zum wahren Glauben bekehren, ich kann als Maintainer der MAX Module lediglich Angebote machen, ob die User diese auch annehmen bzw. nutzen liegt nicht mehr in meiner Macht.

[Beta-User]

Wir können hexenmeister gerne aktiv anpingen .

Den zuständigen Moderator bitte ich um Geduld mit dieser OT-Sache hier .

Zur Erläuterung "meiner Lösung":
Mein Beispiel braucht das "separate" MQTT2_DEVICE nur, weil direkt der reguläre MQTT2_SERVER mit genutzt wird _und_ autocreate "simple" möglich sein soll. Mit "no" geht es auch so, und man baucht diese "Krücke" nciht. Und mit Unterstützung des mitlesenden Maintainers von MQTT2_(SERVER|CLIENT) eventuell auch einfach mit einem zusätzlichen Attribut an diesen IO's?

Die gezeigte Konstruktion (die ich vielleicht sogar noch so ändern würde, dass der Reading-Name auch noch in $base wandert) funktioniert dann auch mit MAX, MQTT2_DEVICE (ja, das kann schon sinvoll sein, z.B. falls man das vorverarbeitet weiterleiten will), EnOcean, ... whatever mehr oder weniger 1:1 genauso. Einfach das Attribut für die Senderichtung setzen bzw. dann noch das für Empfangen, wenn man das will, und aus der betreffenden FHEM-Installation wird genau das weitergegeben, was man haben will, und es werden nur "punktgenaue Anweisungen" entgegengenommen; das ganze ohne, dass Events generiert werden, die "alles mögliche" beschäftigen.
So sollte m.E. die MQTT-Ebene funktionieren, und so bekämen wir auch eine einheitliche Syntax hin für die Anbindung beliebiger externer Lösungen. Aber ich werde keinen hindern, "seine Lösung" zu bauen, ich finde es nur a) unnötig und b) schwer vermittelbar .

Nun darf es gerne "gut sein", falls der hier zuständige Moderator das wünscht .

[Wzut]

Nun da ich den Typ kenne würde ich sagen OT ist :
Ob MGB gute oder schlechte Doku hat oder ob man darüber nachdenkt dessen Fähigkeiten / Attribute zu erweitern.

Nicht OT ist :
Welche möglichen Lösungen gibt es und wie setzt mann sie um ?
Drei haben nun zusammen, ich bin mir sicher da gäbe es noch mehr. Allerdings regt sich halt bisher auf der User noch gar nichts.

In denem vorletzten Posting hast du beiläufig eine Bemerkung über desired-temp gemacht.
Und siehst du genau hier sehe ich einen Punkt an dem ich aktiv werden kann. MAX verwendet heute desiredTemperature.
Die ganze Diskussion über einheitliche Reading Namen ist uralt und daher hat MAX auch bis heute zwei Batterie Readings - da wollte jemand auch mal eine durchgehende Schiene fahren (und ist bei HM auf taube Ohren gestoßen).....
Gibt es in diesem Bezug noch mehr Reading Namen denen zum Thema MQTT Template eine Vereinheitlichung gut tun würden ?

[Beta-User]

Zum Thema "gute Reading-Namen" wäre es toll, wenn sich das jemand mal auf die Fahne schreiben würde und Vorschläge machen würde. Außer den Batterie- und -Medienplayern und der neuen Initiative rund um Photovoltaik gibt es da wenig, und ich stolpere da auch immer wieder rum (zu meinem Leidwesen oft bei völligem Unverständnis der betreffenden User...). Vorrangig, weil man bei MQTT  ja (fast) alles flexibel hin und herschieben kann...

So ist es btw. bei MGB auch: du setzt "einfach" einen MQTT-Alias und schon wird der Topic zu desired-temp:

Code Auswählen Erweitern

attr <max-thermostat> mqttGB1Alias desiredTemperature=desired-temp temperature=measured-temp
(ich hoffe, so herum ist es richtig, ansonsten braucht man afaik einen Neustart, um den Alias wieder zu ändern...)

Wie du siehst, braucht es nicht wirklich viel, um hier eine Art Standard zu entwickeln, der sich an JEDES Modul relativ leicht anflanschen läßt.

Aus gegebenem Anlass (Thread hier) habe ich das eben auch noch für ein HUEDevice (on/off) versucht, was auch "im Prinzip" kein Problem war:

Code Auswählen Erweitern

attr Licht_Essen mqttGB1Publish state:topic={"$base"}
attr Licht_Essen mqttGB1Subscribe state:stopic={"$base"}

(Von daher war es vermutlich doch eine gute Idee, den Reading-Namen aus $base zu lassen).

Code Auswählen Erweitern

mosquitto_pub -h <hostname server> -t FHEM_main/MQTT2FHEM/Licht_Essen -m off -i testing

Code Auswählen Erweitern

FHEM_main/FHEM2MQTT/Licht_Essen dim93%
FHEM_main/FHEM2MQTT/Licht_Essen dim87%
FHEM_main/MQTT2FHEM/Licht_Essen off
FHEM_main/FHEM2MQTT/Licht_Essen dim43%
FHEM_main/FHEM2MQTT/Licht_Essen off
FHEM_main/MQTT2FHEM/Licht_Essen on
FHEM_main/FHEM2MQTT/Licht_Essen dim50%
FHEM_main/FHEM2MQTT/Licht_Essen dim87%

Was man erkennen kann: Hier wäre eine Übersetzungsfunktion hilfreich....



Zur Frage, welche Varianten es noch gäbe: Du kannst direkt aus MQTT2_DEVICE die Funktion im MAX-Modul aufrufen ganz ohne NotifyFn und dann einfach $TOPIC und $EVENT übergeben...

[arm9999]

Habe mit großem Interesse die Diskussion mitgelesen und möchte mal als Anwender meine Erfahrung "von außen als user" hinzubringen.

Mein Fokus war die Hausautomatisierung mit homeassistant als frontend um weitere Elemente zu erweitern und so kam ich sehr schnell auf FHEM als super Schweizer Taschenmesser und perfekte middleware für meine Anforderung. Als Plattform für einen strukturierten Datenaustausch bot sich hier MQTT an und so viel die Wahl auf einen MQTT-Broker, der außer FHEM noch für andere devices und Plattformen zur Verfügung stehen sollte.

MQTT2 ist ein integriertes FHEM Modul das prädestiniert ist, zwischen FHEM Instanzen Daten auf Basis MQTT Protokoll auszutauschen und wurde für diesen Anwendungsfall konzipiert. MQTT2-device unterstützt dabei den direkten Austausch zwischen MQTT topics und FHEM nach den internen Regeln - einfach perfekt.
Meinen Wunsch nach einem systemunabhängigen MQTT-Broker, der auf einem eigenen Server läuft, habe ich mir daher mit MOSQUITTO umgesetzt. (was bei Anwendern von z.B. homeassistant, node red, esp, ... häufiger vorkommt  )

Für den Einsatz eines externen MQTT Broker dient in FHEM das MQTT-Gateway und, so meine Einschätzung nach dem Studium von commandref/wiki/Forum die MQTT_Generic_bridge (MGB). Hier fand ich auch sehr schnell die Funktionen die ich brauchte, um FHEM und MQTT miteinander zu verbinden.

Was mir aber fehlte, war/ist eine Möglichkeit über MQTT Aktionen in FHEM auszuführen. Ein reading mit einem MQTT topic zu verknüpfen, kein Thema. Aber wie wird die Änderung eines MQTT topic an ein FHEM device gemäß den Anforderungen der Module in der commadref übergeben? 

Die Frage hatte @Wzut ja auch schon angesprochen und hier kommt mein "notify Ansatz" mit einem speziellen "FHEM Kommando topic" als Lösung zum Einsatz. So ist es relativ einfach jeder anderen Software die Kommunikation mit FHEM beizubringen, denn es braucht lediglich den richtigen Befehl mit einem publish auf das topic zu senden und die Quttierung/Ausführung wird über die Readings gleich wieder in MQTT zurückgespiegelt. Dadurch habe ich eine offene Schnittstelle zu FHEM, über die ich alle Module mit ihren jeweiligen Besonderheiten ansprechen kann. Wie bei jeder Schnittstelle sollte man sich darüber im Klaren sein, welche man absetzt 

Die MGB ist ein mächtiges Modul und es ist nicht immer alles gut dokumentiert, aber perfekt um mit einem externen Broker zusammenzuarbeiten. Was ich mir vorstellen könnte ist, in Anlehnung an meinen Ansatz, dass die MGB genau ein solches topic in MQTT zum Ausführen von Befehlen zur Verfügung stellt, so das man kein notify braucht. Hier könnte die MGB eine zentrale Rolle in Bezug auf Übergang zu FHEM und den (Sicherheits-)Mechanismen und zulässigen Aktionen übernehmen. Ich denke, ein solches feature wäre universell und damit unabhängig von anderen bestehenden oder neuen Modulen.

Wie lässt sich aus eurer Sicht das Thema "Änderungen bei MQTT topics in FHEM anwenden" noch sinnvoll umsetzen?

[Beta-User]

Für den Einsatz eines externen MQTT Broker dient in FHEM das MQTT-Gateway und, so meine Einschätzung nach dem Studium von commandref/wiki/Forum die MQTT_Generic_bridge (MGB). Hier fand ich auch sehr schnell die Funktionen die ich brauchte, um FHEM und MQTT miteinander zu verbinden.

Dieses Verständnis ist - so ich den Text korrekt verstanden habe - unvollständig:
Es gibt MQTT2_SERVER als integrierte Lösung - in meinen Experimenten habe ich den genutzt, weil er eben da war - ganz ganau so, wie bei "von extern kommenden Usern" in der Regel eben ein mosquitto läuft.

Um einen externen Broker wie mosquitto anzubinden, gibt es ZWEI IO-Module zur Wahl: MQTT (Datei 00_MQTT.pm) und MQTT2_CLIENT; meine Experiemente würden (bis auf weitere cpan-Perl-Module, die man für 00_MQTT.pm wohl installieren müßte) 1:1 auch mit diesen beiden IO-Modulen funktionieren, wobei auch MQTT2_CLIENT im autocreate-Modus möglich wäre, wenn man eine entsprechende bridgeRegexp (bzw. einen weiteren Eintrag in der Liste des "allgmeinen bridgeRegexp-MQTT2_DEVICE") setzt.

Was mir aber fehlte, war/ist eine Möglichkeit über MQTT Aktionen in FHEM auszuführen. Ein reading mit einem MQTT topic zu verknüpfen, kein Thema. Aber wie wird die Änderung eines MQTT topic an ein FHEM device gemäß den Anforderungen der Module in der commadref übergeben? 

Wir sind uns vermutlich völlig einig, dass es extrem schwierig ist, das aus der commandref zu MGB abzuleiten, und selbst wenn man den "Beispiel"-Thread gefunden hat, bleiben viele Fragen offen (wobei ich zugeben muss, dass ich das dann auch eher kurz überflogen hatte, es kann also sein, dass auch Beispiele zu "expression" und "Alias" vorhanden sind (!)).

Mein Angang wäre, hier eine Art Standard zu setzen, den man (gerne auf dem attrTemplate-Weg, aber das ist kein "Muss") als "einfacher user" dann eben relativ leicht übernehmen kann, ohne sich auf der FHEM-Seite _und auf der Seite der externen Lösung_ groß mit irgendwelchen Syntax-Fragen zu belasten.

Was ich mir vorstellen könnte ist, in Anlehnung an meinen Ansatz, dass die MGB genau ein solches topic in MQTT zum Ausführen von Befehlen zur Verfügung stellt, so das man kein notify braucht.

Nochmal: das kannst du auch direkt mit MQTT2_DEVICE, den Code dafür hatte ich bereits gepostet. Das hat aber eben ein paar Nachteile:
- Es ist eine generische Schnittstelle. Man kann grundsätzlich JEDEN Befehl so an FHEM übermitteln. Ergo muss zusätzliche Maßnahmen ergreifen, um dann dieses Sicherheitsloch irgendwie wieder zu begrenzen.
- Die Syntax ist nicht "MQTT-like". Die externe Software muss einen FHEM-Befehl zusammensetzen. Es erschließt sich mir nicht, wo der Vorteil sein soll, wenn man an tasmota an einen set-Topic eine simple Payload "on" (oder ON oder eine 1)  senden soll, aber an FHEM alles über einen zentralen Topic eine Payload mit FHEM-spezifischer Syntax ("set xy on"). Ist doch auch von extern viel komplizierter, oder übersehe ich was...?

[Wzut]

MQTT2 ist ein integriertes FHEM Modul das prädestiniert ist, zwischen FHEM Instanzen Daten auf Basis MQTT Protokoll auszutauschen

Für eine reine FHEM-FHEM Kopplung gibt es IMHO bessere Wege, solange eine Nicht-FHEM Instanz da nicht mitreden will.

[Beta-User]

Für eine reine FHEM-FHEM Kopplung gibt es IMHO bessere Wege, solange eine Nicht-FHEM Instanz da nicht mitreden will.

Anmerkung: Das dürfte häufig richtig sein, aber die MQTT-Anbindung läuft asynchron bzw. "abbruch-tolerant", was z.B. ein Vorteil ist, wenn man ein Mobilfunknetz dazwischen hat. Außerdem kann man mit MGB ggf. die Reading-Namen (und ggf. Werte) gleich "normalisieren" und aussortieren, was man nicht braucht, bei FHEM2FHEM ist es afaik einfach eine (vollständige) 1:1-Kopie.

Vielleicht auch nochmal zum Unterstreichen des Sicherheitsaspekts zwei Zitate von hexenmeister (den ich zwischenzeitlich informiert habe, dass hier u.A. MGB ein Thema ist) zu globalPublish und globalSubscribe (ich hatte dort nicht absichtlich abgeschrieben...):

Oh ... aber mit globalPublish ist es wohl am einfachsten!

Heißt das, dass globalPublish wieder verschwinden kann und nicht supported ist?

Einfach ja, gut - meistens nicht. Damit pustet man ohne Kontrolle Daten raus. Kommt später ein neues Gerät hinzu - werden möglicherweise Daten gesendet, die man nicht senden wollte. Beim subscribe hätte man u. U. damit gleich ein Sicherheitsproblem.
globalPublish ist schon drin und wird auch jetzt bleiben, man sollte jedoch die Risiken im Auge behalten. globalSubscribe wird es aber nicht geben.

globalSubscribe ist iMo. ziemlich nahe an der "notify-'Lösung'", aber immer noch deutlich "eingeschränkter"...

[hexenmeister]

Hallo allerseits,

ich hätte vermutlich diese Diskussion hier tatsächlich niemals von allein mitbekommen. Daher danke an Beta-User! 

Ich habe die MQTT_GENERIC_BRIDGE geschrieben, weil mir der Weg mit MQTT_DEVICE und MQTT_BRIDGE zu aufwendig und zu unlogisch war. Auch wenn ich diese Module letztendlich übernommen habe, so "richtig" angefreundet habe ich mich damit nicht. Aber sie erfüllen sein Zweck und, als ich mit der Bridge angefangen habe, gab es noch nichts anderes. Leider sind diese Module auch intern etwas ungewöhnlich aufgebaut, das hat auch seine Spur in der MGB-Code hinterlassen.

Wie für manche anderen hier, ist für mich MQTT eine Art Middleware, um FHEM-Instanzen, MQTT-native Geräte (wie Tasmota) und ggf. andere Automation-Lösungen miteinander zu verbinden. Eben darum ist die Bridge so flexibel aufgebaut - damit man alles verbinden kann und jedem ggf. sein Dialekt zu ermöglichen. Einiges ist entstanden "auf dem Weg", anderes ist durch Wünsche aus der FHEM-Gemeinde dazugekommen. Sicher habe ich nicht alles konsequent durchzuhalten geschafft und die Kritik zu der Doku ist sicher berechtigt - macnhmal musste ich schon selbst überlegen, wie ich das  gemeint hat Bin offen für Vorschläge, wie man es besser beschreiben kann, werde die Doku ggf. überarbeiten.
Auch für neue Features bin ich offen, soweit wir gemeinsam zu einer Linie kommen und alle sich über deren Nutzen einig sind.
Bin leider aus mehreren Gründen zeitlich etwas eingeschränkt, werde daher nicht immer gleich antworten können, werde mir aber schon Zeit suchen.

Ich finde es besser, die MQTT-Anbindung zentral zu halten, ohne sie in jedem Modul einzeln unterstützen zu müssen - das führt zwangsläufig zu unterschiedlichen Implementierungen und Dialekten.

Ich habe nicht ganz verstanden, was hier über Ausführung der FHEM-Befehle über MQTT diskutiert wurde - die MGB kann das ja über die Ausführung der 'set' Commandos der Geräte, dafür gibt es 'stopic'. Wenn es jedoch gemeint ist, die nativen FHEM Befehle von außen anzusetzen - dovon halte ich aus diversen Gründen gar nichts (unsicher, proprietär,..).

Zu guter Letzt mal ein Beispiel, wie ich HM Thermostat per MQTT weiterreiche, ist natürlcih nur eine der vielen möglichen Lösungen und hat keinen Anspruch auf "Perfektion" :

Code Auswählen Erweitern


defmod KU_WT01_Climate CUL_HM xxx
attr KU_WT01_Climate group Steuerung
attr KU_WT01_Climate icon hm-tc-it-wm-w-eu
attr KU_WT01_Climate model HM-TC-IT-WM-W-EU
attr KU_WT01_Climate peerIDs 00000000,xxx,
attr KU_WT01_Climate room HomeMatic->Küche

attr KU_WT01_Climate mqttDefaults roomid="ku" num="01"  roomname="Küche"  dev_manuf="HomeMatic"

attr KU_WT01_Climate mqttPublish desired-temp:topic={"$base/usr/$roomid/act/clima/temperature/$num/value"} \
\
desired-temp!json:topic={"$base/usr/$roomid/act/clima/temperature/$num/json"}  \
desired-temp!json:expression={toJSON({value=>$value,time=>"$time",reading=>"desired-temp",num=>"$num",unit=>"°C",\
  valuetype=>"number",format=>"00.0",roomid=>"$roomid",room=>"$roomname",display=>"Solltemperatur"})}\
\
desired-temp!info:topic={"$base/usr/$roomid/act/clima/temperature/$num/info"} \
desired-temp!info:expression={toJSON({manuf=>"$dev_manuf",type=>"actor",categorie=>"clima",\
  reading=>"desired-temp",num=>"$num",unit=>"°C",valuetype=>"number",format=>"00.0",\
  roomid=>"$roomid",room=>"$roomname",name=>"$device",dev_uid=>"$uid",display=>"Solltemperatur",act_topic=>"set"})}\
\

attr KU_WT01_Climate mqttSubscribe desired-temp:stopic={"$base/usr/$roomid/act/clima/temperature/$num/set"}


MGB-Device vollständigkeitshalber:

Code Auswählen Erweitern


defmod mqttGenericBridge MQTT_GENERIC_BRIDGE
attr mqttGenericBridge IODev mqtt
attr mqttGenericBridge alias MQTT generic bridge
attr mqttGenericBridge globalDefaults base=home
attr mqttGenericBridge group MQTT
attr mqttGenericBridge icon mqtt
attr mqttGenericBridge room IO_Devices
attr mqttGenericBridge stateFormat dev: device-count in: incoming-count out: outgoing-count

Es entsteht im MQTT-Raum ein Topic-Baum mit aktuellen Informationen zu dem Gerän und seinem Stand:

Code Auswählen Erweitern


home/usr/ku/act/clima/temperature/01/value = 20.0

home/usr/ku/act/clima/temperature/01/json =
{
  "display": "Solltemperatur",
  "format": "00.0",
  "num": "01",
  "reading": "desired-temp",
  "room": "Küche",
  "roomid": "ku",
  "time": "2021-01-11 23:52:34",
  "unit": "°C",
  "value": "20.5",
  "valuetype": "number"
}

home/usr/ku/act/clima/temperature/01/info =
{
  "act_topic": "set",
  "categorie": "clima",
  "dev_uid": "5cdfd0c2-f33f-7939-0094-25d29e02aeaf78a4",
  "display": "Solltemperatur",
  "format": "00.0",
  "manuf": "HomeMatic",
  "name": "KU_WT01_Climate",
  "num": "01",
  "reading": "desired-temp",
  "room": "Küche",
  "roomid": "ku",
  "type": "actor",
  "unit": "°C",
  "valuetype": "number"
}


"info" ist dabei statisch und retained, soll dem Empfänger erlauben, sich gleich nach dem Connect eine Übersicht der Geräte und deren Eigenschaften zu verschaffen.

Zudem existiert ein Steuer-Kanal zum Setzen der Temperatur:

Code Auswählen Erweitern

home/usr/ku/act/clima/temperature/01/set

An der Gegenüberseite steht eine weitere FHEM-Instanz, die als Steuer-Oberfläche dient (ich schaue mich immer mal um, ob ich etwas anderes dran schrabe, HAS wäre ein guter Kandidat. Das schöne dabei ist, man kann alles auch parallel zueinander betreiben) und NodeRED, wo u.a. eine generische Anbindung zum Befühlen der InfluxDB (für Grafana-Dashboard) realisiert ist (daher auch einige zusätzlichen Parameter in "json" und "info"). Alles jedoch noch nicht 100% ausgereift, komme nie dazu, die Fleißaufgaben zu Ende zu bringen.

[rudolfkoenig]

Ich habe nicht ganz verstanden, was hier über Ausführung der FHEM-Befehle über MQTT diskutiert wurde - die MGB kann das ja über die Ausführung der 'set' Commandos der Geräte, dafür gibt es 'stopic'.

Zeigt nur, dass ich die Doku nicht sorgfaeltig gelesen habe, danke fuer den Wink mit dem Zaunpfahl.

Gibt es einen Grund, warum MQTT::parseParams gegenueber main::parseParams verwendet wird? Die MQTT:: Variante scheint von der main:: Variante abgeleitet worden zu sein. Das hinzugefuegte Feature mit dem acceptedkeys Parameter wird in 10_MQTT_GENERIC_BRIDGE nicht verwendet.

Mit dem angehaengten Patch braucht MQTT_GENERIC_BRIDGE kein MQTT.pm (und damit kein Module::Pluggable), falls als IODev  MQTT2_SERVER/CLIENT verwendet wird. Meine einfachen Tests mit

Code Auswählen Erweitern

defmod mgb MQTT_GENERIC_BRIDGE
define d dummy
attr d setList on off
attr d mqttPublish humidity:topic=/TEST/Feuchte
attr d mqttSubscribe state:stopic=/TEST/set

funktionieren, sowohl mit MQTT als auch mit MQTT2_SERVER
Zu etwas Komplexeres bin ich im Moment nicht in der Lage