Von MQTT2_SERVER verschickte Nachrichten mit type "reserved"

[Beta-User]

(In Teilen überschnitten mit Otto's Hinweisen, die aber interessanterweise mir unbekannte Tools referenzieren; zumindest das ist (für mich) was neues...)

Allgemeiner zum MQTT-Protokoll:Nach http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/csprd02/mqtt-v3.1.1-csprd02.html#_Toc385349767 gilt doch der Grundsatz, dass die clientId existieren muss. Eine fehlende clientId "kann" der Server akzeptieren; muss er aber nicht. Da die clientId letztlich doch zur Identifizierung des einen, speziellen Gerätes verwendet wird, verstehe ich schon nicht, warum überhaupt "ohne clientId" erlaubt ist: Wie unterscheidet man verschiedene Geräte? Die Vergabe einer zufallsbasierten clientId ohne Speicherung, die einen Client-Neustart überlebt, ist für mich genauso unverständlich; letztlich kann man dann auch keine vergeben. Wie soll denn dann die Identifizierung mehrer (Valetudo-)Clients erfolgen? Nur durch Anpassung von bspw. "identifier": "rockrobo", "topicPrefix": "valetudo"? Was soll die clientId dann?

Das mqtt.js-Package wird doch häufig verwendet. Tritt das hier beobachetet Problem(?) auch bei anderen darauf basierenden Clients auf. Und über den "Tellerrand geschaut": Wie lösen andere MQTT-Server das Problem mit den clientIds.

Dass das Problem mit den Random-clientId's besteht, hatte ich ja bereits geschrieben, bisher waren das noch zigbee2mqtt und Octoprint.

Dass da eine Random-Angabe verwendet wird, hat wohl damit zu tun, dass nach dem, was du schreibts, eben der Broker die Angabe verlangen kann (dann wird dem entsprochen), aber nicht muß. Da der beliebte mosquitto zu den Vertretern der "ist mir egal"-Fraktion zu gehören scheint, ist das Problem für viele schon gar nicht existent (mir war vor der "MQTT2-Zeit" auch nicht klar, dass da überhaupt was ist, allerdings ohne mich je mit den Grundlagendokumenten dazu auseinandergesetzt zu haben...).

Generelle Feststellung also: In der MQTT-Welt ist der Topic-Tree nach meinem Empfinden das eigentlich wesentliche, und um den zu manipulieren, stellen praktisch alle Frameworks/firmwares (soweit ich die bisher kennengelernt habe, was nicht zu viel Erfahrung ist) Mittel bereit. Das ist also mMn. das eigentliche Unterscheidungsmerkmal, nicht die clientId.
Dazu kommt: Es gibt (zumindest mit mosquitto) auch die Möglichkeit, Server zu brücken, also Daten miteinander auszutauschen. Spätestens dann geht die Quellenangabe aus der clientID verloren, und ein Stück weit auch die Unterscheidung zwischen Server und Client.

Ob allerdings mit der Verwendung der IP (die ja meistens einigermaßen statisch ist) ein Sicherheitsrisiko verbunden ist,entzieht sich meiner Kenntnis, tendiere aber dazu, das zu verneinen, denn letztlich entscheidet ja der Client, unter welcher clientID er sich zu erkennen geben will...


Zu dem Tasmota-OT: dass da im default "sonoff" verwendet wird, ist wirklich unglücklich und vermutlich nur aus der Historie zu erklären... Der Hinweis auf der Webseite des Projekts, dass man den ändern sollte, ist da kein wirklicher Ersatz für eine Änderung an der Stelle (warum nicht die Chip-ID verwenden, wie an anderer Stelle auch?).

[herrmannj]

Das Verhalten dass verschiedene clients unter der gleichen topic publishen dürfen finde ich gut und "Erhaltenswert"

[Beta-User]

Das Verhalten dass verschiedene clients unter der gleichen topic publishen dürfen finde ich gut und "Erhaltenswert"

MMn würde sich daran auch durch die "IP-Lösung" nichts ändern, wenn
- entweder wenigstens einer der Clients eine clientID bereitstellt oder
- die IP-Adresse unterschiedlich ist.

Grundsätzlich würde ich aber jedem Anwender empfehlen, die Topic-Struktur so zu gestalten, dass Verwechslungen ausgeschlossen werden. Andernfalls ist zu befürchten, dass wir sonst immer mal wieder Anwender haben werden, die den Unterschied nicht kennen und dann beim "Rückweg" in der setList nicht sauber operieren (hatten wir das nicht auch schon bei einem Tasmota-Anwender, der immer 4 Geräte gleichzeitig an- bzw. ausgeschaltet hatte?). Auch die attrTemplates ignorieren (bisher und weitgehend) die CID, und es wäre zumindest ein gewisser Aufwand, das zu "korrigieren"...
Apropos "Korrektur": Das würde dann auch dazu führen, dass man nicht mehr so einfach das IO wechseln könnte (SERVER zu CLIENT und anders rum, CLIENT liefert btw. sowieso prinzipbedingt nichts "brauchbares").

[rudolfkoenig]

Das Wissen ueber die ClientId ermoeglicht topics automatisch einzelnen Geraeten zuzuordnen, und da mein Ziel mit MQTT2_SERVER die MQTT-Integration in FHEM zu vereinfachen war, habe ich das gerne genutzt.
Ohne Clientid muss man die Instanzen entweder komplett manuell oder mit einer manuell gepflegten "Datenbank" (siehe die Bridge-Devices) anlegen.

Ein Wechsel vom MQTT2_SERVER zu MQTT2_CLIENT ist aufwendig, weil autocreate die ClientIDs in den readingList Attributen verewigt, und das muss man entfernen. Und hoffen, dass nicht mehrere Geraete die gleichen topics befuellen. Der Wechsel in die andere Richtung (MQTT2_CLIENT => MQTT2_SERVER) sollte problemlos sein.

[Beta-User]

Der Mechanismus an sich ist top!

Den Vorteil sehe ich vor allem auch darin, dass über die CID jeweils (auch später noch) das "richtige" Gerät ermittelt werden kann. Bitte das ganze nicht als Wunsch mißinterpretieren, das auszubauen, sondern +1 für erhalten...

Zu dem Wechseln von CLIENT=>SERVER aber noch: Wird nicht auch bei CLIENT eine CID übergeben (eben die des CLIENT) und dann in der readingList verewigt?
Ich hatte schon länger keinen CLIENT mehr in Betrieb, kann also sein, dass das zwischenzeitlich mal geändert wurde, aber ich habe das noch anders im Kopf (? ist evtl. anders, wenn das durch eine bridgeRegexp durch ist...?). Bei CLIENT macht das "Merken" der CID jedenfalls meistens wenig Sinn (mal abgesehen von dem etwas speziellen Fall, dass man mehrere Server hat, die jeweils einen eigenen CLIENT haben). Wenn das also noch so wäre, wäre der Wechsel auch in diese Richtung mit hohem Aufwand verbunden...


Aber abgesehen davon, ist die erste Frage doch: Schickt das js-Framework immer _gleich_ eine random-clientID oder wird es erst ohne cientID versucht, und dann erst nachgelegt (wie das der von mir neulich zitierte Beitrag schildert) ? Das ergibt sich aus den von krikan verlinkten Stellen für mich nicht so recht. Sieht man dazu ggf. was im log des SERVERS?

Kommt immer gleich eine Random-clientID, ist es schwierig (bzw.: man könnte das Muster erkennen), ansonsten müßte man "nur" den "unbenannten" Client akzeptieren und selbst eine CID vergeben.

Ansonsten vielleicht noch eine Ergänzung zur Frage, wie andere Projekte das lösen mit der userseitigen Vergabe der clientID: Unter https://github.com/OctoPrint/OctoPrint-MQTT/pull/60/commits/6e686f5c621a0fdf43ebc742a7630f1906de5687 scheinen die (überschaubaren) Änderungen zu stehen, die bei OctoPrint ausreichend waren, um das Problem "an der Wurzel" aus der Welt zu schaffen. Vielleicht kann damit jemand eine Lösung für Valetudo basteln...

[krikan]

Danke für Euren Input; muss jetzt erst einmal gedanklich sortieren.
Und ich möchte erst mal in FHEM gar nichts ändern, sondern MQTT halbwegs verstehen, bevor ich mir eine Meinung zu Änderungen in FHEM erlauben kann. 

Aber abgesehen davon, ist die erste Frage doch: Schickt das js-Framework immer _gleich_ eine random-clientID oder wird es erst ohne cientID versucht, und dann erst nachgelegt (wie das der von mir neulich zitierte Beitrag schildert) ? Das ergibt sich aus den von krikan verlinkten Stellen für mich nicht so recht. Sieht man dazu ggf. was im log des SERVERS?

Interpretiere mqtt.js-API-doku so, dass sofort eine Zufalls-clientId verwendet wird, wenn keine vorgegebene clientId als "options" bei mqtt.connect übergeben wird. Das sehe ich auch so im verbose-5 Log bestätigt. Das ist eine erstmalige CONNECT-Nachricht des Clients an den FHEM-Server:

Code Auswählen Erweitern

2019.10.22 12:40:19.738 4: Connection accepted from fhemMqtt_192.168.188.46_38902
2019.10.22 12:40:19.780 5: in:  CONNECT: (16)(27)(0)(4)MQTT(4)(2)(0)<(0)(15)mqttjs_fd62c953
2019.10.22 12:40:19.781 4:   fhemMqtt_192.168.188.46_38902 mqttjs_fd62c953 CONNECT V:4 keepAlive:60
2019.10.22 12:40:19.781 5: out: CONNACK:  (2)(0)(0)

Die Codeänderung für Valitudo für die Vorgabe einer clientId dürfte, wenn meine obige Valetudo-Analyse stimmt, sicherlich relativ einfach sein. Habe aber keine Energie das zu testen/make zu starten.    Die Vorgehensweise von MQTT/mqtt.js bei der clientId wird sicherlich einen Grund haben.

[Beta-User]

Hmm, ok, bin auch der Meinung, dass man in den FHEM-Modulen nichts ändern sollte.

Was "wir" liefern könnten, wäre ein attrTemplate, das die CID-Angaben aus der readingList wirft und die Steuerungs- und Abfragebefehle bereitstellt . Aber das ist unter diesem Thread-Titel wohl "falsch" . (Ich würde eine RAW-Definition von dem Ding benötigen und evtl. einen schnellen Link zu den Befehlen, die via MQTT akzeptiert werden, dann kann ich beizeiten einen ersten Wurf liefern...).

Bei Gelegenheit werde ich wohl auf jeden Fall die bridgeRegexp im allgemeinen "Client"-template anpassen/erweitern, dass die "identifier"-Angabe (typisch: "rockrobo") als CID verwendet wird, was auch immer dann in der .json verwendet wird...