Parameter setzen bei ism7mqtt

[fhem024]

Hallo zusammen,
ich habe ism7mqtt an MQTT2_SERVER angebunden (autocreate=complex). Alle Readings wurden im automatisch angelegten Device MQTT2_Wolf_1921683117 erstellt. Soweit so gut.

Jetzt würde ich gerne die Parameter nicht nur auslesen, sondern auch setzen. Ein angelegtes Reading ist z.B.:
TOB_0x8_Obere_Brennerleistung_Warmwasser

Folgende subscriptions meldet FHEM (im list):
subscriptions: Wolf/192.168.3.117/+/set
subscriptions: Wolf/192.168.3.117/+/set/#

Meine Frage ist nun: wie mache ich einen Wert schreibbar - z.B. den oben genannten TOB_0x8_Obere_Brennerleistung_Warmwasser? Leider habe ich nicht die geringste Idee, wo ich hier ansetzen kann / soll, obwohl ich schon diverse Dokumentationen gelesen habe.

ism7mqtt erwartet zum Setzen ein Json. Auf github wird folgendes Bsp. genannt:

Code Auswählen Erweitern

{
    "Programmwahl": {
        "360051": {
            "value": 0
        }
    }
}
oder
{
    "Programmwahl": {
        "360051": {
            "text": "Standby"
        }
    }
}

incl. Angabe des entsprechenden topics (könnte wohl das subscription in FHEM sein? Wobei das + aus den subscriptions dann wohl durch TOB_0x8 im konkreten Fall ersetzt werden muss?)

Ich wäre für jede Unterstützung dankbar!

Gruß
fhem024

[Beta-User]

Ich wäre für jede Unterstützung dankbar!

https://forum.fhem.de/index.php?topic=112327.0
Ohne (raw-) list (und uU. ohne den konkreten MQTT-Traffic) kann man wenig zu dem Ding sagen, siehe das Beispiel aus github: https://github.com/zivillian/ism7mqtt#example

"complex" ist vermutlich nicht hilfreich, das erzeugt imo in diesem Fall zu lange Readings, die man dann wieder mit jsonMap (siehe Attributhilfe dazu) auf "lesbare" Readings mappen müßte.

Siehe dazu auch https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt

[fhem024]

Hallo Beta-User,

ich bin mittlerweile mit setList weitergekommen:

Code Auswählen Erweitern

Warmwassersolltemperatur:slider,40,1,60 Wolf/192.168.3.117/WWSystem_BM-2_0x35/set/Warmwassersolltemperatur_eingestellt/350009
funktioniert schon mal.
Jetzt wäre noch spannend, wie man den slider (oder sonstige widgets) mit dem aktuellen Wert voreingestellt bekommt.

[Beta-User]

Jetzt wäre noch spannend, wie man den slider (oder sonstige widgets) mit dem aktuellen Wert voreingestellt bekommt.

jsonMap die einhunderste...

[fhem024]

Hallo Beta-User,

sorry, wenn ich scheinbar etwas begriffsstutzig bin. In wie weit mir jsonMap beim Vorbelegen eines Wertes in setList mit dem aktuellen Wert vorausgewählt helfen kann, ist mir nicht klar. Ich habe jsonMap verwendet, um Readings anzupassen (Umlaute rauszuwerfen). Glücklicherweise benötige ich die, soweit ich es sehe, nicht als setter.

Jetzt habe ich aber noch ein anderes Problem: Es gibt das Reading DHK_BM-2_0x35_Winter/Sommer_Umschaltung. Daraus würde der Befehl

Code Auswählen Erweitern

Wolf/192.168.3.117/DHK_BM-2_0x35/set/Winter/Sommer_Umschaltung
Der funktioniert aber nicht, weil FHEM den letzten Slash wohl als Pfadtrenner interpretiert und nicht als Readingname. Wie übergibt man denn so was? Escapen hat jedenfalls nicht geholfen.
Ein anderes Bsp. dafür ist DHK_BM-2_0x35_ECO/ABS.

Leider habe ich noch keine Doku gefunden, die erläutert, wie man die Slashes in den Readings korrekt übergibt. Das Umlautethema wäre ein weiteres, wenn es da setter gäbe ... .

Danke für Deine Geduld,
fhem024

[Beta-User]

