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?

[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

[Beta-User]

@Rudi:
Danke für's anschauen!

@hexenmeister:
Habe Hier noch eine Idee zu dem incoming-count-Thema von https://forum.fhem.de/index.php/topic,98079.0.html, weiß aber im Moment weder, ob das nur Symptome kuriert noch, ob es bei 00_MQTT.pm als IO noch korrekt (bzw. kompatibel) agiert;
Mit drin wäre dann auch der patch von nestor aus https://forum.fhem.de/index.php/topic,117659.msg1121004.html#msg1121004, allerdings ohne escapte 2. Klammer (braucht man afaik nicht).

Was mir bei der Durchsicht noch aufgefallen war: die Prüfung auf die IO-Type wird jedesmal in der "Vollversion" durchlaufen; evtl. könnten wir überlegen, ob es Sinn macht, das zu beschleunigen (z.B. indem man ein Internal oder einen helper-hash setzt)?

Jetzt arbeite ich erst mal noch den patch von Rudi in mein Hauptsystem ein...

Grüße,
Beta-User

[hexenmeister]

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

Hallo und danke für den Patch!
Eine gute Idee, die Abhänigkeit dynamisch zu machen.
Habe übernommen, nur die parameter für 'parseParams' habe ich wieder eingesetzt, ich meine mich zu erinnerb, dasd das dafür da ist, damit mehrzeilige Attribute korrekt zerlegt werden.

Den anderen Patch schaue ich mir morgen genauer an, heute ist schon zu spät zum Denken
Kurz getestet, keine Probleme gefunden.

P.S. wir brauchen, denke ich, langsam einen eigenen Thread.

[Beta-User]

@hexenmeister:
Danke für's Einchecken!

P.S. wir brauchen, denke ich, langsam einen eigenen Thread.

Jedenfalls betreffend diverse Coding-Fragen und die Interaktion zwischen den MQTT.*-Modulen siehe hier: https://forum.fhem.de/index.php/topic,117737.0.html

Vermutlich wäre es sinnvoll, die Doku-Fragen gesondert aufzugreifen.
PS:
Zwischenzeitlich ist mir auch der Thread Node-Red als Frontend über den Weg gelaufen; das scheint der "Urvater" dieser "notify"-"Lösung" zu sein, die dann auch letztlich den Anstoß in Richtung der Entwicklung von MGB gegeben zu haben scheint...

PPS: Eventuell sollten wir auch MQTT_BRIDGE nochmal ansehen, was Doku/cref dazu angeht. Da gehört m.E. mindestens ein dringlicher Warnhinweis ran, dass User sich damit nicht mehr befassen sollten, wenn sie erst in das Thema einsteigen; es gab ein paar solcher Fälle die vergangenen Monate, v.a. von englischsprachigen Nutzern.

[hexenmeister]

PS:
Zwischenzeitlich ist mir auch der Thread Node-Red als Frontend über den Weg gelaufen; das scheint der "Urvater" dieser "notify"-"Lösung" zu sein, die dann auch letztlich den Anstoß in Richtung der Entwicklung von MGB gegeben zu haben scheint...

Ja, die Idee hat mich inspiriert, die Funktionalität in ein Modul zu packen

PPS: Eventuell sollten wir auch MQTT_BRIDGE nochmal ansehen, was Doku/cref dazu angeht. Da gehört m.E. mindestens ein dringlicher Warnhinweis ran, dass User sich damit nicht mehr befassen sollten, wenn sie erst in das Thema einsteigen; es gab ein paar solcher Fälle die vergangenen Monate, v.a. von englischsprachigen Nutzern.

Das ist eine gute Idee. Quasi eine 'End-of-life' Erklärung für dieses Modul.

[arm9999]

Die MQTT Generic Bridge einzustellen wäre keine gute Entscheidung und ich würde es sehr bedauern (andere Nutzer möglicherweise auch). Aus den bisherigen Beiträgen gibt es zwar einzelne Lösungsansätze um das zu kompensieren was die MGB bietet, aber mit Verlaub gesagt, sind das nur Ansätze die wesentlich komplexer und komplizierter sind. Wie sich das auf das Lastverhalten und die Fehleranfälligkeit auswirkt müsste man separat betrachten.

Ich denke es wäre hilfreicher die Dokumentation zur MGB und auch zu den anderen Modulen deutlich zu verbessern - hier stecken nach meinem Dafürhalten die Fehlerteufel - für mach einen Nutzer ist das auch einfach nur unverständlich und schwer nachvollziehbar was sinnvoll einsetzbar ist.

Ich z.B. habe erst hier im Thread bemerkt das ich mit "stopic" Einfluß auf devices nehmen könnte - ist  mir vorher nicht aufgefallen und damit werde ich mich demnächst mal beschäftigen. Vor allem, wie und ob das mit MAX geht.

Was mir immer noch fehlt  ist ein echter Alternativvorschlag wie man über MQTT in FHEM einen Befehl ausführen kann (unabhängig von irgendwelchen Modulen) und auch wie man sonst alle readings in FHEM für MQTT nutzbar machen kann, ohne "meine" globalPublish Methode.
Was ich nicht möchte ist jedes reading von jedem device separat definieren zu müssen - das ist bei einer Vielzahl von devices nur eine Fehlerquelle und wenig zweckmäßig.

Bin mal auf Vorschläge gespannt 

Mein Vote: MGB ist ein Klasse Modul und sollte unbedingt bleiben! Als homeassistant Nutzer ist das die perfekte Schnittstelle und ich liebe die.

[rudolfkoenig]

Mein Vote: MGB ist ein Klasse Modul und sollte unbedingt bleiben! Als homeassistant Nutzer ist das die perfekte Schnittstelle und ich liebe die.

Dein Vote ist total ueberfluessig, keiner will MGB einstellen. Es geht um das Einstellen von MQTT_BRIDGE (ohne Generic).
Ansonsten bin ich mit den Bemerkungen einverstanden, sei konstruktiv, und hilf uns mit Vorschlaegen

[Beta-User]

Keine Sorge, MGB ist grade "in der Mache", und wie du in diesem Thread und hier nachlesen kannst, haben wir eine Hürde zur verbesserten Verwendung bereits "erledigt": Man braucht im Hintergrund kein 00_MQTT.pm und kein libmodule-pluggable-perl mehr.

Für die Doku wäre es nett, wenn du uns etwas Zeit zugestehst, oder ggf. sogar aktiv daran mitwirkst, dass sie verbessert wird, ich werde dann hier Meldung machen, wo und wie das sinnvoll ist.

Die gewünschten Alternativvorschläge (zu "versende alles" und "nimm einen beliebigen FHEM-Befehl entgegen") sind hier bereits genannt, allerdings werde ich das nicht noch deutlicher schreiben, weil es nach meiner persönlichen Meinung gefährlich bzw. unnötig ist und - wie hexenmeister ja bestätigt hat - genau die Vermeidung derartiger "Großlöcher" auch die Motivation hinter MQTT_GENERIC_BRIDGE war.

Ich möchte dich daher einladen, eine Art "Testuser" für die eventuelle künftige Doku "MQTT_GENERIC_BRIGDE für Einsteiger" zu machen .

Dazu gehört zum einen, direkt globalPublish _abzuschalten_.
Du kannst stattdessen alle Readings eines Devices automatisch versenden, indem du in den MAX-Devices einfach als Reading-wildcard einen Stern (*) angibst.

Die Basis sollte ähnlich sein wie in der Zusammenfassung hier, dann hättest du _für den einen Thermostat_ (bei Verwendung des Standard-präfixes für die zusätzlichen Attribute) dann dieses Ergebnis:

Code Auswählen Erweitern

attr Thermostat_Schlafzimmer_Clima mqttPublish *:topic={"$base/$name"}
attr Thermostat_Schlafzimmer_Clima mqttSubscribe desiredTemp:stopic={"$base/$name"}

Das war es eigentlich schon, du musst dann eben eine andere Topic/Payload-Kombination versenden - die ist dann aber deutlich näher an dem, was andere "Plain-text-MQTT"-Implementierungen auch verlangen...



Was MQTT_BRIDGE angeht: "Einstellen" war gar nicht meine primäre Intention, es reicht vermutlich, das Modul zum einen ausdrücklich nicht für den Neu-Einsatz zu empfehlen, und es ggf. (eher als Signal an Neu-User) mittelfristig nach contrib zu verschieben (aber ohne, dass man es den bestehenden Installationen entzieht).

[arm9999]

Sorry wenn ich da was durcheinander gebracht habe  . Die MQTT Generic Bridge ist mir halt sehr wichtig und die meisten die ich kenne nutzen diesen Weg auch für ihre Kopplung zu FHEM.

Wenn ich was beitragen kann, dann natürlich immer gerne.

Dazu gehört zum einen, direkt globalPublish _abzuschalten_.
Du kannst stattdessen alle Readings eines Devices automatisch versenden, indem du in den MAX-Devices einfach als Reading-wildcard einen Stern (*) angibst.

Auf dieser Weise muss man ja jedes devices in FHEM erneut anpacken und es nochmals explizit zuweisen ?!  Ich möchte ja gerade das alle Readings von allen devices aus allen Modulen in MQTT übertragen werden. Das ist sicherlich OK für jemanden der nur bestimmte Readings braucht ... warum soll das denn unbedingt entfallen?  Wo liegt denn der Mehrwert an der Änderung? (Muss mal so direkt nachfragen  )

[Beta-User]

Sorry wenn ich da was durcheinander gebracht habe  . Die MQTT Generic Bridge ist mir halt sehr wichtig und die meisten die ich kenne nutzen diesen Weg auch für ihre Kopplung zu FHEM.

Kein Problem, du bist nicht der erste, der Schwierigkeiten in der Orientierung hat, und sicher nicht der letzte (wobei das Entfallen von der "einfachen" MQTT_BRIDGE ein Schritt in Richtung mehr Übersichtlichkeit wäre).

  Auf dieser Weise muss man ja jedes devices in FHEM erneut anpacken und es nochmals explizit zuweisen ?!  Ich möchte ja gerade das alle Readings von allen devices aus allen Modulen in MQTT übertragen werden. Das ist sicherlich OK für jemanden der nur bestimmte Readings braucht ... warum soll das denn unbedingt entfallen?  Wo liegt denn der Mehrwert an der Änderung? (Muss mal so direkt nachfragen  )

Der Mehrwert liegt darin, dass man es BEWUSST tut, wenn man es jeweils im Device EINSCHALTEN muss, und zwar mehr oder weniger einzeln (du kannst das auch per regex "auskippen", indem du statt "Thermostat_Schlafzimmer_Clima" eben "TYPE=MAX" schreibst; das ist ja grade der Charme von regex und der Verwendung der Variablen in den MGB-Attributen ).

Wir machen die Erfahrung, dass so ein FHEM-System typischerweise deutlich mehr wächst, als sich ein User das zu Beginn so gedacht hatte. Ist es dann später mal so, hat man - auf allen Ebenen - urplötzlich deutlich mehr Informationen (bzw. in FHEM "Events"), als man ursprünglich mal auch nur geahnt hat.
Das aktive Anschalten ist daher eine Art Vorsichtsmaßnahme im Hinblick darauf, und es ist - bezogen auf den laufenden Betrieb - auch kein Unterschied in der Last, im Gegenheit!

(Vielleicht liest du nochmal, was ich ganz zu Beginn dieser Diskussion hier geschrieben hatte und denkst auch darüber nach, warum sehr erfahrene User wie hexenmeister ebenfalls das globalPublish nicht mehr unbedingt für eine Super-Idee halten.)

Wenn ich was beitragen kann, dann natürlich immer gerne.

Dann einfach "mitmachen" und ggf. einfach mal "stopic" austesten, und gerne auch "dumme Fragen" stellen, letztlich wollen ggf. auch andere "schwarz auf weiß" haben, warum bestimmte Dinge "umständlich" sein sollten...

[hexenmeister]

Auch wenn wir von "Abschalten" sprechen, ist es ja nicht geplant, Funktionalität "weg  zu nehmen". Die MQTT_BRIDGE soll "depricated" werden und wird mittelfristig nicht mehr supported. FUnktionieren wird sie jedoch weiterhin.

Die MQTT_GENERIC_BRIDGE behält auch alles, was jetzt schon geht, soll aber besser dokumentiert und ggf. optimiert werden. Vorrangig um einfachere Verwendung zu ermöglichen und die Einstiegshürde zu minimieren. Auch einer neuen Funktionalität stehe ich offen gegenüber, wenn es denn gewinscht und von Allen als sinnvoll erachtet wird.

Was "globalPublish" und "globalSubscribe" angeht - ich erkenne schon den WUnsch, auf eine sehr eiinfache Weise alle (auch künftige) Geräte nach "Außen" weiter zu reichen. Wollte ich anfangs beides implementieren. Habe jedoch zum Schluss gekommen, dass man sich damit viele ungewünsche Nebeneffekte "ins Haus" holt, ggf. ohne diese gleich zu erkennen. Hat, wie ich finde, ein zu großes Gefahrenpotential.
Ich hätte evlt. eine andere Idee dazu - wie wäre es z.B. mit einem Helper-Gerät, der bekannte Typen auflisten kann und "per Klick" an den Geräten notwendige Attribute erstellt (indem z.B. templates angewendet werden). Könnte man sich so vostellen: "ich habe Gerät 'X' von Typ 'Y' gefunden, habe dazu Template 'A' und Template 'B' im Angebot. Welches soll angewendet werden: A, B, oder keines davon".
Damit hat man einerseit einfache Konfiguration und andererseits kontrolliertes Umfeld, gleichartiges Syntax, gute Übersicht und keine plötzliche "Überraschungen".

[Beta-User]

Ich hätte evlt. eine andere Idee dazu - wie wäre es z.B. mit einem Helper-Gerät, der bekannte Typen auflisten kann und "per Klick" an den Geräten notwendige Attribute erstellt (indem z.B. templates angewendet werden). Könnte man sich so vostellen: "ich habe Gerät 'X' von Typ 'Y' gefunden, habe dazu Template 'A' und Template 'B' im Angebot. Welches soll angewendet werden: A, B, oder keines davon".
Damit hat man einerseit einfache Konfiguration und andererseits kontrolliertes Umfeld, gleichartiges Syntax, gute Übersicht und keine plötzliche "Überraschungen".

Finde das mit dem "helper"-Gerät eine interessante Idee.

Ggf. könnte man das sogar mit einem "Trick" direkt an MQTT_GENERIC_BRIDGE via AttrTemplate-support _fast_ so umsetzen, indem man den Device-Namen anfragt und dann statt DEVICE TARGETDEV mit Attributen versorgt. Wenn gewünscht, kann ich die Tage mal ein paar Experimente dazu machen.

Allerdings wäre es gut, wir würden vorab klären, wie das eigentliche "Ziel" aussehen soll, und wir müssten etwas Material sammeln. Wie man das dann strukturiert und ggf. "unter die Leute bringt", ist m.E. eine gesonderte Frage.

Um nicht zu sehr OT zu werden, (@Moderator: bitte melden, wenn es too much ist...), würde ich für so eine "Normalisierung" betr. Thermostate z.B.:
- (sofern erforderlich) Aliase setzen => desired-temp, measured-temp,
- Rundung vorsehen (Temp. immer gerundet auf eine Stelle hinter dem Komma?)
- Wahl zwischen "sende alles", "sende nur Basics (desired-temp, measured-temp)" und "sende erweiterte Basics (desired-temp, measured-temp, valve (?) und batteryPercent)"?
- braucht es on/off-Kommandos und boost...?

(Was mit attrTemplate nicht wirklich komfortabel gut geht, sind mehrstufige Abfragen, es sollte - um es einigermaßen handhabbar zu halten - eine gewisse Vorauswahl vorhanden sein; im Zweifel kann der User zusätzliche schaffen und die ggf. auch allg. zur Verfügung stellen).

[hexenmeister]

Ich habe mich mit dem Thema 'templates' noch nicht wirklich auseinander gesetzt. Wenn man das direkt an der Bridge machen kann, ohne den Code aufzublähen, dann wäre das gut. Ansonsten würde ich lieber auslagern.

Das Ziel... Ich denke, das Ziel ist eine Vereinfachung der Konfiguration, besonders, wenn man viele Geräte 'versorgen' will, oder sich mit dem Syntax nicht auskennt / nicht auskennen will (erspart also Fehler). Und natürlich ist das eine sanfte Methode, Standardisierung der Namen und Topics durchzusetzen.

Aliase sind unumgänglich, spätestens wenn Hardware von verschiedenen Herstellern für den ähnlichen Anwenungdszweck verwendet werden soll (typischer Beispiel - schaltbare Zwischenstecker). Rundung ist auch eine gute Sache.

Eine Wahl zw. "alles" etc. würde ich eher durch 'Klassen' realisieren: 'Thermostat' (valve, boost,..), 'Climacontrol' (desired-temp), 'Climasensor' (temperature, humidity), 'batterie' (voltage). Dann kann man ja 'Devices' aus mehreren Klassen 'zusammensetzen'.

[Beta-User]

Vom Coding her ist es einfach (Wzut kann das bestütigen), "pur" (ohne SetExtensions) geht es ähnlich wie bei SetExtensions, indem man einfach "unbekannte setter" an AttrTemplate durchreicht...

Eine weitere Vereinfachung wäre z.B. auch, "brightness" und "pct" auf "pct"-Level (0-100) zu bringen...

Das mit den "Klassen" ist via attrTemplate eher nicht so einfach (also das dynamische Zusammenbauen von (und Analysieren vorhandener) Attribute) bzw. tendenziell fehleranfällig, aber wenn jemand ein anderes Tool anbieten will, soll mir das recht sein. Meine Erfahrungen mit den attrTemplate für die Sprachsteuerung war eher die, dass es doch eine eher begrenzte Zahl von (sinnvollen) Varianten gibt, und die kann man dann auch hart vercoden.
(Händisches Erweitern ist ja deswegen noch lange nicht verboten)...

[Wzut]

Um nicht zu sehr OT zu werden, (@Moderator: bitte melden, wenn es too much ist...), würde ich für so eine "Normalisierung" betr. Thermostate z.B.:
- (sofern erforderlich) Aliase setzen => desired-temp, measured-temp,
- Rundung vorsehen (Temp. immer gerundet auf eine Stelle hinter dem Komma?)
- Wahl zwischen "sende alles", "sende nur Basics (desired-temp, measured-temp)" und "sende erweiterte Basics (desired-temp, measured-temp, valve (?) und batteryPercent)"?
- braucht es on/off-Kommandos und boost...?

Mit den Reading Namen hast ja geradeso noch die Kurve bekommen ...
desired-temp als Reading als auch als set Kommando kann die nächste Version von 10_MAX als Zusatz zum heutigen desiredTemperature
measured-temp wäre dann temperature, wobei temperature als Ist heute gängig ist bei Temperatur Sensoren
valve ist heute valveposition und auch bei HM nur so im state des Clima Channels, als reines Reading ist es dort ValvePosition
batteryPercent liefern die wenigsten Geräte, battery & batteryState ist weit verbreitet (MAX hat beide) , HM je nach Gerät noch batteryLevel & batVoltage
Runden : es macht IMHO extrem wenig Sinn mehr als 1/10° zu verwenden, welches Device liefert hier eine 1/100° Auflösung ?
Bei den Soll Temperaturen reichen 0,5° Schritte
Boost und on/off sind sinnvoll, wobei MAX in Wahrheit aus on 30.5 macht und aus off 4.5 , der Normalbereich liegt daher bei 5 - 30

[Beta-User]

Hmm, ich habe gewisse Zweifel, ob es Sinn macht, "historische" Namen zu modernisieren, aber optional ist es ggf. eine gute Sache.

Was das Ergebnis angeht (measured-temp etc.) wäre mein Vorschlag, das auszulagern, das geht eigentlich in die Richtung der Maintainer und würde an die Battery-Geschichte anknüpfen.
Was die Standardisierung auf MQTT-Ebene angeht, können wir mit vielem leben und auch entsprechende "Übersetzungsprogramme" etablieren, das ist gar kein Thema, wir brauchen eben rechtzeitig sowas wie einen Konsens, wie es (optimalerweise) aussehen sollte.

ZWave macht z.B. "19.42 C" nach "temperature", ist lustig, aber nachvollziehbar... Die Xiaomi-BT-Dinger liefern es auch "sehr genau", und bei den DS18B20 bekommst du ggf. sogar 3 Stellen hinter dem Komma.
Soll-Temperaturen sollten m.E. unverändert (bestenfalls nummerisch) übermittelt werden, die sind aber praktisch überall sowieso 20.5 etc..
Was die "set"-Seite angeht, macht Umrechnen m.E. wenig Sinn, da sollte man auf die "andere Seite" verweisen, von da muss halt was umsetzbares geliefert werden (m2ct).

Was on/off/boost angeht, sehe ich das auch als wünschenswert an, weiß aber (noch) nicht, inwieweit sich das wirklich verallgemeinern läßt...

Grundsätzlich: MQTT ist ein transparentes Protokoll, und Glättungen und gewisse Übersetzungen machen ggf. Sinn, aber übertreiben muss man es auch nicht; der Grundsatz sollte mAn. bleiben: übermitteln "as is".
(Aber funktionierende Code-Beispiele für das Runden mit expression zu basteln ist gar nicht so einfach...! (Ich hab's in der Schublade, es geht! Wie folgt ggf. ein andermal))

[Beta-User]

Mit den Reading Namen hast ja geradeso noch die Kurve bekommen ...
measured-temp wäre dann temperature,

Dann hoffe ich auf Gnade des Moderators, wenn ich hier kurz mitteile, dass ich eben eine kleine Erweiterung zu "general_use.template" eingecheckt habe. Ab morgen per update oder zum sofortigen Testen mit

Code Auswählen Erweitern

{ Svn_GetFile("FHEM/lib/AttrTemplate/general_use.template", "FHEM/lib/AttrTemplate/general_use.template", sub(){ AttrTemplate_Initialize() }) }
Da ist jetzt eine Art "showcase" enthalten, wie das aussehen _könnte_ mit dem "Seitenaufruf von attrTemplate für Devices, die das eigentlich gar nicht unterstützen".

Um es auszutesten, braucht man im Moment als "helper-Device" einen dummy mit SetExtension-support:

Code Auswählen Erweitern

defmod mgbAttrT_testing dummy
attr mgbAttrT_testing useSetExtensions 1


Dann kann man - vorausgesetzt, es gibt in der Installation auch eine MGB und die war bei AttrTemplate_Initialize() auch schon vorhanden - ein attrTemplate aus der Liste wählen, das dann abfragt, ob man von diesem Zieldevice nichts, ein paar Readings oder alles versenden will und welchen TYPE das Zieldevice hat, screenshot unten.

Nachteile:
- Die TYPE-Abfrage könnte man "eigentlich" weglassen, im Moment bekomme ich sie leider nicht effektiv beseitigt, dafür müßte AttrTemplate eine Art "postpar:" unterstützen, also bestimmte Parameter erst auflösen, wenn andere ermittelt sind (oder ich übersehe mal wieder was);
- für CUL_HM (bzw. in meinem Beispiel den HM-CC-RT-DN) müsste man sich darauf verständigen welcher Kanal eigentlich konfiguriert wird. Ich nutze effektiv nur (noch) den .*_Clima-Channel, auch in der Raumansicht (mit einem "speziellen" devStateIcon, das auch ein paar indirekte features enthält...). Das wäre aber natürlich eine Art Konvention, die man (auch als Endanwender) erst kennen muss (=>wie kommunizieren?)...

Was bietet es sonst an Anschauungsmaterial:
- Aliasing measured-temp=>temperature für CUL_HM (um fast beim Thema zu bleiben ...);
- Rundung auf eine Kommastelle für ZWave-temperature (statt alphanummerischem Wert);
- Aufgliederung "der paar MGB-spezifischen Zeilen" für einzelne TYPE-Umfang-Kombinationen.

Falls sich jemand fragt, warum das intern auf zwei templates verteilt ist bzw. so aufgebaut: Ursprünglich dachte ich, über diesen Trick bekäme man ggf. den TYPE automatisiert ermittelt. Erst mal so belassen ist es, weil man durch die 2. Stufe dann eventuell die Textabfrage auf Stufe 1 entfallen lassen kann zugunsten einer RADIO_Option auf der 2. Stufe (aber nur vielleicht, kann auch sein, dass man dann wieder auf Stufe 1 landet, weil zwischendurch TARGETDEV verloren gegangen war).

Feedback wäre willkommen...

[LuckyDay]

Ich habe soetwas mit einem MQTT2 Device erledigt.
die Logik über einen Dummy leuchtet mir einfach nicht ein

Code Auswählen Erweitern

defmod SZ_R MQTT2_DEVICE
attr SZ_R IODev mqttclient_localhost
attr SZ_R devStateIcon ok:batterie@green
attr SZ_R group HZ_R
attr SZ_R readingList haus/HM/sz_temp/measured-temp:.* measured-temp\
haus/HM/sz_temp/battery:.* battery\
haus/HM/sz_temp/dewpoint:.* dewpoint\
haus/HM/sz_temp/desired-temp:.* desired-temp\
haus/HM/sz_temp/humidity:.* humidity\
haus/HM/sz_temp/actuator:.* actuator\
haus/HM/sz_temp/R-controlMode:.* controlMode\
haus/HM/sz_temp/controlMode:.* controlMode
attr SZ_R room test
attr SZ_R setList desired-temp:6.0,16.0,17.0,17.5,18.0,19.0,20.0 cmnd/haus/HM/sz_temp desired-temp\
controlMode:manual,auto,central cmnd/haus/HM/sz_temp controlMode
attr SZ_R stateFormat measured-temp °C actuator %
attr SZ_R webCmd desired-temp:controlMode

setstate SZ_R 16 °C 44 %
setstate SZ_R 2021-01-16 17:13:30 actuator 44
setstate SZ_R 2021-01-16 12:39:22 battery ok
setstate SZ_R 2021-01-08 02:03:21 controlMode manual
setstate SZ_R 2021-01-16 12:39:22 desired-temp 16.0
setstate SZ_R 2021-01-16 17:13:10 dewpoint 11.6
setstate SZ_R 2021-01-16 17:13:10 humidity 75
setstate SZ_R 2021-01-16 17:13:10 measured-temp 16
setstate SZ_R 2021-01-16 12:39:21 state desired-temp


Edit: falls sich jemand fragt warum es measured-temp und nicht nur temperature heißt, es gibt bei Thermostaten mehrere Temperaturen!

measured-temp
day-temp
desired-temp
desired-temp-manu
night-temp
party-temp

[Beta-User]

Mißverständnis....

Der dummy ist (im Moment) nur dazu da, dass attrTemplate verfügbar wird. Die Attribute selbst werden an dem CUL_HM-Device gesetzt, und wären dann ggf. die "Gegenstelle" auf der Installation, auf der sich das CUL_HM-Device befindet (also wäre dort kein notify oä. erforderlich, um die Daten zu liefern bzw. zu empfangen).
Das MQTT2_DEVICE "als Gegenstück dazu" auf der "Sammelinstanz" sähe (fast: measured-temp wird temperature) genauso aus, wie du das hier zeigst, wenn man eben statt NodeRed oder Homeassistant FHEM als Visu einsetzen will...

[Wzut]

Zwei Dinge verstehe ich jetzt aber nicht :
a. wir sind im MAX Forum, also warum nur die beiden "Fremden" Zwave & CUL_HM ?
b. das AttrTemplate hat 10_MAX ja schon einige Monate drin, macht es nun Sinn das MAX Templates um ein paar Zeilen zu erweitern (wie damals bei der Sprachausgabe)
oder soll das immer über das general_use.template abgefrühstückt werden ?

[Beta-User]

ad a: Das waren die beiden Typen, die mir auf die Schnelle zum Testen zur Verfügung standen, und die MAX-Readings und setter zusammenzusuchen, das haben die MAX-User vermutlich besser drauf...

ad b: Eventuell könnte man das sogar als weitere Stufe einfach an die Sprachsteuerungsgeschichten dranhängen; da ist je z.B. schon klar, wie das Zielgerät heißt und ob es um einen Thermostat geht, ein (pct- oder brightness-dimmbares) Licht etc pp...
Hat aber uU. auch ein paar Nachteile, tendenziell sollten wir aber ggf. diese Fragen vertiefen.

An sich _glaube_ ich, dass es keinen großen Sinn macht, das in den gerätespezifischen attrTemplate-Sätzen mit abzuhandeln. Ist im Moment aber eher ein - v.a. aus den Erfahrungen mit der Sprachsteuerung gespeistes - Bauchgefühl. Das Thema betrifft (noch?) zu wenige User, und die Einstellungen kann man eigentlich als (interessierter/betroffener) User eventuell sogar einfacher festlegen wie ein Modulautor, der ggf. weder mit attrTemplate noch mit MQTT irgendwas am Hut hat...

In general_use.template ist es im Moment nur, weil ich es da auch unauffällig wieder ausbauen kann, das ganze war eher als "showcase" gedacht wie als finale Lösung zu dem Themenkreis. Tendenz wäre, das ganze letztendlich in einer "mqtt_generic_bridge.template" unterzubringen. (Die beiden "allgemeinen" attrTemplate-files general_use und spreechcontrol waren auch erst Teil von mqtt2.template).

Edit: falls sich jemand fragt warum es measured-temp und nicht nur temperature heißt, es gibt bei Thermostaten mehrere Temperaturen!

Sorry, den Edit hatte ich erst eben gesehen.

Falls du dich fragst, warum ich in Kenntnis dieser diversen - aus meiner Sicht durchaus sinnigen - sprechenden Benennungen dann aus der einen (!) Temperatur measured-temp jetzt im showcase "temperature" gemacht habe: M.E. war der Einwand von Wzut berechtigt, dass "da draußen" für die Ist-Temperatur bei Thermostat-Geräten eben "temperature" üblich ist.

Und das, was bei CUL_HM "day-temp" ist nennt sich - nach meinem Verständnis - bei ZWave dann "heating" bzw. "night-temp" entspräche "energySaveHeating", und MAX hat hier wieder eine andere Begrifflichkeit, nehme ich mal an, und "actuator" finde ich eigentlich zwischenzeitlich die beste Begrifflichkeit für das Ventil-Ding.

Hierzu im "showcase" _weitere_ Vorschläge für Aliasing zu machen, habe ich auch BEWUSST unterlassen, denn wie bereits hier auch geschrieben, sollte man sich m.E.
a) daran orientieren, was "draußen" üblich ist (v.a. in der "MQTT-Welt") und
b) Gedanken machen, ob und wie man ggf. die https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings etc. erweitert, damit zumindest _zukünftig_ nicht jeder macht, wie im grade der Sinn steht.
([OT @Wzut] Evtl. könntest du die Readingnamen in einen Hash schreiben und dann $featurelevel- bzw. attributabhängig belabeln. Mit settern wäre es etwas schwieriger, aber möglich sollte auch das sein, oder?[/OT]

[OT @fhem-hm-knecht] Es würde mich interessieren, wie die "Gegenstelle" aussieht, die "cmnd/haus/HM/sz_temp controlMode" auswertet... (ist hier aber m.e. wirkliuch OT)

[Wzut]

Edit: falls sich jemand fragt warum es measured-temp und nicht nur temperature heißt, es gibt bei Thermostaten mehrere Temperaturen!

measured-temp
day-temp
desired-temp
desired-temp-manu
night-temp
party-temp

Richtig , wobei das auch wieder nur bei Hersteller X so zurifft , bei MAX hätten wir da im Angebot :

Code Auswählen Erweitern

comfortTemperature
desiredTemperature
ecoTemperature
maximumTemperature
minimumTemperature
temperature
windowOpenTemperature
und ja ich bin Fan von einheitlichen Reading Namen und deren Schreibweise, aber leider haben wir hier keine verbindliche Regel, Altlasten und manchmal ignorante Modulautoren (Thema HM und Battery).
Toppen kann man das Ganze noch wenn dann noch Einheiten ins Spiel kommen, da es manchem Autor nicht reicht einfach nur temperature X zu schreiben.
Bsp : temperature 25°C oder noch schlimmer :  temperature 25 C (measured)
mit der Folge das dann mit schöner Regelmäßigkeit irgendwelche selbst geschriebenen Vergleiche in die Hose gehen und wir immer wieder predigen "Leute nehmt ReadingsNum statt stur immer ReadingsVal" usw. 

[Beta-User]

[OT]
Man sollte einen Mod holen, hier werden Maintainer, die nicht an der Diskussion beteiligt sind unnötigerweise angegangen!
[/OT]

Im Ernst: Manches ist "ärgerlich" oder schlecht nachvollziehbar, und vieles kann man sich nur historisch erklären oder aus der Funktionalität der dahinter stehenden Hardware.

Irgendwo gab es auch mal einen (ergebnislosen) Thread zur Frage, wie mit Einheiten umzugehen sei....

DAS HILFT M.E. alles nichts, v.a. nicht bei Modulen, die eben schon da sind. Das mit Battery ist btw. auch eher eine nachdrückliche Bitte im Nachhinein, und manches ist halt wie es ist, gibt schlimmeres.

Bei denen kann nur "jemand" z.B. zeigen, wie man - bei überschaubarem Zusatzaufwand auf allen Seiten (Aktuell beliebte Userfrage: "ich habe jetzt FHEM x Jahre ungewartet am laufen, was muss ich beachten, wenn ich jetzt update...?") - ggf. "moderne" oder allgemein für gut befundene Benennungen etc. wählt.

Aber das ist hier OT und sollte ggf. in der Developer-Ecke diskutiert werden, m.E. am besten anhand eines konkreten Vorschlags (ähnlich wie das grade rund um Solar-Ertrags-Themen geschieht).

Hier ging es um die Frage, wie man FHEM-Devices (am Beispiel MAX) am einfachsten von und nach MQTT bringt. Das überschneidet sich zwar in Teilen, aber es muss m.E. nicht 1:1 dasselbe dabei rauskommen, und via eines zentralen template-Satzes kann man auch relativ leicht diesen Teil wieder überarbeiten.

Bei den hier an der Diskussion Beteiligten mache ich im Moment einen Zwischenstand von 3:1:2 aus bezüglich der Frage, ob denn MQTT_GENERIC_BRIDGE (in welcher Form auch immer) das grundsätzlich als "Standardvorgehensweise" zu supportende Mittel der Wahl ist:
3 für (klar) "ja" (Rudi, hexenmeister und meinereiner)
1 für (eher) "nein" (fhem-hm-knecht)
2 unentschieden (Wzut und arm9999).

Bei den letzteren Drei habe ich mitgenommen, dass zum das Konzept eher noch unklar ist, was eigentlich allg. hinter MGB steckt (v.a. die Richtung MQTT => FHEM) und zum anderen die Syntax der Attribute erklärungsbedürftig erscheint bzw. (bei arm9999) auch noch Nacharbeiten erforderlich wären, um die Syntax auf der Gegenseite kompatibel zu machen.

Da ihr drei eher "die User" repräsentiert: Was fehlt euch bzw. was sind konkret die Kritikpunkte?

(für arm9999 habe ich z.B. das "publish all" (auf Device-Ebene) vorgesehen, mit dem "Bonus", dass ggf. dann eben direkt auch ein "standardisierter Readingname" verwendet wird, der ggf. besser zu dem passt, was aus anderen MQTT-Quellen kommt; wäre interessant zu hören, ob das z.B. für homeassistant hilfreich ist).

[Wzut]

Ich bin nicht unentschieden Als reiner User habe ich 11 Monate im Jahr keine Verwendung für MQTT2_Server & MQTT2_Device und für MGB gar keine.
Als Modulautor stehe ich Thema völlig offen gegenüber, da ich hier lediglich zuarbeite wo immer es halbwegs sinnvoll erscheint.

[Beta-User]

Als reiner User [...]

Dann mal an den "User" "new news" zu dem Thema:

hexenmeister hat u.a. zwischenzeitlich auch den support für AttrTemplate in MGB eingebaut, von daher wäre es nett, von den "Usern" hier eine Rückmeldung zu bekommen, ob denn das "setup an sich" nachvollziehbar ist, passende attrTemplate-file zum ersten Testen anbei.

Damit das hier nicht als OT gilt: Als TYPE für das Thermostat-template kann man jetzt auch MAX wählen , ich hoffe nur, die Infos passend zugeordnet zu haben...

Da MAX ebenfalls attrTemplate kennt, wäre es vermutlich auch möglich, hier einen passenden Satz innerhalb der max.template anzubieten, allerdings bin ich eher skeptisch, ob das zielführend im Sinne einer Vereinheitlichung wäre.

Btw.: dazu gibt es einen eigenen Thread, bei dem auch schon Popcorn im Angebot ist: https://forum.fhem.de/index.php/topic,117933.0/topicseen.html. Also falls jemand Lust hat, sich mit in die Nesseln zu setzen .

Ad OT: der Post hier soll nur dazu dienen, etwas Rückmeldung zu geben und ggf. zu erhalten. Einige Basisfragen müssten m.e. eigentlich aber erst mal noch gesondert (via Post im MQTT-Bereich) geklärt werden. Insbesondere wie mit $device umzugehen sein soll; eventuell wäre es besser, das mit in den Geräte-spezifischen-Teil aufzunehmen?

Mal sehen...

[Wzut]

Danke für die Info , ich werde mir das Template mal anschauen und testen.

[Beta-User]

Gerne.

Damit wir den [OT]-Teil dann auch beenden können, gibt's dann (bis auf weiteres) hier bei MQTT_GENERIC_BRIDGE - sinnvolle defaults (für attrTemplate) die Möglichkeit, alles weitere on Topic zu diskutieren .