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