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

[arm9999]

Hallo,

MAX Thermostate abzufragen und zu steuern da gibt es ja einige Methoden und Ansätze, jeder hat da so seine Vorlieben. Wenn der Wunsch nach einer Kopplung mit anderen Systemen besteht, dann kommt man sehr schnell an einen Punkt wo man Daten austauschen und ändern möchte.

Bei mir laufen in der Hausautomatisierung eine Vielzahl von Sensoren, Aktoren und Geräte, die über eine zentrale Oberfläche und Steuerung zusammengefasst sind. Als führendes System hatte ich mich mal für Homeassistant entschieden, dass auf einem Raspberry Pi3B läuft. Für die Anbindung der jeweiligen Herstellersysteme und Gateways kommt bei mir FHEM zum Einsatz und als konsolidierende Datenbank MQTT.

Hört sich kompliziert an, ist es aber nicht
MQTT ist eine standardisierte Methode über die Maschinen Daten bereitstellen und austauschen können. Dazu benötigt man eine Datenbank in der alle Informationen gespeichert sind und einen Protokollhandler der als Broker fungiert. Die Geräte die diese Datenbank dann nutzen sind MQTT Devices die Nachrichten senden (publish) und lesen (subscribe) können. Da ich ein Freund von freier Software bin kommt hier MOSQUITTO zum Einsatz. Unter mosquitto.org/download gibt es für jede Plattform eine passende Installation, die unkompliziert und einfach ist.

Haben wir einen MQTT Broker installiert, dann kommt als nächster Schritt die Kopplung mit FHEM. Zuerst richten wir eine Schnittstelle (Gateway) zum Broker ein:
> IP Adresse und Port eures Brokers verwenden.

Code Auswählen Erweitern

# MQTT Gateway
define MQTTGW MQTT 192.xxx.0.xxx:1883
attr MQTTGW alias MQTT GW
attr MQTTGW icon mqtt
attr MQTTGW last-will retain:1 fhem/connection/state getrennt
attr MQTTGW on-connect retain:1 {Log3("mqtt",3,"connected to MQTT server");;;;1} fhem/connection/state verbunden
attr MQTTGW on-disconnect retain:1 {Log3("mqtt",3,"disconnected from MQTT server");;;;1} fhem/connection/state getrennt
attr MQTTGW room Gateway


Kleines Schmankerl: das MQTT gateway schreibt seinen Status auch gleich in die MQTT Datenbank, so dass man sehen kann ob es läuft
oder nicht. Dies wird über on-connect und on-disconnect gesteuert. Der Status ist unter dem topic fhem/connection/state in MQTT verfügbar.

Damit FHEM mit dem Broker kommunizieren kann, brauchen wir eine MQTT Bridge. Die wird wie folgt angelegt:

Code Auswählen Erweitern

# MQTT Bridge
define mqttGeneric MQTT_GENERIC_BRIDGE
attr mqttGeneric IODev MQTTGW
attr mqttGeneric globalDefaults sub:qos=2 pub:qos=0 retain=1
attr mqttGeneric globalPublish *:topic={"fhem/$device/$reading"} *:resendOnConnect=last
attr mqttGeneric icon mqtt_bridge_1
attr mqttGeneric room MQTT_Bridge
attr mqttGeneric stateFormat dev: device-count in: incoming-count out: outgoing-count


Die Bridge legt in der MQTT Datenbank einen Pfad (topic) mit Namen FHEM an. Unter diesem topic werden dann alle FHEM devices und darunter die jeweiligen readings angelegt. Und schon sind alle devices und readngs von FHEM über MQTT sichtbar.

Wer wissen will wie das in der MQTT Datenbank aussieht und Werte manipulieren möchte ... hier das meiner Meinung nach beste Schweizer Taschenmesser dafür: MQTT-Explorer-0.3.5 unter mqtt-explorer.com zu finden.

Und wie kann man nun FHEM über MQTT steuern ?
Mein Ansatz ist, an FHEM direkt shell Befehle zu übergeben, so ist man unabhängig von weiteren Schnittstellen/APIs und jedes andere Programm kann an FHEM Befehle senden. Auch hier nutze ich wieder MQTT als Plattform  .

