MQTT best current practice

[martinp876]

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?

[Beta-User]

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?

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.

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

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

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

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

[Beta-User]

[OT]

wä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":

Code Auswählen Erweitern

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  kennst du? Das wäre m.E. eine Altlast, die man beseitigen sollte, und auch nicht in neue Modulvarianten perpetuieren...

[TomLee]

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

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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

[Beta-User]

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

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

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)

[rudolfkoenig]

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.

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

[TomLee]

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

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

Danke

[TomLee]

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

Code Auswählen Erweitern

  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:

Code Auswählen Erweitern

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

[Beta-User]

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

[rudolfkoenig]

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

Vielen Dank fuer den Hinweis, habs korrigiert.

[martinp876]

Hi,
zunächst einmal Stellungnahme:
1) ich bin nicht sicher, dasss meine Schlüsse allgemein gültig sind. Sicher bin ich, dass das aktuell angebotene für mich nicht "komplett" taugt.
2) für MQTT ist die IP Adresse irrelevant (fast). Für den Anwender aber nicht. Im grösseren Bild konfiguriere ich die Devices über deren Web-Interface - hierzu brauche ich (zumindest) die IP Adresse - und am Besten einen Link. Die komplette config über FHEM zu machen halte ich bei der Vielfalt für utopisch. ==> IP Adresse ist mehr als relevant für den Betrieb - MQTT ist nur ein Teil der ganzen Story.
3) Servers "versteckte" Instanzen:
3a) unklar, warum man diese über aus meiner Sicht seltsame Autocreate instanziieren lässt. Ich erstellen zuerst ein Device über dessen Webpage. Dann würde ich es eigentlich gerne selbst definieren - und sehen.
3b) die Instanz - welch wohl so etwas wie ein Port ist (auf der Protokoll Seite) macht einiges mehr. So werden zum Beispiel zyklische Update Abfragen gesendet. Diese sind, da versteckt, nicht steuerbar. Für mich sind das viel zu viele Anbfragen - definitiv unnötiger WLAN Trafik. Was ich allerdings brauche wäre ein Alive-Signal. Leider ist das nicht inclusiv. Alive ist eines der wichtigsten Maintenance Elemente - das muss auswirkungen auf alle anhängigen Entities haben (Kanäle) um anzuzeigen, dass wir "unreachable" sind und alle Daten fraglich.
3c)Zurodnung. Mir unklar, ob es einen anderen Fall gibt - aber jedes MQTT2-DEVICE ist einem SERVER Port zugeordnet. Einem Serverport sind oft mehrere MQTT2_DEVICE zugeordnet. Diese Abhängigkeit kann man auch klar darstellen
3d) eigentlich sehe ich - aus der FHEM-Blickrichtung - dass das SERVER_PORT wie ein MQTT2_DEVICE-device aggiert - leider nicht ausreichend. Ok, der Begriff "device" ist schon vergeben - das Device eines Geräte ist (bei mir  und auch an anderen Stellen) die CPU im externen Gerät welche housekeeping und Protokol behandlt. Die Funktionen sind dann die Kanäle. Da das "Port" mehr also nur einfache kommunikation macht ist es eben "ein bisschen device"
3e) ich habe verschiedene Methoden für das Port gesehen und - ganz klar - das Protokoll kenne ich (noch) nicht. Mir unklar ob es link-basierend ist, keep-alive benötigt,... . So wie die Lage ist muss ich mir wohl ein paar Grundlagen aneignen, da meine Vorstellung von Maintenance und low-traffic sowie hierarchical-alarming kaum zu realisieren sind.

=>klar, dass die IP Adresse sich ändern kann, was das MQTT Protokoll dann abkann. a) gerade dann will ich sehen, welche IP genutzt wird um an das WEB-Interface zu gelangen. b) in meine environment werden IP Adressen von installierren Device statisch vergeben. Muss man nicht, ich brauche und will hier keine Dynamik

