MQTT2_SERVER und MQTT2_DEVICE

[Beta-User]

K.A., ob sich User mit klassischen mqtt-Einbindungen alleine gelassen fühlen. Ich fühlte mich damals etwas alleine, was auch an der neuartigen nutzung der sidoh-firmware lag; aber jetzt sind wir ein paar Monate bzw codezeilen weiter. Im Moment muss man sich halt entscheiden, und das zu einem Zeitpunkt, in dem man klassischerweise keine Ahnung hat. Das ist ein Dilemma, aus dem so eine Brücke helfen könnte. Ob jemand den Aufwand für so ein Modul treiben will? Mal schauen...

Was Dummy angeht: der Zweck ist klar, nur gibt es häufiger Leute, die vorhandene Info planlos umpacken bzw. keine Phantasie dahingehend haben, dass man einen Dummy für mehrere Infos nutzen könnte usw.. Wenn man _wirklich_ nur ein Objekt braucht, ist es völlig OK. Nur ist das eher selten der Fall .

[hexenmeister]

Der Unterschied ist, es existiert anscheinend kein Weg mehr, diese Module in einer Umgebung zu nutzen, wo ein externer Server unvermeidlich ist. Das war vorher nicht so. Und jetzt einfach nicht (mehr) möglich. Aus meiner Sicht ein No-Go

[Beta-User]

Den Einwand verstehe ich nicht. Erstens gibt es.heute beide Wege und man kann beides mit verschiedenen Ports nebeneinander betreiben. Vermutlich kann man auch beide Servertypen sogar brücken (geht mit 2 mosquittos ja auch).

Was die sehr viel flexiblere Konfiguration für Widgets und Json-Sendeblobs mit Mqtt2 angeht, hindert dich niemand, das ähnlich oder gleich anzubieten, ich unterstelle mal, dass Rudi keine Einwände GG. einen coder-reuse hätte. Dann könnte man in der raw-Definition einfach die "2" löschen und das IO ändern, um zwischen den Welten zu wechseln.

Oder habe ich irgendwas völlig missverstanden?

[hexenmeister]

Vlt. missverstehe ich was... Wenn ich es richtig verstanden habe, können mehrere mqtt Client Module nicht mehr direkt mit mqtt als IO verwendet werden. Mosquitto mit MQTT2_SERVER zu brücken ist keine Lösung, da ineffizient. Zwei echte Server zu brücken ist ein ganz andere Geschichte.

[Beta-User]

Nein, es gibt nur ein einziges Mqtt2-Modul (MQTT2_DEVICE), das nicht mit 00_MQTT zusammenarbeitet.

Und das ist sehr flexibel. Vielleicht kannst du auch 00_MQTT so umbauen, dass es das 2-er Device als client akzeptiert? Dann müsste man nur das IO ändern. Sollte eigentlich kein Ding der Unmöglichkeit sein (ohne dazu in den code gesehen zu haben. Aber es geht intern ja "nur" darum, einfachen Text zu manipulieren).

[hexenmeister]

Leider ist das durch die Art, wie das Modul damals von dem ursprünglichen Entwickler erstellt wurde, nicht ganz so einfach. Das Modul ist alles andere als fhem-konform. Dennoch war das über eine längere Zeit Standard. Und ist in Gegensatz zum neuen eine allgemeinlösung. Mag sein, dass die neue Lösung bequemer ist, aber durch ihre Art für viele Szenarien nicht einsetzbar. Und jetzt werden die speziellen Hardware Module nur für eine kleine Teilmenge der Nutzer angeboten.

[Beta-User]

Tut mir leid, aber das mit den "speziellen Hardwaremodulen" verstehe ich nicht. Es gibt nur ein Client-Modul, das sich flexibel auf alle mir bisher begegneten Varianten von Topics und Messages anpassen läßt.