Zuerst legen wir in MQTT unter dem topic FHEM einen Untertopic mit Namen Befehlausfuehren an. Sieht dann so aus: fhem/Befehlausfuehren
Das anlegen geht über den MQTT Explorer oder man schickt über seinen Broker eine publish Nachricht mit fhem/Befehlausfuehren 0.

Damit FHEM mitbekommt was wir in dieses topic reinschreiben, legen wir in FHEM ein MQTT-Device an, das dem topic fhem/Befehlausfuehren folgt und ausliest wenn sich hier was ändert.

Code Auswählen Erweitern


# MQTT Device
define SYS_MQTT MQTT_DEVICE
attr SYS_MQTT userattr subscribeReading_cmnd
attr SYS_MQTT IODev MQTTGW
attr SYS_MQTT alias MQTT_Command
attr SYS_MQTT icon mqtt_device
attr SYS_MQTT room MQTT_Bridge
attr SYS_MQTT subscribeReading_cmnd fhem/Befehlausfuehren


und zu guter letzt, ein Notify was unseren Befehl in FHEM dann auch ausführt:

Code Auswählen Erweitern


# MQTT command notify
define n_SYS_MQTT_cmnd notify SYS_MQTT:cmnd:.* \
{\
  if($EVENT =~ qr/.*?: (.*)/p)\
  {\
    my $cmnd = $1;;\
    Log3 ($NAME,5,"execute mqtt command : ".$cmnd);;\
    fhem($cmnd);;\
  }\
}
attr n_SYS_MQTT_cmnd alias Befehle über MQTT in FHEM ausfuehren
attr n_SYS_MQTT_cmnd icon mqtt
attr n_SYS_MQTT_cmnd room FHEM notify


FERTIG 
Wir haben nun alle Readings in MQTT zur Verfügung und können jeden Wert auslesen. Möchten wir etwas ändern, dann schreiben wir in das topic fhem/Befehlausfuehren was wir machen wollen,

zum Beispiel: set MAX_181122 desiredTemperature auto 22.0

FHEM führt diesen Befehl direkt aus und ändert die Temperatur am WT/HT. 


Viel Spaß damit und ich freue mich über euer feedback und Anregungen.
(demnächst ergänze ich mal, wie man MAX Thermostate und Wandthermostate über ein einfaches WebScript in FHEM über jeden Browser ändern kann, vor allem die Erstellung des Wochenprogramms.) 

[Beta-User]

So richtig verstehe ich nicht, was das Thema speziell mit MAX! zu tun hat...

Generell halte ich den Weg über das "MQTT-notify" für nicht empfehlenswert!
Und auch das globale publish ist m.E. suboptimal, v.a., wenn man sich nicht vorher mal intensiv mit der Event-Seite mancher "super-gesprächiger" Devices auseinandergesetzt hat.

Jedenfalls zu der notify-"Lösung": Man reißt sich damit ein riesiges Sicherheitsloch nach FHEM, Details dazu - und wie man es mAn. besser macht - sind ab hier zu finden: https://forum.fhem.de/index.php/topic,109192.msg1095845.html#msg1095845.

Alles nicht so "super-easy", aber eben sauber!

[Wzut]

So richtig verstehe ich nicht, was das Thema speziell mit MAX! zu tun hat...

das war eine Bitte von mir weil das Stichwort MQTT in einem anderen Thread gefallen ist und ich dort nicht OT diskutieren/fragen wollte.
Generell interessieren mich halt auch Dinge die etwas über dem MAX Tellerrant liegen. Auch wenn ich bei weitem kein MQTT Guru bin (trotz meiner vier Gosunds als Weihnachtsbeleuchtung) wollte ich mir das mal genau ansehen und der Hintergedanke war ob man nicht schon von der MAX Modul Seite aus da etwas zuarbeiten kann. Wenn da also irgend welche Ideen vorhanden sind, dann immer her damit.

@arm9999 , THX für das ausführliche Posting. 

[Beta-User]

OK, dann verstehe ich den Forenbereich.

