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

[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]

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))