4) subscription
mir ist nicht klar, was du von einem Anwender erwartest. Ich kann damit erst einmal nichts anfangen - muss mich damit beschäftigen. Nach Möglichkeit will ich das aber nicht - muss ich? Meine Philosophie ist (und damit auch mein Wunsch und meine Empfehlung): sichtbar sollte alles sein, was der Anwender für Betrieb und üblicher Maintenance benötigt. Er sollte aber einfachen Zugriff auf alle - auch versteckte und seltene - Daten haben. Für alle meine "frisierten" Module habe ich das realisiert -  sogar generisch (Rudi könnte das generisch einbauen, für alle). Konkret heisst dies:
- wenn ich Daten "sichtbar" mache (readings, internal, Attribute,...) dann versuche ich die "interessanten" zu identifizieren (ok, ansichtssache)
- mein "get list [normal|hidden|modul]" gibt ein "list" der Entity aus (normal) - mit allen "hidden", also mit "." beginnend (hidden) und ein List auf das Modul (bspw MQTT2_DEVICE) bei modul. Keine geheimnisse, ein jonglieren mit global showhiddenvalues.
Zu subscription: wer weis, was es bedeutet, wenn es da ist oder nicht? Kann man das nicht einfacher machen? Warum muss dieser Ellen lange Wert mein ganzen Frontend unleserlich mache, wenn ich es so gut wie nie ansehe?

5) das Port ist definitiv associated. Dies nicht zu inkludieren hat nichts mit geschmackssache zu tun - es ist Sache des Anwenders, dies zu beurteilen. Allerdings ist das zu verfügung gestellte "associated" eh schwach, rate mal - ich habe hierzu ein generisches "get fellows". Das ist definitv vollständiger und aussagekräftier, da es auch Aussagen über die Art der Beziehung macht - mehrstufig.

6) CUL_HM
6a) es gibt Daten welche nur einmalig zu lesen sind (SN, mID, Model, FW...) FHEM bietet als remanenten Specher nur attr. Zu gerne hätte ich es anderen Orts abgelegt - ich kannte keinen
6b) das ist in einer frühen Schaffensphase meiner selbst entstanden. Das verstecken (".") kam erst etwas später
6c) und hier die Frage, was dem Anwender relevant sein könnet. mID ist hidden. Model und SubType ist m.E. interessant. IOgrp mit Sicherheit!. fw könnte an nach hidden verstecken (das "get list hidden" habe ich mit erst später ausgedacht). commStInCh ist fraglich, ok. Ist dem "unsicheren" protokoll von CUL_HM, der Verzögerung,... geschuldet. Bei mir ist es an! expert muss der Anwender steuer.
Über die (nicht klartext) mID könnte man model und subtype ableiten. Als ich CUL_HM übernahm war mID allerdings garnicht genutzt. Ok, eine Entschuldigung, nur der Grund, warum.
Und noch einmal: ich stehe zu "nicht änderbaren Attributen" so langen eine weitere kategorie geschaffen ist. De-fakto kann der Anwender in FHEM sowieso alles - nur eben nicht über das frontend. Wo also ist das Problem?
==> richtig viel spam kann ich nicht erkennen - da ist MQTT2_DEVICE schon eine andere Nummer

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.

mein "util" ist de facto "privat". Korrekt, eigentlich sollte es grundlegend eingearbeitet werden. Da ich aber weder Zeit noch Lust und möglicherweise auch nicht das wissen habe, dies zu tun, behelfe ich mir so. Was ich damit aufzeigen 'könnte' ware, wie ich mir das Ganze vorstelle. Die Requirements sind zu aller Erst die Anforderungen des Anwenders. Und da divergieren meine vom aktuellen Konzept. Auch klar: wenn die Verantworlichen des Moduls anderen Anforderungen haben ist das vollkommen ok - dann muss ich damit zurecht kommen(aktuell nicht) oder anpassen - thats live.