Aber ohne den Code aller Module mal im Detail angesehen zu haben, führt das nicht weiter. Ich mach das mit meinen ziemlich besch...einen "Kenntnissen" bei Gelegenheit mal, allerdings wird das dauern. Die Idee wäre, 00_MQTT zu einer Art "Doppelmodul" zu erweitern, das auch mit 2-er Devices als Client klar kommt. Wäre zwar bei jeder Massage eine Unterscheidung mehr, aber im Ergebnis bekäme der user davon nix mit und wäre bei Wahl dieses Clients nicht an einen bestimmten broker-Typ.gebunden. "best of both worlds..."

[hexenmeister]

Das verstehe ich jetzt nicht. Es gibt ein allgemeines Client Modul (MQTT2_DEVICE) und spezielle Module für milight, zigbee, die nicht mehr mit mqtt zusammen verwendet werden können. Richtig?

[Beta-User]

Na ja, (angesehen von der vermuteten Option, die Server zu Brücken) muss man sich im Moment schon entscheiden, an welchen Broker zigbee2mqtt (oder irgend eine anderen konkrete HW) seine Daten schicken soll. Meinst du das?

[rudolfkoenig]

Es gibt ein allgemeines Client Modul (MQTT2_DEVICE) und spezielle Module für milight, zigbee, die nicht mehr mit mqtt zusammen verwendet werden können. Richtig?

Mein Stand: Es gibt ein Modul fuer sidoh-bridge (fuer Milight, setzt auf MQTT auf), was nicht mehr weiterentwickelt wird, weil eine vergleichbare(?) Funktionalitaet durch das Konfigurieren einer MQTT2_DEVICE erreicht werden kann. Fuer zigbee2mqtt gab so ein Modul noch nie, nur die Beschreibung der MQTT2_DEVICE Konfiguration. Die MQTT2-Verschwoerung gegen die MQTT-Fraktion ist deutlich kleiner als angenommen.

[hexenmeister]

Nein. Meine Frage ist, kann ich diese Module ganz OHNE MQTT2_SERVER verwenden oder nicht?

[hexenmeister]

Ich verwende beides nicht, es geht jedoch um eine prinzipielle Klärung, ob es akzeptabel ist, die bestimmte Anwendungsfälle auszuschließen.
Ein Modul, was nicht weiter entwickelt wird im Gegensatz zu seinen Pendant ist über kurz oder lang tot.

Ich spreche nicht von einer Verschwörung, ich will nur alle sensibilisieren, das es gerade eine unnötige Spaltung herbei geführt wird.

[hexenmeister]

Wenn es nur Konfiguration ist, dann habe ich es falsch verstanden und müsste mir alles mal genau ansehen.
Dennoch finde ich, die Entwicklung geht in die falsche Richtung. Ist natürlich nur meine Meinung.

[Beta-User]

Jedenfalls um Moment kannst du das Modul mqtt2_device nur mit dem zugehörigen Server-Modul verwenden. Die Hardware kannst du aber auch mit mosquitto sprechen lassen und auf dem bisherigen - schwerer zu konfigurierenden Weg einrichten. Es gibt allerdings nach meiner Kenntnis noch keine vollwertigen Beispiele für Hue-Geräte unter den alten Modulen.

Daher nochmal: das Beste aus usersicht wäre, das (eine!) Client-Device-Modul einrichten zu können und dann das IO (also die broker-Komponente) nach Belieben wechseln zu können...

M.E. geht die Diskussion jetzt in die richtige Richtung: aus usersicht geht es nur um Konfiguration! Und die ist in Rudi's Modul m.E. benchmark (templates mal vorweggenommen, aber eigentlich auch jetzt schon...)

[hexenmeister]

Ich fand die alten Module nie besonders toll. Aus meiner Sicht, das Richtige wäre, wir tun uns zusammen und schaffen einen kompatibles Pendant zum MQTT2_SERVER für Anbindung von externen Servern. MQTT2_CLIENT oder so.