Wie an anderer, bereits verlinkter Stelle schon bemerkt, finde ich die hier vorgestellten Mechanismen an zwei Stellen äußerst fragwürdig:
- global publish an MGB bläst afaik einfach "alles" in die weite Welt hinaus. Das mag ok sein, wenn man nur "MAX auf der FHEM-Insel" betreibt, aber generell ist es m.E. ein Unding (@Wzut wegen des Hintergrunds: es gab in jüngerer Vergangenheit ein paar Threads, die sich mit der Zahl der Events befassen und der Hänger, die das Verursachen kann).
- das notify schließlich öffnet einen allgemeinen, völlig ungesicherten Weg, beliebige Kommandos an FHEM zu übermitteln. MAn. ein ABSOLUTES NOGO. (@arm999: das ist nicht persönlich gemeint, ich vermute, du nutzt FHEM nur als Nebensystem und hast dich mit den Mechanismen "dahinter" nie befasst und auch kein Problem damit, dass dann die ausgeführte Anweisung wieder an dein Hauptsystem zurückgespielt wird. Aber wenn man nicht aufpasst, kann man sich auf diesem Weg auch eine sehr lästige Dauerschleife bauen...)

Kurz: Wenn man es richtig macht, muss man deutlich mehr Aufwand treiben, was v.a. für die Nutzer ziemlich schwierig ist, die FHEM nur als Nebensystem zur Hardwareintegration einsetzen.

Als lästig scheint insbesondere das Setzen der Attribute für die MQTT_GENERIC_BRIDGE empfunden zu werden, wenn man es richtig macht, braucht man afaik je eines für die Sende- und Empfangsrichtung. MGB kann eine Art "base-topic" verwenden, von daher wäre es _möglich_, sowas auch für Geräte wie die MAX-Devices zu ver-attrTemplaten, um das zu vereinfachen (und ggf. auch zu standardisieren).

Ob das wünschenswert wäre, ist eine andere Frage.
@Wzut: MAX wäre vermutlich geradezu "prädestiniert", hier ggf. sowas wie den Vorreiter zu spielen (Umsteiger vom Alzheimer-Cube bzw. Aussteiger aus der Wolke), relativ überschaubare Anzahl von Geräten und Readings...
Beantwortet aber nicht die Frage, ob es wünschenswert ist...

WENN ihr eine Art "Musterimplementierung" bauen wollt, nehmt aber bitte ein MQTT2_IO, dann reicht "pluggable" als zu installierendes OS-Perl-Modul, sonst braucht man noch 2 weitere von cpan (so jedenfalls mein Kenntnisstand).

@arm999: Wzut kann dir vermutlich bestätigen, dass es in der Regel (und auch insbesondere hier) nicht persönlich gemeint ist, wenn ich so deutlich "Kante" zeige, schon gleich nicht, wenn es darum ging, eine Musterlösung zu entwickeln/zu zeigen...

@Wzut: Falls du das irgendwie nachvollziehen willst, was da in MQTT passiert, würde ich ein Zweit-FHEM mit MQTT2_SERVER empfehlen; daran "klinkst" du dann in deinem MAX-Testsystem einen MQTT2_CLIENT dran, holst das "pluggable" und aktivierst eine MGB (aber ohne das globale publish, oder von mir aus auch gerne mal sowas im Hauptsysstem, damit du siehst, was ich meine mit "rauspusten").

[Wzut]

Ich lese viele Beitäge im Forum daher kenne ich natürlich auch die jüngsten Diskussionen zum Thema überflüssige/zu viele Events und bin auch bereit mir an gegebener Stelle an die eigene Nase zu fassen. Mir ist auch nicht entgangen das es garade in den letzten Wochen immer wieder hoch kam das bestimmte MQTT Geräte irrsinnig geschwätzig sind, allerdings bleib es bisher immer nur beim lesen da ich mangels Geräte keine eigene Erfahrung habe.
Aber die vier Tasmota-Gosunds werden ja in 5 Tagen frei und wenn ich ab da dann endlich etwas tiefer in die MQTT Welt abtauche werde ich mir mit Sicherheit noch Rat bei Leuten die Ahnung haben holen bevor ich da eine neue Datenschleuder in Umlauf bringe.

[Beta-User]

