FHEM Forum

nachdem Homematic nun EOL ist - und teuer - und die IP version auch teuer und mächtig indirekt bin ich bei shelly und Tasmota vermeintlich fündig geworden. Ich versuche nun diese beiden in deren generischen Versionen über MQTT2 in die bestehende Installation einzubinden. Die bestehende Beschreibubg ist sehr mächtig - ich hatte jedoch einige Probleme (auch weil ich nur sehr selten weiter arbeite...) das ganze mit Hand und Fuss einzubauen - und habe es immer noch nicht. Ertstes wirkliches Objekt ist ein  Shelly 2 kanal schalter (eigentlich einfach).
Anforderungen der Implementierung sind (für mich auf der Hand liegend):
- einfache Handhabung der Installation (keine endlos langen Attribute!)
- performantes System - ich rechne leicht mit 30+ devices und 100+ entities in fhem.
- automatische Systemprüfung - sind alle devices erreichbar
- nahtlose Einbindung in das bestehende System - beinhaltet, dass alle Readingnamen denen üblichen konventionen entsprechen
- Kanal Entities - zumindest möglich. Ein System funktioniert nur so generisch

Dass mir die Attribute zu lang sind, somit schlecht überprüfbar und ausserdem die Webdarstellung torpedeiren  - nun ja - werde ich ändern.
Performance-wise: die CID muss der Schlüssel zur Prüfung und erstellung der Readings sein. Das ist aktuell ein suchen über sämtliche regexp - passt mit meinen Performance-regeln nicht zusammen.
Die Erstellung der ReadingsList regeln ist für meine Lesart komplex - da die Namen der einzelnen Elements nicht klar erklärt ist - ich habe es am Ende durch endlose Experimente geprüft.
Schlüssel zur Erstellung der Readings ist "json2nameValue". zum Ersten fehlt hier eine "ordentliche" Dokumentation (und wie immer - im Forum nachlesen ist für Anwendung, ersetzt nie eine Dokumentation). wie wann und wo die postitiv und negativ filter eingesetzt werden, welche Optionen von anderen abhängig sind,... am Besten den Code nachlesen. Wie die jsonmap aussehen muss - keine Beispiele.
json2nameValue nutzt als Trenner der hierarchiestufen "_". Das ist m.E. maxinal ungeschickt, da dies typisch auch in den Namen vorkommt. In den endgültigen Readigns will ich natürlich nur "temperatur" stehen haben - und nicht die dem device eigene MQTT Hierarchie. Leider kann ich die Stufen nachträglich nicht mehr identifizieren, also nach "_" splitten - zumindest nicht sauber.
Logisch (für mich) - ich will die gemeldeten Datenpunkte verarbeiten (zustand des Ausgangs), egal über welche Methode er eingeholt wurde. Ich muss die Stufen also auflösen können.
Anhand der Stufen muss ich erkennen können, welcher Kanal sich gemeldet hat.
Am Ende muss ich die Kanalangabe, den Readingnamen und den Value in FHEM-Momenklatur übersetzen. Also ein
...switch_1_...output true
in
<channel1>level on
sowie dupliziert - da fhem dies bspw bei dimmern auch als state und pct benötigt - sowie der korrekten entity zugewiesen.
==> es ist (für mich) nicht hinnehmbar, dass MQTT im Frontend (readings) sich von anderen unterscheidet
==> die einfachen Methoden, dies zu übersetzen, entites zuzuweisen und auch die Values anzupassen habe ich nicht gefunden.
==> eine performante Lösung für das auflösen der Events in Readings - ohne exzesives regexp gesuche - suche ich ebenfalls

wie geht ihr damit um? Bin ich allein und bin ich auf den Holzweg?
ggf. werde ich wieder einmal den Code frisieren müssen

Warum nicht im richtige Forumbereich "MQTT" diskutieren?

Als ich mit mqtt angefangen habe, war mein erster Schritt, mich von dem ganzen Attribut-Gedöns, das man versucht, per template aufzuzwingen, verabschiedet habe. Die devices habe ich so angelegt, wie ich es mir vorgestellt habe.

Wenn ich einmal ein device eines bestimmten Typs erstellt habe, verwende ich dieses als Vorlage, falls weitere Geräte des gleiche Typs dazukommen. Im devicetopic muss ich dann nur die eindeutige ID ändern, und schon läuft das neue device.

Die ClientID spielt bei mir überhaupt keine Rolle. Sie ist nirgends definiert.

Als mqtt Server verwende ich mosquitto (auf einer Lightsail Instanz bei Amazon) und nanomq (hier im lokalen Netzwerk in einem proxmox container).
Diese Trennung mache ich deshalb, weil ich alle JsonMOD und HTTPMOD devices, die externe Quellen abfragen, auf Amazon ausgelagert habe und die ermittelten Werte dann per mqtt übertragen werden.
Die ganzen lokalen Shellies etc. brauchen aber keine Internetverbindung. Diese arbeiten komplett über den lokalen nanomq server.

Ist ja alles nett, und wer MQTT liebt, soll es auch nutzen. Aber versuch doch einfach mal (und bei ca. 30 Devices geht das problemlos...) das generische Shelly-Modul.

LG

pah

Zitat von: Prof. Dr. Peter Henning am 26 Juli 2026, 13:14:12Ist ja alles nett, und wer MQTT liebt, soll es auch nutzen. Aber versuch doch einfach mal (und bei ca. 30 Devices geht das problemlos...) das generische Shelly-Modul.

es gibt weitere MQTT - wie ich schon sagte bspw Tasmote (generisch,also nocht sonos). Die (meine) Idee ist, nicht x unterschiedliche Protokolle zu prüfen, lernen, anpassen. Shelly ist nur ein Beispiel - ESP32 und derivate ist für generische Ansätze in sonderfällen maximal flexiben. Eine spezial-Shelly Lösung ist daher endlich - und einarbeiten müssste ich mich auch noch. Ich sprach von 30+ devices - wenn man einmal anfängt geht es hier erst los!

ZitatDie ClientID spielt bei mir überhaupt keine Rolle. Sie ist nirgends definiert.

die CID wird in MQTT quasi immer einbezogen - und steht in der ReadingList an erster Stelle, vor dem ":". Ausserdem erscheint sie im define - oder was soll da rein?
Diesen Teil sehe ich einmal so (korrigieren mich)
define devicename CID
attr devicename readinglist CID:<topic>:<value> <action>
eigentlich hätte ich mir genau so die Definition des Attributs vorgestellt. Allerdings ist die CID in der Definition nicht vorgeschrieben. Daher werden bei jeder FHEM entity auch alle CIDs zugelassen.
Die CID ist prädestiniert um als Adresse zu fungieren (sagt ja der Name schon).
Wenn ich keine sinnvolle Alternative finde werde ich es genau so - und stringent - implementieren:

• im Define steht die CID
• Für Kanäle einer CID überlege ich noch. Der 2-fach switch hat eigentlich 4 Kanäle, frei programmierbar: 2 mal out und 2 mal in
• Readings werden auf die CID gefiltert - die wird in der message immer geliefert - bietet sich nicht nur an, das ist sicher die Idee von MQTT
• Readings der Kanäle brauchen einen diskriminator - definier ich mir noch
• Auswertung der Readings (readinglist-pendant) wird über die Adresse/ID (bei MQTT also CID) der/den entities zugewiesen
• Templates muss es auch geben hier bietet es sich an, wie bei CUL_HM (und sicher auch anderen) ein "model" zu definieren (Attribut) worüber das template ausgewählt wird
• da es wie immer keine weiteren interessenten gibt ist es nicht (wie bei CUL_HM) notwendig, user-templates zuzulassen. Wäre aber kein Problem, ist schon erprobt.
• ich werde nicht umhin kommen, eine subroutine zu schreiben, welche die Auswertung durchführt
• Giganto-Attribute mit unendlikch code sind keine Option - nicht übersichtlich, nicht wartbar, nicht managebar.

Noch einmal, es ins rechte Licht zu rücken -  vielen Dank für MQTT2 und auch json2nameval. Ist prima - aber ist für meine Ansprüche nicht ausreichend.
Eine Lösung mit auslagerungen - auch nach Amazon - lehne ich (bis jetzt) strikt ab.

Zitat von: martinp876 am 26 Juli 2026, 14:11:38die CID wird in MQTT quasi immer einbezogen - und steht in der ReadingList an erster Stelle, vor dem ":".

Dein Versteifen auf die CID halte ich persönlich für einen Holzweg.
Und in MQTT 5 ist die CID mehr oder weniger vollständig optional bzw. wird leer übergeben.

Zitat von: martinp876 am 26 Juli 2026, 14:11:38Ausserdem erscheint sie im define - oder was soll da rein?

Bei mir erscheint in keinem define eine CID.

defmod ku_Licht_Vintage MQTT2_DEVICE
attr ku_Licht_Vintage IODev nanomq
attr ku_Licht_Vintage devicetopic shellies/ShellyVintage-34945479E80B/light/0

Basierend auf dem devicetopic werden dann readingList und setList befüllt.

Ich glaube, die CID erscheint im define, wenn autocreate das device erstellt. Autocreate setzt die ja auch in die readingList, wenn mich nicht alles täuscht.

Kann man sich aber, wie betateilchen richtig sagt, komplett sparen. Das ist nur eine zusätzliche Fehlerquelle. Einfach in den Geräten ordentliche Topics konfigurieren und gut ist.

Zitat von: martinp876 am 26 Juli 2026, 13:43:25nicht x unterschiedliche Protokolle zu prüfen, lernen, anpassen

Na, da ich die ersten Jahre über das Shelly-Modul gepflegt habe, kenne ich das API sehr genau. Protokoll gibt es da, wenn man es genau nimmt, genau eines: REST. Aber, und das vor allem wegen der starken Veränderung des API über die Zeit, mit ganz unterschiedlichen Spezifikationen. Das Shelly-Modul verbirgt das vor dem Anwender, um eben nicht diesen ganzen Zoo verstehen zu müssen.

LG

pah

@pah: Du hast ja recht, aber die Frage hier im Thread ist nicht "Shelly best practice" sondern "MQTT best practice".
Spätestens, wenn man irgendwann ein mqtt-sprechendes device einsetzt, das nicht vom Shelly-Modul abgedeckt wird (z.B. weil es gar nicht von Shelly stammt) muss man mit (mindestens) zwei verschiedenen Ansätzen arbeiten. MQTT ist dabei der Weg, das mehr oder weniger zu vereinheitlichen.

Zitat von: passibe am 26 Juli 2026, 16:37:06Ich glaube, die CID erscheint im define, wenn autocreate das device erstellt

Ok, ich arbeite weder mit autocreate noch mit attrTemplate.
Das macht mir die Arbeit schon erheblich leichter und meine mqtt devices funktionieren so, wie ich es mir vorgestellt habe.

Für mich ist das Attribut devicetopic jedenfalls sehr viel wichtiger und hilfreicher als eine CID, zumal man in dem Attribut innerhalb eines devices sogar unterschiedliche devicetopics definieren kann, um beispielsweise eingehende mqtt-Nachrichten unterschiedlicher Geräte in einem einzigen FHEM device zusammenzuführen.

Zitat von: betateilchen am 26 Juli 2026, 16:55:47MQTT ist dabei der Weg, das mehr oder weniger zu vereinheitlichen.

Ich habe viele Devices, die FHEM via MQTT versorgen, dazu gehören zwei E-Autos und drei Staubsaugerroboter.

Meine Erfahrung: Nix einheitlich, Geräte verhalten sich komplett unterschiedlich.

LG

pah

Etwas Hintergrund zu ClientID (aka CID) in FHEM:
- die CID des Senders kennt nur der MQTT Server. "Normale" MQTT Clients, die ueber einen externen Broker arbeiten, haben keine Ahnung, wer eine Nachricht gesendet hat.
- MQTT2_SERVER & MQTT2_DEVICE sind entstanden, damit die MQTT Anbindung in FHEM einfacher wird, autocreate war einer der Ziele.
- MQTT2_DEVICE erweitert beim Empfang einer unbekannter Nachricht das readingsList der Instanz mit der gleichen ClientID.
- das funktioniert ohne Weiteres mit MQTT2_SERVER. Bei einem externen Broker (d.h. MQTT2_CLIENT) muss man ein bridgeRegexp Attribut setzen (was je nach Topic eine ClientID erfindet), damit autocreate funktioniert.
- beim Implementieren von MQTT2 hatte ich keine Erfahrung mit MQTT Geraeten, ich bin davon ausgegangen, dass Geraete der gleichen Art auch die gleichen Topics verwenden. Deswegen wurde das ClientID Teil der readingList. Aus heutiger Sicht ist ClientID im readingList ueberfluessig und sollte ausgebaut werden, da ein so angelegtes readingList nicht ohne Aenderung ueber einen externen Broker bedient werden kann.
- ClientID in der readingList ist ueberfluessig, weil die ueblichen MQTT-Geraete eine eindeutige ID als Teil des Topics seinden. Es sei denn der (unerfahrene) Benutzer meint das Topic selbst bestimmen zu wollen, wodurch die muehsam vorbereiteten attrTemplates nicht mehr anwendbar sind.
- es gibt einige Geraete (eher selten), die temporaere oder leere ClientIDs verwenden.

nun - ich lerne gerne.
die CID kennt der Sender selbst und der Broker sieht sie in jedem Fall. Zustimmung. Allerdings habe ich mit dem Begriff "Client" ein Problem - und hier stellen sich struktur-Fragen.
Die Idee und Semantik der Broker und Client berstehe ich als ein Sender triggert ein Device wobei der Broker das Routing übernimmt. Hier enrolt man sich um über die event (welchen einen eben interessieren) informiert wird.

die vorhandenen Module sehe ich aber anders. Der Server ist kein Broker sondern nur das IO device. Mein MQTT-Device ist kein Client sonder das Abbild/die visualisierung des externen devices.

Der Broker ist eigentilch das fhem-notify. Hier werden die trigger an die clients weitergereicht und führen zu Aktionen. FHEM-notify somit der inter-protokol-broker in MQTT sprache. Geht natürlich in beide Richtungen.

==> klar, kann man anders machen - aber bislang sind die Abbilder der HW nur die Darstellung  und das Interface zu den HW-devices.

Was Rudi sagt ist eine Möglchkeit. Der erste Teil des Topic welcher bei shelly "prefix" genannt wird, wird per default mit der CID gleich gesetzt. Den Prefix wollte ich "aufsparen" - wofür weiss ich auch noch nicht.
Wenn man also die CID nicht nutzt und der prefix faktisch als ID genutzt wird ist das auch eine Lösung - grundsätzlich das gleiche Ergebnis.

Das ändert aber rein gar nichts an der zuordnung/FHEM-routing der Messages. "Meine" FHEM entity lauscht mit, was die MQTT-HW so alles von sich gibt. Sie ist also interessiert an allen messages (jetzt neu:)  mit diesem Prefix. Meine Entity wird also mit diesen Prefix getaggt werden - irgendwo (DEF oder ATTR - wurscht). Dann werden alle messages der Entity verarbeitet - unutzes verworfen... so wie bei jeder anderen HW in FHEM ebenso.
Durch das Setzen der Readings welche sich daraus ergeben werden dann die notifies gespeist - und so weiter.

Damit ist die Entity erst einmal in fhem eingebunde wie alles andere auch. Und wie bei allen anderen IOs kann man (jetzt neu) über den Prefix genau die entites füttern, welche diesem Prefix zugeordnet sind. Damit bietet sich DEF als Tagging-Point an.

Danke für die Diskussion über CID - generell ändert dies nur marginal meine Darstellung. Das "routing" im MQTT Server ist für mich immer noch unpassend. Es ist eher ein broker, welchen ich an dieser Stelle nicht brauche. Das passt auch nicht zu FHEM.

@pah: mit Sonderfällen muss man gesondert umgehen.


p.s.: auch auswerten könnte man die source information in der message. Ist aber umständlicher, wäre aber wohl eindeutig.
"Topic " ist deutlich geschmeidiger und sollte reichen.

Vorab @Rudi: Magst du https://forum.fhem.de/index.php?topic=116162.0 mal im für MQTT passenden Bereich anpinnen?
Der geht wohl gerne mal unter...

@martinp876:
Der Thread wäre vermutlich im MQTT-Foren-Bereich besser aufgehoben als unter "Sonstiges"...
Neben dem og. Thread würde ich https://wiki.fhem.de/wiki/MQTT2_DEVICE_-_Schritt_f%C3%BCr_Schritt als Einstiegslektüre empfehlen, nach wie vor sind beide auf dem ziemlich letzten Stand der Dinge.

Was "Server" und "Client" angeht, stellt sich mir die Frage, was daran die Frage ist. FHEM stellt zwei Module bereit, eines zum verbinden als Client an einem "extern" laufenden Server, eines als "Server", der in der MQTT-Sprache eben nicht mehr "Broker" heißt, aber von "typischen Clients" (wie den Shelly- oder Tasmota-ESPs) als Server-Dienst akzeptiert wird.
Dass das in der FHEM-Funktionalität zugleich IO-Module im zweistufigen Modulaufbau sind, ist doch damit nicht ausgeschlossen.

Da die Welt der "typischen MQTT-Clients" sehr bunt ist (und teils dadurch geprägt zu sein scheint, dass mal eben der Azubi eine MQTT-Funktionalität eingebaut hat - ohne Rücksicht auf Sinnhaftigkeit dessen, was da passiert - ) ist leider weiter Stand der Dinge.

Dazu eine Art "shared best practices" bereit zu stellen, war der Gedanke hinter attrTemplate. Wer es nicht mag oder besser weiß, kann ja sein eigenes Ding zusammenschustern. Jedenfalls: Da ist der Versuch zu finden, "FHEMische" Devices/entities zu basteln mit "üblichen" Steuerungsfunktionen und Reading-Namen.

Sicher nicht perfekt, aber vorhanden...
 
 

@martinp876:

vielleicht könntest Du Dich gedanklich (meinetwegen vorübergehend) von der FHEM-eigenen MQTT2-Implementierung des Servers verabschieden. Dann wird das Grundverständnis zu mqtt vermutlich etwas klarer. Letztlich handelt es sich um ein Protokoll und nicht um Hardwarestrukturen.

Du wirfst meines Erachtens gerade zu viele Dinge zusammen in einen Topf, die da nicht zusammen hineingehören.

ZitatVorab @Rudi: Magst du https://forum.fhem.de/index.php?topic=116162.0 mal im für MQTT passenden Bereich anpinnen?

Erledigt.

ZitatDa die Welt der "typischen MQTT-Clients" sehr bunt ist (und teils dadurch geprägt zu sein scheint, dass mal eben der Azubi eine MQTT-Funktionalität eingebaut hat - ohne Rücksicht auf Sinnhaftigkeit dessen, was da passiert - ) ist leider weiter Stand der Dinge.

Gut formuliert. MQTT erfordert einfach, sich von den eigenen Vorurteilen in Bezug auf Standardisierung zu trennen.

LG

pah

mir ist (ernsthaft) nicht klar, was an meiner Aussage unklar ist.
Der Server ist das IO welches die MQTT cienten mit den realen devices verbindet.
In der Welt ausserhalb kann man MQTT clienten direkt verbinden - das ist vollkommen klar.
Meine Annahme ist, dass ein Client in FHEM erst einmal "nur" alle Informationen des realen Device einsammelt und darstellt. Ok, die Senderichtung habe ich gerade unterschlagen.

So funktionieren zumindest einige andere Famielen in FHEM auch. Das ist eine Kernauffassung aus der sich dann exterm viel ableitet.
Also erste Frage: haben wir hier einen Konsenz oder sind die MQTT_DEVICES bei euch anders definiert?
a) mir ist klar, das man es anders machen KANN. Aber nicht muss.
b) ich muss und will nicht alles implementieren, was MQTT hergibt. Der obige Ansatz sollte reichen, MQTT in FHEM zu harmonisieren
c) mittelfristig ist es mir zu komplex, komplexe abhängigkeiten einzubauen - das werde ich in 2 Monaten nicht mehr warten können

Ich weiss also nicht, was ich durcheinander werfe. Ich habe gesehen, dass ein MQTT_DEVISE zugriff auf alle MQTT messages haben kann. Und genau das brauche ich nicht (KISS-Ansatz).

Ich wieder hole mich wohl,wenn ich also sage:
- die Funktion IO für den Server reicht mir aus
- ein Client  oder auch MQTT_DEVICE bekommt alle Nachrichten seines realen Partners (Kanäle ist eine Abwandlung des gleichen)
- sämtliche interne Trigger werden über notify erledigt.

Das sehe ich als schlank und daher übersichtlich.
Es beraucht noch eine best-practice (nach der ich hier eigentlich gefragt habe) wie man die messages parsed, in Readings wandelt, filtert,...

Wenn der Grundgedanke nicht übereinstimmt  - was ist ein Client "in FHEM"  - dann kommen wir klar zu anderen Ergebnissen.

Noch eines (evtl wiederholt es sich): Ich will MQTT in FHEM einbinden und nicht umgekehrt.

Noch einmal explizit die Frage an das Auditorium das ein MQTT Client in FHEM  leisten soll.
Und noch eines - sorry - meine (experiment-)shelly sind auch clients - formal. die tun auch real etwas. der fhem-client ist also immer nur ein Soft-Abbild. Das ist aus meiner sicht der entscheidende Unterschied zu realen Device.

@martinp876


Mein erster Post am Sonntag hat es nicht geschafft, seit dem hat sich die Diskussion weiter entwickelt.
Mit scheint, jetzt ein guter Zeitpunkt für einen neuen Versuch gekommen zu sein.


Ich setze MQTT inzwischen recht umfangreich ein: Tasmota, Shelly Gen1/Gen2, Zigbee2MQTT, OwnTracks, AWTRIX und einige eigene Dienste. Als Broker verwende ich direkt MQTT2_SERVER:

    define MQTT2_FHEM_Server MQTT2_SERVER 1883 global
  attr MQTT2_FHEM_Server autocreate complex
 
  Meine Praxis ist dabei:

  1. attrTemplate als Ausgangspunkt verwenden.
  2. Danach readingList auf die wirklich benötigten Topics und Readings reduzieren.
  3. Mehrkanalgeräte in mehrere MQTT2_DEVICE-Entities aufteilen, wo sinnvoll. Beim Rolladen natürlich nicht.
  4. Mit devicetopic, jsonMap und manchmal auch etwas Perl in der readingList die MQTT-Daten auf FHEM-übliche Readings abbilden.
  5. Erreichbarkeit über LWT beziehungsweise online/availability behandeln.

  Ein Beispiel für einen Shelly Plus 1:

    define GartenSteckdose MQTT2_DEVICE shellyplus1_xxxxxx
  attr GartenSteckdose devicetopic zuhause/terrasse/steckdose

  attr GartenSteckdose jsonMap
  switch_state:state
  switch_temperature_tC:temperature
  switch_temperature_tF:0
  params_wifi_sta_ip:ip

  attr GartenSteckdose readingList
  $DEVICETOPIC/online:.* online
  $DEVICETOPIC/events/rpc:.* { json2nameValue($EVENT,"",$JSONMAP) }
  $DEVICETOPIC/status/switch_0:.* {
  $EVENT =~ s/"output":true/"state":"on"/g;;
  $EVENT =~ s/"output":false/"state":"off"/g;;
  json2nameValue($EVENT,"switch_",$JSONMAP)
  }

  attr GartenSteckdose setList
  toggle:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Switch.Toggle","params":{"id":0}}
  off:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Switch.Set","params":{"id":0,"on":false}}
  on:noArg $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Switch.Set","params":{"id":0,"on":true}}
  on-for-timer $DEVICETOPIC/rpc {"id":0,"src":"fhem","method":"Switch.Set","params":{"id":0,"on":true,"toggle_after":$EVTPART1}}

  attr GartenSteckdose setStateList on off
 
  Damit wird aus dem Shelly-Feld output:true bewusst ein FHEM-typisches state:on. Die Zuordnung mache ich nicht erst nach dem vollständigen Flattening eines großen JSON-Baums, sondern bereits anhand des konkreten Topics status/switch_0.

  Für Mehrkanalgeräte verwende ich getrennte FHEM-Devices. Ein Tasmota-Gerät (Shelly analog) mit zwei Relais sieht bei mir vereinfacht so aus:

    define LichtTisch MQTT2_DEVICE DVES_xxxxxx
  attr LichtTisch devicetopic zuhause/wohnzimmer/licht
  attr LichtTisch readingList
  tele/$DEVICETOPIC/LWT:.* LWT
  tele/$DEVICETOPIC/STATE:.* {
  my $r=json2nameValue($EVENT);;
  return { map { $_ => $r->{$_} }
  grep { /^(?:Uptime|POWER1|RSSI)$/ } keys %{$r} };;
  }
  stat/$DEVICETOPIC/RESULT:.* { json2nameValue($EVENT) }
  attr LichtTisch setList
  off:noArg cmnd/$DEVICETOPIC/POWER1 0
  on:noArg cmnd/$DEVICETOPIC/POWER1 1
  toggle:noArg cmnd/$DEVICETOPIC/POWER1 2
  attr LichtTisch stateFormat POWER1

  define LichtCouch MQTT2_DEVICE DVES_xxxxxx
  attr LichtCouch devicetopic zuhause/wohnzimmer/licht
  attr LichtCouch readingList
  tele/$DEVICETOPIC/LWT:.* LWT
  tele/$DEVICETOPIC/STATE:.* {
  my $r=json2nameValue($EVENT);;
  return { map { $_ => $r->{$_} }
  grep { /^(?:Uptime|POWER2|RSSI)$/ } keys %{$r} };;
  }
  stat/$DEVICETOPIC/RESULT:.* { json2nameValue($EVENT) }
  attr LichtCouch setList
  off:noArg cmnd/$DEVICETOPIC/POWER2 0
  on:noArg cmnd/$DEVICETOPIC/POWER2 1
  toggle:noArg cmnd/$DEVICETOPIC/POWER2 2
  attr LichtCouch stateFormat POWER2
 
Beide Entities haben dieselbe CID und dasselbe devicetopic. Die Trennung erfolgt durch die konkreten Topics beziehungsweise durch das Filtern auf POWER1 oder POWER2. So können Automatisierungen mit normalen FHEM-Devices wie LichtTisch und LichtCouch arbeiten, ohne die MQTT-Kanalstruktur kennen zu müssen.

Bei Zigbee2MQTT ist es meist noch kürzer:

    define Kuechenlicht MQTT2_DEVICE zigbee_kuechenlicht
  attr Kuechenlicht devicetopic zigbee2mqtt/zuhause/kueche/licht
  attr Kuechenlicht readingList
  $DEVICETOPIC:.* {
  my $r=json2nameValue($EVENT);;
  $r->{state}=lc($r->{state}) if defined $r->{state};;
  return $r;;
  }
  $DEVICETOPIC/availability:.* availability

  attr Kuechenlicht setList
  on:noArg $DEVICETOPIC/set {"state":"ON"}
  off:noArg $DEVICETOPIC/set {"state":"OFF"}
  brightness:colorpicker,BRI,0,5,255 $DEVICETOPIC/set {"state":"ON","brightness":$EVTPART1}

  attr Kuechenlicht setStateList on off
 
Hier normalisiere ich ON/OFF direkt auf on/off. Die Erreichbarkeit kommt separat über availability.

Mein Fazit: Ich versuche nicht, aus jedem eingehenden JSON automatisch ein universelles FHEM-Device zu erzeugen. MQTT ist für mich zunächst der Transport. Die Übersetzung in die FHEM-Nomenklatur erfolgt pro Gerätefamilie über attrTemplate, readingList, jsonMap und gegebenenfalls eine kleine Perl-Funktion.

Die langen Attribute sind in der Weboberfläche tatsächlich wenig angenehm. In der Konfigurationsdatei sind sie mit Einrückung und Zeilenumbrüchen aber noch gut wartbar. Wichtig für die Performance ist aus meiner Sicht vor allem, Topics möglichst konkret zu abonnieren und aus großen JSON-
Nachrichten nur die tatsächlich benötigten Readings zurückzugeben.

Damit habe ich auch bei vielen Geräten und getrennten Kanal-Entities bislang keine praktischen Performanceprobleme festgestellt.

Grüße Sidey

@Sidey:
Besser kann man das kaum zusammenfassen.

@martinp876
Das mit den langen Attributen ist lästig, aber für ein generisches ("fhem-client-") Modul kaum zu vermeiden, denn letztlich muss irgendwo die Info hin, wie eine auf ein bestimmtes Topic kommende Payload auszuwerten sein soll (readingList) bzw. wie und wohin ggf. von FHEM aus zu sendende Anweisungen bzw. Anfragen zusammenzubauen sind (setList/getList).

Die "alte" Implementierung (IO-Modul MQTT, "fhem-clients" MQTT_DEVICE/MQTT_BRIDGE) macht das statt der o.g. Attribute (zu MQTT2_DEVICE) durch eine Vielzahl der "immergleichen" Attribute, ohne die Option, direkt Perl-Funktionen aufzurufen oder "generische" Variablen (=>devicetopic) zu verwenden.

Da die Einrichtung eine einmalige Sache ist, ist das mit den multiline-Attributen m.E. weiterhin der praktikabelste Weg.

Für manche Zwecke rufe ich auch schon mal direkt modifizierte Varianten von json2nameValue() auf. Hier z.B. ein (zigbee-) Device, das an den zigbee2mqtt-Dienst eben sekündlich Daten sendet, die dann von dort aus auch so (ungefiltert) eingehen:
defmod Solaranlage_FI MQTT2_DEVICE zigbee_0xblub
attr Solaranlage_FI devicetopic zigbee2mqtt/0xblub
attr Solaranlage_FI readingList $DEVICETOPIC:.* { FHEM::attrT_z2m_eocr_Utils::j2nV_extended($NAME,$EVENT) }\
$DEVICETOPIC/availability:.* { $EVENT=~s{state}{availability}x;; my $ret=json2nameValue($EVENT);; $ret->{state}='off' if $ret->{availability} eq 'offline';; return $ret }


Es gibt auch noch ein paar fhem-client-Module, die sehr spezifischen Code beinhalten, aber das macht in der Regel nur Sinn, wenn es eigentlich nicht darum geht, erst mal Infos zu sammeln, die dann FHEM-typisch per notifyFn weiter ausgewertet werden. (Bsp: RHASSPY als Sprachsteuerungsoption).