Datenpunkte in MQTT sollten für FHEM einen "Kreis" ergeben. Also: Was du als set-Befehl auf ein Reading (Beispiel hier: "Warmwassersolltemperatur") schreibst, sollte dann eine Antwort aus der Gegenstelle erhalten (Kreis bedeutet: anderer Pfad). Und den Datenpunkt mappst du halt auf dein Reading, Fisch geputzt. Ob es funktioniert, sieht man am einfachsten, wenn man setStateList auf irgendwas setzt, z.B. "on off". Dann wird nämlich das "set_xy" ins Reading geschrieben, bis die Antwort da ist (und richtig gemappt).

Es ist übrigens wenig hilfreich, dass du weiter meinst, es ginge ohne raw-list einfacher... So habe ich jedenfalls noch keine konkrete Idee, wie deine jsonMap jetzt aussieht und wie das gewünschte Reading grade  benannt ist.

[fhem024]

Hallo Beta-User,
ich habe Dir hier die rawlist bereitgestellt - ich hoffe, ich habe das korrekt verstanden und dass die Dir weiterhilft.

Danke
Gruß
fhem024

[Beta-User]

Ist das irgendwie geheim? Wenn nein: wie soll ein eventueller Mitleser was daraus lernen?

Also nochmal von vorne: Warum "complex"? Beim Durchsehen der Reading-Liste ist mir zumindest auf die Schnelle nichts aufgefallen, was in irgendeiner Form "wirklich doppelt" wäre und von den "prefix"-Settings profitieren würde. Nur die Außentemperatur scheint auf zwei Datenpunkten zu kommen, die geringe Abweichung kommt vermutlich daher, dass der Messwert einfach zu unterschiedlichen Zeiten gemessen und übertragen wurde.

(anonymisierter) Vorschlag für die Vereinfachung:

Code Auswählen Erweitern

attr DEVICE readingList Wolf/[^/]+/[^/]+:.* { json2nameValue($EVENT, '', $JSONMAP) }

Aber erst mal weiter ohne das. Ergänze jsonMap mit einer weiteren Zeile - ich hoffe, den passenden Datenpunkt für die "Rückmeldung dazu" erwischt zu haben, dann wird vielleich klarer, was ich meine.

Code Auswählen Erweitern

WWSystem_BM-2_0x35_Warmwassersolltemperatur_eingestellt_350009:Warmwassersolltemperatur

Und versuche mal das mit setStateList wie vorgeschlagen.

[fhem024]

Sorry Beta-User,
Du hast mich abgehängt. Mit dem Setzen der Warmwassertemperatur gibt es absolut keine Probleme. Das funktioniert, wie es soll. Das Problem sind die Readings mit / im Namen. Wie soll ich die übergeben?

Wenn ich Dich richtig verstanden habe, soll jsonMap z.B. für die Rückmeldung für die Warmwassersolltemperatur erweitert werden. Leider passt der Wert Warmwassrsolltemperatur nicht, weil das ein anderer Wert ist (das kannst Du nicht wissen). Der Wert ist immer auf 10 (default), solange gerade keine Ladezeiten programmiert sind und die auf die aktuelle Zeit passen.
D.h., das Mapping wäre dann

Code Auswählen Erweitern

WWSystem_BM-2_0x35_Warmwassersolltemperatur_eingestellt_350009:WWSystem_BM-2_0x35_Warmwassersolltemperatur_eingestellt_350009

Muss man das tatsächlich angeben - auch wenn es gleich ist? Nebenbei - ich such nur einen Weg, den aktuellen Wert in der Auswahlliste vorzubelegen. Oder würde das dieses Mapping erreichen?

Oder noch besser wäre es, wenn ich den Wert inplace - also im Reading selbst - ändern könnte. Ist sowas evtl. möglich?

Update:
Mir ist auch absolut nicht klar, was setStateList konkret erreichen soll / macht. Was ich gelesen habe, ist, dass man es verwenden soll, wenn es für ein Device mehrere States gibt (gibt es hier ja pro Setter - eine riesige Menge). Hier würde mir eine ausführliche Doku weiterhelfen, die v.a. auch zeigt, welches Problem mit diesem Attribut konkret gelöst wird (ich muss erst mal das Problem erkennen - ich habe ja an dieser Stelle aus meiner Sicht derzeit gar keines - es funktioniert ja).


Danke
Gruß
fhem024

[Beta-User]

Du hast mich abgehängt. Mit dem Setzen der Warmwassertemperatur gibt es absolut keine Probleme. Das funktioniert, wie es soll.

Und woran siehst du das?

Das Problem sind die Readings mit / im Namen. Wie soll ich die übergeben?

Im list sind keine Readings mit "/" - das wäre auch nicht zulässig, da keine "goodReadingNames()".