Na ja, wenn du dich in das Thema einarbeiten willst und schon einen MQTT2_SERVER am laufen hast, kannst du MGB auch so mal austesten...

MGB ist eigentlich dafür gemacht, eine Schnittstelle für "nicht"-MQTT-Geräte zu MQTT anzuflanschen, und man kann die Geräte auch via devspec einschränken. Sollte z.B. so gehen:

Code Auswählen Erweitern

defmod mqttGeneric MQTT_GENERIC_BRIDGE TYPE=MAX
Dann kannst du z.B. mit mosquitto_sub auch "von außen" lauschen, was der MQTT2_SERVER so "zu bieten hat", wenn man ansonsten die globalPublish-Lösung von hier verwendet und auch mal checken, ob du mit mosquitto_pub "set"-Befehle (via "richtigem subscribe, wenn möglich) an die MAXe ranbekommst...

[arm9999]

@Beta-User,
kein Thema, kannst gerne direkt alles ansprechen was dir auf dem Herzen liegt und wer tiefer in MQTT einsteigen möchte, dem sei natürlich das Forum und dein Thread hier ans Herzen gelegt.

Als MQTT Insider hast du ja gleich erkannt, das meine Bridge alle FHEM devices und deren Readings nach MQTT überträgt und das ist auch gewollt, da ich alles zur Verfügung haben möchte. Wem das zuviel ist oder nur bestimmte devices oder Readings braucht, schränkt das im verwendeten Filter einfach ein, optional kann man ein Notify für ein spezielles Reading erstellen und dieses über publish nach MQTT transportieren - da gibt es so viele Ansätze und Möglichkeit, ganz so wie man es für seinen spezifischen Anwendungsfall braucht.

FHEM ist für mich eine supertolle middleware mit besonderen Fähigkeiten die ich mir zu nutze mache, um die Funktionalität von z.B. homeassistant zu erweitern (oder anderen Systemen).

Was das Lastverhalten angeht, so "langweilt" sich mein FHEM mit den knapp 100 devices die es betreut (und nein, es ist keine highend HW, nur ein alter Z83 mit Windows 10).   

Deine Sicherheitsbedenken kann ich aber nicht teilen - wer möchte kann alle security Mechanismen von FHEM auch mit MQTT nutzen, liegt an jedem selbst was er wie zugänglich macht. Bei mir zum Beispiel ist die gesamte Hausautomatisierung in einem nicht öffentlich zugänglichen eigenen Bereich meines Netzwerkes und es gibt auch keinerlei cloud-Anbindungen oder Dienste. Möchte ich mal von "außen" auf etwas zugreifen, so nutze ich eine verschlüsselte zertifikatsbasierte VPN Verbindung - that's my way 

Wichtig für mich: verfügbare Möglichkeiten, zu Aufwand und wirklichem Nutzen in der Waage zu halten. Habe ich ein dediziertes System, reiße ich ja "kein riesiges Sicherheitsloch" oder "blase alles in die Welt" hinaus. Der "einzige Angreifer" in meiner Installation sitzt bei mir selbst an den Tasten und den ich kenne persönlich 


@Wzut
dein Gedanke die Readings für MQTT über das Modul verfügbar zu machen gefällt mir. Ich denke man bräuchte dann beim device selbst ein Atrtribute ob Readings nach MQTT exportiert werden sollen und ein weiteres Attribut unter welchem topic das geschehen soll. So könnte man je device entscheiden ob und wohin ein MQTT publish erfolgen soll. Vielleicht ließe sich noch implementieren, dass Änderungen auch über MQTT empfangen und an die HT/WTs weitergeleitet werden - das wäre dann die Kür - über die boardmittel von FHEM lässt sich das allerdings heute schon prima und zuverlässig machen.

[Beta-User]

Wichtig für mich: verfügbare Möglichkeiten, zu Aufwand und wirklichem Nutzen in der Waage zu halten. Habe ich ein dediziertes System, reiße ich ja "kein riesiges Sicherheitsloch" oder "blase alles in die Welt" hinaus. Der "einzige Angreifer" in meiner Installation sitzt bei mir selbst an den Tasten und den ich kenne persönlich 

Na ja, man kann über diesen Weg auch ein "delete .*" an FHEM senden, man muss nur irgendwie Zugang zu deinem Broker haben und den Topic identifizieren. Am Ende muss das jeder selbst wissen, ich will nur deutlich machen, dass das deutlich weiter greift, als die Möglichkeiten zu nutzen, die MQTT_GENERIC_BRIDGE bietet.

@Wzut
dein Gedanke die Readings für MQTT über das Modul verfügbar zu machen gefällt mir. Ich denke man bräuchte dann beim device selbst ein Atrtribute ob Readings nach MQTT exportiert werden sollen und ein weiteres Attribut unter welchem topic das geschehen soll. So könnte man je device entscheiden ob und wohin ein MQTT publish erfolgen soll. Vielleicht ließe sich noch implementieren, dass Änderungen auch über MQTT empfangen und an die HT/WTs weitergeleitet werden - das wäre dann die Kür - über die boardmittel von FHEM lässt sich das allerdings heute schon prima und zuverlässig machen.

Genau das ermöglicht MGB nämlich: klare set-Anweisungen an die Devices zu verteilen, für die man das wirklich braucht und will, und zwar afaik mit dem "Zuckerstückchen", dass MGB auch überwacht, dass man keine unbeabsichtigten loops baut...

Dazu muss man nicht die Funktionalität der MAX-Module aufbohren, sondern kann einfach nutzen, was MQTT_GENERIC_BRIDGE bereitstellt. Deine  Antwort zeigt ja auch, dass dir dieser Teil der Funktionalität bisher unbekannt war, oder täuscht das?

Die Attribute sind in einem Thread von hexenmeister eigentlich sehr gut beschrieben, mAn. paßt das hier schon recht gut: Aktoren, die in einer FHEM-Instanz definiert sind, aus einer anderen schalten

[LuckyDay]

den Ansatz von @arm9999

hätte er die neuen Module Mqtt2 -> client bzw device genommen würde ich hier auch etwas schreiben

die MQTT_GENERIC_BRIDGE benütze ich nicht!
a. mit der syntax komme ich nicht wirklich klar , liegt aber daran das sie sich komplet von Mqtt2 unterscheidet
und
b. Dummy geht gar nicht bei mqtt2, das erledigt man mit man mit einem mqtt2 device!
c. bei mqtt kennt man keinen Absender, ergo ist alles fälschbar --> Thema Sicherheit.

bei mir läuft die Trennung der FhemDienste(Signatur) bereits seit mehr als einem Jahr
liegt zum Teil daran, Bude zu groß, Wartbarkeit-> keine Angst mehr vor Update

[Beta-User]

hätte er die neuen Module Mqtt2 -> client bzw device genommen würde ich hier auch etwas schreiben

Na ja, wenn man "von außerhalb" kommt und eher das allgemeine Internet als Info-Quelle nutzt, kommen halt viele ältere Anleitungen, die die "klassischen" Module nutzen, und von daher ist es auch wenig verwunderlich, dass dann noch nicht mal verschlüsselte Verbindungen verwendet werden...

Und dieses mAn. unselige "SYS_MQTT" scheint leider weiter verbreitet zu sein wie man so denkt...

die MQTT_GENERIC_BRIDGE benütze ich nicht!

Ich hatte die auch nur mal kurz im Einsatz und kann nachvollziehen, dass es für einen "notify"&Co-Kenner erst mal viel einfacher erscheint, das mit anderen Bordmitteln zu erledigen.
Um Readings zu publishen, reicht ja im Prinzip ein notify, das - ähnlich wie ein FileLog-Device - halt die gewünschten Events abgreift und dann direkt an das IO schreibt.

Aber für das Steuern _glaube ich_, dass es via MQTT_GENERIC_BRIDGE einfacher ist, wenn man sich erst mal eingearbeitet/eingedacht hat. Man pflegt in publish- bzw. subscription-Richtung je ein Attribut pro "regulärem Device" (ähnlich setList/readingList bei MQTT2_DEVICE) und hat damit die Anbindung dieses Devices an MQTT.

Von daher fände ich es lohnenswert, da Syntaxbeispiele für sowas standardisiertes wie Thermostate anzubieten, das ganze aber tendenziell eher als separaten attrTemplate-Satz ähnlich der Sprachsteuerungsgeschichte (und auch nicht automatisiert aufgerufen!).

b. Dummy geht gar nicht bei mqtt2, das erledigt man mit man mit einem mqtt2 device!

Sehe ich ähnlich, es gibt aber ein paar Gewohnheitstiere, die aus der alten Welt kommen und MQTT_DEVICE nicht so prickelnd zu konfigurieren fanden (da braucht man pro Reading ein Attribut) und daher auf die Kombination von dummy+MQTT_GENERIC_BRIDGE ausgewichen sind.
Das geht auch und läuft im Ergebnis praktisch auf's selbe raus. Aber wer neu anfängt, sollte von niemanden auf dummy oder MQTT_DEVICE verwiesen werden.

c. bei mqtt kennt man keinen Absender, ergo ist alles fälschbar --> Thema Sicherheit.

Von daher sind wir uns vermutlich einig, dass das SYS_MQTT-notify an sich schon ein no-go ist, schon gleich ohne gesicherte Verbindungen...

bei mir läuft die Trennung der FhemDienste(Signatur) bereits seit mehr als einem Jahr
liegt zum Teil daran, Bude zu groß, Wartbarkeit-> keine Angst mehr vor Update

Du hattest dazu - wenn ich mich recht entsinne - auch mal ein paar Code-Brocken irgendwo gepostet. Vielleicht magst du das im "Workshop" verlinken und/oder (kurz) so aufbereiten, dass man das Prinzip in Sende- und Empfangsrichtung erkennen kann, wie das bei dir läuft? (Und ggf. auch die Aufteilung in "logische Segmente" wg. blocking usw.?)
(Lieber irgendwo ein "sicheres Beispiel" dargestellt, das man wiederfindet wie Neulinge dazu verleitet, funktionierende unsichere Beispiele zu kopieren, weil sie nichts besseres gefunden haben...)

OT: Falls jemand Fragen oder Anmerkungen zum MQTT2-Workshop hat, darf er gerne einen Thread dazu eröffnen, es ging mir vorrangig darum, erst mal alles mögliche an Aspekten zusammenzutragen, das nimmt nicht für sich in Anspruch, "best practice" sein sondern soll auch als Diskussionsgrundlage dienen. Leider scheint es in dieser zusammengewürfelten Form "schwer verdaulich" zu sein...?

[Wzut]

Ich habe mal etwas gespielt. Der erste Schritt war naürlich die Werte eines/aller MAX Geräte meiner Testinsel zum MQTT Server zu publishen
( MQTT Server hatte ich schon auf meinem aktiven FHEM -> MQTT2_SERVER )
Ich habe zuerst das Beispiel von arm9999 mit MQTT & MGB benutzt und nachdem mit klar war wie die Nachrichten aussehen direkt auf MQTT2_CLIENT umgestellt. Damit da nicht jedesmal X Topics übertagen werden habe ich 10_MAX eine zusätzliche sub spendiert die alle Readings des Device als ein JSON Block zum MQTT2_SERVER überträgt. Der MQTT2_SERVER hat attr autocreate complex und auch sofort ein neues MQTT2_DEVICE angelegt und mir die Json Liste in die Readings sortiert. Noch ne kleine Anpassung bei readingList und mein Thermostat Template drüber und schon ist das MQTT2 Thermostat optisch nicht mehr von einem echten MAX Thermostsat zu unterscheiden. Soweit so gut , über die sinnvolle Topic Namen reden wir später.

Nun ging es an den Rückweg : beim MQTT2_DEVICE setList ausgefüllt und auf der Testinsel beim MQTT2_Client noch das Attribut subscriptions gesetzt.
Im verbose 5 Log des MQTT2_Client sehe ich nun auch wenn ich auf dem anderen System die Soll Temperatur ändere , soweit so gut.

Wenn ich bis jetzt alles richtig verstanden habe wäre nun der nächste Schritt das was ich bereits im Log sehe nun einem MQTT2_Device unterzuschieben. OK und dann ?  Bei arm9999 kam ja jetzt das verteufelte notify ins Spiel. Wie mache ich es nun richtig ohne notify ?
Wieder ran ans 10_MAX und das MQTT2_DEVICE als notifydev setzen ?   Werd ich morgen mal testen , für heute ist es genug.

[Beta-User]

Wenn ich bis jetzt alles richtig verstanden habe wäre nun der nächste Schritt das was ich bereits im Log sehe nun einem MQTT2_Device unterzuschieben. OK und dann ?  Bei arm9999 kam ja jetzt das verteufelte notify ins Spiel. Wie mache ich es nun richtig ohne notify ?
Wieder ran ans 10_MAX und das MQTT2_DEVICE als notifydev setzen ?   Werd ich morgen mal testen , für heute ist es genug.

Nochmal: V.a. die Empfangsseite ist die eigentliche Aufgabe und m.E. Stärke von MQTT_GENERIC_BRIDGE. Man _kann_ das auch umgehen oder dieses vermalledeite notify durch eine "direkte" Lösung mit MQTT2_DEVICE ersetzen. Hatte ich hier schon beschrieben:

[...] aber an der Stelle der Nachweis, dass das auch via MQTT2_DEVICE geht - dieses eine Device ersetzt dann die Kombination von MQTT_DEVICE und notify (allerdings ohne Log, aber das könnte man auch noch anflanschen...):

Code Auswählen Erweitern

define MQTT2_Notify_replacement MQTT2_DEVICE n_replacement
fhem/SYS_MQTT/cmnd:.*  { fhem($EVENT) }

Für MQTT_GENERIC_BRIDGE würde man auf Basis von dem hier

Aktoren, die in einer FHEM-Instanz definiert sind, aus einer anderen schalten
Dimmer

Aktor-Definition:

Code Auswählen Erweitern

defmod <actor-device-name> CUL_HM xxxxxx
attr <actor-device-name> model HM-LC-Dim1TPBU-FM
...
attr <actor-device-name> mqttPublish pct:topic=haus/wohnzimmer/licht/level state:topic=haus/wohnzimmer/licht/state
attr <actor-device-name> mqttSubscribe pct:stopic=haus/wohnzimmer/licht/set
[...]

eher zu sowas kommen (der versteht doch "desired-temp", oder?):

Code Auswählen Erweitern

defmod <max-device-name> MAX <was auch immer hierher gehört>
attr <max-device-name> mqttSubscribe desired-temp:topic=haus/wohnzimmer/<max-device-name>/desired-temp/set disable:atopic=haus/wohnzimmer/<max-device-name>/disable/set
(EDIT: "s" entfernt (topic= statt stopic=), geht ja nicht um state)

...fertig die Laube - unterstellt, man hat entweder autocreate ausgeschaltet oder alle eingehenden subscriptions via globaler bridgeRegexp auf eine CID "" umgeleitet...

Wie man sieht, spielt hier "die Musik" eher im Aufbau der Topic-Struktur, und afaik könnte man da auch bequem mit Variablen arbeiten (MGB kennt z.B. $room), so dass diese Topics dann eigentlich sogar identisch sind bei MAX-, CULH_HM- oder ZWave-Thermostaten... => one expression fits all, aber eben jeweils dort angeflanscht, wo man die Verbindung haben will.

Wegen der CID/autocreate-Thematik neige ich allerdings dazu, den "set"-Anteil am topic eher nach vorne zu ziehen und eindeutiger FHEM zuzuordnen:

Code Auswählen Erweitern

defmod <max-device-name> MAX <was auch immer hierher gehört>
attr <max-device-name> mqttSubscribe desired-temp:stopic=toFHEM/haus/wohnzimmer/<max-device-name>/desired-temp disable:atopic=toFHEM/haus/wohnzimmer/<max-device-name>/disable
Dann kann man das leichter über eine bridgeRegexp auf MQTT_GENERIC_BRIDGE "ableiten"...

[Wzut]

Ich möchte die Arbeit von hexenmeister die er in MGB gesteckt hat aif keinen Fall klein reden,
allerdings sehe ich die MGB im Moment als Krücke um dem Device das MQTT Laufen beizubringen.
IMHO wäre der viel bessere Ansatz Modulautoren würden sich Gedanken machen in der Richtung "wie bringe ich meinem Device MQTT bei".
Aber als Option, d.h. der User kann es leicht nutzen in dem er ein/zwei Attribute setzt oder es lassen.

Ich habe nun das 10_MAX soweit das es komplett via MQTT ferngesteuert werden kann ( alle sets & gets ) ohne zusärtlichen Dummy oder DOIF/notify.
Mein Ansatz besteht wie bereits geschrieben im engen Zusammenspiel von 10_MAX und MQTT2_CLIENT, denn MQTT2_CLIENT kann sowohl alle aktuellen Readings veröffentlichen als auch aus dem Stand set/get Kommandos für ein MAX Device annehmen und diese zu ihm weiterleiten.
Hierzu ist beim MQTT2_CLIENT lediglich das Attribut subscriptions zu setzen.
Bsp : subscriptions = MAX/#
erwartet wird nun ein Topic mit folgendem Aufbau MAX/Name_des_MAX_Device/cmnd/<Kommando>
Bsp : MAX/Test_HT/cmnd/set:desiredTemperature 13.0
Beim Gerät Test_HT läuft das auf dessen NotifyFn, dort wird geprüft ob der Name im Topic mit dem eigenen Namen übereinstimmt -> Test_HT
und ob der Abschnitt Kommando ( set:desiredTemperature 13.0 ) mit set oder get beginnt. wenn ja wird der zweite Teil des Kommandos direkt ausgeführt -> desiredTemperature 13.0
In meinen Augen simpel, die Frage ist halt nur wo liegen bei diese Lösung die Fallstricke/nogos die ich z.Z. nicht sehe.


 

[Beta-User]

Klingt vielleicht radikal, aber ich sehe keinen Vorteil darin, eine zentrale "Krücke" (nur um die m.E. unpassende Wortwahl aufzugreifen) durch Zusatzaufwände bei jedem Modul (und zusätzliche Events?) zu doppeln, um dann "nicht-MQTT-like" Messages versenden zu können an starre topics (was machst du, wenn du zwei Instanzen über einen Broker laufen hast...? Ok, die Namen passend wählen...).
Das erhöht letztlich nur die Vielfalt, sehr viele User verstehen ja schon jetzt kaum die Zusammenhänge, und das wird durch sowas m.E. nicht besser....

Gut finde ich auf alle Fälle, dass die Kommandos immer nur begrenzte Wirkung entfalten können, das ist jedenfalls um Welten besser, als ungefiltert "csfrtoken" zu umgehen, und das ganze ggf.  via retain-flag auch noch auf dem Silbertablett zu präsentieren, falls sich jemand Zugang zum MQTT-Server verschafft hat...

Insgesamt wäre m.E. aber besser, wenn mehr Leute die vorhandenen Optionen etwas besser verstehen würden und wir uns ggf. auf "Standards zur Krücke" verständigen könnten (und ggf. den Aufwand treiben, MGB ohne weitere Perl-Module aktivieren zu können).

Nur meine 2ct, und nicht böse gemeint.

Nachtrag noch:
Das mit dem "get" ist eventuell interessant, im Moment scheint sowas bei MGB "nur" durch den Umweg "expression" möglich zu sein...

[rudolfkoenig]

So eine Kopplung gehoert aus meiner Sicht nicht in Geraete wie MAX/etc. MQTT ist z.Zt. in, vergleichbare Standards kommen und gehen (WebService anyone?), wenn die naechste Programmierer-Generation erwachsen wird, dann gibts wieder was Neues. Man kann die Modulentwickler nicht alle paar Jahre auffordern, das aktuell hochgehypte Standard zu implementieren, und fuer die Endanwender ist das auch keine Loesung.
Abgesehen von diesem "Architektur-Sicht" stellt sich die Frage der Performance: wenn alle Module Event-Empfaenger werden, dann wird das schwer zu optimieren sein.

FHEM hat ein API, um Geraete zu schalten (set/get/etc), die Kopplung an MQTT sollte entweder durch Adapter wie notify, DOIF, MQTT_GENERIC_BRIDGE, etc erfolgen, oder, wenn es sinnvoll ist, in MQTT2_CLIENT (und MQTT2_SERVER!) direkt eingebaut werden.

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