Ansonsten wäre meine Anregung, dich an die für MQTT@FHEM üblichen Begrifflichkeiten zu gewöhnen, sonst gibt das eine Unzahl von Einbruchsstellen für Missverständnisse... (Meintest du in deinem letzten Beitrag tatsächlich MQTT_DEVICE, oder war nicht doch MQTT2_DEVICE gemeint? Eindeutig letzteres...)

@Sidey,
1) dein Ansatz der FHEM Entites bezüglich der Kanäle entspricht exakt meiner Vorstellung - und Planung.
2) die Auswertung der ReadingList werde ich mir Ansehen

@Beta-User

ZitatDas mit den langen Attributen ist lästig, aber für ein generisches ("fhem-client-") Modul kaum zu vermeiden...

sehe ich ganz und garnicht so. Ok, wenn man es in Attributen machen will, schon. Aber notwendig ist das nicht. Ich habe einfach eine Sub in meinen Utils hierfür erstellt.
attr mydevice coverAbDoor:shelly.*:.* {muParseMQTT($NAME,$CID,$TOPIC,$EVENT)}diese werden ich ausbauen analog wie es bei CUL_HM funktioniert.
- dem MQTT Device werden ich einen "Modelnamen" zu weisen (attr) und ggf eine "Kanal" extra. Weiter werde ich eine ID verankern in def oder in attr - funktional egal.
- die (meine) templates werde ich dann in einer entsprechenden Struktur hinterlegen, welche die Auswertung und die Readings steuert. Um kompatibel zu bleiben wird die Struktur in gewohnter weise zurückgegeben.

Damit erreiche ich, dass die Auswertung für alle gleichem Model gleich (gut oder schlecht) ist.
- Auch setlist wird über das "model" gesteuert werden. Wie alle Typen welche ich ernsthaft betreibe werden auch hier noch meine generischen kommandos addiert - da kann ich die setlist  abfrühstücken.

damit ist meine Installation (cfg) einfach zu prüfen - der Rest ist code und nach "abnahme" statisch und stabil. So brauche ich es.

also danke für den Vorschlag zu den readings - interessiert mich sehr.

@pha @Beta-User klar was ihr sagt - unklar, was ich damit anfangen soll. JEDES device und jede variante/kanalmodel muss jemand /werde ich bei Einsatz prüfen müssen und ein Template erstellen.

Das ganze geht noch nicht meine Bedenken der Performance an. Und da bin ich etwas sensibel... mal sehen, evlrt glätte ich MQTT_DEVICE etwas.
Und dann kommt noch die Maintenance Aufgabe - bspw prüfen der Devices auf "lebt noch".

Vielen Dank für die gute Diskussion bis jetzt.

Zitat von: martinp876 am 29 Juli 2026, 18:41:381) dein Ansatz der FHEM Entites bezüglich der Kanäle entspricht exakt meiner Vorstellung - und Planung.

Wir haben da vermutlich alle miteinander eine ziemlich ähnliche Vorstellung: Jeder (on-/off-) schaltbare (Haupt-) Kanal sollte ein fhem-device ("entity") ergeben.

Einige "Sonderlocken", die es sonst (fast) nur in CUL_HM gibt, finden sich auch in MQTT2_DEVICE: So kann man (via setStateList) einen on-Befehl übergangsweise mit "set_on" nach "state" bekommen, bis die Bestätigung von der Hardware zurückkommt, dasselbe z.B. für "brightness" oder "pct"... 

Die allermeisten in attrTemplate (mqtt2.template) hinterlegten Beispiele berücksichtigen das ;).

Zitat von: martinp876 am 29 Juli 2026, 18:41:38sehe ich ganz und garnicht so. Ok, wenn man es in Attributen machen will, schon. Aber notwendig ist das nicht. Ich habe einfach eine Sub in meinen Utils hierfür erstellt.
Code Auswählen Erweitern

Code Auswählen Erweitern

attr mydevice coverAbDoor:shelly.*:.* {muParseMQTT($NAME,$CID,$TOPIC,$EVENT)}diese werden ich ausbauen analog wie es bei CUL_HM funktioniert.

Zwei Anmerkungen:
1. Ist das nicht genau das, was ich beschrieben habe? Du nimmst ein Attribut und schreibst rein, wie eingehende Info zu verarbeiten ist? Wie lange der auslösende Topic-Abschnitt ist, ist in dem Zusammenhang erst mal irrelevant, da in der Regel auf der Hardware zu konfigurieren.

2. Tipp: Verwirf den Gedanken, $CID sei irgendwie wichtig. Klare Topic-Strukturen sind hilfreich, alles andere zur Identifikation der dahinter liegenden Hardware kann (und sollte) man daraus ableiten können.

Zitat von: martinp876 am 29 Juli 2026, 18:41:38Und dann kommt noch die Maintenance Aufgabe - bspw prüfen der Devices auf "lebt noch".

"pct set_90" hatte ich ja bereits als Indikator genannt.
Was "LWT" angeht, sind meine Erfahrungen etwas gemischt. MQTT2_SERVER hat da bei mir z.B. ein Problem mit einem Tasmota, der (jetzt) im LAN hängt (der Vorgänger war mit demselben Symptom via WLAN eingebunden...).

Und was macht man mit Hardware, die hinter einem (Hardware-Interfacing)-Dienst hängt? zigbee2mqtt geht offline, wenn die Software streikt, und dann ist alle Hardware, die dahinter hängt nicht mehr erreichbar (ähnlich, wie wenn das letzte CUL_HM-IO ausfällt). (Ähnliches gilt für den AHOY-DTU-ESP32, mit dem meine PV-Inverter abgehorcht werden).

Kurz: Sowas ist imo eine Aufgabe für ein Querschnittsmodul wie ReadingsWatcher (oder ein "at"...).

Was Performane angeht, kann man sicher das eine oder andere straffer vercoden, v.a., wenn man nur jeweils den Teil berücksichtigt, den man in der eigenen Installation braucht und dabei ggf. den "Zoo" noch dadurch vereinfacht, dass man nur bestimmte Hersteller/firmwares wählt. Solange das klappt, ist alles gut, wenn nicht, wird es schnell (imo) unwartbar.

Aber vermutlich übersehe ich was wichtiges oder wir sprechen aneinander vorbei.

ZitatMQTT2_SERVER hat da bei mir z.B. ein Problem mit einem Tasmota, der (jetzt) im LAN hängt (der Vorgänger war mit demselben Symptom via WLAN eingebunden...)

Zitat(Ähnliches gilt für den AHOY-DTU-ESP32, mit dem meine PV-Inverter abgehorcht werden)

Beides find ich interessant. Hattest Du dazu mal irgendwo mehr Hintergrund geteilt?

Zitat von: TomLee am 29 Juli 2026, 22:55:35Beides find ich interessant. Hattest Du dazu mal irgendwo mehr Hintergrund geteilt?

Nein, jedenfalls nicht, soweit ich mich entsinne.

Da das hier aber ziemlich OT (und nach wie vor im falschen Forenbereich) ist: https://forum.fhem.de/index.php?msg=1367219

Zitat1. Ist das nicht genau das, was ich beschrieben habe

vielleicht - nein, eher nicht. Musst du entscheiden.
Mein Code ist in einer Subroutine. Das ist für mich entscheidend. Die folgende Auswertung wird nämlich deutliche ausführlicher und subtiler als das, was ich in einem Attribut darstellen kann. Weiter wird die Subroutine generisch - und für ALLE devices gültig sein. Die Steuerung wird über Attribute erfolgen, welche dem Device anhängen - wie "model" oder "Channel".
So eine Routine gibt es auch in CUL_HM - da ist sie nicht sichtbar, weil im Code verankert.

Zitat2. Tipp: Verwirf den Gedanken, $CID sei irgendwie wichtig

also in MQTT_DEVICES wird dieser erst einmal extensiv ausgewertet.
Ich werde das prüfen. Typisch hat eine message in jeden Protokol eine source und eine destination adresse. Es gilt, diese zu identifizieren und dann die Readings mit den Messages der aus der source zu befüllen.
in ReadingsList werden die Level "source-select" und "content-eval" vermischt. Das macht die Sache nicht geradlinig.
Für Tasmota und shelly kann ich sowohl CID alsauch topic (bei shelly ist es prefix) einstellen. Ok, CID wird als Adresse ausserhalb von json genutzt - ist aber erste einmal egal.
Ich kann also die masse meiner Devcices sauber darüber identifizieren. Wenn mit welche unterkommen die hier schlampen werde ich das dann betrachen.

ZitatUnd was macht man mit Hardware, die hinter einem (Hardware-Interfacing)-Dienst hängt?

ich verstehe die Frage nicht. Natürlich verstehe ich die Aussage - allerdings verstehst du meinen Ansatz nicht. Hier ein paar Überlegungen und Statemens von mir
1) mit "Alive" stelle ich fest, dass ein Gerät erreichbar ist
2) Geräte sollte ich klassifizieren in "statisch" und "dynamisch" erreichbar. Fest installierte sind statisch während tragbare geräte in der Hosentasche das Haus auch verlassen dürfen. Statische MÜSSEN erreichbar sein
3) "dead" ist evtl die falsche Phrase - sie kann immer nur bedeuten "unreachable" (ist mir aber zu lang :) )
4) nicht erreichbar von statischen Devices ist IMMER einen Alarm (unterschiedlichen Levels ) wert - irgend etwas ist nicht mehr steuer oder überwachbar.
5) die Auswirkungen von "Dead" sind zu prüfen - also was soll das System 'automatisch' machen. m.E. sollte der State auf Dead gesetzt werden - ggf auch verschiedene Readings. Ein Thermostat liefert eben keine Werte mehr und damit ist das Reading "Temperatur" unsicher. Und unsicher ist für mich kein tragbarer zustand. Beachte, dass ich Temperatur ggf auch in Grafiken ansehe, den Zusammenhang mit "state" also nicht sehen kann.
6) alarm-hierarchie: über die denke ich schon etwas länger nach - habe auch einen Level in CUL_HM eingebaut. Ich vermute dass dies ausser mir keine nutzt. Die Überwachung der Geräte soll performance-schonend sein (logisch, gilt immer) - also werden nur die Devices (CUL_HM Nomenklatur) auf Alive geprüft. Die Kanäle bzw deren Readings werden ausgehend von Device entsprechend modifiziert
Der next-level, das IO also... das habe ich schon lange auf dem Schirm. Rein formal ist das kein Unterschied. Wenn das IO ausfällt sind alle geräte dahinter "dead"  - oder sematisch korrekt "unreachable". Wir verstehen die Details und müssen sie hier nicht runter brechen: Multiple IOs, temporary stuck (device overload),...
==> Unreachable ist unreachable (und damit für FHEM dead). Kein Grund, das Device in den Müll zu werfen aber ein Grund tätig zu werden und das Problem zu lösen.
==> hat man ein instabiles System hat man eh verloren

ZitatWas Performane angeht, kann man sicher das eine oder andere straffer vercoden,

nun, ich sehe, dass für alle MQTT messages sämtliche devices mit allen Readings geprüft werden. Ok, die Prozessoren werden immer schneller... aber hier bin ich halt etwas eigen.
Mit steigender Anzahl der Devices potenziert sich das ganze. Mehr messages müssen gegen mehr regexp geprüft werden. Das geht m.E. besser. Ich probiere es gerade einmal - und da kommt führend eben die CID - oder der Topic - oder der prefix zum tragen.

kurz die Idee:
eines der obigen werde ich als "adresse" nutzen (das ist sicher) mit welcher ich die entity tagge.
Empfange ich die message suche ich das entsprechende Device. Hier lese ich die Tags "model" und "channel" (fix ist das noch nicht, sollte aber zum Verstehen der Idee reichen). Dementsprechend werde ich die message parsen und in Readings wandeln.
In der Entity setze ich also "Device-ID" und "Model" - und dann ggf noch "channel". Der Rest ist dann ein Template. So kann ich "baugleiche" devices spielend und übersichtlich einbauen und duplizieren.
Es gibt einiges zu feilen, klar

Meine 2 sehr kurzen ct:
- In "MQTT_DEVICES" (?) ist $CID nur relevant, wenn man sich statt dieses nicht existierenden Moduls mit MQTT2_DEVICE befasst (=> korrekte Terminologie ist mir wichtig, sonst reden wir weiter ständig aneinander vorbei). Was letzteres angeht, hat der Erfinder und Maintainer deutlich (in etwas anderen Worten) jüngst geäußert, dass er das zwischenzeitlich selbst für einen Irrweg hält...

- Die Welt der Geräte und Dienste, die das MQTT-Protokoll implementiert hat, ist sehr viel bunter, als du das mit deinen (mit Verlaub) eben mal 2 Typen beurteilen kannst.

- ad "alive" und den vermuteten allgemeinen Problemen bei ESP-basierter Hardware siehe auch https://forum.fhem.de/index.php?topic=145223.msg1367339#new

Kurz: Dein Ansatz ist m.E. ein unwartbarer Irr- und Sonderweg.

Wie gesagt: Meine 2ct.

Das ist übrigens zwar deutlich gesagt, aber nett gemeint, und den Code von CUL_HM kannte ich auch mal einigermaßen im Detail ;) .

---

Um noch was positives anzufügen:
Für (mehr oder weniger) jedes "model" bzw. "model-family" je eine spezifische Perl-Routine aufzurufen, dürfte eher zielführend sein. Es gibt durchaus Spezifika bei einzelnen Gerätegruppen (oder Diensten wie zigbee2mqtt), die über die generische Attribut-Auswertung via json2nameValue() nicht "gut" (und effizient) abgebildet sind. Z.B. sendet zigbee2mqtt die Batterie-Spannung typischerweise in mV...

Falls in diese Richtung Vorschläge kommen, befasse ich mich gerne damit!

nun - meine Experimente gehen voran - und mein Konzept nimmt gedanklich Gestalt an. Zu eueren Bedenken fehlt mir tatsächlich der Zugang - oder die Beispiele.
Hier noch einmal meine Anforderungen. Falls diese sich von euren unterscheiden können wir es versuchen, abzugleichen
Ziele und Requirements
1) MQTT in FHEM integrieren - nicht umgekehrt. D.h. ich muss nicht alles, was MQTT könnte auch machen. U.a. bedeutet dies, dass ein MQTT_DEVICE kein genereller Client ist sondern nur ein avatar des realen Geräts. Damit vereinfachen sich die Routing-Anforderungen
2) Tasmota und Shelly sind meine Kandidaten und Prototypen. Das Konzept wird offen sein so dass ich anderen integrieren kann wenn der Bedarf besteht
3) kodieren in Attributen (readingList) geht aus mehreren Gründen nicht. Zum einen wird die gesamte Darstellung dermassen versaut, dass es nicht mehr lesbar ist - geht garnicht. Zum 2. wird die Vergleichbarkeint 2er devices unangemessen schwer. MEINE templates werden nicht per Copy erstellt sondern per Referenz. Alles andere ist für mich am Ende nicht akzeptabel
4) die Performance beim Parsen ist wichtig - die aktuelle Implementierung unangemessen. Das geht deutlich besser
5) das einrichten einer entity muss mit wenigen Handgriffen UND übersichtlich erfolgen können
6) Entites auf Kanalbasis sindsowieso gesetzt

Zu den Einwänden
CID ist ein Holzweg
kann ich aktuell nicht erkennen. Shelly und Tasmota laufen bereits. Sollte ein Device "erscheinen" welches das nicht kann werde ich es betrachten und eine Lösung finden. MQTT arbeitet  damit - src und dst werden übertragen (sollten wohl auch)... Ich sehe bislang kein Problem. Klar - der Anwender (also ich) muss die CID am Device korrekt einstellen.
eigene Implementierung des Servers
Ich werden sowieso nichts auf fhem veröffentlichen (neues Modul) wenn keine relevante Nachfrage besteht. Ich habe (leider) schon mehrere Module frisieren müssen.
Aktuell wird bei meinen Konzept der Server nicht angetastet - "DEVICE" ist der Kandidat.

Mein Konzept
Vorwort
ich erwarte nicht, dass es in MQTT3 umgesetzt wird. Ziel ist es wie immer, möglichst am alten Code festzuhalten.
realisierung
Es wird EINE "Device-routing-entity" geben welche eben den Parser und router beinhaltet.
defmod MQTTroute MQTT2_DEVICE
attr MQTTroute readingList .*:.*:.* {muParseMQTT($NAME,$CID,$TOPIC,$EVENT)}
Alle Messages werden in der Funktion "muParseMQTT" bearbeitet.
KEIN anderes MQTT2_DEVICE hat ein readindList Attribut.

MQTT2_DEVICEs werden getaggt mit CID, Model und function/channel. In der Wahl der Tag.Namen bin ich noch frei :)

MQTT2Modul wird Daten der Devices aufbereiten für performanten Zugriff. D.h. eine Referenztabelle CID->Entityname wird erstellt und maintained. Bei der Gelegenheit auch die anderen Tags von oben.  MQTT hat also immer eine aktuelle und performante Referenz.
Hierzu wird sich MQTTroute an das global-notify hängen und alle updates durchführen. Das ist bereits eine standardübung - realisiere ich aber erst am Schluß. Und logisch - bei allen anderen entites wird notify unroled - unnötig, Performance.
Jede empfangene Nachricht wird also genau einmal geparst - wie folgt
1) prüfen der Adresse (aktuell immer noch CID). Abbruch, wenn keine passende Entity gefunden wird.
2) Zerlegen der Message mit json2namevalue. Da hier der Trenner "_" ist wird einem das Leben schwer gemacht - eben so dass die Beschreibung unvollständig ist. Aber der Anwender muss sich am Ende nicht mehr damit herumschlagen (ich vergesse das innerhalb von weingen Tagen!)
3) Anpassen der DP: Filtern und Übersetzen in Readings entsprechend dem Template. Hierzu wird es eine Tabelle(hash) geben, welche gemäß "model" die Anpassungen vornimmt.
4) die Values werden angepasst nach erstellten Regeln.
5) die DP/Readings werden gemäß "Kanal" oder "Funktion" gruppiert um sie zuweisen zu können, wenn der Tag passt
6) die Readings werden über ReadingBulk den Entites zugewiesen wie selektiert

User Interface
Templates erstelle ich als single-user in einem entsprechenden File - als hash. Für eine "öffentliche" implementierung kann man das auch "öffnen" und dem User hier eigenes erlauben. CUL_HM hat dies schon vor Jahren realisiert - erfolgreich, wenn auch nur selten notwendig.
Für alle existierenden Templates kann der User über die Tags einstellen, welche Funktionen er in der Entity sehen will. Damit lassen sich Kanäle einfach realisieren/abbilden und auch "sondergruppen" einblenden (und ausblenden!!!) wie eine IP configuration.

noch nicht betrachtet
Die setList werde ich mir später vornehmen.
Es wird weitere Kommandos brauchen - bspw ein clear-readings. Aber hierfür habe ich schon ein Standartmodul welches minimal-invasiv die Liste der set/get um m.E. notwendige erweitert ;)

Ist jetzt etwas hoplahop... hoffentlich halbwegs verständliche, vielleicht erntet es sogar die eine oder ander Zustimmung oder zumindest Interesse.
Ich bastle mal weiter wenn es einen hinreichenden Stand hat und interesse besteht stelle ich es natürlich vor.

Zitat von: martinp876 am 02 August 2026, 08:00:45dass ein MQTT_DEVICE kein genereller Client ist

...

Code Auswählen Erweitern

defmod MQTTroute MQTT2_DEVICE


Kannst Du mal bitte irgendwann Deine Nomenklatur geradeziehen?
Warum schreibst Du immer von MQTT_DEVICE wenn Du dann ein define mit MQTT2_DEVICE aufzeigst?

MQTT_DEVICE und MQTT2_DEVICE sind zwei völlig voneinander getrennte Module.
Diese Vermischung erschwert die Nachvollziehbarkeit Deiner Ergüsse erheblich.

Danke.

Und für Diskussionen zu MQTT/MQTT2 gibt es sogar ein eigenes Unterforum...

Zitat von: martinp876 am 02 August 2026, 08:00:45hoffentlich halbwegs verständliche, vielleicht erntet es sogar die eine oder ander Zustimmung oder zumindest Interesse.

Abgesehen von dem Benennungs-Ding, auf das betateilchen auch nochmal hingewiesen hat: halbwegs verständlich, und ja, durchaus interessant.

Anmerkungen:
- Wenn Performance DAS erste Leitkriterium ist, wäre der erste in diese Richtung wichtige Schritt, vom Server nur diejenigen Topics zu abonnieren, die einen für FHEM-Entities interessieren. Ergo: Externer Server, die subscriptions müssen dann von deiner Zwischenschicht verwaltet werden. Was das für dein "so wichtiges" CID-Ding bedeutet, liegt auf der Hand...

- Es gibt FHEM-Module, die das mit korrekten, automatisch generierten subscriptions bei einem externen Server heute schon machen. Bei Interesse würde ich einen Blick in Blick in MQTT_GENERIC_BRIDGE anempfehlen.

- Das eben genannte Modul hat auch eine Funktionalität, durch die der unter performance-Gesichtspunkten überflüssige erste Dispatch über dein MQTTroute-Device ersetzt; effektiver wäre ein eigenes MQTT3_BRIDGE-Modul.(MQTT_GENERIC_BRIDGE ist als package vercoded, du kannst einfach einen Klon machen und da erst mal nur deinen Code als ParseFn() anflanschen)

- Da meine genannten Beispiele für komplexere Zwischenschichten (zigbee2mqtt und AHOY-DTU) anscheinend nicht angekommen sind: Wir werden immer aneinander vorbei reden, wenn du sowas noch nie live erlebt hast. Als Prototypen für derartige Konstruktionen würde ich (zumindest empfangsseitig) einen ESP32 mit OpenMQTTGateway (BLE) empfehlen. Da geht es immer darum, dass man einen "Dienst" hat, der mehrere bzw. viele hinter dem Dienst liegende Hardwares auswerten (bzw. auch aktiv ansprechen) kann.
Ansonsten wäre zigbee2mqtt der Kandidat, Falls du neben den zu diesem Komplex zu findenden Infos im FHEM-Wiki weitere Details brauchst: Melden.

@martinp876

Ich kann mir gut vorstellen, dass die Verarbeitung von mqtt Nachrichten in gewissen Fällen optimiert werden könnte.
Z.B. durch den Einsatz einer Hash Table, welche Topics abbildet.
Ich gehe aber davon aus, dass es dadurch Verluste der Flexibilität gibt.


Was mich an deinen Ausführungen überrascht ist, dass Du nur ein einziges MQTT2_DEVIVE anlegst.
In was bildest Du denn die Readings und Schaltbefehle dann ab?

Ich kenne deine Code Anpassungen nicht, hast Du schon Werte, wie viel CPU Zyklen du je Nachricht einsparst?


Grüße Sidey

Wieso einfach, wenn es auch kompliziert geht?

Aber ist ja auch in Ordnung, bekanntlich führen mehrere Wege ans Ziel.

ZitatEs wird EINE "Device-routing-entity" geben welche eben den Parser und router beinhaltet.

Da in diesem Fall die MQTT2_DEVICE Funktionalitaet eher hinderlich ist, empfehle ich ein separates Modul zu bauen, und diesem per MQTT2_SERVER Attribut clientOrder den Vorrang zu geben.

Sorry - ich bin langsam - im Antworten und codieren.

MQTT_DEVICE vs MQTT2_DEVICE: sorry,  werde mich bemühen. Anmerkung: die unterschiede habe ich nie ergründet, werde ich auch nicht mehr. Als User sehe ich diese Vielfalt nicht als Vorteil sondern als verwirrend. Die klare, einzeilige Empfehlung: wann nehme ich was - fehlt mir.

Performance ist nicht DAS erste Thema. Usability ist prio 1. Performance ist immer ein Thema - insbesondere bei "Familien" mit vielen Entites

Wieso einfach, wenn es auch kompliziert geht? Sehe ich auch so. Nur eben anders. Das UI ist aus meiner Sicht kompliziert, die Codierung eher einfach. Ich will es ungekehrt - und zwar zwingend. Als Codeschreiber mache ich mir einmal richtig Gedanken, also User komme ich hoffentlich einfach zurecht

Da in diesem Fall die MQTT2_DEVICE Funktionalitaet eher hinderlich ist, empfehle ich ein separates Modul zu bauen, und diesem per MQTT2_SERVER Attribut clientOrder den Vorrang zu geben.
==>Ich denke (so ich es verstanden habe) ich stimme zu. Allerdings sehe ich eine m.E. einfachere Lösung - beschreibe ich weiter unten.

Zu den offensichtlich vielen Vorschlägen, wo was in Sachen MQTT umgesetzt ist, alles scheinbar nach einem anderen Konzept: Ich habe am Ende weder Zeit noch Nerven, mir jede Installation anzusehen, zu testen, zu bewerten, anzupassen. Ich werden schneller sein, meine Idee einfach umzusetzen - da bekomme ich was ich will - sogar generisch, usable, erweiterbar und schneller als it 1000 fehlversuchen und "fast-richtig".

Im nächsten Post mein Ansatz. Mich würden dann Kommentare interessieren zu
- Konzeptidee
- Umsetzung
- Anregungen

Mein Konzept läuft schon, auch wenn noch etliche Arbeiten zu erledigen sind. Zumindest für die Receive-Seite.

1) was kann mein Ansatz mehr als MQTT2_DEVICE? Nichts. Es werden MQTT messages in Readings umgesetzt - fertig.
2) Ziele
2a) Kompatibilität: ich werde mich an MQTT2_DEVICE anwanzen - d.h. mit eigenem zusatz-Code funktionalität erweitern/ergänzen/anpassen
2b) Usability: die halte ich aktuell für inakteptabel. Was ich als best-current-practice gesehen habe ist nicht das, mit dem ich also User umgehen kann/will/werde.
2c) flexibilität: Natürlich werden Erweiterungen (neue Module) möglich sein. Da ich von exterm begrenztem Interesse der Komumnity ausgehe werde ich das UI hierzu in Grenzen halten.
Gemäß dem Motto: "wer nach allen Seiten offen ist kann nicht ganz dicht sein" wird es Regeln geben an die sich zu halten ist oder die erzwungen werden.
3) Umsetzung
3a) repository vs library: die aktuellen "Templates" werden je entity kopiert und angepasst. Das geht für mich garnicht. Code im UI (attr ReadingList), unübersichtlich, fehleranfälling => nogo.
Mein Konzept: "attr model". Messages werden gemäß "model" geparst. Der Parser wird über "config-hashes" konfiguriert. Die Konfigs sind in einem .pm verankert. So ist es de-facto bei allen modulen, so sollte es hier sein.
Usability: setze attr model shellyPM2 - done.
Channel-funktion wird nach dem gleichen Konzept funktionieren
4) provisioning
4a) CID: Man sagte mir schon, es sein ein Holzweg - nur kann ich es aktuell nicht erkennen.
4aa) kann man die CID nutzen ist das ein Quantensprung in der Unsetzbarkeit. Tasmota und shelly machen das prima. Über pah's rasenmäher kann ich keine Aussage machen - ignoriere ich also
Mit CID kann ich - wie es bei allen anderen device auch üblich ist - die Attribute und Eingenschaften des Empfängers ermitteln und entsprechend parsen - perfekt.
4b) model: die Message wird gemäß den model-regeln in Readings umgesetzt
4c) channel - oder function: der Name des attributs ist noch offen, wird aber die Funktion der Entity festlegen, also bspw den Kanal. Die ermittelten Readings werden nur zu dieser Entity propagiert, wenn die "Function" dies einfordert.
4d) evalMQTT: eine evaluierungs-option. Meine Erfahrung ist, dass es extrem erregend und umständlich ist, die Messages des Device zu erfassen um sie dann überhaupt in Templates umsetzen zu können. Da die CID bislang "fehlte" war es auch nicht ganz einfach. Setzt man dieses Attribut werden die Messages incl. topic in Readings sichtbar und man kann an seinem Template arbeiten. So stelle ich mit usability vor. Anhand des Konzepts könnte man sich eine eval-entity für unbekannte/neue Devices anlegen und hier die - gelegentlich seltenen - messages loggen. Im UI, wie es sein sollte
5) UI Umsetzung:
5a) es wird EINE routing-entity definiert
  define MQTTroute MQTT2_DEVICE route
  attr MQTTroute readingList .*:.*:.* {muParseMQTT($NAME,$CID,$TOPIC,$EVENT)}
diese Entity bekommt ALLE messages.
5b) Client-entites (hoffentlich die korrekte Wortwahl)
  define <myMQTTdev> MQTT2_DEVICE <CID>
  attr <myMQTTdev> userattr model function evalMQTT:0,1
  attr <myMQTTdev> model shellyPM2
  attr <myMQTTdev> function switch_0
  -   readingList ist verboten!
5c) natürlich werde ich die Kommandos entsprechend generisch erweitern um bspw die Readings vomUI aus bereinigen zu können. Dafür habe ich schon utilitis um "minderbemittelte" Module zu pimpen ;)

6) Performance 
Inhaltlich denke ich geht es in Rudis Richtung, nur ein anderer Gedanke/Umsetzung.
Dank der Konstruktion von MQTT2_DEVICE kann sich die routing-entiy einfach einklinken - in schlicht alles. Damit ereiche ich
- jede message wir nur von einer Entity empfangen
- jede Message wird nur einmal zerlegt -nach model. Ich werden verhindern, dass einer CID unterschiedliche Model Attribute untergejubelt werden (wer nach allen Seite...)
- da es mehrere Entites mit gleicher CID geben kann (Kanäle) wird hier das Verteilen der Readings vorgenommen.
6a) prepare/cache
Das Processing hängt also von den Enities und deren Attributen ab - eine wilde Sucherei.... wird es natürlich nicht geben. Wie in jedem ordentlichen System bereitet man sich vor, wenn es an der Zeit ist. MQTTroute wird also hashes und caches haben mit Doziers über alle relevanten MQTT2_DEVICEs. Über ntf "global" wird es auf Stand gehalten - logisch. Dafur hat Rudi das sicher auch eingebaut.

Wie ist der Stand bei mir: läuft grundsätzlich, noch nicht vorzeigbar.
MQTTroute ist am Start, devices sind eingerichtet, readings werden ordnungsgemäß propagiert.
=>die 10% inspiration sind umgesetzt, von den 90% transpiration bin ich erst bei 20%

Zitat von: martinp876 am 15 August 2026, 08:08:59Anmerkung: die unterschiede habe ich nie ergründet,

• Die Module MQTT_.* sind die erste Generation und benötigen noch zusätzliche externe perl Module.
• Die Module MQTT2_.* wurden von Rudi viel später gebaut, um das MQTT Protokoll ohne die externen Abhängigkeiten in FHEM verwenden zu können.