Muss man das tatsächlich angeben - auch wenn es gleich ist

Auf dasselbe zu mappen, ist in der Tat sinnlos. Aber wenn du unbedingt diese Bandwurmnamen verwenden willst, kannst du das ja auch in der setList entsprechend ändern.
Also statt

Code Auswählen Erweitern

Warmwassersolltemperatur:slider,40,1,60 Wolf/blub/WWSystem_BM-2_0x35/set/Warmwassersolltemperatur_eingestellt/350009dann eben

Code Auswählen Erweitern

WWSystem_BM-2_0x35_Warmwassersolltemperatur_eingestellt_350009:slider,40,1,60 Wolf/blub/WWSystem_BM-2_0x35/set/Warmwassersolltemperatur_eingestellt/350009
Die "Vorbelegung" kommt aus dem Reading-Wert, und der muss halt vorhanden sein (siehe setStateList-Vorschlag) und meine Hinweise zum "Kreis". Der Änderungsvorschlag oben ist auch nur wieder ein "Kreis", nur halt mit einem anderen Reading-Namen auf der FHEM-set-Seite. Er setzt halt voraus, dass irgendwas zurückkommt und Anweisung und Ergebnis irgendwie inhaltlich zusammenpassen...

[fhem024]

Und woran siehst du das?

Weil der Wert, der kurz danach zurückkommt, der korrekte neue Wert ist.

Im list sind keine Readings mit "/" - das wäre auch nicht zulässig, da keine "goodReadingNames()".

Suche nach ECO/ABS oder Winter/Sommer - Umschaltung. Beides mal sind "/" im Readingnamen. Siehe hier aus meiner raw-List:

Code Auswählen Erweitern

#      DHK_BM-2_0x35_Winter/Sommer_Umschaltung:
#        logdb:
#          TIME      1731752442.84484
#          VALUE      18
Der korrekte Pfad ist hier DHK_BM-2_0x35/[Readingname = Winter/Sommer_Umschaltung]]
Das Problem ist, dass der letzte / zum Namen gehört und nicht zum Pfad.

Zum Thema Vorbelegung in der setList: ich glaube, jetzt wird mir erst klar, welches Mapping hier genau gemeint ist: Hier soll der "sprechende Name" (der erste Parameter), welcher in der setList verwendet wird, an anderer Stelle wieder einem Reading zugeordnet werden. Auf diese Weise wird dann die Vorbelegung erreicht. Der Name in der setList ist daher nur bedingt ein frei wählbarer Name. Wenn ich die Vorbelegung haben möchte, muss dieser Name immer gleich dem (technischen) Reading sein. Mit jsonMap kann ich ja aus dem technischen Namen jeden anderen beliebigen Namen machen - ist dann aber fürs Debugging weniger transparent und wirkt sich auch auf die Einträge in der DB aus. Am schönsten wäre, wenn man im setList da direkt das zugehörige technische Reading fürs Mapping angeben könnte.

Ergänzung:
Die Präfixe wie DHK_BM-2_0x35, WWSystem_BM-2_0x35 oder TOB_0x8 will ich auch nicht wirklich weg haben, weil die darüber Auskunft geben, aus welchem Device / Steuerungsteil der Heizungsanlage der Parameter tatsächlich stammt. Dir ist ja z.B. schon der Außentemperaturparameter aufgefallen. Den gibt es an unterschiedlichen Stellen und der kann dann auch unterschiedliche (deutliche!) Abweichungen haben - je nach dem, wie man die Anlage konfiguriert hat. Bei mir differieren die aktuell nicht wirklich - weil die Konfig entsprechend ist. Zum Verständnis der Anlage ist schon gut, wenn man die Herkunft der Parameter sieht. Sind ja doch ein paar.

Ergänzung 2:
Mit

Code Auswählen Erweitern

setStateList on off
funktioniert die Vorbelegung tatsächlich auch bei sprechendem Namen, der vom Reading abweicht, sobald man den Wert einmal gesetzt hat. Ich kann aber derzeit nicht abschätzen, welche Nebenwirkungen dieses on off hier hat. Hätte auch hugo mueller zum selben Resultat geführt?

Danke
Gruß
fhem024

[fhem024]

Ich konnte den offenen Punkt noch klären. Hier für andere, die evtl. auch straucheln:

"/" im Readingnamen - aus dem MQTT-Trace (JSON):

Code Auswählen Erweitern

Wolf/192.168.3.117/DHK_BM-2_0x35   {"Winter/Sommer Umschaltung": 18}

