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

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