Zitat von: martinp876 am 15 August 2026, 08:08:59Als User sehe ich diese Vielfalt nicht als Vorteil sondern als verwirrend. Die klare, einzeilige Empfehlung: wann nehme ich was - fehlt mir.

Es geht nicht um "Vielfalt" im Sinne von "wähle aus, was Du verwenden möchtest", sondern um technische Weiterentwicklung.

Du kannst prinzipiell beide Serien für alles verwenden. MQTT2 hat den Vorteil, dass Anpassungen und Bugfixing zeitnah umgesetzt werden.

Eine Empfehlung "wann nehme ich was" kann man nicht am Einsatzszenario festmachen. Gefühlt würde ich dazu raten, MQTT2 zu verwenden, einfach weil es die aktuellere Umsetzung in FHEM ist.

Anmerkung: Das Modul MQTT_GENERIC_BRIDGE lassen wir in dieser Betrachtung mal außen vor. Dessen Name passt nicht ganz in das beschriebene Schema. Dieses Modul ist als Zusatz in der Lage, sowohl mit MQTT als auch MQTT2 zu kommunizieren. Es stammt aber historisch auch noch aus der "MQTT"-Entstehungszeit.

Zitat von: martinp876 am 15 August 2026, 08:09:424a) CID: Man sagte mir schon, es sein ein Holzweg - nur kann ich es aktuell nicht erkennen.

Stichprobe aus meinem aktuellen System zum Thema CID (praktisch alle mit MQTT2_SERVER als IO-Modul):
Count: 127 devices for devspec TYPE=MQTT2_DEVICE
Count: 118 devices for devspec TYPE=MQTT2_DEVICE:FILTER=DEF~.+
Count: 88 devices for devspec TYPE=MQTT2_DEVICE:FILTER=DEF~zigbee.+
Count: 12 devices for devspec TYPE=MQTT2_DEVICE:FILTER=DEF~inverter.+Von den 127 vorhandenen entities haben also 9 gar keine CID. Es sind channel-Devices von echter Hardware.
Alleine 88 entfallen auf den ZigBee-Dienst (zigbee2mqtt). Diese CID sind also (vielleicht bis auf eine) "unechte" CID, die abgeleitet sind aus der Topic-Struktur, und von daher auch keine Mehr-Info zu TOPIC enthalten können.
Entsprechendes gilt für die "inverter"-CID, nur dass das nicht über einen docker-container kommt, sondern über einen ESP32 (mit nRF-Funkmodul und entsprechender firmware).

Sagt vielleicht mehr als Code-Analyse, warum das Berücksichtigen der CID keinen Mehrwert bietet; dieselben Infos sind (entsprechende Vorgaben an den Konfigurator berücksichtigend) eben auch in den Topics drin, und den Topic wertet man ja so oder so immer aus...

PS: Wenn man sich von "CID" aus der DEF etwas frei macht, wird auch sowas möglich:
define m2d_test MQTT2_DEVICE model=shellyPM2:function=switch_0:evalMQTT=1
#   CID        model=shellyPM2:function=switch_0:evalMQTT=1
#   DEF        model=shellyPM2:function=switch_0:evalMQTT=1
Spart ggf. eine Ladung umständlich einzuführender Attribute, die man einmal setzt...

Zitat von: betateilchen am 15 August 2026, 10:10:12Anmerkung: Das Modul MQTT_GENERIC_BRIDGE lassen wir in dieser Betrachtung mal außen vor. Dessen Name passt nicht ganz in das beschriebene Schema. Dieses Modul ist als Zusatz in der Lage, sowohl mit MQTT als auch MQTT2 zu kommunizieren. Es stammt aber historisch auch noch aus der "MQTT"-Entstehungszeit.

Code-technisch wäre es eigentlich für Martin interessant, aber er will ja partout diesen indirekten Weg über das Verbiegen einer MQTT2_DEVICE-Instanz gehen...
(Es ist in 0,nix zu klonen, um mit dem Klon dann Rudi's Vorschlag umzusetzen.)

4a) CID: Man sagte mir schon, es sein ein Holzweg - nur kann ich es aktuell nicht erkennen.
Um es anders zu formulieren:

Ein Umstieg von MQTT2_SERVER zu MQTT2_CLIENT ist nicht moeglich, wenn CID eine zentrale Rolle spielt, weil man als Client diese Infos nicht kriegt.
Wenn MQTT2_SERVER ein bestimmtes v5 Feature, worauf das externe Geraet unbedingt besteht, nicht unterstuetzt, dann kann man das Geraet nicht anbinden.
Mit MQTT2_CLIENT ist das kein Problem, weil externe MQTT-Server wie mosquitto beide Protokolle (MQTT v3.11 und v5) gleichzeitig unterstuetzen.

Es gibt zunehmend mehr Protokollwandler nach MQTT (zigbee2mqtt, ble2mqtt, matter2mqtt, usw), die als Bridge fungieren, und mehrere Geraete via MQTT anbinden.
In diesem Fall kann man mit der CID der Bridge wenig anfangen.

CID: bei Shelly sowie Tsamota kann ich die CID einstellen. Das ist mein Target.

Zitatdefine m2d_test MQTT2_DEVICE model=shellyPM2:function=switch_0:evalMQTT=1

geht wohl garnicht, geh tam Ziel vorbei. Die (zumindest meine) Idee ist doch eindeutig, das ein Entity genau die Messages IHRES device entpängt.
Model ist die HW, Function idee eingestelle Funktion. Damit filtere ich eben nicht die Messages MEINER entity heraus.
Vielmehr ergibt Model und Funcktion zusammen "mein" Template nachdem die Messages inhaltlich zerlegt und gefiltert werden sollen - das was ich aktuell als "model" Attribut vergebe. Alle meime shellyPM2/switch bekommen das Template.
Shelly als beispiel nutzt explitzit eine "einstellbare" CID welche mit shelly_<MAC> vorbelegt ist und damit weltweit eindeutig.

Zurück auf Start:
ich bin faul - eigentlich will ich ein einfaches Interface - OAMP (operation, administration, maintenance, provisioing). Gefühlt hat mich das einreichten des ersten und insbesonderen des 2. Devices deutlich zu viel Zeit gekostet, ist (ich gehe im Folgenden immer von mir aus) zu ... umständlich auf fast allen Ebenen.
Von mir bekommt es ein mangelhaft. Ich will niemanden zu nahe treten - ich sehe durchaus den schanken Ansatz des Moduls - ich will einen Schlangen Ansatz für mich als Anwender (OAPM&P). Dafür codiere ich gerne deutlich mehr.
Die einleitende Frage war: mache ich etwas falsch oder ist das schon die best-current-practice. Und das ist nun einmal so.

Zu Rudi's Ausführungen(kam vorher schon einmal): in FHEM gibt es offensichtlich und kaum verwunderlich einige MQTT basierende Module - ist ja schliesslich ein offener Standard. Cool fände ich nun ein generischer Sende/Empfangs "IO" welches die Messages einer Device-HW an die FHEM-entity (welche ein Abbild darstellt) routed und dort - ggf in einem modul erlegt wird.
Das kann ich aktuell nicht erkennen.
Ich kenne Beta-Users Module nicht - aber die CID ist m.E. (ich habe mich nicht eingearbeitet) eben eine eindeutige Kennung.
Shelly unterstützt dies in jeden Fall - ich sehe keine Einschrängung.
Bei Shelly kann ich auch direkte Device2Device kommandos schicken, so die Doku. Habe ich noch nicht genauer angesehen, aber der receiver muss in jeden Fall den Absender ein-eindeutig erkennen. Model und Typ sind in keinem Fall ausreichend! Wenn es nicht die CID ist, was ist es dann?

Und klar, da man die CID einstellen kann (bei genannten Devices) kann man Chaos anrichten. a) selbst schuld und b) Aufgabe der Maintenance, hier zu sniffen.


Da ich meine Shelly nun endlich sauber an den Start (oder in Stufe real-usable) setzen muss bleibt mir mangles ausreichender Alternative nur, es selbst fertig zu machen.

Mein Konzept steht:
#Dev 1 device information only
define m2d1_1 MQTT2_DEVICE <CID>
attr m2d1_1 model shellySwitch
attr m2d1_1 channel device

#Dev 1 channel0 information only
define m2d1_0 MQTT2_DEVICE <CID>
attr m2d1_0 model shellySwitch
attr m2d1_0 channel switch_0

#Dev 1 channel1 information only
define m2d1_1 MQTT2_DEVICE <CID>
attr m2d1_1 model shellySwitch
attr m2d1_1 channel switch_1

#Dev 2 all information
define m2d2 MQTT2_DEVICE <CID>
attr m2d2 model shellySwitch

#Dev 2 evaluate MQTT messages from this CID
define m2d2 MQTT2_DEVICE <CID>
attr m2d2 evalMQTT 1

Technisch wird es ein Modul myMQTT welches sich an MQTT2_DEVICE koppelt.
Ich denke dass es in Sachen Usability deutlich vorne liegt  - das ist eh klar, ich mache es ja auch , wie ich denke.
Vorläufig werde ich es ohne meine System-addons bauen, damit einfach kopierbar. Später wird sich das sowieso   ändern müssen, da grundsätzlich nützliche Funktionen für mich IMMER fehlen
Weiter werde ich die Template-Erstellung nicht mit einem "schönen" UI ausstatten - das brauch ich erst einmal nicht und wenn es keine anderen Interessenten gibt ist es vergebener Aufwand.

Die übrigen Diskussion war für mich sehr interessant und erweiternd. Aber es war nichts dabei, was mein Vorgehen ändert.

Schlusssatz: wenn es Interessenten an meinem Ansatz gibt - unverbindlich, klar -kann ich sie auf dem Laufenden halten.
 

Vielleicht nochmal ein Versuch der Klarstellung, ausgehend von diesem Codeschnippsel:

Zitat von: martinp876 am 15 August 2026, 08:09:42attr MQTTroute readingList .*:.*:.* {muParseMQTT($NAME,$CID,$TOPIC,$EVENT)}

Nur darauf bezog sich mein Hinweis, dass "$CID" keinen Mehrwert bietet und als zu übergebender Parameter entfallen kann bzw. sollte.

Zitat von: martinp876 am 23 August 2026, 17:20:17Die (zumindest meine) Idee ist doch eindeutig, das ein Entity genau die Messages IHRES device entpängt.

Sorry, wenn das für Verwirrung gesorgt hat. Dass man eine Art "identifier" benötigt, um ein einzelnes Stück Hardware (oder sogar einen bestimmten "Channel" auf der Hardware) eindeutig addressieren (und auswerten) zu können, steht außer Frage.

Nur steckt die meistens (Achtung: nicht immer!) im Topic, und genau da hat ja auch die bei Shelly, Tasmota und (fast) überall sonst einstellbare Option der ClientID _auch_ einen Niederschlag.

Für mich ist der korrekte Ort für die Hinterlegung dieses tragfähigen "identitifiers" nicht (zwingend) die DEF, sondern (eher) das Attribut "devicetopic" (wie auch immer man dein Parser das dann auswertet).

Jedenfalls: die heutigen MQTT2-Module nutzen die CID-Info, die im define steckt, ausschließlich dazu, dass die autocreate-Funktion einen Anhaltspunkt hat, welcher Instanz "unbekannte" Nachrichten zuzuordnen sind. Wenn du das anders erledigst, kann die DEF auch dafür genutzt werden, alle Info unterzubringen, die man sonst auch in eine Vielzahl von (neu einzuführenden) Attributen stecken kann. 
Mein define-Vorschlag war (nur) dazu gedacht, einen Weg aufzuzeigen, wie man es auch machen kann, wenn man sich von diesem autocreate-Konzept verabschiedet. Es spricht andererseits auch nichts dagegen, die "identifier"-Info dann auch noch mit in die DEF zu schreiben, wenn man sie gerne dort haben will.

nun, bei Identifier sind wir uns eigentlich einig. Ja, Shelly sowie Tasmota haben neben der CID auch eine "Prefix" welchen sie nutzen. Dieser ist per default identisch zur CID - und ja, das habe ich gesehen, die genaue Analyse aber aufgeschoben.
Mittlerweile klar, beim Senden der Kommandos reagiert das Device auf den "Prefix".
Wie immer braucht das Kind einen Namen, sonst kann man damit nicht umgehen. "Prefix" scheint üblich zu sein, auch wenn ich lieber etwas mit "ID" gesehen hätte - egal.

Diesen Prefix habe ich natürlich auch gesehen - die Beurteilung aber aufgeschoben, da es am Konzept genau nichts ändert.
Da man das bei den mir vorliegenden Deivces einstellen kann, ist es möglich, lustige Sachen einzurichten, wie Stellvertreter-devices. All das ignoriere ich sehenden Auges - wer so etwas macht muss genau wissen was er tut - mit egal.
Die ID - jetzt eher "Prefix" gehört für mich in die Definition. Es ist bei mehreren Modulen so üblich, dass der UID hier steht - wie IP Adressen, Homematic-ID,... also die Adressen.

Zusammenfassend sehe ich in meiner Welt - und als Regel:
- der Prefix ist einer UID gleichzusetzen. Der Operator bekommt den Hinweis und die Verantwortung.
- mehrere Entities dürfen (in meiner installation) die gleiche UID haben. Die UID ist unique für die HW, nicht die Entity. Damit kann man unterschiedliche Funktionen eines Device in verscheidenen Entites abbilden (Kanäle, debug-entities, device,...)
- wie bei mir üblich wird (wenn ich erst einmal so weit bin) jedes HW-Device EINE Entity haben, über welche ich die Primary-Maintenance mache - also alive-check usw. Diese Entity kann natürlich parallel auch Kanäle beherbergen.

Zusammenfassend: an meiner Vorstellung der Architektur ändert sich durch die Verschiebung der CID auf Prefix nix (aber danke für den Hinweis!). Ich werde auch nicht alles zulassen und einbauen, was möglich ist oder bei irgendwelchen Rasenmähern vorkommt, sondern eine Struktur fordern (in meiner Installation).
Meine eigenen Dokumentation wird dies dann abbilden(damit ich auch morgen noch ein neues Device aufsetzen kann, wenn ich wieder alles vergessen habe :) )

Unter "prefix" hätte ich jetzt eher einen gemeinsamen Topic-Abschnitt für mehrere Hardwares einer "Familie" (z.B. shellies) verstanden, unter "identifier" tatsächlich was Hardware-bezogenes.

Ist aber erst mal nicht wichtig, wenn man davon absieht, dass du damit vermutlich wieder eine "eigene Terminologie" einführst, die nicht allgemein verständlich ist.

die CID sollte man nicht nehmen, weil das dann z.b. mit dem MQTT2_CLIENT nicht funktionieren dürfte. Ein anderes Problem sind bridges. Viele schicken ihre eigene CID, statt der von den verwalteten Geräten und manche auch garnichts. die CID ist aus meiner Sicht nicht entscheidend und wird von zuvielen Devices nicht einmal mitgesendet.

UID/CID/Prefix:
Das wir einen identifier benötigen steht für mich zumindest ausser Frage. Tasmota sowie Shelly trage einen solchen in CID sowie Prefix ein. Insbesondere der Fakt, dass ich kommandos an shelly nur mit diesem Prefix zustellen kann hat mich final bewogen, diesen als UID zu nutzen und die CID zu verwerfen/ersetzen.
Shelly und Tasmota nutzen hier die MAC - das sollte mehr als eindeutig sein. Stellt der Anwender nichts um steht Wert an beiden Stellen identisch.
==>
define <entity> MQTT[b]2[/b]_DEVICE <PREFIX>
Zurück zur anfänglichen Frage nach "Best Current Practice".  Danke für alle erläuterungen - so ähnlich sah es bei mir auch aus. Und da ich dies als mangelhaft betrachte fragte ich nach, bevor ich es umschreibe, ob es nicht doch etwas smartes gibt.
Da sich nichts gefunden hat läuft mein "add-on" langsam aber stetig.

Was sind die Anforderungen?
1) templates müssen als Library erstellt werden. Repository ist nicht tragbar
2) ein baugleiches Device muss mit minimalem Aufwand funktionsgleich erstellt werden können
3) zu einem HW-Device mussen mehrere Entites funktionsbezogen erstellt werden können (2-fasch Schaltaktor,...
4) das Frontend muss einfach und geordnet sein
5) eine Eval Option ist bei MQTT unumgänglich - muss beinhaltet sein
und dann noch einiges mehr: DeadOrAlive, Verlinkungen, ...

Begriffe und Wording
Ein model ist zu definien und bildet eine HW-Funktion ab. ein shelly2PM bspw kann als 2-fach Schaltaktor, als Rollosteuerung oder als Jalousie genutzt werden. Man würde hier 2 oder 3 unterschiedliche templates anlegen.
Die function bezieht sich auf die Funktionsgruppen eines Models welche man darstellen will. So sind bspw bei einem Shelly2PM als schalter die Funktionen switch0/switch1/input0/input1/wifi/...vorhanden und müssen bedient werden - je nach Entity und wunsch.

Einrichten auf Basis einer bestehenden Templates
Hierzu muss man die Entity mit Prefix definieren, dann das Attribut "model" festlegen und ggf das Attribut "function". Mehr darf nicht notwendig sein.

Einrichten mit neuem Templates
Das ist spannnd - oder nervig - egal. Es ist sicher notwendig die Messages zu kennen, welche das Device so sendet. dafür setzt man das Attribut "evalMQTT" und die rohen messages werden in Readings gepackt.

Anhand einer Vorgabe erstellt man dann ein Template für das Model mit
- Topics to be collected
-        readings in Topic to be ignored
- Grouping of DPs for later function selection
- translation of datapoints to readings
- translation of values to match FHEM standard

Processing
natürlich werden alle Daten für das Verarbeiten aufbereitet. Änderungen in der Konfiguration (Attr) werden umgehend berüchsichtigt

So weit steht es jetzt schon einmal. Für die Eingabe und die Prüfung der Templates habe ich noch kein frontend. Da es wohl keine Interessenten extern gibt, braucht es das auch nicht.

Implementierung ist ein addon modul zum bestehenden, also minimalincasiv

Kannst du mich einmal kurz aufklären, was du da eigentlich machst? Geht es dir nur darum MQTT Devices einfacher einzurichten oder was ist der Plan?

Zitat von: Guybrush am 06 September 2026, 12:51:43Kannst du mich einmal kurz aufklären, was du da eigentlich machst? Geht es dir nur darum MQTT Devices einfacher einzurichten oder was ist der Plan?

Nach meinem Verständnis:

Die aktuelle Implementierung der Analyse eingehender Nachrichten wird als unzureichend (v.a.: nicht performant genug) empfunden. Dabei geht es weniger um die Ersteinrichtung, sondern um den laufenden Betrieb.

Daher gehen ALLE eingehenden Nachrichten (einmalig!) durch einen Parser, der dann ermittelt, welche Instanz von MQTT2_DEVICE welche Infos (als Reading-Wert) erhält. Dabei kann eine Message - je nach Konfiguration mit den von Martin neu eingeführten Attributen - eben keiner, einer oder mehreren Instanzen von MQTT2_DEVICE "zugeordnet" werden.

Dementsprechend kann (bis auf das "Dispatch"-Device) in allen Instanzen von MQTT2_DEVICE auf das Setzen des Attributs "readingList" verzichtet werden.

Grundsätzlich finde ich den Ansatz interessant. Allerdings würde ich manches im Detail anders lösen: die vielen neuen Attribute sind imo unnötig, und der Code wäre besser in einem "MQTT2_DISPATCH"-Modul aufgehoben.
Ob das trägt (oder ggf. mit Hilfe deines "HomeAssistant-autocreate"-Moduls vereinfacht werden) könnte, wären die aus meiner Sicht spannenden Fragen.

Ist aber nur meine persönliche, vermutlich zu vereinfachende Zusammenfassung.

Bei allem Respekt vor der Arbeit, die hier hineingesteckt wird:

Ich sehe darin eine erhebliche Verkomplizierung des eigentlich einfachen MQTT-Prinzips.
Natürlich wird niemand gezwungen, das dann zu benutzen.

Ich rege trotzdem an, per Umfrage unter den FHEM-MQTT-Nutzern herauszufinden, wer sich eigentlich dafür interessiert.

LG

pah

Zitat von: Beta-User am 08 September 2026, 16:50:21Dementsprechend kann (bis auf das "Dispatch"-Device) in allen Instanzen von MQTT2_DEVICE auf das Setzen des Attributs "readingList" verzichtet werden.

Das will ich gar nicht. Bei mir ist es sogar so, dass gleiche Gerätetypen in MQTT2_DEVICEs unterschiedliche readingList verwenden.

Grundsätzlich habe ich in vielen Jahren FHEM die Erfahrung gemacht, dass ALLES, was mir irgendwie "automatisch" das Selbst-Nachdenken abnehmen möchte, am Ende vorne und hinten nicht funktioniert (im Sinne von: liefert mir nicht die erwarteten Ergebnisse) und ich schneller ans Ziel komme, wenn ich mir devices selbst und von Hand einrichte.

Das fängt bei autocreate an und geht weiter über die Verwendung von eventTypes, attrTemplates und was es da alles noch im FHEM-Universum gibt.

Einzige positive Ausnahme: Das Erzeugen von SVG Definitionen aus FileLog oder DbLog liefert mir brauchbare Ergebnisse, die ich dann gerne als Basis für meine Anpassungen verwende.

Insofern unterstütze ich den Einwand von pah zu 100%. Aber vermutlich wird eine Umfrage selbst nicht aussagefähig, da nur ein begrenzter Teilnehmerkreis sich dafür interessieren und ggf. teilnehmen wird.
Viele Anwender haben jetzt schon Probleme damit, das eigentlich simple MQTT in FHEM einzurichten. Das wird mit dem hier angefangenen "Projekt" nicht besser oder gar leichter verständlich werden.

genau das ist das problem. Interessanter Ansatz, aber schon schwer zu verstehen. Ich hab das auch so beobachtet, dass es zu oft an den reinen basics scheitert. die readingList bekommt man dank autocreate noch hin, auch wenn dann die readings zugemüllt werden. die setLists machen dann aber bei zuvielen Probleme. Einer der Gründe für MQTT2_DISCOVERY  ;)

was ich mache und warum:
mir geht es um ein einfaches und übersichtliches Interface für den Anwender (nach einer Implementierung werde ich zum Anwender und will alles vergessen). Komplizierter wird es nicht - für den Anwender. Ob es für den Programmierer "etwas" komplizierter wird ist mir wurscht. Programmierer bin ich einmal, Anwender ständig. Ich komme aus der Systemtechnik - da geht "Repository" meist schief - ordentlich (auch wenn anstrengender) ist Library.

Und für alle, die Interessiert sind - es handelt sich im einen alernativen Ansatz. Den ziehe ich gerade durch - was ich schon bei ein paar Modulen tat. Ich ändere nichts am bestehenden Repository, alles nur bei mir. Also keine Angst - und evtl die eine oder andere Idee mitnehmen - oder auch ablehnen. Zuhören wäre schön.

Wie ich schon sagte, es gibt für mich no-gos - einige sind einfach zu umgehen, wenn ich schon dabei bin mache ich es natürlich komplett.
Zu "Kompliziert" habe ich zu sagen: Ich sehe es als absolute Pflicht, wenn man Attribute anderer Entites auswertet, sich über entsprechende Änderungen am Laufenden zu halten. Also "Notify global" auswerten. Weiter ist ein Suchen "über alles" IMMER möglich - aber uncool. Rudi hat daher seinen notify-hash eingebaut - absolut sinnvoll.
So als highlight von mir: DBlog war masslos zu komplex, aufwändig, unübersichtlich und unbedienbar (meine Ansicht). Ich habe ein Modul vorgebaut, werte die notwendigen Attribute beim Setzen aus und kann performat meine Standart-auswertungen ausführen ohne SQL zu tippen. Ausgabe des letzen Zeitabschnitt oder der letzten x Einträge. Sogar die Grafik mit Anfangs und Endwert der Interfvalle funktioniert nun reibungslos und korrekt. Das war vorher eben nicht auf "userniveau".

Da will ich auch hin - und es sieht schon gut aus. Wenn kompliziert bedeutet, dass man bei der Erstellung etwas hirnen muss dann nehme ich das gerne in kauf.

Noch einmal die highlights welche ich für mich sehe:
Model:
wenn ich ein model beschreiben will ich es einfach wieder nutzen können. Definitiv als Library, nicht als Repository.
Ich befasse mich also einmal mit einen Device - z.B. "Shelly2PM als Cover" und überlege/evaluiere was ich steuern, abfragen und sehen will. Dann erstelle ich die Filter und sortierungen, ähnlich wie es auch jetzt geschieht. Diese werden als template abgelegt - auch ähnlich dem aktuelle Ansatz.
Der Abstract ist also gleich, die Implementierung macht den Unterschied.
- um eine Entity nun funktional zu "definieren" weise ich dies mit einem Attribut "model = cover" zu. Einfacher geht es nicht mehr. Optional kann ich nun die funktion des "cover" auswählen, welche dargestellt werden soll. Beim Cover mit nur einem Aktor ist das wenig notwendig. Allerdings hat auch dieser 2 Eingänge "sensoren" welche ich darstellen möchte oder nicht, getrennt oder nicht.
- Die Funktion wird also über ein 2. Attribut zugewiesen.

Nachdem ich nun das Model definiert habe (oder jemand anders hat hierzu ein Template erstellt) kann ich "in die Produktion" gehen und meine 20 Aktoren Cover schnell und übersichtlich einrichten. Habe ich einen Bug oder eine Erweiterung ändere ich die Library.
So funktionieren systeme.
Aktuell wird eine Kopie des Template erstellt, welche sowieso unvollständig ist und nachgearbeitet werden muss um die Readings an fhem defaults auzupassen. Schon klar, dass die basis-Readings meines Shelly dem der Homematic entsprechen werden - ebenso wie die basis-Kommandos und Aufrufe.
Die ausufernden Listen in den Attributen sind ungenügend, müssen über weiter Subroutinen vervollständigt werden, versauen die Webdarstellung und sind alles andere als übersichtlich. Wie ich langfristig meine 20+ Rollos und noch mehr Lichtschalter auf sabere Konfiguration prüfen will ist mir schleierhaft.


Nachteil ist die Definition der Templates im Code - schon klar. Für mich taugt es - allerdings könnte man hierzu auch einen template-generator erstellen - habe ich bei Homematic ja auch schon gemacht. Kein grundsätzliches Problem also.

Selbstredend gibt es bei mir auch immer "info" kommandos. So wird man über ein "get modelInfo" die eigenschaften und einstellungen des Templates einsehen können.

Nervig war bei MQTT auch die Evaluierung des Device und des Protokolls. Eigentlich wollte ich mich damit garnicht befassen, aber es war alles unvollständig und es blieb mir ncihts anders übrig. Damti ich es beim nächsten mal leichter habe, habe ich schon eine eval-attribut vorgehalten. Hier kann ich die rohnachrichten aufzeichnen - aber nur die meines Device, vollständig und "häßlich". Damit kann ich mein model erstellen oder anpassen.

Eigentlich ist mir vollkommen unklar, was an einer struturierten Lösung mit einfachem Frontend "kompliziert" sein soll - es ist doch straight forward.
Btw.: kompiziert ist json2reading - da gibt es keine vollständige Beschreibung, trenner sind leider "_" was mit Datenpunkten kollodiert und hinreichend ist die Ausgabe für mich sowieso nicht.

Entscheidend wird für mich die Bedienbarkeit sein, nicht der Kodieraufwand. Kriterium ist, dass  ich es aus dem Sofa an Tablet bedeinen kann, noch nach 2 Monaten, wenn 70% vergessen sein. Kein SQL wissen, kein MQTT wissen notwendig. Ich muss das gefühl haben das Interface einfach erklären zu können. So muss das - bei mir.

Aktuell werden die Kommandos in meinen kommand-parser eingefügt. Auch so ein Ding welches mir viel Spass macht PAH aber sicher zu komplex ist.
Anforderung war, dass man die Kommandsyntax "wie üblich" definiert: anzahl Argumente, reihenfolge, namen, Wertebereiche, kennzeichnung ob optional, wenn optional dann welcher default. Und das zu 100%.
Das läuft bei mir seit jahren problemlos.
Jedes Kommando wird in genau einer Zeile umfänglich und nach üblicher nomenklatur spezifiert. Als Anwender sehe ich nun endlich, wenn ein Kommando optional ist, was als default genutzt wird (hat mich schon oft aufgeregt,...). Das wird dann auch gleich bei der Eingabe genutzt, diese zuprüfen. Das schöne: in der Bearbeitung kann ich mich darauf verlassen, dass die Argumente zulässig sind. Als Anwender bekomme ich fehlerlemdungen exakt nach dem gleichen Verfahren. So muss das. Noch ein paar weitere Feature welche es erträglicher machen, damit zu arbeiten.
Nichts für Automone, etwas für Systematiker. Bin mir nicht sicher, wo ich mich hier befinde - beides hat vorteile, ich tendiere immer zur Systematic bei SW.

hoffentlich habe ich jetzt nicht alle abgeschreckt

Ein paar Anmerkungen und Hinweise für manche hier Mitlesende.
 