wird wie folgt übersetzt:

Code Auswählen Erweitern

Wolf/192.168.3.117/DHK_BM-2_0x35/set/Winter_Sommer_Umschaltung
=> alle Leerzeichen und "/" im Namen müssen durch "_" ersetzt werden!

Es gibt auch verschachtelte JSONs. Sowas z.B.

Code Auswählen Erweitern

Wolf/192.168.3.117/DHK_BM-2_0x35 {"Programmwahl":{"340029":{"value":1,"text":"Auto"},"340032":1}}
Dies wird zu

Code Auswählen Erweitern

Wolf/192.168.3.117/DHK_BM-2_0x35/set/Programmwahl/340029/value
übersetzt, falls man über die Values arbeiten möchte.

Nochmal lieben Dank Beta-User, dass Du mir geduldig den einen oder anderen Tip gegeben hast, wie man das ganze umsetzen könnte.

Gruß
fhem024

[Beta-User]

Schön, dass nun einigermaßen klar ist, wie das "Kreis"-Prinzip funktioniert und auch bei deiner Gegenstelle (mit dieser seltsamen Struktur) konkret umgesetzt ist.

Magst du den Thread noch als [gelöst] markieren?

Die Präfixe wie DHK_BM-2_0x35, WWSystem_BM-2_0x35 oder TOB_0x8 will ich auch nicht wirklich weg haben, weil die darüber Auskunft geben, aus welchem Device / Steuerungsteil der Heizungsanlage der Parameter tatsächlich stammt.

Das mit "unabhängige Anlagenteile" erinnert mich an ebus. Da haben wir die einzelnen Teile zum größten Teil in eigene MQTT2_DEVICE-Instanzen ausgelagert, so dass man z.B. die Brauchwasser-Soll-Temperatur als "desired-temp" an der Brauchwassersteuerung einstellen kann. Das fügt sich m.E. sehr viel besser in den FHEM-Kontext ein als irgendwelche "technischen Readingnamen". Klar muss man wissen und nachvollziehen können, was woher kommt und sollte nichts durcheinanderwerfen, was nicht zusammen gehört, aber wenn man das "Ergebnis" nicht wirklich "lesen" kann, fängt man damit imo auch nicht allzuviel an.

Ich kann aber derzeit nicht abschätzen, welche Nebenwirkungen dieses on off hier hat. Hätte auch hugo mueller zum selben Resultat geführt?

Bezüglich des setters für die Temperatur ist das in der Tat völlig gleichgültig, was da steht, schon gleich, wenn und solange es diese setter gar nicht gibt.

Vielleicht schaust du zum Ganzen nochmal ins Wiki, da gibt es einen ("knackigen") Artikel zu MQTT2_DEVICE - Schritt für Schritt. Anregungen zur Verbesserung darfst du gerne geben .

[fhem024]

Hallo Beta-User,

ich habe leider noch einen Punkt vergessen, zu erwähnen . Da gibt es doch noch einen Setter, den ich benötige, der mit Umlauten im Namen daherkommt - genauer mit einem 'ß'. Das habe ich ja mit jsonMap gerade gezogen. Der Setter in der setList sieht dann wie folgt aus (ich habe via jsonMap aus ß -> ss gemacht):

Code Auswählen Erweitern

Wolf/192.168.3.117/DHK_BM-2_0x35/set/Normaussentemperatur_Heizkurve

Das funktioniert dann auch soweit - aber die Vorbelegung, also die Variable HK_Normaussen (unter diesem Namen rufe ich den Setter auf) wird zwar gesetzt (wie in allen anderen Fällen auch), aber die Rückmeldung bekommt er hier wohl nicht auf die Reihe. Ich bin aber froh, dass ich den Setter überhaupt nutzen kann.

Hast Du da noch eine Idee?

[Beta-User]

Hast Du da noch eine Idee?

Das jsonMap in deinem list sah dazu eigentlich ganz ok aus.

Ich würde in dem Fall man schauen, wie der MQTT-Verkehr im Ablauf ausschaut, wenn du den Parameter (in FHEM) setzt.(Siehe z.B. https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt#MQTT_-_Datenverkehr_mitlesen). Ohne diese Info ist es vermutlich ein "Stochern im Nebel".

Nachtrag noch: Wo sind eigentlich die ganzen Namen definiert? Vielleicht kann man "den ganzen problematischen Scheiß" auf der Gegenseite soweit gradeziehen, dass man nicht ständig nacharbeiten muss...?