Es gibt ein paar Threads von dir, die man zum besseren Verständnis des hier geschriebenen imo kennen sollte, bitte verbessern oder ergänzen, falls das ein Missverständnis meinerseits wäre:
- FHEM implement strategy (https://forum.fhem.de/index.php?topic=140062.0)
- command parser als library function (https://forum.fhem.de/index.php?topic=125067.0)

Die damalige Entscheindung, Änderungen an den attrTemplate nicht automatisiert in die Devices zu übernehmen, die damit (vor-) konfiguriert worden sind, mag man kritisieren, war aber bewußt getroffen. Wer es anders haben will, kann das z.B. auch über "archetype" erreichen, das sowohl beim Systemstart wie auch bei Änderungen im laufenden Betrieb den jeweils letzten Stand der attrTemplate "drüberklatschen" könnte.

Die Lösung in CUL_HM mit der notifyFn für Attributänderungen erschlägt das Problem, aber wenn man sowieso ein "Konfigurations-Zwischen-Device" benötigt, kann man dazu auch ein eigenes Modul "schreiben", das den notify-Teil gleich mit erledigt, ohne dafür an bestehenden Modulen irgendwelche Zusatzbasteleien vorzunehmen.

Auch vor dem Hintergrund z.B. dieses Threads shelly duo bulb gen3 über mqtt schalten (https://forum.fhem.de/index.php?topic=145402.0) hielte ich es für hilfreich, wenn ihr beide euch ggf. zusammentut, um eine (je nach Einstellung automatisierte) direkte semantische Überleitung in gängige FHEM-Standards zu erreichen. Das wäre sicher für viele User hilfreich, und wer es anders mag, kann ja weiter "händisch" (oder per attrTemplate) konfigurieren.

ok - es scheinen min über 90% mit dem Absatz des MQTT2_DEVICE hoch zufrieden zu sein. Ist vollkommen ok, auch wenn ich beim besten Willen diesem Weg nicht folgen kann. So etwas könnte ein Grund sein, warum alle meine Bekannten sich gegen FHEM entschieden haben - man muss zu viel selbst machen und die Variantionen sind üpig. Zu viel Handarbeit, zu wenig Übersicht. Kommt nicht von mir, habe ich auch in Vergleichen so gelesen. Ich kann es bestätigen.

Ich stelle noch einmal dar, wie sich diese Modul "abstract" für mich präsentiert und was "best current practice" ist:
1) man richtet eine MQTT2_DEVICE entity ein - dann wählt man in der Drop-down Liste ein möglicherweise passendes Device aus. Nun werden automatisch (?) (ok, nach Kommando) Attribute gefüllt.
2) die Attribute sind hilfreich, das Device zu konfigurieren - müssen aber bearbeitet werden.
2a) da der Code in den Attribute steht sind diese für mich I) unangemessen lang ,II) nur schwer zu formatieren ,III) schwer zu lesen und zu editieren
2b) um den Code an die Entity anzupassen (Filter für receive sowie Setlist) muss man manuell editieren
2c) durch die Länge allein wird die Web-Darstellung - zumindest bei mir - komplett unleserlich - das allein ist ein no-go für mich
3)wenn ich nun die Attribute zurechtgestutzt habe und meine nächsten Schalter, Rollos,... identisch haben will muss ich - nun, was eigentlich? Die Attribute kopieren UND editieren - das ist aus meiner Sicht maximal unpraktipabel
4) nun will ich eine Änderung/Verbesserunge am Schalter-Template vornehmen - nichts einfacher als das  - einfach alle Entites kurz editieren, schon fertig (?!)
5) Konsistenzcheck: ich will prüfen, welche Entites nun alle auf dem gleichen Stand sind - einfach alles schnell mal durchlesen, raus kopieren, in excel vergleichen - anderer Vorschlag?
6) ich sehe keine wirkliche Unterstützung - schon gar nicht für Anfänger bei MQTT - die MQTT Messages zu erfassen, auszuwerten um dann (s)ein Template zu gestalten
7) Processing (ist nun für den User transparent, leider habe ich es gesehen). Alle einkommenden Messages werden gegen ALLE regexp aller MQTT2_DEVICES geprüft. Das potenziert sich.

Die Vorteile dieser Implementierung sollten klar sein:
schnelle Änderung, Template sichtbar (wenn auch schwer zu lesen), gut für seltene Entites wie Rasenmäher (kein Duplizieren notwendig). Viel mehr kann ich nicht erkennen.

Zu meinem Ansatz:
- hier werden keine Attribute automatisch gesetzt. FHEM bietet leider keine "system-Attribute", welche das Device "sichtbar" und non-volatil definieren. Sonst hätte man es in Internals machen können, geht leider nicht. Und die versteckten Attribute sind aus meiner Sicht ... unangemessen, weil "normal" nicht sichtbar (natürlich habe ich einen View systemweit in meiner Implementierung)
- Templates werden nicht in die Attributen geschmiert sondern im Code verwaltet - so wie es de facto bei allen anderen Systemfamilien auch ist, sogar noch weiter innen im Code und nikcht änderbar
- Änderungen an Templates sind durch die Referenzierung einfach über das ganze System auszurollen (einfacher geht es wirklich nicht)
- Mit dem Eval-Mode kann man die Messages einzelner Devices aufzeichnen und dann sein template gestalten. Ein Kommando zum aufräumen der Readings ist selbstredend einzubauen, um wieder Licht zu sehen - systemweit!.
- Empfangene Messages werden nur gegen die entsprechenden Entites geprüft und ausgewertet
- das Erstellen einer funktional identischen Entity sollte ein Kinderspiel sein - Definition und max 2 Attribute, fertig.
- Vielfalt der Darstellungsmöglichkeiten ist gegeben (model + function attribut - welche natürlich nicht automatisch gesetzt werden). Kanal-getrennt, kombiniert,...

Um ein effizientes Processing zu erreichen werden hash-tabellen genutzt. Das macht MQTT2_DEVICE bereits. Durch den zentraleren Ansatz allerdings - und weil ich es für deutlich effizienter halte  - werte ich relevante Attributsänderungen aller MQTT2 Devices aus und halte die Tabellen auf Stand - incl Device-rename/delete/incarnate.

Sollte der Ansatz interessenten finden würde eine dynamischere Erstellung von Templates keine Hürde sein. Aktuell allerdings ist es brotlose Kunst.

Die Anmerkung "komplex" zur Implementierung kann ich beim besten Willen nicht nachvollziehen. Das Ganze ich mit ein paar einfachen Routinen zu machen. Teile der aktuellen Implementierung sind mit Sicherheit min genauso komplex.

So weit könnte es für Interessierte noch passen.
Abhängen werde ich dann die Meisten, da ich bei den Kommandos eine systematische, zentralistische und vollkommen generische Lösung nutzen werden (welche schon erprobt ist). Eingebaut ist dies ein einziger Funktionsaufruf - wie ich finden ein Quantensprung mit etlichen Vorteilen. Entites aller Module, welche ich per Namen einbinde, bekommen u.a. systemweite Kommandos ins drop-down wie "clear readings" "list entity/entityHidden/modul" oder ein "peerlookup" welcher den Namen auch verdient und automatisch gefüllt wird. (Hier werden Attribute anderer Entites mitgelesen - bitte nicht verwechseln mit Modifiziert).

Ich hoffe, dass mein Ansatz sowie meine Beweggründe klar geworden sind. Mir ist klar, dass nicht jeder dem Folgen will - das ist logisch und vollkommen ok.
Was mich überracht sind manche Kommentare über Komplexität und Attribute welche ich hier überhaut nicht erkenne. Und noch mehr, dass scheinbar die übergroße Mehrheit aktuell hoch zufrieden ist.

Nun, da ich meinen Weg gefunden habe,zu 50% gegangen bin und sich keine Interessenten zeigen, werde ich meine Lösung "privat" vervollständigen. Es sieht aktuell ansprechen aus - gemäß meiner Vorstellung.

das Problem scheint eher zu sein, dass es sich zu kompliziert anhört - oder du es zu kompliziert erklärst. Eins von beiden trifft bestimmt zu  ;) Das Problem von FHEM ist aber ganz klar, dass es für viele zuviel Freiheit bietet. Ich denke man sollte das eher mal global thematisieren, statt nur hier für MQTT zu diskutieren. Das Problem was du meinst betrifft ja nicht nur MQTT. HA macht deutlich mehr vorgaben, dafür kommen unerfahrene damit besser klar. ein zweites HA braucht aber auch niemand. Insofern stellt sich da eher die Frage, ob man für standardzeug nicht mehr "plug&play" braucht

Zitat von: martinp876 am 14 September 2026, 21:21:20Sollte der Ansatz interessenten finden

Meine Gedanken dazu sind anderswo zu finden:

Zitat von: Beta-User am 08 September 2026, 18:56:32Die vorhandenen attrTemplate sollen v.a. funktionale Devices bringen, die aus FHEM-Sicht "typisch bedienbar" sind. Das geht ausdrücklich an manchen Stellen zulasten der Performance, um auch mal auf den Thread MQTT best current practice (https://forum.fhem.de/index.php?topic=145198.0) zu verweisen und klarer zu machen, warum es (berechtigte) Kritik an der einen oder anderen Stelle gibt.

Zitat von: Beta-User am 13 September 2026, 06:49:54"Mein" Vorschlag (auf martinp876 Konzept basierend) wäre für "reine" Discovery-Devices: Es wird GANZ auf das Anlegen von readingList verzichtet, das Dispatchen des MQTT-Traffices übernimmt für diese Instanzen von MQTT2_DEVICE AUSSCHLIESSLICH dein Modul. Die "Blaupause" für diese Art der Auswertung des eingehenden Traffics wäre MQTT_GENERIC_BRIDGE, das verteilt übrigens auch "seine" Attribute an die damit verwalteten Devices (und deren Änderung via notifyFn()), so dass die von matinp876 angedachten weiteren Infos ohne weiteres in einem passenden Attribut unterzubringen wären (ggf. mit mapping-Angaben ala jsonMap etc., parseParams() ist unser Freund).

Martin hat schon recht: Das heutige Konzept ist nicht nur eher unübersichtlich, sondern v.a. ineffizient, v.a was die Auswertung der Topics für vielkanalige Devices angeht, und (vermutlich) auch was die Kompilierung zur Laufzeit bei "sonstigen" Auswertungs-Perl-Routinen angeht. Ich habe daher auch insbesondere für das zigbee2mqtt-Zeug zwischenzeitlich auch teilweise eigenen Code (myUtils) gebastelt, der eingehende Messages in FHEM-konforme Syntax überführt. Das als Standard-Code vorzuhalten, wäre imo die nach heutigen Gesichtspunkten sinnvolle Vorgehensweise.

Du kannst natürlich weiter behaupten, dein Konzept fände keine Interessenten...

Ein Problem ist imo, dass du mit deiner Lösung auf einem Punkt ausetzt, zu dem dir mind. im Moment (in der Konzeption und der pratischen Umsetzung) wenige folgen können. Ich selbst habe auch nur eine grobe Idee, wie das aussieht, und bin vermutlich einer der wenigen, die versucht haben zu erfassen, was in den zugrunde liegenden Threads steht.

Und nach wie vor bin ich der Auffassung, dass ein auf gerade mal zwei "Familien" (Shelly-rpc und Tasmota) basierendes Konzept viele Aspekte nicht berücksichtigt, die wir heute eigentlich schon kennen. Der Teufel steckt wie immer nämlich (auch) im Detail.

wenn man sich damit mal anfängt zu beschäftigen findet man plötzlich unglaublich viele "Familien" :o Bevor ich mit MQTT2_DISCOVERY angefangen hatte, hatte ich auch nur HA und die teilweisen Abweichungen von Tasmota vor Augen... Das ist ja gerade das Problem. Es gibt da keinen Standard. MQTT ist nur ein broker und man musste bislang alles händisch selbst erfassen. Genau das ist dann auch das Problem, wenn man plötzlich mehrere devices zu pflegen hat. Insofern hat Martin einen anderen Ansatz als ich ihn mit MQTT2_DISCOVERY umgesetzt hab. Beides zielt im Kern aber drauf ab. die readingList/setList Funktionen sind aus meiner Sicht aber auch nur ein Behelf. Besser wären reine internals, wo keiner mehr ran muss. Dafür muss nur sichergestellt sein, dass das auch funktioniert. Ggf. könnte man auch setlist/readinglist als rein optionale Erweiterung definieren und die tatsächliche (Grund)Steuerung über Internals laufen lassen, die nur durch die Attribute optional ergänzt werden könnten. So mal als idee..

Zitat von: Guybrush am 15 September 2026, 11:46:26Es gibt da keinen Standard.

Noch weitergehend: Selbst da, wo man zunächst davon ausgehen würde, dass es Standards geben würde, sind diese nicht unbedingt vorhanden oder eingehalten. Das betrifft insbesondere zigbee2mqtt: Da wird im Prinzip auch nur 1:1 sämtliche Information weitergegeben, die per Funk am Coordinator ankommt - manche firmwares melden z.B. direkte Schaltaktionen via Fernbedienung, andere nicht. Für Wochenprofile für Thermostate sind mir mind. 4 Varianten bekannt, wie das zusammengebastelt werden muss... Ziemliches Chaos, mit dem man eben im Ergebnis umgehen muss.

Und dann eine Entscheidung von Theo, irgendwas grundlegendes an Tasmota zu ändern, und ganze Biblietheken werden teilweise wertlos... (zugegeben: Das ist schon lange nicht mehr vorgekommen)

Zitat von: Guybrush am 15 September 2026, 11:46:26Insofern hat Martin einen anderen Ansatz als ich ihn mit MQTT2_DISCOVERY umgesetzt hab.

Dass der Ansatz etwas unterschiedlich ist, ist klar. Mein Gedanke war: Wenn man schon automatisch ermitteln kann, was eine "entity" an eigenschaften mitbringt, und wie man die ggf. Ansteuern kann, kann man auch gleich den "Zwischenschritt" mit erledigen, das ganze "nach FHEM zu übersetzen", um "übliche Konventionen" einzuhalten. Das eine Viertel (Erkennung) kommt mit deinem Modul, ein anderes Viertel von Martin, jetzt ginge es darum, das ganze so zusammenzuführen, dass man ein für den "Konfigurator" einfach dazwischenzuschaltendes Stück Software daraus bastelt, mit dem dann mit wenigen ergänzenden Angaben oder Funktionsaufrufen am Ende das erreicht ist, was alle gerne haben wollen:

Übersicht, Effizienz und (einigermaßen) einheitliche Standards im laufenden Betrieb.

readingList und setList sind heute "eigentlich" schon optional, man müßte nur dafür sorgen, dass in der Kette SetExtensions=>AttrTemplate bei "GetAllSets(<device>)" eine passende MQTT2_DISCOVERY-Funktion vorab aufgerufen wird.

Genauer:
1. Die Aktualisierung irgendeines Readings in irgendeinem Device muss nicht zwingend durch den Code für das Modul an sich erfolgen, das kann man auch "quer" machen, readingList ist daher in diesem Sinne bereits heute einfach nur eine von mehreren Möglichkeiten, Readings an MQTT2_DEVICE-Instanzen zu aktualisieren.

2. setList macht heute nur Sinn, wenn es was an das Device zu versenden gibt. Bedeutet aber nicht, dass tatsächlich irgendwas darin stehen müßte: um die Web-Darstellung für die attrTemplate-Liste zu generieren, werden tatsächlich (auch) zwei andere Module durchforstet, falls es den Befehl nicht in setList gibt.

Statt also das Ergebnis deiner Analyse nach setList zu schreiben, könntest du auch einfach hergehen, und die passende Rückmeldung zurückgeben (für die Webdarstellung u.ä.), oder die Aktion aus deinem Modul heraus auslösen.
Das wäre noch viel eleganter, wie das dann doch wieder umständlich in den einzelnen Instanzen zu verwalten.
Zur "Verstetigung" würde ich vorschlagen, dass das Modul noch eine configfile bekommt, in der alles notwendige gespeichert wird, damit man nicht erst irgendwelche "birth messages" abwarten muss.

(Vermutlich klingt das klingonisch?) 

sowas ähnliches hab ich in MQTT2_DISCOVERY schon drin. Ich erstell da bereits eine semantic map mit Metadaten, aus der man auch Einheiten etc passend zur capability direkt erhält und on the fly fertig erstellte Geräte bekommt. Im Anhang ist ein Screenshot davon drin. Das ist nur FTUI3 mit einem angepassten backend coordinator. Ich hab nichts davon händisch erstellt, das ist das was automatisch nach Discovery rauskommt... 8)Semantic ist ein FHEM Modul, was von Werte von Modulen passend aufbereitet. Das hab ich bei MQTT2_DISCOVERY schon drin. Kann man so aber z.b. 1:1 bei allen anderen Modulen wie KNXIO usw genauso gut integrieren. Das wäre sogar wegen der dpt dafür prädistiniert.

bei meinem MQTT2 Device "schwimmbadentfeuchter" sieht diese semantic map z.b. so aus:

{ JSON::PP->new->pretty->canonical->encode($defs{"schwimmbadentfeuchter"}{SEMANTIC_METADATA}) }

{
  "confidence" : 0.95,
  "entities" : [
      {
        "capabilities" : {
            "value" : {
              "read" : "ANALOG_Temperature",
              "unit" : "° C"
            }
        },
        "class" : "sensor",
        "device_class" : "temperature",
        "id" : "analog_temperature",
        "name" : "ANALOG Temperature",
        "state_class" : "measurement"
      },
      {
        "capabilities" : {
            "value" : {
              "read" : "ENERGY_Power",
              "unit" : "W"
            }
        },
        "class" : "sensor",
        "device_class" : "power",
        "id" : "energy_power",
        "name" : "ENERGY Power",
        "state_class" : "measurement"
      },
      {
        "capabilities" : {
            "power" : {
              "activeValue" : "ON",
              "inactiveValue" : "OFF",
              "kind" : "boolean",
              "options" : [
                  "ON",
                  "OFF"
              ],
              "read" : "POWER",
              "write" : "POWER"
            }
        },
        "class" : "switch",
        "id" : "power",
        "name" : "power"
      }
  ]
}

ist leider noch nicht so weit, dass ich das freigeben wollte. Ist zur Zeit auch noch Spielerei, auch wenn das schon gut funktioniert.

Zitat von: Guybrush am 16 September 2026, 01:37:21sowas ähnliches

Sieht nett aus!

Jetzt würde es "in der mittleren Hälfte" eben darum gehen, die FHEM-Entities an sich "sauber" zu erstellen, damit z.B. die beiden "Schalter" eigene (state-) on/off-FHEM-Devices werden.

Das geht also weiter wie das heutige KNX, das wohl teils aus technischen Gründen, teils, weil das dem Maintainer nicht wichtig ist (? meine Schlussfolgerung nach einigen Schubsern meinerseits in die Richtung auf "bessere channels"), auf "Kosmetik" angewiesen ist (und bei dem noch dazu zumindest früher imo eher unglücklich gewählte Beispiele für eigene Anpassungen/"Normalisierungen" im Wiki standen). Das sollte daher imo nicht der Maßstab sein, sondern ggf. könnte diese Diskussion hier auch ein Anstoß dafür sein, dass sich jemand nochmal intensiver mit dem KNX-Teil befasst, der ("bessere") "channels" haben will.

Hier nochmal die Zusammenfassung, warum m.E. der (möglichst pure) "channels"-Weg von Martin (statt späterer Kosmetik) vorzugswürdig gegenüber solcher "Kosmetik" ist:

Zitat von: Beta-User am 13 September 2026, 06:49:54- SetExtensions brauchen "on"/"off" (state) setter, damit timer-Aktonen gestartet werden können
- Sprachsteuerung wird sehr viel schwieriger, wenn man "drumrum" was basteln muss
- Entsprechendes gilt für die Web-Darstellung mit fhemAPP etc.. Man braucht für jede Kleinigkeit ein mapping, was zwar per copy/paste einigermaßen einfach geht, aber letztlich unnötiger Aufwand ist, wenn man gleich auf der Eingangsseite eine/die "Normalisierung" vornimmt.
- Mir geht es mit FHEM um Automatisierung. Hardware zu tauschen ist sehr viel aufwändiger, wenn man einen Aktor aus der CUL_HM-Welt ersetzt durch ein mehrkanaliges (z.B.) zigbee2mqtt-Gadget, das nicht on/off kann. Entsprechendes gilt für andere "Wechsel", angefangen damit, dass jemand möglicherweise dieses "rpc-Gedönses" überdrüssig ist und Tasmota auf den ESP flasht => komplett andere Topics etc...

Just my2ct.

Das ist ein sehr guter Ansatz.

Einen ganz konkreten Änderungsvorschlag habe ich: Statt "kind" sollte "type" verwendet werden.

Zweitens schlage ich vor, zum Thema Semantik einen eigenen Thread aufzumachen - denn das ist unabhängig von MQTT.

Drittens muss ich etwas grundsätzlicher werden - man verzeihe mir das, denn Datensemantik habe ich >25 Jahre lang gelehrt:
Wenn man so etwas aufsetzt, sollte es eine saubere Ontologie geben, die alle möglichen Datentypen und Werte so genau wie möglich beschreibt.
Ob man diese in einer Ontologiesprache verfasst, oder als JSON Schema, ist egal.

Übrigens ist gerade der gigantische Gerätezoo, den wir mit FHEM bedienen können, eine gute Voraussetzung für die Erstellung einer solchen Ontologie.

LG

pah

wir könnten das tatsächlich mal allgemeiner thematisieren und da einen SOLL Zustand definieren. Ich hab jetzt den Weg eingeschlagen, das direkt über FTUI3 abzubilden. ob man das direkt in fhemweb integrieren sollte - keine ahnung. Über FTUI3 funktioniert das aber schon echt gut, zumal man so direkt eigene Masken ergänzen kann etc. Ich hab bei mir fhem auch nur als admin/verwaltungsoberfläche. die reine Steuerung erfolgt bei mir über ein FTUI3 Oberfläche. Das ist wesentlich zeitgemäßer. Die Semantic Map bildet jedenfalls schon sehr viel ab, weils quasi ein Bestandteil bei HA ist und ich in der Kombination MQTT2_DISCOVERY und SEMANTIC das versucht hab abzubilden. Insofern wird das, was über MQTT2_DISCOVERY schon automatisch konfiguiert auch über semantic abgebildet. Kann ja jeder gerne mal testen... einfach MQTT2_DISCOVERY installieren und bei den konfiguierten devices dann $defs{<device>}{SEMANTIC_METADATA} anschauen

Zitat von: Guybrush am 16 September 2026, 13:29:51die reine Steuerung erfolgt bei mir über ein [...] Oberfläche. Das ist wesentlich zeitgemäßer.

Hier scheinen sich mir zwei grundlegende Unterschiede im Verständnis dessen zu liegen, was eine "Steuerung" sein soll, und was unter "zeitgemäß" zu verstehen ist.

Mir geht es praktisch überhaupt nicht darin, eine schnieke, "zeitgemäße" Bedienoberfläche zu haben, mit der man dann alles mögliche manuell bedienen kann, sondern um eine funktionale, (eventuell sogar halbwegs auch für Dritte) wartbare (und in diesem Sinne zeitgemäße) Heimautomatisierung. FHEM tut im Hintergrund einfach, was grade dran ist, wie es im web-UI aussieht, ist mehr oder weniger egal.

Ein Beispiel, dann wird es eventuell klarer: Wir stellen uns der Einfachheit halber vor, der seitherige Admin hat das zeitliche gesegnet und diverse Außenlichter funktionieren nicht mehr. Der arme Dritte, den die überforderte Hausherrin her zitiert stellt fest, dass der im Schaltschrank verbaute Aktor (ein 6-Kanal-ZigBee-Ding wie das hier: https://www.zigbee2mqtt.io/devices/PN6.html) hinüber ist, der diese Licher eigentlich schalten soll. Im Ersatzteilfundus sind zwar eine Reihe einkanaliger Hutschienen-Aktoren vorrätig, aber die laufen teils mit MATTER, teils ist es WLAN-Shelly-Gedönse (oder Tasmota?)

Wie soll denn jetzt dieser Dritte, der zufälligerweise schon etwas FHEM-Erfahrung hat, die Aufgabe lösen, den defekten Aktor zu ersetzten? Schon der erste Schritt rauszufinden, wo der überall in der Automatisierung drin steckt (notfiy und Co, nicht primär das UI...) ist nicht ganz trivial, und wenn man dann überall statt "set AussenlichtA chA true" etc. dann den neuen mit "set AussenlichtA on" schalten muss, ist man uU. eine Weile beschäftigt, bis man nicht nur die komplette Konfiguration durchsucht hat, sondern auch noch alle myUtils-Routinen usw. Das Risiko ist extrem hoch, dass er was übersieht.
Dass die "moderne UI" sich automatisch repariert ist ein eher kleiner Trost gegenüber dem (nachvollziehbaren) Frust, warum ein einfacher an-aus-Aktor (bzw. ein channel davon) denn nicht einfach mit "ein" und "aus" zu schalten geht und den man nicht mit einem schlichten "replace AussenlichtA newaktor" einfach "durchtauschen" kann (für automatische Nachverfolgungen von Umbenennungen bin ich außerhalb des "associatedWith"-Radings (wo es afaik nicht geht, aber ausdrücklich sinnvoll wäre...) einigermaßen allergisch).

Dass mit dieser Art der "Standardisierung" gleichzeitig eine nachvollziehbare Repräsentation in FHEMWEB verbunden ist (nicht "zeitgemäß", aber verständlich), ist schlicht ein angenehmer Nebeneffekt, aber eben nicht mehr.

Manuelle Eingriffe sollten bei uns sowieso in der Regel entweder durch Tasten, Telegram-"Tastaturen" oder schlicht per Sprachsteuerung erfolgen, und dazu vielleicht noch per fhemAPP, so jedenfalls die Vision, aber das ist hier OT.

Wenn du sowas realisieren willst, dann ist das aber noch ein Schritt weiter. Auf der einen Seite müsste man die gewünschte Funktionalität definieren. Z.b. Licht Keller ein/aus, auf der anderen Seite die Geräte. Geräte kann man automatisieren. Wenn dann ein neues Gerät erkannt wurde kann man definieren was es an welchem Ausgang macht. Das wäre dann völlig unabhängig vom verwendeten Bus/Interface.

Ich hab bei mir das meiste auch automatisiert, was ja Sinn und Zweck von Fhem bei mir ist. Gleichwohl gibt es genug, was man noch händisch bedienen können sollte. Dafür nutz ich eben FTUI3 als Schnittstelle zu fhem

Zitat von: Guybrush am 16 September 2026, 21:54:25dann ist das aber noch ein Schritt weiter

Nach meinem Verständnis geht es hier die ganze Zeit bereits eigentlich um diesen weiteren Schritt: Statt durch "Tonnen von (statisch gesetzten) Attributen" soll zumindest im Bereich von klar umrissenen "MQTT-Familien" ein framework _vorab_ die Aufgabe erledigen, anhand von wenigen Uservorgaben (Martins neue Attribute) "sinnvolle Standard-FHEM-Entities" (hier als MQTT2_DEVICE-Instanzen) zu bilden.

Was heute in attrTemplate (insbesondere, aber nicht nur (!) als "split"-Varianten) enthalten ist, verfolgt auch (allerdings in den heute möglichen Attributen statisch) den Ansatz: Das Ergebnis ist funktional identisch, egal, ob es z.B. ein schaltbarer Kanal aus einem Aktor mit vielen Relays ist, oder z.B. ein Thermostat, bei dem die Solltemperatur eben immer "desired-temp" als Readingnamen hat, egal, was dem "Übersetzer" aus der zigbee-, xy- oder z-Welt gerade eingefallen ist, wie das dort benannt werden könnte.

Ziel wäre es "nur", die Vorgehensweise zu ändern, und das ganze zu dynamisieren, damit man (automatisch) in einem Zug alles geändert bekommt, wenn sich z.B. bei zigbee2mqtt was grundlegendes ändern sollte.

Alles nett. Aber bei den ganzen Templates fehlt mir vor allem eines: Eine Dokumentation. Warum etwas so gelöst worden ist, was man tun kann, um es zu ändern etc.

Ich habe das gemerkt, als ich ein neues ebusd-Interface eingebaut habe: Massig MQTT-Templates - aber keinerlei Erklärung. Ergo habe ich alles wieder von Hand gemacht.

LG

pah

P.S.: Ich votiere nach wie vor für eine Ontologie. Und zwar sowohl von Geräten, Gerätekombinationen - als auch von Nutzungsszenarien (Licht an, Licht aus, Licht an wenn..., Licht aus nach xxx Sekunden etc.).

ich hab das in er semantic map in grundzügen drin. Mach doch mal konkrete Vorschläge wie das definiert sein könnte.

Zitat von: Prof. Dr. Peter Henning am 17 September 2026, 08:59:09Alles nett. Aber bei den ganzen Templates fehlt mir vor allem eines: Eine Dokumentation. Warum etwas so gelöst worden ist, was man tun kann, um es zu ändern etc.

Puh...

Also: Im Quellcode (klar: nicht optimal, aber im Wiki zu attrTemplate sollte es stehen...) steht fast immer (über dem betreffenden template) die (Foren-) Quelle drin, aus der man häufig auch die "immer gleichen" Diskussionen um gute Reading-Namen, den Nachrichtenkreislauf usw. nachvollziehen kann. Weil es mir irgendwann leid war, diese "immer gleiche" Diskussion zu führen, ist meine erste Reaktion auf die Anfrage für ein neues Gadget, man möge doch bitte zuerst den Weg gehen, wie er sich aus "Schritt für Schritt" ergibt, da ist in den Grundzügen erklärt, wie die Attribute aufeinander aufbauen. Die Transferleistung, das dann im eigenen Sinne anzuwenden, werde ich keinem abnehmen.
Falls du also Verbesserungsbedarf (v.a.) an der (zusammenfassenden) Doku siehst - feel free.

Teils finden sich in desc, teils in den betreffenden Foren dann auch Hinweise, wenn ich Dinge für nicht gut gelöst hielt, die betreffenden User aber nicht willens oder in der Lage waren, die notwendigen Infos beizubringen oder unbedingt an ihrer "Lösung" festgehalten haben.

Zitat von: Prof. Dr. Peter Henning am 17 September 2026, 08:59:09ebusd-Interface eingebaut habe: Massig MQTT-Templates - aber keinerlei Erklärung.

Gerade das ist ein Beispiel für jemand, der bei der Mitarbeit "beratungsresistent" war (soweit es dieses dummy-spamming betrifft). Daher finden sich diese Teile auch nicht unmittelbar in mqtt2.template, und meine mühsamen Versuche, jemanden zu motivieren, das (endlich) besser zu machen, wirst du auch mühelos finden können... Also: feel free, es besser zu zeigen, auch an dieser Stelle!

(Ähnliches gilt für Shelly-rpc, aber da gibt es für "normale on/off-Devices wenigstens einen Vorschlag von betateilchen. Muss mal schauen, ob ich das schon eingecheckt habe, das ständige Gemaule hat mich zugegebenermaßen einigermaßen demotiviert).

Nochmal zurück zu dem Vorschlag, aus MQTT2_DEVICE nicht direkt SetExtensions aufzurufen.

Die aktuelle Lösung von Guybrush sieht vor, setList in etwa so zu befüllen:

Zitat von: Guybrush am 08 September 2026, 17:12:18

Code Auswählen Erweitern

attr shelly1g4_********* setList switch_0:on,off { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_773c31e37677a16e', $EVENT) }

Das wäre "überflüssig, wenn man statt (aktuell Zeilen 409f des M2D-Codes)
  my $cmd = $sets->{$cmdName};
  return SetExtensions($hash, $cmdList, @a) if(!$cmd);
sowas machen würde:
  my $cmd = $sets->{$cmdName};
  if(!$cmd) {
    return MQTT2_DISCOVERY_SetExtensions($hash, $cmdList, @a) if defined MQTT2_DISCOVERY_SetExtensions;
    return SetExtensions($hash, $cmdList, @a);
  }
Kann MQTT2_DISCOVERY_SetExtensions() nicht mit den Infos anfangen, wird das einfach dann an das "normale" SetExtensions weitergereicht. Hoffe, der Gedanke ist jetzt klarer?

ja ist er. ich schau mir das mal an. das wäre dann aber optional als attribut umzusetzen. mit setExtensions hab ich selbst jedenfalls noch nicht so viel gemacht.

Zitat von: Guybrush am 17 September 2026, 12:48:46ich schau mir das mal an. das wäre dann aber optional als attribut umzusetzen.

Nope: wenn es die Funktion gibt (und setList den Befehl nicht enthält), wird immer deine Zwischenfunktion aufgerufen, wenn diese vorhandenen ist, also das Modul auch geladen.

Dann kannst du intern prüfen, ob das ein gültiger set-command (ggf. für den "Channel") ist, oder nicht. Wenn nein: Argumente durchreichen, das ist schon alles.

Zum Testen: mal in $cmdList zusätzlichen was reinschreiben, dann weiterreichen und schauen, was du in fhemweb an Kommando auswählen kannst...

So, jetzt hat Guybrush es geschafft, hier läuft jetzt auch eine (modifizierte) Fassung von MQTT2_DISCOVERY.

Das liefert dann für einen zigbee2mqtt-Bewegungsmelder (ohne setList-Attribut) auf die Frage:
{getAllSets('Bewegungsmelder_Eingang')}

ZitatfunnyTesting:a,b attrTemplate:?,General_Info,MQTT2_CLIENT_general_bridge, [...]

@martinp876 und Guybrush
Bitte um Rückmeldung, ob Interesse an einem intensiveren gemeinsamen review besteht, um das in der hier gezeigten Richtung auszubauen, damit man z.B. für ein "einfaches Shelly-Licht" weder ein readingList-Attribut anlegen muss, noch ein setList-Attribut benötigt?

(Anm: Die MQTT2_DISCOVERY funktioniert vermutlich nicht "solo", man benötigt auch die anderen Dateien aus dem github repo)

ich schau mir das am WE mal in Ruhe an. Und ja, natürlich besteht Interesse. Ich hab das Modul ja für die Allgemeinheit rund gemacht. Sieht man doch schon an der umfassendsten Doku  :)) Also sollte es auch so komfortabel wie möglich werden um die Akzeptanz zu steigern und dem einen oder anderen aus dem Attributjungle verhelfen.

@Rudi:

a) Der Plan wäre, über dieses Modul ggf. dann auch ein paar "generische setter" zu ergänzen. Manches ginge sicher auch direkt über das MQTT2_DEVICE-Modul, anderes wäre ggf. dann nur vorhanden, wenn tatsächlich das MQTT2_DISCOVERY-Modul geladen wäre. Dementsprechend wäre es hilfreich, die Doku zu den betreffenden set-Befehlen anzeigen zu können, was derzeit nicht geht, weil eben (so mein Verständnis) nur jeweils die commandref zum TYPE durchsucht wird.
Eventuell wäre es möglich, einen "versteckten" allgemeinen Teil der commandref zu generieren, bei dem das jeweilige Modul dann angeben kann, für welche Ziel-TYPE(s) der set-Befehl wäre? Also ähnlich wie das heute bei der Attribut-Hilfe schon umgesetzt ist...

b) Ich hatte gestern ein paar harte Abstürze beim Versuch, "reload MQTT2_DEVICE" abzusetzen. Dachte erst, es läge am coding (was zunächst auch teils der Fall war), die im log zu findende Ursache ist aber wohl anderer Natur und hat sich dann später bei "reload MQTT2_DISCOVERY" wiederholt:
2026.09.17 20:46:44 1: PERL WARNING: Use of uninitialized value in regexp compilation at fhem.pl line 4195.
Can't use an undefined value as a subroutine reference at fhem.pl line 4203.
Bei reload wird wohl die ParseFn() der Module gelöscht. Wenig hilfreich für das kommende Testen, wenn man FHEM jedes Mal neu starten muss.

@Guybrush:
Als Fingerübung wäre mein Vorschlag, zunächst mit "clearReadings" (als set-Befehl am Zieldevice) anzufangen, und dann mit "rebuildDevice", wobei ich dazu gleich funktional die Frage hätte, warum du da nicht die "devicetopic"-Variante ziehst, mehre Zuweisungen zu machen:

Zitatif the value does contain an equal sign (=), then it is interpreted as

    Var1=Var1Value Var2="Value with space" Var3=...

and $Var1,$Var2,$Var3 are replaced in the readingList, setList and getList attributes with the corresponding value.

Das würde imo das Nebeneinander von neuer und alter Welt beim "rebuild" eventuell vereinfachen?

Ansonsten wäre noch die Frage, was man ggf. sinnvollerweise als gemeinsames Testgerät hernehmen könnte. Im Keller hier liegt noch ein Tasmota-Ding rum, was interessant sein könnte: Ein Steckdosen-Zwischenstecker mit eingebautem Nachtlich - zwei "channels", der eine ein einfaches on/off-Device, der andere ein rgb-Licht. Falls du nichts vergleichbares hast: bitte melden, hier sind zwei vorrätig (weiß aber nicht, ob beide Tasmota-geflasht sind).

Ach so: Den Code habe ich noch nicht angeschaut, muss erst mein Perl etwas auffrischen (und in dem Zug zunächst ein paar andere Hausaufgaben erledigen). Das sieht mir aber nach ziemlich umfangreichem rework aus, eventuell wäre es einfacher, zunächst das "Basismodul" als gepackagtes Modul aufzusetzen, und dann die ganzen Erweiterungen nach und nach da reinzuziehen. Alles auf einmal wird vermutlich schwierig...

Zitata) Der Plan wäre, über dieses Modul ggf. dann auch ein paar "generische setter" zu ergänzen.

Muss noch ueberlegen, wie ich das generisch machen kann, ich mag keine hartkodierte Sachen.

Zitatb) Ich hatte gestern ein paar harte Abstürze beim Versuch, "reload MQTT2_DEVICE" abzusetzen.

Da hat wer in den Clients Eintrag eines Moduls, was Nachrichten per Dispatch verteilt, Muell eingebaut.
Ich tippe auf MQTT2_DISCOVERY, da wird oefters das clientOrder Attribut des IODevs gesetzt.
MQTT2_CLIENT/MQTT2_SERVER pruefen nicht beim Setzen des Attributes, ob der Inhalt wenigstens Formal korrekt ist, das koennte ich noch einbauen.

eigentlich dispatcht MQTT2_DISCOVERY das so wie es reinkam. Ich unterwuche nur ob es mit einem passenden prefix beginnt und dispatchte das sonst direkt, da nichts verändert werden soll, was nicht discovery betrifft. nur die discovery topics sollen "verschluckt" werden. ich schau mir das aber auch mal an.

devicetopic sollte sich ja eigentlich nicht ändern solang man das Gerät nicht anfasst. Das was du ins Spiel bringst ist ja schon mehr als an was ich ursprünglich dachte  :P

@Rudi:
Danke!
Zum Testen wäre "on-for-timer" etc. eventuell ein schöner Kandidat?

@Guybrush:
Wir sehen vermutlich alle noch nicht alles, was "anders" wird, als sich das der eine oder andere gedacht hat *grins*

Hallo zusammen,

ich habe mich gestern und heute auch zum ersten Mal mit der dev-Fassung von MQTT2_DISCOVERY (0.9.11) beschäftigt, an einem Shelly 1 Mini Gen3 auf einem separaten FHEM. Dabei habe ich ein paar Änderungen und Korrekturen vorgenommen und ergänzt, wie aus meiner Sicht ein einkanaliges Gerät automatisch angelegt werden sollte.

Ihr kennt mich ja: Ich bin weder der große Schreiberling noch der große Programmierer. Darum habe ich alles zusammenfassen lassen, was mich dabei beschäftigt hat:

Die harten Abstürze beim reload

Die beiden Zeilen

PERL WARNING: Use of uninitialized value in regexp compilation at fhem.pl line 4195.
Can't use an undefined value as a subroutine reference at fhem.pl line 4203.

lassen sich gezielt erzeugen. In `Dispatch` läuft FHEM über den zwischengespeicherten
`.clientArray` des IODev und greift dabei auf `$modules{$m}{Match}` und `$modules{$m}{ParseFn}` zu.
Steht dort ein Modulname, dessen Eintrag in `%modules` leer ist, beendet sich FHEM. Nachgestellt
mit zwei Zeilen im laufenden System:

$modules{LEER_TEST}{Irgendwas} = 1;                      # Eintrag ohne Match und ParseFn
$defs{MQTT2_Server}{".clientArray"} = ["MQTT2_DISCOVERY", "LEER_TEST", "MQTT2_DEVICE"];

Die nächste eintreffende MQTT-Nachricht hat FHEM beendet, im Log standen genau die beiden Zeilen
von oben.

Zwei Punkte dazu:

- Müll in `clientOrder` allein reicht nicht. Ich habe einen erfundenen Modulnamen ins Attribut
  geschrieben; `computeClientArray` filtert Einträge ohne `Match` zuverlässig heraus, es gab keinen
  Absturz. Gefährlich ist erst der **zwischengespeicherte** Array, der beim Setzen von `clientOrder`
  nicht neu berechnet wird.
- Woher der leere Eintrag kommt: durch Autovivification. Jedes `$modules{<noch nicht geladenes
  Modul>}{...} = ...` legt ihn an. Genau in diese Falle bin ich beim Nachbauen des Hooks selbst
  gelaufen, siehe unten.

Als Absicherung in `fhem.pl` würde ein `next if(!$modules{$m}{ParseFn});` in der Dispatch-Schleife
genügen, unabhängig davon, wer den Eintrag erzeugt hat.

Zum SetExtensions-Hook

Zwei Kleinigkeiten am Entwurf:

1. In `$list .= 'funnyTesting:a,b'` fehlt das Trennzeichen. `$cmdList` entsteht in
  `MQTT2_getCmdHash` als `join(" ",@cmd)`, also ohne Leerzeichen am Ende. Am Gerät kommt heraus:

 
 
Unknown argument ?, choose one of switch_0:on,offfunnyTesting:a,b attrTemplate:... 

  Beides ist damit unbrauchbar. Richtig wäre `$list .= ($list eq '' ? '' : ' ') . '...'`.

2. Der Hook wird für **jedes** MQTT2_DEVICE aufgerufen, nicht nur für die von Discovery verwalteten.
  Im Modul lässt sich das mit `MQTT2_DISCOVERY_runtimeRegistryRecord($name)` prüfen, das liefert den
  Registry-Eintrag oder nichts.

Zum auskommentierten `# if(!$list)`: Das habe ich nachgestellt, es ist unkritisch. `SetExtensions`
steigt bei leerer Liste zwar sofort zu `AttrTemplate_Set` aus, ohne `on` und `off` in der Liste
landet es aber ein paar Zeilen später ohnehin dort. Die Abkürzung nachzubauen wäre sogar hinderlich,
sie würde das Zusatzkommando ausgerechnet bei Geräten ohne setList unterdrücken, also bei Sensoren.

Und einer, der mich Zeit gekostet hat: `use SetExtensions;` am Modulkopf macht MQTT2_DISCOVERY
außerhalb von FHEM untestbar, mit dieser Zeile brechen 11 der 22 Testdateien des Repos schon beim
Übersetzen ab. `10_MQTT2_DEVICE.pm` lädt `SetExtensions.pm` ohnehin selbst in Zeile 7.

Registrieren statt fest verdrahten

@rudolfkoenig: Dein ,,ich mag keine hartkodierte Sachen" trifft genau den Punkt. In FHEM trägt sich
sonst das Fremdmodul ein, der Kern kennt es nicht: `$data{FWEXT}{...}{FUNC}` bei FHEMWEB,
`$modules{<Typ>}{FingerprintFn}`, `{NotifyOrderPrefix}`, `{AttrFn}` in `fhem.pl`. Eine Prüfung der
Art `defined &main::Fremdfunktion` kommt in `fhem.pl` an keiner Stelle vor.

my $cmd = $sets->{$cmdName};
if(!$cmd) {
  my $fn = $data{MQTT2_DEVICE}{SetExtensionsFn};
  return &{$fn}($hash, $cmdList, @a) if($fn);
  return SetExtensions($hash, $cmdList, @a);
}
und im Fremdmodul einmal beim `Initialize`:

$data{MQTT2_DEVICE}{SetExtensionsFn} = 'MQTT2_DISCOVERY_SetExtensions';

Bewusst `%data` und nicht `%modules`: Der Schreibzugriff auf einen noch nicht geladenen Moduleintrag
erzeugt genau den leeren Eintrag, der weiter oben FHEM beendet hat. Offen bleibt, dass ein einzelner
Eintrag nur einen Registranten zulässt; bei mehreren bräuchte es eine Liste samt Reihenfolge.

## Es geht wirklich ohne setList

Ich habe den Hook einen Schritt weitergebaut: Das Discovery-Modul schreibt bei gesetztem Attribut
kein `setList`-Attribut mehr, sondern legt die Befehle strukturiert in seiner Registry ab. Der Hook
ergänzt sie bei `set ... ?` in der Auswahl und führt einen bekannten Befehl selbst aus, inklusive
`state` — diesen Schritt macht `MQTT2_DEVICE_Set` sonst selbst, aber nur für Befehle aus seiner
eigenen setList.

Am Gerät sieht das so aus:

attr shelly1minig3_e4b3231cf8a8 setList  ->  (keins)

set shelly1minig3_e4b3231cf8a8 ?
  off:noArg on:noArg off-till off-till-overnight on-for-timer on-till-overnight blink ...

Am echten Relais getestet: `on`, `off` und `on-for-timer 5` funktionieren, letzteres läuft über
SetExtensions wieder in den Hook hinein.


Code zum Anschauen

Die Prototypen liegen als einzelne Zweige in einem Fork, jeder mit ausführlicher Commit-Nachricht
und grüner Testsuite: edit: Link entfernt

Für diesen Thread relevant ist `feat/sets-via-hook`, die nötige Ergänzung in `10_MQTT2_DEVICE.pm`
steht dort in `docs/mqtt2-device-hook.md`. Die übrigen Zweige betreffen Fehler im Modul selbst.

Dateien angehangen falls es sich wer anschauen möchte...

Zitat von: TomLee am 18 September 2026, 14:56:57Dateien angehangen falls es sich wer anschauen möchte...

Noch nicht im Detail, aber das ist erst mal auch nicht notwendig!

Sehr cool!!!!

Magst du die These verifizieren, dass man auch keine readingList benötigt, wenn man so einen Shelly hat?

Stichwort: ParseFn() in discovery setzt die readings, Code aus mqtt_generic_bridge transferieren.

ZitatMagst du die These verifizieren, dass man auch keine readingList benötigt, wenn man so einen Shelly hat?

Stichwort: ParseFn() in discovery setzt die readings, Code aus mqtt_generic_bridge transferieren.

Geht:

defmod shelly1minig3_e4b3231cf8a8 MQTT2_DEVICE shelly1minig3_e4b3231cf8a8
attr shelly1minig3_e4b3231cf8a8 autocreate 0

setstate shelly1minig3_e4b3231cf8a8 off
setstate shelly1minig3_e4b3231cf8a8 2026-09-18 18:31:50 IODev MQTT2_Server
setstate shelly1minig3_e4b3231cf8a8 2026-09-18 18:31:57 lwt online
setstate shelly1minig3_e4b3231cf8a8 2026-09-18 18:50:59 state off
Alle neuen Schalter sind Attribute am MQTT2_DISCOVERY-Device und stehen default auf 0. Ohne
sie verhaelt sich das Modul wie bisher: readingList und setList am Geraet, und alle erkannten
Readings sind sichtbar.

Attribut             Vorgabe        Wirkung bei 1
readingsViaParse     0              kein readingList-Attribut, Auswertung in ParseFn
setsViaHook          0              kein setList-Attribut, Befehle über den Hook
fhemConventions      0              ein Kanal: state, on/off statt true/false
availabilityReading  availability   none: kein verdichtetes Reading, nur lwt

Nach dem Umschalten genuegt set <discovery> rebuildDevice <device>.

Payloads zum Nachstellen ohne Mini Gen3

Der Adapter fragt ueber `<prefix>/rpc` nacheinander `Shelly.GetDeviceInfo`, `Shelly.GetConfig`,
`Shelly.GetStatus` und `Shelly.GetComponents` ab. In jeder Anfrage stehen `id` und `src`; die Antwort
gehoert auf `<src>/rpc`, mit derselben `id` und `"src":"<geraete-id>"`. Damit laesst sich das Geraet
mit mosquitto_pub vollstaendig simulieren.
Hier die vier Antwortinhalte, echte Werte eines Shelly 1 Mini Gen3 mit FW 2.0.0:


1. Shelly.GetDeviceInfo
{"name": null, "id": "shelly1minig3-e4b3231cf8a8", "mac": "E4B3231CF8A8", "slot": 1, "model": "S3SW-001X8EU", "gen": 3, "fw_id": "20260710-101122/2.0.0-g87fbfa4", "ver": "2.0.0", "app": "Mini1G3", "auth_en": false, "auth_domain": null, "matter": false, "provision": "complete", "enhanced_security": false}
2. Shelly.GetConfig
{"ble": {"rpc": {"enable": false}}, "bthome": {}, "cloud": {"enable": false, "server": "iot.shelly.cloud:6012/jrpc"}, "input:0": {"id": 0, "name": null, "type": "button", "enable": true, "invert": false, "factory_reset": true}, "knx": {"enable": false, "ia": "15.15.255", "routing": {"addr": "224.0.23.12:3671"}}, "matter": {"enable": false}, "mqtt": {"enable": true, "server": "192.168.188.27:1883", "client_id": "shelly1minig3-e4b3231cf8a8", "user": "Thomas", "ssl_ca": null, "topic_prefix": "shelly1minig3-e4b3231cf8a8", "rpc_ntf": false, "status_ntf": true, "use_client_cert": false, "enable_rpc": true, "enable_control": true}, "switch:0": {"id": 0, "name": null, "in_mode": "detached", "in_locked": true, "initial_state": "restore_last", "auto_on": false, "auto_on_delay": 60.0, "auto_off": false, "auto_off_delay": 60.0, "counts": {"enable": true}}, "sys": {"device": {"name": null, "mac": "E4B3231CF8A8", "fw_id": "20260710-101122/2.0.0-g87fbfa4", "discoverable": true, "eco_mode": false, "tls_check_cert_validity_time": true, "enhanced_security": false}, "location": {"tz": "Europe/Berlin", "lat": 49.4841, "lon": 8.374}, "debug": {"level": 2, "file_level": null, "mqtt": {"enable": false}, "websocket": {"enable": true}, "file_log": {"enable": false}, "udp": {"addr": null}}, "ui_data": {"device_revision": "1-70"}, "rpc_udp": {"dst_addr": null, "listen_port": null}, "sntp": {"server": "time.cloudflare.com"}, "cfg_rev": 89}, "wifi": {"ap": {"ssid": "Shelly1MiniG3-E4B3231CF8A8", "is_open": false, "enable": false, "range_extender": {"enable": false}}, "sta": {"ssid": "FBF", "is_open": false, "enable": true, "ipv4mode": "dhcp", "ip": null, "netmask": null, "gw": null, "nameserver": null}, "sta1": {"ssid": null, "is_open": true, "enable": false, "ipv4mode": "dhcp", "ip": null, "netmask": null, "gw": null, "nameserver": null}, "roam": {"rssi_thr": -80, "interval": 60}}, "ws": {"enable": false, "server": null, "ssl_ca": "ca.pem"}}

3. Shelly.GetStatus
{"ble": {}, "bthome": {}, "cloud": {"connected": false}, "input:0": {"id": 0, "state": null}, "knx": {}, "matter": {"num_fabrics": 0, "commissionable": false}, "mqtt": {"connected": true}, "switch:0": {"id": 0, "source": "MQTT", "tag": null, "output": false, "counts": {"on_time": 90240, "on_time_rst_ts": 0, "switch_on": 54, "switch_on_rst_ts": 0}, "temperature": {"tC": 58.6, "tF": 137.5}}, "sys": {"mac": "E4B3231CF8A8", "restart_required": false, "time": "18:45", "unixtime": 1789749942, "last_sync_ts": 1789749223, "uptime": 13281, "ram_size": 276212, "ram_free": 153688, "ram_min_free": 129644, "fs_size": 917504, "fs_free": 450560, "cfg_rev": 89, "kvs_rev": 0, "schedule_rev": 0, "webhook_rev": 0, "btrelay_rev": 0, "bthc_rev": 2, "available_updates": {"beta": {"version": "2.0.1-beta3"}}, "reset_reason": 3, "utc_offset": 7200}, "wifi": {"sta_ip": "192.168.188.238", "status": "got ip", "ssid": "xxx", "channel": 6, "rssi": -53, "bssid": "fc:ec:da:fd:26:1a", "sta_ip6": ["fe80::e6b3:23ff:fe1c:f8a8", "2003:cd:1710:3500:e6b3:23ff:fe1c:f8a8"]}, "ws": {"connected": false}}
4. Shelly.GetComponents
{"components": [], "cfg_rev": 89, "offset": 0, "total": 0}

danke für die zuarbeit ;D Ich schau dass ich das glatt gezogen bekomm und übernehm das was geht ins Modul.

Wurde denn bei dir auch insoweit alles erkannt und funktional angelegt?

Fänds gut, wenn Du das alles erstmal bei allen Beteiligten _ein_paar_Tage_ sacken lässt.
Erst was gerade ziehst, wenn zu jedem Branch eine Rückmeldung kam und jeder seinen Senf dazu gegeben hat...

keine sorge. ich guck mir auch erstmal an, was auf jeden fall geändert werden muss, wegen der Fehler. die Anpassungen davon sind losgelöst. War etwas missverständlich mit Glatt ziehen ausgedrückt.

@martinp876
Eine Rückmeldung wäre nett, ob wir die Diskussion an anderer Stelle fortsetzen sollen, oder ob das hier (was ich annehme) in deinem Sinne ist.

@TomLee:
Kurz zusammengefaßt: Ein riesiges DANKE!
(Soweit) funktionsfähiger Code sagt mehr, als ich hier in 1000 sehr kalten Wintern nicht hätte schreiben können, und du hast die Anregungen super erfaßt, die hinter meinen teils sehr kryptischen mobilen Zwischenrufen standen :)  :)  :) .

@Rudi:
vermutlich habe ich das mit "generisch" nicht richtig ausgedrückt. Es ging mir darum, den Hilfetext (Auszug aus der commandref) anzuzeigen, der zum set-Kommando paßt, obwohl der nicht aus dem TYPE des Moduls paßt. Also "set <device> on-for-timer 300" => Anzeige des Hilfetxts aus SetExtensions...
Denn Punkt von TomLee wegen "Registrieren statt fest verdrahten" hatte ich so nicht gesehen, meine aber, dass das so oder so ein Problem werden wird, falls es noch mehr Module geben sollte, die sich da Einklinken wollen. Wenn, dann müßte man das als Array bauen und "jeder" der sich registriert, muss sagen, an welcher Stelle er will. Vorschlag: Wie wäre es, das über eine SetExtensionsFn() zu machen, die im define-Aufruf registiert wird, wie DispatchFn() etc. auch? Dann wäre die Reihenfolge auch klar: Anhand der clientOrder... (Edit: zu kurz gedacht, MQTT2_DEVICE kann beim Define nicht wissen, dass ein anderes Modul vorab den unbekannten set-Befehl haben will; das müßte man timer-basiert nach $init_done bzw. define von "Utils" machen).

(v.a) @Guybrush:
Ich würde auch darauf tippen, dass irgendwas in deinem Modul für die Abstürze bei reload verantwortlich ist. Ich habe in der Vergangenheit mit zwei anderen "Kandidaten" viel getestet, und das hatte ich nie. Kann aber auch Zufall sein, denn clientOrder setzt man einmal, und das war es dann...

---

Mein möglicherweise etwas ungeordneter Gedankenstrom zum Rest:
Modulname
"discovery" trifft es nach den jetztigen Änderungen nicht mehr so wirklich. Würde MQTT2_Utils (oder config, helper, tools, admin) vorschlagen. Das Ganze läuft m.E. auf ein umfangreicheres Toolset hinaus, mit dem man massivst das Verhalten der MQTT(2)-Welt in FHEM beeinflussen kann.

Schlüssel und Defaults
Sehr spannendes Themenfeld.

Zitat von: TomLee am 18 September 2026, 19:05:24Alle neuen Schalter sind Attribute am MQTT2_DISCOVERY-Device und stehen default auf 0. Ohne
sie verhaelt sich das Modul wie bisher: readingList und setList am Geraet, und alle erkannten
Readings sind sichtbar.

Ich würde dazu gerne ein paar Thesen bzw. Eckpfeiler zur Diskussion stellen:

• Jedem Schlüssel ein Attribut ist keine Option

Kurzform der Begründung: Wir brauchen diese Art Schlüssel "global", per "Familie" und auch noch auf Device-Ebene. Und mein Bauchgefühl sagt mir: Wir werden sehr viele Schlüssel brauchen, von denen allerdings die wenigsten User jemals Gebrauch machen...

• Der allgemeine Default solle "FHEMish" sein.

Die jetzige Vorgaben für die ersten drei genannten Schlüssel sind daher imo nach dem ersten Testen "falsch". Guybrush "braucht" es wegen seiner FTUI-Kosmetik anders, aber alle anderen werden sich fragen, warum sie bei einer solchen Lösung überhaupt etwas einschalten sollen, um zu einer "gewohnten" Device-Anlage zu kommen, wie sie das aus CUL_HM, ZWave, ... kennen 

• Auf Device-Ebene gesetzte Schlüssel müssen geprüft werden

Warum überhaupt auf Device-Ebene? Beginnen wir bei forceNEXT: Wer ein "spezielles" Gadget hat, will eventuell (!) den Datenverkehr zusätzlich auswerten, Dispatch() muss also weitergehen. Das "global" zu schalten würde Chaos bedeuten,... Kann aber natürlich sein, dass jemand das forceNEXT nie für die Shelly-family haben will, aber immer für Tasmota und/oder zigbee2mqtt. Das bei jedem Device neu setzen zu müssen ist (zu/unnötig) umständlich. Damit wäre auch erklärt, was mit "Familien-Ebene" gemeint ist.
Geprüft? Warum und wie?
Das Modul muss den User so führen, dass der keinen Fehler machen kann. Die einfachste Variante ist: Wir erlauben (offiziell) gar keine direkte Eingabe... Der User soll bitte schön einen set-Befehl absetzen, um den Schlüssel zu aktivieren, das Modul überträgt ihn dann in das entsprechende Attribut am Device, merkt sich, dass es das grade selbst veranlasst hat und lässt erst dann die Attribut-Änderung zu.
Stichworte: addToDevAttrList() aus fhem.pl, das neue $checkInstance verwenden (Modulhilfe über $module wäre sowieso Pflicht).

• Auf Device-Ebene setzbare Attribute müssen einfach zu finden sein

Da wir heute nicht wissen, was die User im Einzelnen darauf machen, würde ich dafür plädieren, hier auch den "<prefix>"-Mechanismus aus MQTT_GENERIC_BRIDGE (u.a.) zu übernehmen, und dann auch nur eins bzw. bestenfalls einige wenige Attribute vorzusehen, in denen man schlicht den Schlüssel an- oder ausschalten kann. Das dann durch parseParams() laufen lassen.

• Auf Device-Ebene setzbare Schlüssel

Hier könnte/sollte man auch nochmal die Vorschläge von @martinp876 anschauen, wobei ich im Moment vermute, dass sich das meiste erledigt haben könnte?
@Rudi: Da war auch der Vorschlag drunter, zum Debuggen die "rohen Nachrichten" anzeigbar zu machen. Das kann man zwar auch mit anderen Mitteln erreichen (ich selbst würde dazu mosquitto_sub bemühen), aber eventuell wäre es wirklich hilfreich, wenn man direkt am IO die Option einbaut, allen ein- und ausgehenden Traffic mit zu loggen, begrenzt auf Topics, die bestimmten Geräten zuzuordnen sind (statt "+" an einer bestimmten Stelle im Topic z.B. Globalsuche (nur!) über den Topic nach "shelly1minig3-e4b3231cf8a8|DVES_75CA78"?

---

Bin sicher nicht fertig, aber mein Kopf ist jetzt erst mal leerer...

---

Doch noch nicht ganz. Drei Stichworte hätte ich noch

• package (!!!)

Alles nach main ist imo keine Option.

• perlcritic

Hier habe ich das noch nicht ausgetestet, aber man glaubt es kaum, was da alles (sehr häufig zurecht!) bemängelt wird! Btw: die Prototype-Schreibweise in meinem Schnippsel war der Eile geschuldet, und der deklarierte prototype der Funktion weicht auch noch vom tatsächlich erwarteten ab. Hatte keine Lust, mich damit näher auseinanderzusetzen, aber sowas bereitet mir Kopfzerbrechen.

• perltidy

Nicht soooo wichtig, aber z.B. Tabulator-Marken werden nicht in allen Editoren gleich dargestellt...

  my $fn = $data{MQTT2_DEVICE}{SetExtensionsFn};
Ich habe die Idee weiter generalisiert: $modules{<modulename>}{SetExtensionsFn} ist eine Liste, und die Funktionen in der Liste werden der Reihe nach aufgerufen.
Implementiert ist das in SetExtensions, d.h. alle Module, die SetExtensions verwenden, koennen so erweitert werden.
AttrTemplate_Set wird in die Liste von SetExtensions selbst eingetragen (falls es nicht per disableFeatures deaktiviert wurde).
Die eingetragenen Funktionen werden der Reihe nach aufgerufen, bis einer was Anderes als "Unknown argument $cmd, choose one of ..." zurueckliefert.
Die Parameter sind identisch zu SetExtensions bzw. AttrTemplate_Set.

ZitatEs ging mir darum, den Hilfetext (Auszug aus der commandref) anzuzeigen, der zum set-Kommando paßt, obwohl der nicht aus dem TYPE des Moduls paßt. Also "set <device> on-for-timer 300" => Anzeige des Hilfetxts aus SetExtensions...

Die Hilfe kommt z.Zt. per help (Maintainer: betateilchen) und besteht aus dem =pod...=cut Teil der Datei FHEM/\d\d_<modulname>.pm.
Eigentlich(TM) sollte die Hilfe dynamisch sein, weil manche Befehle bei bestimmten Geraeten nicht anwendbar sind, bin aber z.Zt. ueberfragt, wie man das halbwegs einfach machen koennte.
Wenn wir nur die SetExtensions dazupacken wollen, dann koennte FHEMWEB diese Liste in der DetailAnsicht als Attribut hinterlegen, und fhemweb.js koennte help mit diesen Dateien (ohne _Set) zusaetzlich aufrufen.
Voraussetzung waere, dass help nicht auf \d\d_ im Dateinamen besteht.

ZitatDa war auch der Vorschlag drunter, zum Debuggen die "rohen Nachrichten" anzeigbar zu machen.

Warum reicht "Show MQTT traffic" nicht?
Vermutlich habe ich etwas ueberlesen.

ZitatIn `Dispatch` läuft FHEM über den zwischengespeicherten `.clientArray` des IODev und greift dabei auf `$modules{$m}{Match}` und `$modules{$m}{ParseFn}` zu.
Steht dort ein Modulname, dessen Eintrag in `%modules` leer ist, beendet sich FHEM.

Das ist sicher richtig, wenn man .clientArray kaputtmacht.
Diesen Eintrag sollte man aber nicht selbst setzen, das macht computeClientArray.
Wenn man Clients/MatchList aendert, dann muss man .clientArray entfernen, dann wird sie neu berechnet.
MQTT2_SERVER und MQTT2_CLIENT machen das, wenn man das clientOrder Attribut setzt.

Zitat von: rudolfkoenig am 19 September 2026, 14:34:37Warum reicht "Show MQTT traffic" nicht?
Vermutlich habe ich etwas ueberlesen.

Die Frage hatte ich hier auch schon an Martin gestellt, warum er der Ansicht ist, dass man per Attribut roh-Nachrichten am MQTT2_DEVICE einschalten können soll und die Antwort wohl auch überlesen.

Mir persönlich "reicht" das Tool auch völlig. Die eigentliche Antwort ist woanders zu finden. Wenn man versucht, Usern zu helfen, und die sind damit überfordert, wenn man das Stichwort in den Raum wirft, muss man erst lange erklären, was man eigentlich haben will, und bekommt dann eventuell doch nur einen Teil. Beispiel: https://forum.fhem.de/index.php?msg=1368906 und vorangegangene Beiträge dazu. Ergo wäre das pendant zu "copy for forum" "set <mqtt2device> utilsLog enable <hh:mm>", und unsere hier diskutierten Tools weisen das IO an, alle ein- und ausgehenden Nachrichten von und an passende Topics für eine gewisse Zeit in ein (IO-bezogenes) log zu schreiben. Der User muss das nur hochladen, und der Helfer/Developer hat dauerhaft Bauteile für eigene Tests und ein (zumindest bezüglich MQTT) vollständiges Bild, was das Gadget so (an)treibt....

---

Ad "help":
Grundsätzlich würde ich weder an der pod/cut Methode etwas ändern, noch statisch (nur) SetExtensions betrachten wollen, wenn, dann sollte man die "erweiterten SetExtensions" mit betrachten. War das so gemeint? Muss auch nochmal in den Code von CUL_HM schauen, da wird -soweit ich mich entsinne - auch eine instanzspezifische (versteckte?) Attributliste gepflegt. Allerding ist mir die Vermischung von Attributen und set-Kommandos etwas suspekt hinsichtlich unerwünschter Nebenwirkungen; manche User sind ja recht kreativ...

!grep($as, ...grep bekommt hier keinen Vergleich. edit: Trägt sich ein Fremdmodul zuerst ein, wird AttrTemplate_Set nie ergänzt.
War es so gemeint:
!grep($_ eq $as, ...

Danke fuer den Hinweis.
Es sollte /$as/ sein, ich dachte man kann es auch einfacher schreiben.

ZitatAls Absicherung in `fhem.pl` würde ein `next if(!$modules{$m}{ParseFn});` in der Dispatch-Schleife genügen, unabhängig davon, wer den Eintrag erzeugt hat.

Könntest du dich bitte damit noch beschäftigen und dazu deine Meinung teilen?

@TomLee:
Ich fuerchte, ich verstehe das Problem noch nicht.
Kannst Du mir was zum Nachstellen beschreiben?

ZitatGefährlich ist erst der **zwischengespeicherte** Array, der beim Setzen von `clientOrder` nicht neu berechnet wird.

Wer clientOrder aendert, der muss .clientArray entfernen.

ZitatKannst Du mir was zum Nachstellen beschreiben?

Mich beschäftigen momentan eigentlich andere Dinge, aber auch das Thema hier finde ich jetzt interessant.

Werd ich die Tage versuchen.

---

ZitatWer clientOrder aendert, der muss .clientArray entfernen.

Wie entsteht das  Array neu?
Das beschäftigt mich gerade, obwohl ich mich bisher noch gar nicht weiter mit dem Thema auseinandergesetzt habe. 😅

ZitatWie entsteht das  Array neu?

In computeClientArray, aufgerufen in Dispatch.

Zitat von: rudolfkoenig am 18 September 2026, 12:57:20

Zitatb) Ich hatte gestern ein paar harte Abstürze beim Versuch, "reload MQTT2_DEVICE" abzusetzen.

Da hat wer in den Clients Eintrag eines Moduls, was Nachrichten per Dispatch verteilt, Muell eingebaut.
Ich tippe auf MQTT2_DISCOVERY, da wird oefters das clientOrder Attribut des IODevs gesetzt.
MQTT2_CLIENT/MQTT2_SERVER pruefen nicht beim Setzen des Attributes, ob der Inhalt wenigstens Formal korrekt ist, das koennte ich noch einbauen.

Theorie:

Nachstellen, ohne .clientArray anzufassen:

1. Modul nehmen, das in clientOrder steht, hier MQTT2_DISCOVERY.
2. In dessen Initialize $hash->{Match} und $hash->{ParseFn} verschreiben, etwa Mtach und PraseFn. Datei bleibt syntaktisch gültig.
3. reload 10_MQTT2_DISCOVERY  meldet keinen Fehler. Danach sind beide Einträge undef, .clientArray enthält den Modulnamen weiter.
4. Irgendeine MQTT-Nachricht schicken.

PERL WARNING: Use of uninitialized value in regexp compilation at fhem.pl line 4195.
Can't use an undefined value as a subroutine reference at fhem.pl line 4203.
FHEM beendet sich. Dasselbe passiert mit nur verschriebenem ParseFn, dann kommt nur Zeile 4203.

Der Cache ist dabei nicht schuld: CommandReload ersetzt den Moduleintrag durch das, was Initialize gefüllt hat, und computeClientArray prüft nur auf Match. Ein Tippfehler beim Bearbeiten eines Client-Moduls reicht also, um FHEM zu beenden. next if(!$modules{$m}{ParseFn}); in der Schleife wäre eine Möglichkeit.

Ich stell jetzt mal saublöd die Frage

Was wollt ihr eigentlich? (wertbefreit das Ziel des Ganzen?)

Und zitiere den ersten Treffer zu mqtt Discovery in Google.

,,MQTT Discovery allows smart home systems like Home Assistant MQTT Integration to automatically detect and set up devices without manual YAML coding"

Ich will jetzt nicht vom 5. Rad am Wagen sprechen, bemerke aber das wir die Verwirrung an anderer Stelle schon haben. (Mqtt <-> Mqtt2)
War der Meinung, das Problem ist mit autocreate und den Templates erschlagen.
Das Discovery in HA in allen Ehren (ich nutz HA nicht) die vollkommene atomisierung, und jeder spuckt in den Topf hat mir nicht geschmeckt.
Will Fhem DAU freundlich werden wie HA, könnte es etwas HA vertragen. (Wegen mir nicht, wegen useability schon)


Und nun zurück zum Thema

Baut des Discovery als fallback oder primär ins autocreate ein. Eine Entmündigung des User ird zu dummen fragen führen, in wie weit man den Löffel dem User in den Mund steckt, schlucken muß er selber

MQTT2_DISCOVERY ist ja gerade so gebaut, dass es nichts vorschreibt. Wir diskutieren hier u.a., ob man das noch einfacher halten kann für diejenigen, die mit setlist/readinglist Definitionen überfordert sind. Wenn man alles nur noch über MQTT2_DISCOVERY laufen lässt, dann sind die Angaben in reading/setlist halt nicht so entscheidend. Wichtig ist vielmehr, dass man problemlos es anpassen kann, wenn man andere Vorstellungen hat. Ich selbst nutz nur noch Discovery. Ich bin jetzt erstmal dabei die Fehler glatt zu ziehen.

Zitat von: Guybrush am 21 September 2026, 17:54:29Wir diskutieren hier u.a., ob man das noch einfacher halten kann für diejenigen, die mit setlist/readinglist Definitionen überfordert sind.

Mir geht es weniger um Überforderung, sondern um Effizienz und Eleganz. Immer wieder denselben redundanten Code an den compiler zur Laufzeit zu übergeben, ist für einige wenige Devices "das Problem erschlagen", aber eben nicht unbedingt übersichtlich, und schon gleich nicht effizient.

Zitat von: DasQ am 21 September 2026, 14:10:52Ich will jetzt nicht vom 5. Rad am Wagen sprechen, bemerke aber das wir die Verwirrung an anderer Stelle schon haben. (Mqtt <-> Mqtt2)

Mein persönliches Ziel wäre, meine zigbee2mqtt-Welt neu zu strukturieren, und ich hatte vor Martins Anstoß zu diesem Thread bereits einige Zeit daran rumüberlegt, wie man manche Einschränkungen aus der bisherigen Welt denn wohl am besten überwinden könnte. Sonst wäre ich (Hobbyist!) vermutlich auch nicht auf den Gedanken gekommen, wie man das "discovery" (das mir in seiner gefühlten non-Persistenz der Daten bei Homeassistant ebenfalls befremdlich vorkommt) mit Martins Ansätzen so kombinieren könnte, dass man am Ende sehr viel schneller das hat, was man mit attrTemplate zwar auch bekommt, aber eben ohne zentrale Verwaltung der Funktionalität.

Wenn man es "richtig" macht, ist der "MQTT2_Utils-Weg" (wie ich ihn mir im Moment vorstelle) übrigens sehr viel schneller erklärt wie attrTemplate und die dortigen Auswahlmöglichkeiten, und es sollte auch möglich sein, mehr Hilfe für Helfer anzubieten.

Das ganze immer mit der Option, das Beste aus allen Welten so zusammenzustellen, wie der User das am Ende haben mag.

Das hat wenig mit Bevormundung zu tun, sondern eher mit einer besseren Benutzerführung, auch und gerade hin zu "fhemischeren" Devices wie denen, die "DISCOVERY" im Moment bietet.

Ad "fhemisch" und der Frage, welche "Namensgebung" denn für Readings sinnvoll ist: https://forum.fhem.de/index.php?topic=117933.0 und https://wiki.fhem.de/wiki/DevelopmentGuidelinesReadings

Die Fehler im Modul, die hier thematisiert wurden, habe ich gefixed. Ist alles im neuen DEV Build auf Github enthalten. Das Problem mit dem .clientArray betrifft das Modul selbst nicht. Das müsste in fhem selbst gehärtet werden.

Wegen des Vorschlags das Modul zu erweitern hab ich aber inzwischen bedenken, dass direkt in MQTT2_DISCOVERY abzubilden. Das würde dann nämlich immer eine zusätzliche Abhängigkeit neben MQTT2_DEVICE bedeuten. Ich halte es für besser, wenn die Laufzeitintegration in MQTT2_DEVICE erfolgen würde. Dafür würde ich in MQTT2_DEVICE eine Schnittstelle integrieren, z.b.:

MQTT2_DEVICE_SetBindings($deviceHash,'mqtt2Discovery',$descriptor);
MQTT2_DEVICE_DeleteBindings($deviceHash, 'mqtt2Discovery');
MQTT2_DEVICE_GetBindings($deviceHash, 'mqtt2Discovery');
MQTT2_DEVICE_ValidateBindings($descriptor);

mqtt2Discovery wäre in dem Fall nur der Owner, um die von Discovery erzeugten Teile ersetzen oder entfernen zu können. MQTT2_DEVICE führt das anschließend alles intern selbst aus. Das hätte den großen Vorteil, dass ein laufendes FHEM keine Abhängigkeit von MQTT2_DISCOVERY hätte und das das Modul - so wie ursprünglich auch angedacht - nur für das Anlegen der Devices anhand der Discovery Topics zuständig bleibt. Dabei müssten dann manuell gesetzte setList/readingList Regeln im MQTT2_DEVICE Device die generierten Bindings überschreiben können. Die müssten dann aber tatsächlich nicht mehr befüllt werden, da MQTT2_DISCOVERY die oben genannten Schnittstellen von MQTT2_DEVICE aufrufen kann (optional per Attribut zu deaktiveren). Das bedingt dann zwar MQTT2_DEVICE als Abhängigkeit, aber ich find die Abhängigkeit bei MQTT2_DISCOVERY von MQTT2_DEVICE nicht kritisch. Andersrum wärs jedenfalls problematischer. So mal als Idee zum weiter diskutieren...

Leider habe ich das mit den Abhängigkeiten selbst nach mehrfachem Lesen immer noch nicht verstanden.

So oder so: MQTT2_DEVICE wird imo doch immer geladen, egal, ob MQTT2_(DISCOVERY|Utils) geladen wird oder nicht. Und unabhängig davon, wie man den Aufruf der Funktionen aus letzterem technisch umsetzt: Es kann nichts sinnvoll ausgeführt werden, wenn nicht am Ende beide Module geladen sind. Was übersehe ich?

Zum Ablauf: irgendwas erst per Attribut in jedem Einzelfall aktivieren zu müssen, was man mit der Entscheidung für eine bestimmte Technik (= define von MQTT2_(DISCOVERY|Utils)) allgemein entschieden hat, halte ich für wider die Erwartung des Konfigurators.

Die eigentlichen Probleme liegen imo woanders:
- Wer pflegt welche Teile des Codes?
- Wer "entscheidet" über defaults und "gute Praxis"?
- Wie verstetigt man das, wenn es (noch) keine discovery-Meldungen gab?

Das wird man ernsthaft diskutieren müssen.

Zitat von: Beta-User am 23 September 2026, 07:26:38So oder so: MQTT2_DEVICE wird imo doch immer geladen, egal, ob MQTT2_(DISCOVERY|Utils) geladen wird oder nicht. Und unabhängig davon, wie man den Aufruf der Funktionen aus letzterem technisch umsetzt: Es kann nichts sinnvoll ausgeführt werden, wenn nicht am Ende beide Module geladen sind. Was übersehe ich?

Genau das sind meine Bedenken. Die zusätzliche Abhängigkeit von MQTT2_DISCOVERY. Thematisch gehört das meiner meinung nach in MQTT2_DEVICE. Das muss eh geladen sein und funktionieren und das was da passiert betrifft auch dessen namespace. MQTT2_DISCOVERY kann die Funktionen dort ja aufrufen zum anlegen. Die Verarbeitung usw sollte aber im Modul selbst bleiben. MQTT2_DEVICE wird ja ohnehin benötigt, wenn man das device öffnet und es wäre meiner Meinung nach nicht gut, wenn aus dem Modul eine Funktion aus einem anderen Modul zur Laufzeit aufgerufen werden muss. Es gibt jedenfalls keinen Grund es in DISCOVERY zu integrieren. Je mehr Abhängigkeiten es gibt umso eher treten Fehler auf.

Zitat von: Beta-User am 23 September 2026, 07:26:38Zum Ablauf: irgendwas erst per Attribut in jedem Einzelfall aktivieren zu müssen, was man mit der Entscheidung für eine bestimmte Technik (= define von MQTT2_(DISCOVERY|Utils)) allgemein entschieden hat, halte ich für wider die Erwartung des Konfigurators.

Deswegen ja per Attribut abschaltbar, nicht anschaltbar ;) Ich bin kein Freund von Legacy Code, aber wenn etwas so lange standard war geht es nicht anders, wenn man alle mitnehmen möchte.

Zitat von: Beta-User am 23 September 2026, 07:26:38Die eigentlichen Probleme liegen imo woanders:
- Wer pflegt welche Teile des Codes?
- Wer "entscheidet" über defaults und "gute Praxis"?
- Wie verstetigt man das, wenn es (noch) keine discovery-Meldungen gab?

DISCOVERY mach ich ja auf absehbare Zeit auf jeden Fall weiter. Wenn das rund ist wird es da auch nicht mehr so viel Pflege benötigen. Die Schnittstelle in MQTT2_DEVICE (oder auch woanders, wenn das da nicht rein soll) müsste man halt schauen. Ich will das gerade nicht leisten. Ich hab noch ein paar andere Sachen, die ich erst fertig machen will. Discovery Messages werden default von den allermeisten devices als retain verschickt. Dafür ist das auch da. Es gibt dummerweise Konfigurationen, wo man das retained flag deaktivieren kann. Auch haben sicherlich einige FHEM User die Discovery Topics auf ihren Devices deaktiviert. So hatte ich das früher auch, weil die ständig FHEM zugemüllt haben. Das muss natürlich mit DISCOVERY rückgängig gemacht werden. DISCOVERY verschluckt/filtert die, so dass diese kein "Problem" mehr darstellen. Am Ende ist der sicherste Weg, dass nach AKtivierung von DISCOVERY jedes MQTT fähige device einmal geprüft wird, dass discovery aktiviert ist und dann restartet wird. Solang solche Devices nicht verändert wurden, sollte das beim Start von FHEM aber automatisch aus dessen retained cache abgeholt und verarbeitet werden.

Losgelöst davon fänd ich es aber gut, wenn man mal einen Standard verbindlich(!) vorgeben würde. Mir ging es auch oft genug so, dass ich kreativ sein musste, weil ich mir mangels Verbindlichkeit was ausdenken durfte. Damit meine ich nicht, dass Module nicht mehr lauffähig sein sollen, wenn sie sich nicht daran halten. Aber dass man diese dann z.b. als validiert anzeigt, was dann hoffentlich Motiviation genug ist für Entwickler ihr Modul entsprechend anzupassen. Dafür müssen ja ansich nur die Rückgabewerte der Standardfunktionen passen. Das könnte man gut mit Perl Test2::V0 abbilden, so dass es einen Test geben könnte, der ein Modul daraufhin testet. Wird ja leider ohnehin von den wenigsten verwendet, dabei hilft das ungemein verborgene Fehler zu finden.

Zitat von: Guybrush am 23 September 2026, 09:40:26Ich will das gerade nicht leisten.

Das ist eine faire Ansage, und imo auch völlig verständlich.

Dementsprechend kann es hier auch "nur" darum gehen, das Feld abzustecken und ggf. zu klären, wie man die Puzzleteile überhaupt zuschneiden könnte, und wer welche Teile beisteuern könnte und (v.a.!) möchte, und ggf. auch den Kopf dafür hinhält.

Rudi hat die Voraussetzungen dafür geschaffen, dass man im Prinzip beide "Plugins" (MQTT2_DISCOVERY und MQTT2_Utils ohne diese Funktionalität (?)) trennen könnte, von letzterem ggf. auch nur den Teil, der nicht (so oder so?) nach MQTT2_DEVICE "sollte". Imo hätte eine Auftrennung allerdings mehrere Nachteile, angefangen damit, dass der geneigte User vermutlich nicht versteht, warum er überhaupt mehrere braucht...

Zitat von: Guybrush am 23 September 2026, 09:40:26Genau das sind meine Bedenken. Die zusätzliche Abhängigkeit von MQTT2_DISCOVERY.

Sorry, ich verstehe die Bedenken immer noch nicht:
Entweder, man verwendet MQTT2_DEVICE "pur". Dann können auch im bisherigen Modell keine Funktionen aus MQTT2_DISCOVERY aufgerufen werden, obwohl sie in setList/readingList verdrahtet sind, wenn dieses weitere Modul nicht geladen ist.
Welchen Unterschied macht das dazu, dass MQTT2_(DISCOVERY|Utils) sich vor SetExtensions registriert bzw. die eingehenden messages parst, außer, dass andere "geht-nicht"-Rückmeldungen für set-Kommandos kommen bzw. eventuell andere Readings (bzw. "geht-nicht"-Rückmeldungen für set-Kommandos) entstehen, wenn autocreate noch aktiv ist und eingehender traffic wider Erwarten nicht (vorher dort) verarbeitet wird.

Zitat von: Guybrush am 23 September 2026, 09:40:26Deswegen ja per Attribut abschaltbar, nicht anschaltbar ;) Ich bin kein Freund von Legacy Code, aber wenn etwas so lange standard war geht es nicht anders, wenn man alle mitnehmen möchte.

Imo ist es eine Frage der Sichtweise: MQTT2_DEVICE in der heutigen Form (ggf. mit kleinen "Extras") darf gerne weiter das "allgemeine Arbeitspferd" bleiben für alle Anwendungsfälle, in denen "wir" keine sinnvolle Automatik anbieten können und/oder die Zahl der Duplizierungen gering wäre, oder der User das schlicht nicht möchte. Das "fancy aufzubohren" und die User mit neuer unerwarteten Automatiken zu "beglücken", hielte ich für einen großen Fehler.

Zitat von: Guybrush am 23 September 2026, 09:40:26Losgelöst davon fänd ich es aber gut, wenn man mal einen Standard verbindlich(!) vorgeben würde.

FHEM ist "irgendwie basisdemokratisch" organisiert, ich sehe (leider?) keinen, der dazu willens oder in der Lage wäre, und anscheinend sind z.B. aktuell auch meine (mehrfach direkt oder indirekt zitierten) Argumente für "on/off" für den Hauptkanal nicht ausreichend, um dich davon zu überzeugen, dass es eine gute Idee wäre, den Aufwand zu treiben (Du kannst ja "legacy" auch deine Kommandos "on the fly" weiter zulassen!).

Was Testen und Code-Standards an sich angeht, wäre das übrigens ein wirklich großes Projekt, in dem man das alles auch an eventuelle Mitmacher vermitteln könnte ;) . Und zwar, ohne alles selber machen zu müssen :) .

Wie könnte man also vorgehen?
Alleine habe ich vermutlich nicht die Zeit, "MQTT2_Utils" anzugehen, obwohl mir das im Moment nicht als soooo furchtbar viel Aufwand vorkommt. Das wäre dann so zu basteln, dass die Vorarbeit, die in MQTT2_DISCOVERY und der Dikussion hier steckt, (erst mal ohne dessen eigentlicher Kernaufgabe) ǘbernommen werden kann, also die "Standardparser" für die jeweilige Gadget-Familie.

Beginnen würde ich mit zigbee2mqtt, das scheint Guybrush nicht im Einsatz zu haben.

@TomLee: Interesse, das eine oder andere zu prompten, und mit zu überlegen und zu testen?
Die Idee dabei wäre (auch), eventuell dann in den attrTemplate das eine oder andere (dazu passend) aufzuräumen, gerade der z2m-Teil kommt mir nicht in allen Details gut strukturiert vor. Das wäre aber eher eine (automatisierbarer?) Nebenaspekt...

Auf so ein Abenteuer mit Dir würde ich mich gerne mal wieder einlassen, da gäbe es für den einen oder anderen bestimmt auch wieder mal was zu knabbern.

Ich habe mich die Tage mit allen angesprochenen Punkten beschäftigt und ins  ::)  Modul einbauen lassen.
Jetzt einfach mal einen Cut gemacht und so, wie der Stand halt ist, gepusht:

Das mit dem Bauen lassen hat halt seine Grenzen, wenn man zu wenig Hintergrund hat.
Ich verzettele mich jetzt schon hier und da, darum wäre es cool, wenn Du über meine Bastelei mal drüberschaust und mir sagst, ob die Kryptanalyse bisher die gewünschte war und ob sich die Bausteine daraus in ein neues Modul einbauen lassen.

Getestet habe ich nur mit dem Shelly Mini und einem Tasmota-Stecker, einmal als Ein- und einmal als Zweikanaler.
Mit z2m zu beschäftigen hat es bisher nicht gereicht.

Was dazugekommen ist, steht im Anhang anleitung-neue-funktionen.md, die neuen Setter und Getter, der Schlüsselraum mit seinen Ebenen und Vorgaben, die Sache mit lwt und availability und die Kanalaufteilung.
Das Kurze davon: Mit den Vorgaben steht am Zielgerät weder readingList noch setList.
Das Modul wertet die Nutzdaten in seiner ParseFn selbst aus und bietet die Schaltbefehle über die SetExtensions-Kette an. Wer die Attributzeilen will, bekommt sie weiter, über den Schlüsselraum, je Gerät, je Familie oder global.

An 10_MQTT2_DEVICE.pm oder einem anderen Kernmodul ist nichts geändert.

Zum Nachvollziehen bei Dir hängen dran:

- mqtt2_discovery_dateien.tar.gz - 10_MQTT2_DISCOVERY.pm plus die 15 Dateien
  unter lib/FHEM/MQTT2_Discovery/. Die Moduldatei allein reicht nicht.
- payloads-tasmota-1kanal.txt,payloads-tasmota-2kanal.txt und payloads-shelly-mini-gen3.txt, die
  Discovery-Nachrichten meiner beiden Testgeräte, so wie sie get <name>
  payloads <device> ausgibt. Mit set <name> replayPayloads
  (im Dialogfeld einfügen) entstehen die Geräte bei Dir, ohne dass Du die
  Hardware brauchst. Geschwärzt sind Passwörter, Hostname, SSID und Adressen;
  Topics und Kennungen stehen drin, sonst beschreibt der Block nicht mehr
  dasselbe Gerät.


Der Rest ist im Repo dokumentiert: README.md für die Bedienung, docs/canonical-model.md für das Modell zwischen Adapter und Mapper, das ist die Stelle, die für einen eigenen Standardparser interessant wäre und docs/mqtt2-device-hook.md für den Set-Pfad samt der zwei Fallen, die in SE_Next stecken.

Die Tests laufen ohne FHEM-Installation: `prove -l tests`, 580 Stück, in der CI auf Perl 5.16 bis 5.42 mit warnings=FATAL.

Zitat von: Beta-User am 25 September 2026, 08:06:28Beginnen würde ich mit zigbee2mqtt, das scheint Guybrush nicht im Einsatz zu haben.

ich hab das bei mir am laufen und das funktioniert auch mit zigbee2mqtt.


Bzgl. der hier diskutierten Erweiterungen - ich möchte die nicht in MQTT2_DISCOVERY drin haben. Das kann ich - so wie es konzipiert war - auch in zukunft supporten und maintainen. Wenn da jetzt mit Agenten irgendwelche Codeerweiterungen passieren bin ich da aber raus. Das übersteigt die mir zur Verfügung stehende Zeit, die ich für sowas aufbringen möchte. Zumal noch einiges im Modul selbst fehlt was ich integrieren will, da weder Jinja komplett unterstützt ist noch alle Backends drin sind, die relevant sein könnten.

Wir sollten sowas wirklich dann in einem seperaten Modul umsetzen - oder am besten direkt in MQTT2_DEVICE, wo es meiner meinung nach thematisch auch richtig aufgehoben wäre. Von mir aus kann man auch ein Meta Modul drüber setzen. Aber es muss wartbar bleiben. Ich find die Idee ansich wirklich gut und würde die Funktionalität in Form von API Calls auch integrieren. Ich will nur nicht noch mehr Code vortragen, der nicht unmittelbar was mit der Verarbeitung von discovery messages zu tun hat. Ich würde aber auch schauen wollen, ob man sowas nicht globaler hinbekommt, also ohne es nur auf MQTT zu beschränken.

Zitat von: Guybrush am 25 September 2026, 21:06:03Ich würde aber auch schauen wollen, ob man sowas nicht globaler hinbekommt, also ohne es nur auf MQTT zu beschränken.

Dazu ein kurzer Aufriss zu meinen bisherigen Überlegungen und Experimenten in diese Richtung:
- eventMap
Kommt mir immer wie (unverstandene) Kosmetik vor. Ich persönlich mag es nicht, weil Events und "nachlesbare Inhalte" (Reading-Werte) auseinanderfallen. Und nach meinen Erfahrungen hat kaum ein User auch nur eine Idee davon, dass das mehrere Dimensionen hat (in der commandref unter "explizite Variante dieses Attributes" zu finden). Meine Meinung: Attribute, die der User selbst korrekt und in jedem Einzefall auf seinen Anwendungsfall anpassen muss, helfen uns letztlich nicht weiter.
Lasse mich aber gerne vom Gegenteil überzeugen.

-readingsChange
Denn meisten komplett unbekannt (https://fhem.de/stats/statistics.html kennt 46 Installationen, auf denen das läuft), aber an sich ein super Ansatz, der aber imo zwei wesentliche Nachteile hat:
1. Man braucht Events. Das ist hinderlich, wenn man "einfach nur" den batteryVoltage-Wert eines zigbee2mqtt-Gadgets auf "standardkonforme" Volt (statt mV) umbiegen will. Und man braucht natürlich eine passende Regex, um mit einem readingsChange alle Anwendungsfälle zu erschlagen.
2. Damit (auch) irgendwelche Umbenennungen der Readings vorzunehmen, war eine Herausforderung, an der ich mir so lange die Zähne ausgebissen habe, bis ich die Lust daran verloren habe. Wer die Quelle dazu sucht: https://forum.fhem.de/index.php?topic=124068.0

- readingsProxy
Ist für "channels" am ehesten das, was heute an funktionierenden Lösungen existiert. Mal abgesehen davon, dass die jüngsten (an sich positiven) Erweiterungen für mehrere Devices und (v.a.) mehrere Readings noch in Teilen "kaputt" sind (Zusammenfassung: https://forum.fhem.de/index.php?msg=1368027) und ich noch nicht dazu gekommen bin, die automatisierte Generierung von set-Funktionen für "typische Anwendungsfälle" anzugehen, bleibt der große Pferdefuß auch dieses Moduls, dass es an die Event-Verarbeitung angekoppelt ist.

- readingsGroup
Nun ja, man hat damit alle Möglichkeiten in der FHEMWEB-orientierten Darstellung, aber es geht ja hier v.a. um Automatisierung, oder?

Damit kommen wir zu noch einem Stummel:
- subDeviceProxy
https://forum.fhem.de/index.php?topic=141647.0
Der Thread ist nicht besonders lang, und bisher hat sich kein weiterer Developer für die Weiterentwicklung zu einem allgemeinen Ansatz interessiert. Von der Ausrichtung her muss man auch da was konfigurieren, von daher ist der (neue, vereinfachte) Ansatz bei readingsProxy der einfacher zu vermittelnde, wenn es nicht grade um "Großdevices" wie das vitoconnect-Ding geht. Da bekomme ich das aber zumindest für mich anders (aber im Plfegeaufwand (zu) aufwändig...) gelöst.

Am Ende lande ich immer wieder bei der Feststellung, dass es immer noch die beste Lösung ist, direkt im jeweiligen Modul für die korrekte Funktionalität (im bereits aufgezeigten Sinne von "normalen FHEM-Devices") zu sorgen, und MQTT ist wegen des "Wildwuchses" von außen noch dazu "der" prädestinierte Kandidat, zumal wir ja sowieso fast immer Perl-Funktionen aufrufen, um ein- und ausgehenden traffic zu analsysieren bzw. zu generieren.

Zitat von: Guybrush am 25 September 2026, 21:06:03Aber es muss wartbar bleiben.

Das ist in der Tat ein echtes Problem. Kurz bevor TomLee hier gepostet hat, war ich grade dabei, den Code von RHASSPY auszuschlachten, um ein für mich wartbares Grundgerüst für ein "MQTT2_Utils"-Modul zu haben.  In dem Zug habe ich dann immer wieder auch in deinen Code des eigentlichen Moduls geschaut, und dabei mit Bedauern festgestellt, dass ich mit hoher Wahrscheinlichkeit nicht in der Lage bin, diesen Code so zu verstehen, dass ich guten Gewissens dafür support anbieten könnte; und ich glaube leider jedenfalls derzeit auch nicht daran, dass ich dazu mittelfristig in der Lage sein werde, und in dem Fall ist das weniger eine Zeitfrage (die ich zudem auch nicht im notwendigen Umfang hätte) :( . Mit den unter ./lib/FHEM/MQTT2_Discovery zu findenden Teilen sieht es etwas besser aus, aber das alleine hilft nur bedingt weiter...

Wie dem auch sei, anbei zur Info für diejenigen, die das eventuell interessiert, mein gestriger (explizit nicht lauffähiger!!!) Zwischenstand der Ausschlachtung, bis ca. Zeile 233 war ich im Schnelldurchlauf gekommen, um dann festzustellen, dass %sets wohl zu teilen wäre in %sets (für die Utils selbst) und %setsClients (für eine Art "allgemeiner" Rückmeldung aus SetExtensionsFn())...

---

Kurz noch eine Anmerkung, warum es mir nach wie vor sehr wichtig erscheint, die eingehenden Daten gleich beim Eingang zu "fhemisieren": ZigBee lief bei mir zuerst versuchsweise mit zigbee2mqtt. Aus irgendeinem Grund, an den ich mich grade nicht erinnere, hatte ich das aber vor Jahren dann umgestellt auf deconz/HUE(Bridge|Device), bevor der Großteil der heutigen Hardware dazukam.
Vor einiger Zeit habe ich dann wieder zurück auf zigbee2mqtt umgestellt und "kämpfe" hin und wieder immer noch mit den Nachwirkungen, weil die Funktionalität einfach schlicht und ergreifend nicht vollständig kompatibel ist. Besonders "hart" war, dass die Semantik komplett anders ist, und das verleidet mir den Umstieg immer noch etwas :'( , obwohl es prinzipiell "richtig" war.

---

Wie nun weiter:
Wir sollten versuchen, dass sich die Modulfunktionalitäten nicht überschneiden oder gar ernsthaft widersprechen, so dass man ggf. sowohl das eine wie das andere verwenden kann.
Ansonsten muss ich mir den Code in seinen verschiedenen Varianten mal in Ruhe ansehen. Prinzipiell müßte es doch so sein, dass z.B. für die Generierung von publish-Anweisungen für Shelly-rpc derselbe Code verwendet werden könnte, man den aber eventuell anders gliedern müßte oder könnte?
Also sowas wie ein gemeinsames "./lib/FHEM/MQTT2"? Und darunter dann "Discovery" und "Utils"? Ist aber ausdrücklich nur sowas wie eine vage und vermutlich unausgegorene Idee!

@TomLee:
Erst mal vielen Dank!!!
Ich hoffe, morgen im Lauf des Tages dazu zu kommen, das mal auf einem Testsystem auspacken zu können und in Ruhe einen Blick in das Paket haben zu können, heute ist eher keine Zeit mehr, und morgen auch schon eher eng... Dazu wollte ich eigentlich endlich mal readingsProxy fixen und eventuell erweitern, das hätte eigentlich Prio, wird es aber wieder nicht reichen....

ich habe das beim Modul stark modularisiert. Jedes Backend ist da sauber gekapselt und die backends normalisieren ausschließlich die daten. Alles andere wird einheitlich ohne redundanten Code verarbeitet. Jinja Template Support liegt dadrüber usw. So sollte man das auch mit einem globaleren Modul halten. Ich würde das aber nicht auf MQTT beschränken, sondern schauen, dass wir damit anfangen und dann jeder Modulentwickler sein eigenes backend hinterlegen kann oder man es für die häufig genutzten auch direkt selbst umsetzt, wie zb für KNXIO.

Zigbee2Mqtt ist leider teilweise etwas eigensinnig bei der Umsetzung von MQTT. Ich hab meinen Code übrigens echt großzügig inline kommentiert. Was fehlte dir denn da fürs Verständnis?

Nun, es freut mich, dass mein Beitrag eine so rege Diskussion angeregt hat. Ich komme mit dem Lesen kaum nach (habe einiges nur überflogen).

ZitatIch stell jetzt mal saublöd die Frage
Was wollt ihr eigentlich? (wertbefreit das Ziel des Ganzen?)

genau das kann ich aktuell nicht wirklich erkennen. Wenn ich etwas für mich mache kläre ich die Requirements mit mir ab und prüfen nach meinen Masstäben. Diese habe ich rudimentär dargelegt.
Bei der Menge an Mitarbeitern bietet es sich an, Ziele in einem Dokument festzuhalten. Das macht weniger Spass, ist am Ende aber hilfreich. Erst einmal zu codieren und dann zu schauen, was es geworden ist um noch etwas zu tunen ist verbreitet.. aber...
https://scheissprojekt.de/hausbau.html

Ich erzähle man von meinen "internen Richtlinien"
- performance ist wichtig - Operational. Im Setup und bei der Config sind die Weichen zu stellen  - Performance spielt hier keine Rolle, "hashes " sollten erstellt werden
- das Dogma "Attribute ändert nur der User" sehe ich als Richtschnur. Der Programierer muss dies überwachen, einschreiten, korrigieren wenn Blödsinn passiert. ggf auch korrigieren. Ich sehe kein Problem darin
- Das Webfrontend sollte immer lesbar bleiben. Damit sind überlange Zeilen/Einträge "nicht tragbar". Dies gilt für attribute sowie readings(hier kann man nur bedingt eingreifen)
- globale Kommandos im Frontend vermisse ich - wie "set delete reading" oder "get list". Das gilt insbesondere für "hidden" Informationen. Mein "SystemAddOn" baut in JEDE Entity diese Kommandos zusätzlich ein
- Die Syntax der Kommandos muss vollständig und einfach dokumentiert sein. Mein SystemAddOn beschreibt jedes Kommando systaktisch komplett, prüft die Eingaben dagegen, gibt die Kommandoliste aus, beschreibt optiopnale/default/drop-downs vollständig. Ja, der Programmierer muss die Syntax beschreiben - dafür bekommt er einen Parser und der Anwender wichtige Infos.
- es muss immer hinreichend "get infos" zum device geben, so zum Model, wie den Funktionen - aber nicht in überlangen Attributen
- es muss bei MQTT einen Eval-Mode geben welcher die Messages aufzeichnet, damit der Anwender ein eigenes Template erstellen kann.
- das Erstellen des Templates muss dokumentiert sein - und in lesbarer Form abgelegt werden - und bei Bedarf ausgegeben/dargestellt. Immer notwendig ist ein kurzer Kommentar, auf was dies anzuwenden ist (die HW bspw).
- Für mich unumgänglich ist die Option, Devices nach Kanälen aufzusplitten. Dei daraus folgenden Abhängigkeiten müssen programmiert werden. Bspw ist eine "alive" oder "Reachable" Funktion für mich zu 100% gesetzt ( das fehlt mir aktuell noch). Alive wird (logisch) immer vom Device abgeleitet. Ein "dead" (oder unreachable) muss Auswirkungen auf alle Kanal-Entites haben, den diese sind immer "uncertain".
- nach dem Reboot oder der Wiederkehr müssen immer alle Zustände der Devices abgefragt werden (nichts schlimmer als falsche Zustände!!! was soll den dass)
- Jede Entities muss auf dem Laufenden gehalten werden, was die Konfiguration der verbundenen Entites angeht (notify global attr/delete/define/rename,...)
- ein "related to" was den Namen wert ist muss es geben (nun, mal raten - mein SystenAddOn hat ein "get fellows"2 stufing in beide richtungen implementiert, nach oben und nach unten
- Templates müssen parametrierbar sein und kein Coding erfordern - sagen wir zu 90%.
- referenzieren geht klar vor kopieren - gilt auch für Templates
- weniger Freiheit des Anwenders ist oft mehr. Wenn man ein guten Konzept hat ist es nicht notwendig, dass der Anwender jeden I-Punkt umgestalten kann. Die meisten werden danken, glaube ich.


Das ist nun nicht schön zusammengeschrieben, einfach einmal so dahin geblubert. Ich sehe, dass es doch Interessenden gibt - mir ist allerdings nicht klar, ob wir auf einer Wellenlänge sind.
Eines meiner - wie ich finde - gelungenen "Anpassungen" ist DB-Log. Das war für mich faktisch unbedienbar - da ich am Sofa keine SQL Kommandos in mein Tablet hacke. Die Optionen zum Filtern -  positiv + negativ + zustandsabhängig waren unübersichtlich, unperformat und haben systematische Einordnung verhindert. Mein "lead-DB-Addon" kapert ein paar routinen, eliminiert ein paar Attribute und stellt die (m.E.) sinnvollen kommandos gänzlich ohne SQL zu Verfügung. get last X logs of entity by regexp, readingByRegexp. oder gleiches für den letzten Zeitraum X. Oder eine tabelarische Statistik über die Anzahl der Einträge (um Labertaschen zu finden). Also immer an die Maintenance denken!
==> genauso effizient will ich MQTT haben.

Ich habe nun 5 Rollo-steuerungen implementiert nachdem ich das Template erstellt hatte.
So sehen nun die Readings zu meine Device aus (aktuell)
IODev                   mttqIO          2026-09-27 20:04:40
cfgState                initialized     2026-09-27 20:04:45
rpc_method              NotifyStatus    2026-09-28 20:37:00
sys_reset_reason        deviceButton    2026-09-28 20:08:03
sys_restart_required    false           2026-09-28 20:08:03
sys_uptime              86076           2026-09-28 20:08:03
wifi_rssi               -53             2026-09-27 20:13:35
wifi_sta_ip             192.168.178.104 2026-09-27 20:13:35und so zu einem Kanal
Etotal          106.668     2026-09-28 20:41:01
IODev           mttqIO      2026-09-27 09:54:10
apower          135.8       2026-09-28 19:24:58
cfgState        initialized 2026-09-27 20:00:00
current         0.000       2026-09-27 20:13:35
freq            50.0        2026-09-27 20:13:35
lastDir         close       2026-09-28 20:41:01
level           94          2026-09-28 19:24:58
motor           stopped     2026-09-28 20:41:01
pct             94          2026-09-28 19:24:58
pf              0.00        2026-09-27 20:13:35
pos_control     true        2026-09-27 20:13:35
state           94          2026-09-28 19:24:58
temperature     31.3        2026-09-28 20:41:01
trigTast        MQTT        2026-09-28 20:41:01
voltage         235.7       2026-09-28 19:24:57

um einen Eindruck zu vermitteln, was ich als übersichtlich und Userfreindlich empfinde.

Abschliessend - es wäre schön, wenn die Requirement, guidelines und goals schriftlich und am Bestem it guten und schlechten Beispielen schriftlich dargelegt würden.

mein MQTT läuft erst einmal :)

danke für`s back to topic.

btw. haben wir ein eigenes unterforum, wo das ganze besser ausgehoben wär (man nebenbei anmerk)

lg derfaststillemitleser.

p.s.: ich kann hier leider nicht wirklich was beitragen, versuch im ansatz durchzusteigen.
mir hat aber meine erfahrung gelehrt, oft meinen die leute wohl das gleiche, sie drücken sich nur unterschiedlich aus. und telepathie oder gedanken lesen/erwarten hat noch nie funktioniert.

Wenigstens mal eine kurze Wasserstandsmeldung von meiner Seite:

Zitat von: DasQ am 29 September 2026, 09:34:45danke für`s back to topic.

Die Rückmeldung von Martin klang für mich nicht so, als wäre das alles "off topic" gewesen, sondern eher nach "ich habe eine Lösung für mich gefunden, und jetzt kein großes Interesse mehr an Details". Kann mich aber täuschen.

Hier läuft jetzt ein Testsystem mit den Versionen von TomLee. Die ganzen Payloads durchzutesten und/oder mich durch die diversen Code-Varianten zu wühlen hat es nicht gereicht, hier eine kurze Info dazu, wie sich das mit meinem "Testgerät" verhält. Konkret geht es um: https://templates.blakadder.com/maxcio-YX-DE04.html
Also ein 1. "channel" mit einem simplen "ein/aus", und ein mehrfarbiges Licht als 2. channel.

Hier die raw-lists:
efine DVES_EFFE7E MQTT2_DEVICE DVES_EFFE7E
attr DVES_EFFE7E userattr mqttDiscoveryKeys:textField-long
attr DVES_EFFE7E autocreate 0
attr DVES_EFFE7E room MQTT

define Kaffeemaschine_Tasmota2 MQTT2_DEVICE DVES_EFFE7E
attr Kaffeemaschine_Tasmota2 userattr mqttDiscoveryKeys:textField-long
attr Kaffeemaschine_Tasmota2 autocreate 0
attr Kaffeemaschine_Tasmota2 room MQTT
attr Kaffeemaschine_Tasmota2 setList POWER2:on,off cmnd/DVES_EFFE7E/POWER2\
brightness:slider,0,1,100 cmnd/DVES_EFFE7E/Dimmer\
color cmnd/DVES_EFFE7E/Color2\
colorTemp:slider,153,1,500 cmnd/DVES_EFFE7E/CT\
effect:solid,wake_up,cycle_up,cycle_down,random { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_f4fbc911c2dffdd1', $EVENT) }\
white:slider,0,1,100 cmnd/DVES_EFFE7E/White

define m2discover MQTT2_DISCOVERY m2s
attr m2discover room MQTT

define m2s MQTT2_SERVER 1883 global
attr m2s autocreate no
attr m2s clientOrder MQTT2_DISCOVERY MQTT2_DEVICE MQTT_GENERIC_BRIDGE
attr m2s room MQTT

setstate DVES_EFFE7E off
setstate DVES_EFFE7E 2026-10-04 13:35:08 .availability_io online
setstate DVES_EFFE7E 2026-10-04 13:44:51 .availability_policy_27d35044 online
setstate DVES_EFFE7E 2026-10-04 13:44:51 BootCount 43972
setstate DVES_EFFE7E 2026-10-04 13:44:55 Channel_1 43
setstate DVES_EFFE7E 2026-10-04 13:44:55 Channel_2 66
setstate DVES_EFFE7E 2026-10-04 13:44:55 Channel_3 100
setstate DVES_EFFE7E 2026-10-04 13:44:55 Channel_4 0
setstate DVES_EFFE7E 2026-10-04 13:44:55 Color 6EA8FF00
setstate DVES_EFFE7E 2026-10-04 13:44:55 Dimmer 100
setstate DVES_EFFE7E 2026-10-04 13:44:55 Fade off
setstate DVES_EFFE7E 2026-10-04 13:44:51 FallbackTopic cmnd/DVES_EFFE7E_fb/
setstate DVES_EFFE7E 2026-10-04 13:44:51 GroupTopic cmnd/tasmotas/
setstate DVES_EFFE7E 2026-10-04 13:44:55 HSBColor 216,57,100
setstate DVES_EFFE7E 2026-10-04 13:44:55 Heap 27
setstate DVES_EFFE7E 2026-10-04 13:44:55 Hostname DVES-EFFE7E-7806
setstate DVES_EFFE7E 2026-10-04 13:34:54 IODev m2s
setstate DVES_EFFE7E 2026-10-04 13:44:55 IPAddress 192.168.2.30
setstate DVES_EFFE7E 2026-10-04 13:34:58 Info1_FallbackTopic cmnd/DVES_EFFE7E_fb/
setstate DVES_EFFE7E 2026-10-04 13:34:58 Info1_GroupTopic cmnd/tasmotas/
setstate DVES_EFFE7E 2026-10-04 13:34:58 Info1_Module Maxcio YX-DE04
setstate DVES_EFFE7E 2026-10-04 13:34:58 Info1_Version 10.0.0(tasmota)
setstate DVES_EFFE7E 2026-10-04 13:34:58 Info2_Hostname DVES-EFFE7E-7806
setstate DVES_EFFE7E 2026-10-04 13:34:58 Info2_IPAddress 192.168.2.30
setstate DVES_EFFE7E 2026-10-04 13:34:58 Info2_WebServerMode Admin
setstate DVES_EFFE7E 2026-10-04 13:34:58 Info3_RestartReason Software/System restart
setstate DVES_EFFE7E 2026-10-04 13:44:51 LWT Online
setstate DVES_EFFE7E 2026-10-04 13:44:55 LedTable on
setstate DVES_EFFE7E 2026-10-04 13:44:55 LoadAvg 19
setstate DVES_EFFE7E 2026-10-04 13:44:51 Module Maxcio YX-DE04
setstate DVES_EFFE7E 2026-10-04 13:44:55 MqttCount 1
setstate DVES_EFFE7E 2026-10-04 13:44:03 OtaUrl http://ota.tasmota.com/tasmota/release/tasmota-DE.bin
setstate DVES_EFFE7E 2026-10-04 13:44:51 POWER
setstate DVES_EFFE7E 2026-10-04 13:44:55 POWER2 off
setstate DVES_EFFE7E 2026-10-04 13:43:59 PWM_PWM1 0
setstate DVES_EFFE7E 2026-10-04 13:43:59 PWM_PWM2 0
setstate DVES_EFFE7E 2026-10-04 13:43:59 PWM_PWM3 0
setstate DVES_EFFE7E 2026-10-04 13:43:59 PWM_PWM4 0
setstate DVES_EFFE7E 2026-10-04 13:44:51 RestartReason Software/System restart
setstate DVES_EFFE7E 2026-10-04 13:44:55 Scheme 0
setstate DVES_EFFE7E 2026-10-04 13:44:55 Sleep 50
setstate DVES_EFFE7E 2026-10-04 13:44:55 SleepMode Dynamic
setstate DVES_EFFE7E 2026-10-04 13:44:55 Speed 1
setstate DVES_EFFE7E 2026-10-04 13:44:55 Time 2026-10-04T12:44:55
setstate DVES_EFFE7E 2026-10-04 13:44:03 Upgrade Version 15.6.0 from http://ota.tasmota.com/tasmota/release/tasmota-DE.bin
setstate DVES_EFFE7E 2026-10-04 13:44:55 Uptime 0T00:00:10
setstate DVES_EFFE7E 2026-10-04 13:44:55 UptimeSec 10
setstate DVES_EFFE7E 2026-10-04 13:43:59 Vcc 3.568
setstate DVES_EFFE7E 2026-10-04 13:44:51 Version 15.6.0(release-tasmota)
setstate DVES_EFFE7E 2026-10-04 13:44:51 WebServerMode Admin
setstate DVES_EFFE7E 2026-10-04 13:44:55 White 0
setstate DVES_EFFE7E 2026-10-04 13:44:55 Wifi_AP 1
setstate DVES_EFFE7E 2026-10-04 13:44:55 Wifi_BSSId 04:B4:FE:D9:B1:BA
setstate DVES_EFFE7E 2026-10-04 13:44:55 Wifi_Channel 1
setstate DVES_EFFE7E 2026-10-04 13:44:55 Wifi_Downtime 0T00:00:04
setstate DVES_EFFE7E 2026-10-04 13:44:55 Wifi_LinkCount 1
setstate DVES_EFFE7E 2026-10-04 13:44:55 Wifi_Mode 11n
setstate DVES_EFFE7E 2026-10-04 13:44:55 Wifi_RSSI 100
setstate DVES_EFFE7E 2026-10-04 13:44:55 Wifi_SSId Rennstichs_OG24
setstate DVES_EFFE7E 2026-10-04 13:44:55 Wifi_Signal -48
setstate DVES_EFFE7E 2026-10-04 13:44:51 lwt online
setstate DVES_EFFE7E 2026-10-04 17:12:52 state off
setstate DVES_EFFE7E 2026-10-04 13:35:08 subscriptions cmnd/DVES_EFFE7E/# cmnd/DVES_EFFE7E_fb/# cmnd/tasmotas/#

setstate Kaffeemaschine_Tasmota2 brightness
setstate Kaffeemaschine_Tasmota2 2026-10-04 17:29:55 Channel_1 27
setstate Kaffeemaschine_Tasmota2 2026-10-04 17:29:55 Channel_2 42
setstate Kaffeemaschine_Tasmota2 2026-10-04 17:29:55 Channel_3 63
setstate Kaffeemaschine_Tasmota2 2026-10-04 17:29:55 Channel_4 0
setstate Kaffeemaschine_Tasmota2 2026-10-04 17:29:55 Color 456AA100
setstate Kaffeemaschine_Tasmota2 2026-10-04 17:29:55 Dimmer 63
setstate Kaffeemaschine_Tasmota2 2026-10-04 17:29:55 HSBColor 216,57,63
setstate Kaffeemaschine_Tasmota2 2026-10-04 17:29:55 POWER2 on
setstate Kaffeemaschine_Tasmota2 2026-10-04 17:29:55 White 0
setstate Kaffeemaschine_Tasmota2 2026-10-04 17:29:55 state brightness
setstate m2discover active
setstate m2discover 2026-10-04 13:53:06 .registry {"devices":{"m2s|id|tasmota_84F3EBEFFE7E":{"adapter":"tasmota","availability_reading":"","availability_topics":["tele/DVES_EFFE7E/LWT"],"cid":"DVES_EFFE7E","created":0,"entities":{"tasmota/discovery/84F3EBEFFE7E/config|power":{"adapter":"tasmota","alternate_name":"Kaffeemaschine_Light_EFFE7E_1","channel":1,"channel_name":"Kaffeemaschine","device_base":"Kaffeemaschine","device_topic":null,"discovery_topic":"tasmota/discovery/84F3EBEFFE7E/config","entity_key":"tasmota/discovery/84F3EBEFFE7E/config|power","identity":"m2s|id|tasmota_84F3EBEFFE7E","metadata":{"component":"switch","device_class":null,"entity_category":null,"manufacturer":"Tasmota","model":"Maxcio YX-DE04","name":"Kaffeemaschine","state_class":null,"suggested_area":null,"unit":null},"ok":1,"proposed_name":"Kaffeemaschine_Kaffeemaschine","reading_lines":[{"boolean_map":{"off":"off","on":"on"},"kind":"reading","name":"POWER1","payload":null,"semantic_name":"power","template":null,"topic":"stat/DVES_EFFE7E/POWER1"},{"boolean_map":{"off":"off","on":"on"},"kind":"reading","name":"POWER1","payload":null,"semantic_name":"POWER1","template":null,"topic":"stat/DVES_EFFE7E/POWER1"},{"kind":"json_autocreate","name":"STATE","topic":"tele/DVES_EFFE7E/STATE"},{"kind":"json_autocreate","name":"SENSOR","topic":"tele/DVES_EFFE7E/SENSOR"},{"kind":"json_autocreate","name":"UPTIME","topic":"tele/DVES_EFFE7E/UPTIME"},{"key_prefix":"Info","kind":"json_sequence","name":"INFO","parts":[1,2,3],"topic":"tele/DVES_EFFE7E/INFO","unwrap_single_property":1},{"kind":"json_autocreate","name":"RESULT","topic":"stat/DVES_EFFE7E/RESULT"},{"kind":"availability","name":"availability","payload_available":"Online","payload_not_available":"Offline","policy":{"mode":"latest","reading":".availability_policy_27d35044","sources":["lwt"]},"reserved_reading":1,"role":"availability","source_reading":"lwt","template":null,"topic":"tele/DVES_EFFE7E/LWT"}],"reading_name":"power","reading_path":["switch","power"],"semantic_entity":{"capabilities":{"power":{"activeValue":"on","inactiveValue":"off","kind":"boolean","options":["on","off"],"read":"POWER1","write":"POWER1"}},"class":"switch","id":"power","name":"power"},"set_lines":[{"kind":"choice","mapping":{"off":"off","on":"on"},"name":"POWER1","primary_switch":1,"spec":"on,off","template":null,"topic":"cmnd/DVES_EFFE7E/POWER1"}],"set_state_list":["POWER1"],"source_layout":"tasmota","strong_identity":1,"warnings":[]}},"hook_sets":[{"kind":"button","name":"on","payload":"on","spec":"noArg","topic":"cmnd/DVES_EFFE7E/POWER1"},{"kind":"button","name":"off","payload":"off","spec":"noArg","topic":"cmnd/DVES_EFFE7E/POWER1"}],"io":"m2s","json_seen":{"BootCount":1,"FallbackTopic":1,"GroupTopic":1,"Hostname":1,"IPAddress":1,"Module":1,"RestartReason":1,"Version":1,"WebServerMode":1},"name":"DVES_EFFE7E","owned_availability_reading":"","owned_devicetopic":null,"owned_reading":[],"owned_set":[],"parse_readings":[{"json":{"path":"info","renames":{"CT":"","Color":"","Dimmer":"","INFO":"","POWER1":"","POWER2":"","RESULT":"","SENSOR":"","STATE":"","Scheme":"","UPTIME":"","White":""},"unwrap":{"key_prefix":"Info","parts":[1,2,3]}},"regexp":"tele/DVES_EFFE7E/INFO(?:1|2|3):.*"},{"json":{"path":"sensor","renames":{"CT":"","Color":"","Dimmer":"","INFO":"","POWER1":"","POWER2":"","RESULT":"","SENSOR":"","STATE":"","Scheme":"","UPTIME":"","White":""}},"regexp":"tele/DVES_EFFE7E/SENSOR:.*"},{"json":{"path":"uptime","renames":{"CT":"","Color":"","Dimmer":"","INFO":"","POWER1":"","POWER2":"","RESULT":"","SENSOR":"","STATE":"","Scheme":"","UPTIME":"","White":""}},"regexp":"tele/DVES_EFFE7E/UPTIME:.*"},{"reference":"r_3805423d4dc43e9b","regexp":"tele/DVES_EFFE7E/LWT:.*"},{"reference":"r_221074d3cc32d9ff","regexp":"stat/DVES_EFFE7E/POWER1:.*"}],"reachability":"sources","runtime_refs":{"r_221074d3cc32d9ff":{"configuration":{"readings":[{"map":{"off":"off","on":"on"},"name":"state","template":"{{ value }}"}]},"operation":"topic"},"r_3805423d4dc43e9b":{"configuration":{"policies":[{"mode":"latest","reading":".availability_policy_27d35044","sources":["lwt"]}],"reading":"","sources":[{"available":"Online","reading":"lwt","unavailable":"Offline"}]},"operation":"availability"}},"style":"fhem"},"m2s|id|tasmota_84F3EBEFFE7E|ch2":{"adapter":"tasmota","availability_reading":"","availability_topics":["tele/DVES_EFFE7E/LWT"],"cid":"DVES_EFFE7E","created":1,"entities":{"tasmota/discovery/84F3EBEFFE7E/config|power2":{"adapter":"tasmota","alternate_name":"Kaffeemaschine_Kaffeemaschine_2","channel":2,"channel_name":"Tasmota2","device_base":"Kaffeemaschine","device_topic":null,"discovery_topic":"tasmota/discovery/84F3EBEFFE7E/config","entity_key":"tasmota/discovery/84F3EBEFFE7E/config|power2","identity":"m2s|id|tasmota_84F3EBEFFE7E","metadata":{"component":"light","device_class":null,"entity_category":null,"manufacturer":"Tasmota","model":"Maxcio YX-DE04","name":"Tasmota2","state_class":null,"suggested_area":null,"unit":null},"ok":1,"proposed_name":"Kaffeemaschine_Tasmota2","reading_lines":[{"boolean_map":{"off":"off","on":"on"},"kind":"reading","name":"POWER2","payload":null,"semantic_name":"power2","template":null,"topic":"stat/DVES_EFFE7E/POWER2"},{"boolean_map":{"off":"off","on":"on"},"kind":"reading","name":"POWER2","payload":null,"semantic_name":"POWER2","template":null,"topic":"stat/DVES_EFFE7E/POWER2"},{"boolean_map":{"off":"off","on":"on"},"json_key":"POWER2","kind":"json_reading","name":"POWER2","payload":null,"semantic_name":"POWER2","template":"{{ value_json.POWER2 }}","topic":"tele/DVES_EFFE7E/STATE"},{"json_key":"Dimmer","kind":"json_autocreate","name":"Dimmer","payload":null,"semantic_name":"power2_brightness","template":"{{ value_json.Dimmer }}","topic":"stat/DVES_EFFE7E/RESULT"},{"json_key":"CT","kind":"json_autocreate","name":"CT","payload":null,"semantic_name":"power2_colorTemp","template":"{{ value_json.CT }}","topic":"stat/DVES_EFFE7E/RESULT"},{"json_key":"Color","kind":"json_autocreate","name":"Color","payload":null,"semantic_name":"power2_color","template":"{{ value_json.Color }}","topic":"stat/DVES_EFFE7E/RESULT"},{"json_key":"Scheme","kind":"json_autocreate","name":"Scheme","payload":null,"semantic_name":"power2_effect","template":"{{ value_json.Scheme }}","topic":"stat/DVES_EFFE7E/RESULT"},{"json_key":"White","kind":"json_autocreate","name":"White","payload":null,"semantic_name":"power2_white","template":"{{ value_json.White }}","topic":"stat/DVES_EFFE7E/RESULT"},{"kind":"availability","name":"availability","payload_available":"Online","payload_not_available":"Offline","policy":{"mode":"latest","reading":".availability_policy_27d35044","sources":["lwt"]},"reserved_reading":1,"role":"availability","source_reading":"lwt","template":null,"topic":"tele/DVES_EFFE7E/LWT"}],"reading_name":"power2","reading_path":["light","power2"],"semantic_entity":{"capabilities":{"brightness":{"max":100,"min":0,"read":"Dimmer","step":1,"write":"power2_brightness"},"power":{"activeValue":"on","inactiveValue":"off","kind":"boolean","options":["on","off"],"read":"POWER2","write":"POWER2"}},"class":"light","id":"power2","name":"Tasmota2"},"set_lines":[{"kind":"choice","mapping":{"off":"off","on":"on"},"name":"POWER2","spec":"on,off","template":null,"topic":"cmnd/DVES_EFFE7E/POWER2"},{"identity":1,"kind":"publish","name":"power2_brightness","spec":"slider,0,1,100","template":"{{ value }}","topic":"cmnd/DVES_EFFE7E/Dimmer"},{"identity":1,"kind":"publish","name":"power2_colorTemp","spec":"slider,153,1,500","template":"{{ value }}","topic":"cmnd/DVES_EFFE7E/CT"},{"identity":1,"kind":"publish","name":"power2_color","spec":"","template":"{{ value }}","topic":"cmnd/DVES_EFFE7E/Color2"},{"kind":"choice","mapping":{"cycle_down":3,"cycle_up":2,"random":4,"solid":0,"wake_up":1},"name":"power2_effect","spec":"solid,wake_up,cycle_up,cycle_down,random","template":null,"topic":"cmnd/DVES_EFFE7E/Scheme"},{"identity":1,"kind":"publish","name":"power2_white","spec":"slider,0,1,100","template":"{{ value }}","topic":"cmnd/DVES_EFFE7E/White"}],"set_state_list":[],"source_layout":"tasmota","strong_identity":1,"warnings":[]}},"io":"m2s","json_seen":{"Channel_1":1,"Channel_2":1,"Channel_3":1,"Channel_4":1,"Color":1,"Command":1,"Dimmer":1,"HSBColor":1,"Input":1,"OtaUrl":1,"POWER1":1,"POWER2":1,"Upgrade":1,"White":1},"name":"Kaffeemaschine_Tasmota2","owned_availability_reading":"","owned_devicetopic":null,"owned_reading":[],"owned_set":["POWER2:on,off cmnd/DVES_EFFE7E/POWER2","brightness:slider,0,1,100 cmnd/DVES_EFFE7E/Dimmer","color cmnd/DVES_EFFE7E/Color2","colorTemp:slider,153,1,500 cmnd/DVES_EFFE7E/CT","effect:solid,wake_up,cycle_up,cycle_down,random { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_f4fbc911c2dffdd1', $EVENT) }","white:slider,0,1,100 cmnd/DVES_EFFE7E/White"],"parse_readings":[{"json":{"path":"result","renames":{"INFO":"","POWER1":"","RESULT":"","SENSOR":"","STATE":"","UPTIME":""}},"regexp":"stat/DVES_EFFE7E/RESULT:.*"},{"reference":"r_3805423d4dc43e9b","regexp":"tele/DVES_EFFE7E/LWT:.*"},{"reference":"r_27017e477d0d385f","regexp":"stat/DVES_EFFE7E/POWER2:.*"},{"reference":"r_66e98121ed546641","regexp":"tele/DVES_EFFE7E/STATE:.*"}],"reachability":"sources","runtime_refs":{"r_27017e477d0d385f":{"configuration":{"readings":[{"map":{"off":"off","on":"on"},"name":"POWER2","template":"{{ value }}"}]},"operation":"topic"},"r_3805423d4dc43e9b":{"configuration":{"policies":[{"mode":"latest","reading":".availability_policy_27d35044","sources":["lwt"]}],"reading":"","sources":[{"available":"Online","reading":"lwt","unavailable":"Offline"}]},"operation":"availability"},"r_66e98121ed546641":{"configuration":{"readings":[{"map":{"off":"off","on":"on"},"name":"POWER2","template":"{{ value_json.POWER2 }}"}]},"operation":"topic"},"r_f4fbc911c2dffdd1":{"kind":"choice","mapping":{"cycle_down":3,"cycle_up":2,"random":4,"solid":0,"wake_up":1},"operation":"set","topic":"cmnd/DVES_EFFE7E/Scheme"}},"style":"fhem"}},"version":1}
setstate m2discover 2026-10-04 13:45:00 conflicts STATE,RESULT
setstate m2discover 2026-10-04 13:51:23 deviceKey Kaffeemaschine_Tasmota2: -
setstate m2discover 2026-10-04 13:45:00 discoveredDevices 2
setstate m2discover 2026-10-04 13:45:00 discoveredEntities 2
setstate m2discover 2026-10-04 13:45:00 errorCount 0
setstate m2discover 2026-10-04 13:45:00 lastAdapter tasmota
setstate m2discover 2026-10-04 13:45:00 lastError none
setstate m2discover 2026-10-04 13:19:39 lastShellyDiscovery requested
setstate m2discover 2026-10-04 13:45:00 lastTopic tasmota/discovery/84F3EBEFFE7E/sensors
setstate m2discover 2026-10-04 13:45:00 lastWarning none
setstate m2discover 2026-10-04 13:19:33 replayPayloads -
setstate m2discover 2026-10-04 13:19:33 selectReadings -
setstate m2discover 2026-10-04 13:19:39 state active
setstate m2discover 2026-10-04 13:45:00 warningCount 0

setstate m2s 2026-10-04 13:44:51 nrclients 1
setstate m2s 2026-10-04 13:18:59 state Initialized{getAllSets('DVES_EFFE7E')} liefert (attrTemplate ist deaktiviert):
off:noArg on:noArgSehr fein, es fehlt allerdings m.E. das, was SetExtensions eigentlich ergänzen sollte. Habe noch nicht nachgeschaut, ob das ein (neues) Thema aus dem framework ist, attrTemplate hatte jedenfalls vor der Deaktivierung (wg. Übersichtlichkeit) funktioniert.

Der 2. Kanal "Kaffeemaschine_Tasmota2" wird noch "klassisch" angelegt, was mehrfach nicht so schön ist. "autocreate" am MQTT2_SERVER habe ich erst mal an gelassen, das gab ein heilloses Durcheinander... Für den 2. channel habe ich also erst mal alle Readings gelöscht, was nach einem "cleanen" brightness-set-Befehl zurückkommt, ist oben zu finden. Da passen die mappings nicht, das ist nicht "rund".

In den Code bin ich noch nicht tiefer eingestiegen, nicht gefallen haben mir die sachlich nur teilweise passenden KI-Kommentare zu "return undef;", da muss ich wohl manuell ran, wenn das was werden soll mit perlcritic.

Zum Coding allgemein:
Beim Einstieg in das Modul kommt erst mal was von "log", in etwa in dieser Form:
MQTT2_DISCOVERY_gateway($hash)->log(
$hash->{NAME}, $level, "MQTT2_DISCOVERY $hash->{NAME}: $message",
);Bis ich überhaupt bei der eigentlich interessanten Frage angelangt bin, wie solche Funktionen für die setList angelegt werden wie:effect:solid,wake_up,cycle_up,cycle_down,random { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_f4fbc911c2dffdd1', $EVENT) }\ muss ich mir sehr lange den Kopf zerbrechen, für was diese Notation für die log-Anweisung gut ist.

Soweit erst mal, sorry für die Kürze.

sorry, bin etwas knapp in der Zeit und die nächsten Wochen auch nicht verfügbar.
Beta-User hat schon recht (und auch nicht?) "back to topic": die "best-current-practice" passt mir nicht - aus meiner Sicht "ist nicht gut genug". Um gut zu bewerten kommt es auf die Kriterien an - und hier sind mir meine klar, die allgemeinen aber - entweder nicht verständlich oder ich stimme nicht überein.

Ich befasse mich nun - nicht 100% freiwillig - mit dem MQTT2-SERVER. Auch hier habe ich ein Problem, die Philisophie dieses Moduls zu verstehen - oder die Philosphie von FHEM - egal. Was mir "aufgefallen" ist:
 - der "server" legt versteckte Entites an. An diese ist nur umständlich heranzukommen. Warum versteckt man das?
 - Der Server legt bei allen Devices das Reading "subscription" an. Dieses ist hässlich lang, versaut das gesamte Web-frontent und sagt mir erst einmal garnichts - also sinnlos. Steuern kann ich den Inhalt so einfach einmal garnicht.
 - im Server gibt es interessante Logs, kann man über "verbose" steuern. Nicht schlecht? ich denke doch schlecht. Wenn ich den einschalte kann ich nicht auf MQTT2_DEVICES filtern. Das wäre einmal eine Sache.
 - der Server kennt die IP Adresse der Devices - cool - warum wird ie geheim gehalten?

Wie würde das im meiner Welt aussehen
 - die Sub- Elemente des Servers kann man gerne "verstecken" - die versauen die Ansicht (ich vermute, das war auch der Grund dafür)
 - Ein (oder mehrere) "get <MQTT2_DEVICE> info" geben mir aber die Informationen, welche im "Server-Child" vorhanden sind - und dass ich verbunden bin. Derer Infors habe ich immer mehrere, ggf auch mit level. So ein "get" tut garnicht weh.
 - dass man mit "internals" (dem führenden ".") oder im room hidden infos versteckt kann doch nur der lesbarkeit geschuldet sein.
 - mein standard "get <name> list hidden" zeigt mir alle - auch die ausgeblendeten  - Einträge einer entity. Und "get <name> list modul" die des Moduls - auch hier darf es keine Geheimnisse geben.
 - die IP Adresse ist bei MQTT eine elementare Information. So lange nicht alles über fhem einstellbar ist will man auf die Webseite abbiegen und das Device prüfen oder konfogurieren.
 - die Information "subscription" ist in einem "get Info" hervorragend aufgehoben.
 - in propably associated sollte das auch auftauche
 - warum so zurückhaltend mit der Info? Wie ich sagte, mein System-Add-On Modul gibt mit einem "Fellows" über "get" Informationen, wer mit wem verbunde ist und wie. Wer triggert wen. Hier triggert der Server die entites über dispatch.
 - was das Server-logging angeht - bei CUL_HM hatte ich dem "Server" - also dem IO-device - die Option engebaut, über ein attribut festzulegen, von welchem Device ich die Messages loggen will. Zumindest für mich ist das extrem hilfreich gewesen, meist will ich nicht den Server sondern die Kommunikation zu einem Device untersuchen.
 - ich werden nun die Infos aus dem Server im Device sichtbar machen - erst einmal muss ich sie verstehen.
 - der Server selbst wir ein "get assiciated info" bekommen - oder mein "MQTT-router". So geht es jedenfalls nicht.
 ==> es darf keine geheimen Infos geben - alles, ALLES  muss abfragbar sein - über inteligente Komamndos im Web- Interface - nicht verhandelbar.

Noch einmal - hoffentlich anschaulicher: während auf der einen Seite unleserliche und unbedeutende Readings das Forntend zerstören dürfen, werden einfache und hilfreiche Informationen maximal versteckt. Was ist hier der Antrieb und das Konzept?

Zitat von: martinp876 am 04 Oktober 2026, 18:47:33Noch einmal - hoffentlich anschaulicher: während auf der einen Seite unleserliche und unbedeutende Readings das Forntend zerstören dürfen, werden einfache und hilfreiche Informationen maximal versteckt. Was ist hier der Antrieb und das Konzept?

Solange du davon überzeugt bist, dass deine Handvoll WLAN-Shelly oder Tasmota-Gadgets ausreichen, um allgemeingültige Schlüsse und Vorgaben zu machen, werden wir vermutlich nicht zu dem gemeinsamen Nenner kommen, dass ein geschlossenes "Konzept" nicht allgemein zielführend sein wird.

Daher muss/kann/wird es immer so sein, dass man eben schlimmstenfalls "alles" zeigt, was irgendwie zu einem Gadget gehört und der User die undankbare Aufgabe hat, wichtiges von unwichtigem zu unterscheiden und das beste daraus zu machen.

Zitat von: martinp876 am 04 Oktober 2026, 18:47:33- der Server kennt die IP Adresse der Devices - cool - warum wird ie geheim gehalten?

1. Sie ist aus MQTT-Sicht eigentlich völlig irrelevant. Das irgendwie für relevant zu halten, ist nahe an der Annahme, die ClientID sei wichtig. (Eine direkte Option, das Web-Interfaces eined Gadgets aufzurufen, das zufällig überhaupt eine IP-Adresse hat, ist durchaus praktisch, aber das hat nichts mit MQTT zu tun!)

Meine dringliche Empfehlung auch hier: Die IP-Adresse nicht überbewerten!

2. Das list zeigt auf die temporäre Instanz.

Zitat von: martinp876 am 04 Oktober 2026, 18:47:33- der "server" legt versteckte Entites an. An diese ist nur umständlich heranzukommen. Warum versteckt man das?

Die "Logik" dahinter ist dieselbe wie bei anderen TCP/IP-Verbindungen (z.B. FHEMWEB) auch: Jede Verbindung ist eine temporäre Instanz, und das list eines MQTT2_DEVICES zeigt sie, wenn sie vorhanden/bekannt ist. Das ist nicht der Fall, wenn
a) MQTT2_CLIENT als IO verwendet wird, oder
b) das Gadget gar nicht direkt per TPC/IP eingebunden ist. (Das versteht man nicht, wenn man eine Handvoll WLAN-Shelly oder Tasmota-Gadgets als allgemeingültige Referenz betrachtet).

Zitat von: martinp876 am 04 Oktober 2026, 18:47:33- die Information "subscription" ist in einem "get Info" hervorragend aufgehoben.

Guter Punkt. In der Vergangenheit war die Info häufig hilfreich für den User-Support, aber eigentlich ist das etwas, was zur Verbindung (temporäre MQTT2_SERVER-Instanz) gehört, und auch nur (wie IP und ClientID) dann bekannt ist, wenn überhaupt dieser Server-Typ (in derselben FHEM-Instanz) im Einsatz ist.

Zitat von: martinp876 am 04 Oktober 2026, 18:47:33- in propably associated sollte das auch auftauche

Nun, über das Internal ist es verlinkt, ob es eine Doppelung oder andere Lösung braucht, ist m.E. eine Geschmacksfrage.

Nur meine 2ct.

[OT]

Zitat von: martinp876 am 04 Oktober 2026, 18:47:33während auf der einen Seite unleserliche und unbedeutende Readings das Forntend zerstören dürfen

Wenn man sich CUL_HM heute rückblickend ansieht, gibt es da auch "Spam":
define Rollladen_Bad_OG CUL_HM xyz
attr Rollladen_Bad_OG .mId 006A
attr Rollladen_Bad_OG IOgrp VCCU
attr Rollladen_Bad_OG commStInCh off
attr Rollladen_Bad_OG expert defReg,rawReg
attr Rollladen_Bad_OG firmware 2.11
attr Rollladen_Bad_OG model HM-LC-BL1PBU-FM
attr Rollladen_Bad_OG serialNr bla
attr Rollladen_Bad_OG subType blindActuator
#  NTFY_ORDER 48-Rollladen_Bad_OG
#  disableNotifyFn 1
#  READINGS:
#  [viele Restriktions-spezifisch Infos]
#
Ein Haufen für den User nicht sinnvoll änderbare Angaben, die man auch "in one" unterbringen könnte und ggf. lieber in ein "set"-Kommando als "force" unterbringen könnte?
Das "globale notify"-Dingens ist in dem Modul direkt schlicht nicht gut aufgehoben, eigentlich gehört das (nach meiner persönlichen, heutigen Lesart) in eine (verpflichtende!) "Zwischenschicht", bestehend aus HMInfo, VCCU und Actiondetector.
Und dass man "commStInCh" immer noch bei jedem (mehrkanaligem) Device setzen muss, ist imo Unfug. Es mag einzelne User geben, die das anschalten wollen...

Aber solche "Altlasten" zu korrigieren, ist halt nicht vermittelbar, that's all.

Btw.:
10_CUL_HM.pm erzeugt ghost devices mit Anwendung von fhem delete   (https://forum.fhem.de/index.php?topic=145561.0)kennst du? Das wäre m.E. eine Altlast, die man beseitigen sollte, und auch nicht in neue Modulvarianten perpetuieren...

ZitatAlso ein 1. "channel" mit einem simplen "ein/aus", und ein mehrfarbiges Licht als 2. channel.

::)
Hab doch erwähnt das ich nur mit dem Shelly und einem Tasmota Stecker gespielt hatte!?

SetExtensions fehlen: Fehler bei mir

• SetExtensions prüft auf on/off in der Liste, die MQTT2_DEVICE aus der setList übergibt. Die Kette (SE_Next) läuft erst danach.
• Mit sets=hook kommen on/off erst in der Kette dazu, also zu spät. Deshalb gibt es kein on-for-timer, toggle usw. Mit dem attrTemplate standen on/off in der setList, deshalb ging es da.
• Lösung entweder in SetExtensions.pm (erst die Kette nach der Liste fragen, dann ergänzen) oder im Modul (SetExtensions selbst mit erweiterter Liste aufrufen, mit Sperre gegen den Wiedereintritt). Mir wäre ersteres lieber, das müsste aber Rudi entscheiden.

2. Kanal "klassisch"

• sets=hook kann bisher nur Knöpfe und Auswahllisten. Slider, Farbe und Freitext nicht, und dann fällt das ganze Gerät auf setList zurück.
• Die Konvention state + on/off bekommt nur der erste Kanal. Der Licht-Kanal behält POWER2:on,off. Ohne setStateList schreibt MQTT2_DEVICE deshalb den Befehlsnamen nach state, daher dein "state brightness".

Mappings passen nicht

• Die Setter werden umbenannt (brightness, color, colorTemp, white, effect), die Readings aus RESULT kommen aber roh (Dimmer, Color, CT, White, Scheme).
• Scheme kommt als Zahl, effect erwartet einen Namen. Die Rückabbildung fehlt.
• Ziel wäre: Reading heißt wie der Setter, Werte in beide Richtungen gleich.

return undef

• Von den 141 "return undef" im Fork stammen 113 aus dem Original, 28 von mir. Die pauschale Ausnahme in der .perlcriticrc ist meine, und ihre Begründung trifft nur auf einen Teil zu.
• Welche Kommentare meinst du konkret? Dann schaue ich, ob sie von mir sind.

gateway(...)->log / runtimeRef

• Das Gateway kapselt die FHEM-Zugriffe, damit die lib-Teile ohne FHEM testbar sind. Im Modul selbst bringt die Umleitung nichts, Log3 direkt wäre lesbarer.
• runtimeRef sucht in der Registry die Referenz mit Topic und Wertabbildung (solid→0 ...) und liefert "topic payload" an MQTT2_DEVICE zurück. Der Grund: Gespeicherter Discovery-Text wird nie per eval ausgeführt. Beides ist so aus dem Original übernommen.

effect:solid,wake_up,cycle_up,cycle_down,random { MQTT2_DISCOVERY_runtimeRef($NAME, 'r_f4fbc911c2dffdd1', $EVENT) }
Falls dir der Fork zum Nachvollziehen zu groß ist: Im Anhang ein kleiner Entwurf von vorletzter Woche in Richtung MQTT2_Utils (rund 530 Zeilen, Aufbau angelehnt an RHASSPY, eine Regel je Zeile am Zielgerät). Bisher kann er nur lesen, die Sets hängen an derselben SetExtensions-Frage wie oben. Mach damit, was dir nützt.

• Archiv im FHEM-Verzeichnis auspacken, die beiden Dateien landen unter FHEM/ und lib/FHEM/MQTT2/Utils/.
• Nach dem define "set mqttUtils activate", das trägt MQTT2_Utils vorn in die clientOrder des IODev ein.

define mqttUtils MQTT2_Utils <MQTT2_SERVER|MQTT2_CLIENT> [prefix=mqtt] [devspec=TYPE=MQTT2_DEVICE]
set mqttUtils activate
attr <device> mqttUtilsRules <topic> <quelle> <ziel> [<umrechnung>]

Zitat von: TomLee am 05 Oktober 2026, 13:59:38Mach damit, was dir nützt.

:)

Erst mal kurz reinschauen :)  :)  :) . Allerkürzeste Zusammenfassung: Bis auf den für mich überflüssigen Test-Part (überflüssig = ich verstehe nicht, wie es funktionieren soll und was das effektiv hilft), scheint mir das - bis auf das unbedingt einzubauende "forceNEXT"-Attribut sowohl für das Modul wie seine Clients (dort als "key" in einem anderen Attribut) erst mal eine Basis für eventuelle Diskussionen zu sein. (mehr unten)

Zitat von: martinp876 am 28 September 2026, 20:47:51Bei der Menge an Mitarbeitern bietet es sich an, Ziele in einem Dokument festzuhalten. Das macht weniger Spass, ist am Ende aber hilfreich. Erst einmal zu codieren und dann zu schauen, was es geworden ist um noch etwas zu tunen ist verbreitet.. aber...
https://scheissprojekt.de/hausbau.html (https://scheissprojekt.de/hausbau.html)

Manchmal ist v.a. eine Skizze dessen hilfreich, wie das Haus am Ende aussehen soll. Die "Pfriemeleien" zum tunen an MQTT2_DEVICE sind m.E. aus den genannten Gründen nicht vermittelbar.

Von daher soll es bei dem ersten Wurf zu MQTT2_Utils v.a. darum gehen zu zeigen, wie sich das ganze ggf. in die heutige MQTT-Welt einpassen lassen könnte.

Elementar wichtig ist dabei, wann welches Modul überhaupt welche Infos bekommt. Und genau darum geht es bei "forceNEXT": Im Prinzip sollte das neue Modul erst mal alle unbekannten Messages abfangen und NICHT [NEXT] aus Parse() zurückgeben. Jedenfalls, wenn es z.B. so konfiguriert ist, dass es alle Tasmota-like messages auswerten soll. Dann sind (nur) alle diese rauszufiltern, MQTT2_DEVICE bekommt die nicht mehr zu sehen, es sei denn, für einzelne Devices würde etwas anders (dort) konfiguriert.

(sorry, sehr kurz)

ZitatLösung entweder in SetExtensions.pm (erst die Kette nach der Liste fragen, dann ergänzen) oder im Modul (SetExtensions selbst mit erweiterter Liste aufrufen, mit Sperre gegen den Wiedereintritt). Mir wäre ersteres lieber, das müsste aber Rudi entscheiden.

Ich habe SetExtensionsFn so umgebaut, das SetExtensions selbst am Ende der Liste ausgefuehrt wird.

ZitatBis auf den für mich überflüssigen Test-Part (überflüssig = ich verstehe nicht, wie es funktionieren soll

Zum Hintergrund:

Was ,,Tests" eigentlich sind

Bei einem Projekt, mit dem ich mich jetzt schon länger beschäftige und mit "KI" gearbeitet wird, habe ich gelernt, wie dort gearbeitet wird:
Zu jeder Änderung gehören Tests. Das klingt erst mal nach Mehrarbeit, ist aber im Grunde nur das, was wir in FHEM sowieso machen, nur aufgeschrieben.

Wenn du in FHEM etwas änderst, probierst du es aus: set, get, ins Log schauen, in FHEMWEB nachsehen. Ein Test ist genau dieses Ausprobieren als kleines Programm.
Der Vorteil: Man kann es nach jeder Änderung in Sekunden wiederholen, statt alles von Hand neu durchzuklicken. Man merkt auch sofort, wenn eine Änderung an einer Stelle etwas ganz anderes kaputt gemacht hat.

Grob gibt es drei Sorten:

• Eine einzelne Funktion prüfen. Wie wenn du in der FHEM-Kommandozeile
  
  Code Auswählen Erweitern
  { KalenderWoche("2026-12-28") }eingibst und schaust, ob 53 herauskommt. Der Test schreibt Eingabe und erwartetes Ergebnis fest auf und meldet sich, sobald etwas anderes herauskommt. Am Jahreswechsel, bei der Zeitumstellung oder bei leeren Werten findet man so Fehler, an die man beim Ausprobieren nie gedacht hätte.
• Das Ganze prüfen, mit Wegwerf-Daten. Das Testprogramm baut eine eigene Umgebung mit Beispieldaten auf, führt Abläufe durch und prüft das Ergebnis. Danach wird alles wieder gelöscht. Das ist wie eine zweite FHEM-Instanz nur zum Ausprobieren: Die echte Installation wird nie angefasst.
• Die Oberfläche ferngesteuert bedienen. Ein Browser ohne sichtbares Fenster öffnet die Seite, tut zum Beispiel so, als wäre er ein Handy, klickt oder wischt und misst danach nach: Ist das Element sichtbar? Ist die Seite breiter als der Bildschirm? Wie viele Pixel sind übrig? Manches sieht man beim Anschauen nicht, beim Nachmessen schon.

Warum das mit KI so wichtig ist

Eine KI kann keinen Bildschirm anschauen und kein Handy in die Hand nehmen. Sie kann nur Programme laufen lassen und deren Ausgabe lesen. Ohne Tests rät sie, ob ihr Code funktioniert. Mit Tests prüft sie es nach und findet viele ihrer eigenen Fehler selbst, bevor ich sie überhaupt zu sehen bekomme.

Wo die Grenze liegt

Ein simulierter Klick ist kein echter Finger. Ob sich etwas im Alltag gut anfühlt, muss am Ende trotzdem ein Mensch ausprobieren. Tests ersetzen das Ausprobieren nicht. Sie sorgen dafür, dass man nur noch das ausprobieren muss, was ein Programm nicht beurteilen kann.

---

Zu MQTT2_Utils hab ich erstmal noch nichts weiteres beizutragen, weil ich mit anderem beschäftigt bin. Dazu muss erst eine Zeit kommen, in der ich Abends noch fit bin und es mich packt da einzudenken.

---

ZitatIch habe SetExtensionsFn so umgebaut, das SetExtensions selbst am Ende der Liste ausgefuehrt wird.

Danke

DoSetExtensions ruft in der ersten Zeile noch SE_Next, das es nicht mehr gibt.
  return SE_Next($hash, $list, $name, $cmd, @a) if(!$list);Mit leerer Liste (Gerät ohne eigene Sets, dazu attrTemplate abgeschaltet oder kein passendes Template) endet das in "Undefined subroutine &main::SE_Next".

Vorschlag, passend zu den anderen Stellen:
  return "Unknown argument $cmd, choose one of $list" if(!$list);
Heisst nicht das ich mich mit beschäftigt habe, ich hab die Änderung nur kontrollieren lassen, damit ich irgendwann da weiter machen kann wo ich vor rund zwei Wochen aufgehört habe mich einzudenken ...

Zitat von: rudolfkoenig am 06 Oktober 2026, 17:34:08Ich habe SetExtensionsFn so umgebaut, das SetExtensions selbst am Ende der Liste ausgefuehrt wird.

Auch von meiner Seite: Danke!

Damit sind wir erst mal eher wieder am Ende der Kette, also der Auswertung der eingehenden Nachrichten.

1. Da war es so, dass beim 2. channel meines Tasmota-Testgeräts zwar in Folge des (imo "falsch" benannten, da 0-100 => "pct") "brightness"-Kommandos zwar das "Dimmer"-Reading aktualisiert wurde, aber nicht triggernd.

Habe daher (leider wieder nur (zu) kurz) in den Code des modifizierten MQTT2_DISCOVERY geschaut, um mir da mal anzusehen, ob/wie da das "forceNEXT" usw. umgesetzt ist. Vermutlich muss ich die Aussage von heute morgen etwas relativieren: Die Logik dazu sollte so sein, dass am Ende '[NEXT]' zurückgegeben wird, wenn kein Device aktualisiert wurde (oder im Sinne einer VCCU: hätte versorgt werden können, wenn es denn "angelegt" worden wäre?). Dann soll sich das nächste Modul (MQTT2_DEVICE) darum kümmern, was es damit anfangen möchte. Jetzt gibt es ziemlich viele Ausgänge aus der Funktion, die in diesem Sinne "gut" ausschauen, von daher dürfte das nicht an der letzten letzte Zeile von "Parse" liegen, sondern entweder daran, dass die Prüfung auf "shelly" zu eng ist (vermutlich), oder es ist @updated trotz aller Tests für meinen 2channel nicht vollständig? Nach ein paar Tests: Der Effekt wirkt zufällig, verbose 4 zeigt, dass beide Devices aktualisiert werden... Keine Idee grade, wie auch immer:

2. Damit wären wir beim heiklen Thema "autocreate".
Wenn das am IO aktiviert ist, gibt es "heilloses Durcheinander", wenn zum falschen Zeitpunkt irgendwas zu M2D durchkommt. Dementsprechend sollte in der aktuellen Modulfassung (auch in der originalen!) beim "activate" zwingend (!) autocreate deaktiviert werden, und nicht nur clientOrder passend geschrieben. Unbekannte "Gadgets" kann dann "Utils" (in einer "VCCU"-Funktion) "abfangen".
Als "Vision" würde ich das so beschreiben: autocreate kann aktiv bleiben, alles, was wir automatisch in Utils parsen können, fängt Utils ab, alles andere geht durch. 

3. clientOrder:
Wenn MQTT2_DEVICE gar nicht in clientOrder auftaucht, ist das ein Problem, und "Utils" müßte sich unmittelbar vor MQTT2_DEVICE einreihen. Wer z.B. MQTT_GENERIC_BRIDGE verwendet, wird wissen, was er tut, und notfalls das forceNEXT-Attribut dort finden...

4. Mappings:
Problem ist klar, Rom wurde auch nicht an einem Tag erbaut.

5. Test:
"Eigentlich" ist vieles dazu klar. ABER: Wenn die Begründung für das "Verbasteln" rund um Log3 lautet, dass man das nur so testen kann, frage ich mich, wo die Tests denn die anderen Funktionen aus fhem.pl hernehmen? (Muss mal prüfen, ob das "neue" lib-Verzeichnis nicht auch durch fhem.pl mit eingebunden wird, so dass man das auch nicht jedes Mal separat benötigt...)
Und wie man damit umgeht, dass es das Ziel sein sollte, Teile des Codes möglichst für eine Mehrfachnutzung bereit zu stellen. Letztlich sollten solche Test irgendwie den ganzen Code drumrum auch kennen, sonst kommt es mir erst mal nur wie die (unübersichtliche) Hälfte vor.

Wie dem auch sei: (Auch) Mein heutiges Zeitbudget für das Thema ist aufgebraucht...

ZitatDoSetExtensions ruft in der ersten Zeile noch SE_Next, das es nicht mehr gibt.

Vielen Dank fuer den Hinweis, habs korrigiert.