Frage zu MQTT und MQTT2

[mark79]

Zwei MQTT Server machen im allgemeinen gar keinen Sinn.

Zum umstellen macht das schon Sinn, man will ja nicht alles auf einmal machen und es gibt auch Anwendungen, die man nicht über MQTT2_SERVER schicken möchte.
Mein bestes Bespiel ist SNIPS (alexa in lokal), dort werden die Audio Daten über MQTT übertragen.

[Beta-User]

Für mich ist in deinen Schilderungen weiter völlig unklar, wie IO-Devices und Mqtt-devices (deine eigentlichen Geräte) zusammenhängen. Du scheint ja zwei Systeme parallel zu betreiben.
Also wo ist nun ein Broker, was ist das (scheinbar nur noch mqtt2-server, nirgends mehr mosquitto).
Dann muss auf diesem mit dem richtigen Modul zugegriffen werden. Also mqtt2-device für den Rechner mit dem mqtt2-server, und _auf allen anderen_Rechnern mqtt2-client zusätzlich dazwischen.
Oder eben mosquitto und nur noch jeweils ein IO (mqtt2-client).

Die Option, den mqtt2-server mit dem (klassischen) mqtt- Modul zu brücken, ist IMO nicht gut. Lieber (zumindest) erst mal mosquitto am laufen halten und darauf (auch) mit mqtt2-client zugreifen. Dann ggf. langsam umstellen...

Ich hoffe, das wird nun klarer.

Ein list vom ...-device sagt übrigens NICHTS über das IO (ausser dem beliebig austauschbaren Namen).

[hexenmeister]

Zum umstellen macht das schon Sinn, man will ja nicht alles auf einmal machen und es gibt auch Anwendungen, die man nicht über MQTT2_SERVER schicken möchte.
Mein bestes Bespiel ist SNIPS (alexa in lokal), dort werden die Audio Daten über MQTT übertragen.

Ich verstehe schon, wenn man zwei Server zusammen verbindet (BridgeModus), aber zwei getrennte? Muss schon ein Speziallfall sein.
Und wenn man schon ein Mosquitto laufen hat, wozu dann der zweite Server? Mosquitto ist performant genug, Audiodaten samt dem Rest zu übertragen. MQTT2_SERVER ist dafür eher nicht gedacht (und geeignet).

[moonsorrox]

OK kurze Erklärung

Neuer Fhem Server IP 10.0.0.51
Dell T20 mit OMV und einigen VMs u.a. eben der Fhem Server in einer VM

MQTT2_Server - Name - m2server
2 MQTT2 Geräte - die ich noch nicht brauche aber umgestellt habe
---------------------------------------------------------------------------------

Alter Fhem Server IP 10.0.0.50
Intel-NUC i3

MQTT_Server - Name - myBroker (mosquitto)
Hier sind weitere 6 MQTT Geräte angemeldet die aber arbeiten wie z.B. Beleuchtung Garten usw.
-----------------------------------------------------------------------------------------------------------

Beide Fhem Server laufen noch parallel, weil ich am Neuen noch keine Homematic Geräte drin habe das wird noch etwas Arbeit geben.
Deshalb laufen die beide.

Naja mir wurde ja gestern gesagt warum ich nicht gleich auf MQTT2 umstelle und somit habe ich damit begonnen. 
Auf dem Neuen habe ich auch kein mosquitto installiert.

Tja was ist nun richtig/gut jetzt bin ich am zweifeln?
2 Screenshots neuer und alter Fhem Server auf dem alten sind nicht alle Geräte zu sehen, einfach nur als Information

[hexenmeister]

Welche ist denn die weniger performante Lösund.?
Ich dachte die MQTT2 Lösungen sind die neuen besseren.

MQTT2-Geräte sind neuer, beim besser kommt es darauf an. Sie sind leichter zu konfigurieren (von der MQTT_GENERIC_BRIDGE abgesehen) und sind vermutlich sauberer implementiert. Der einzige noch vorhandene Vorteil von alten MQTT-IO liegt daran, dass dieser automatisch nur die in vorhandenen FHEM-Devices konfigurierte Topics aboniert und MQTT2_SERVER lauscht einfach auf alles. Wenn das verbessseert wird, würde ich einen Verbund aus mosquitto und MQTT2_CLIENT am performantesten schätzen. Zugegeben, in kleinen Installationen wird der Unterschied nicht auffallen.
Einen MQTT2_SERVER würde ich entweder den absoluten Anfängern empfehlen, oder für die Fälle, wo Installation von mosquitto (bzw. einem anderen Broker) nicht in Frage kommt bzw. unverhöltnissmäßig wäre.

[hexenmeister]

Tja was ist nun richtig/gut jetzt bin ich am zweifeln?

Ok, habe jetzt was von 6 Geräten gelesen. Für die paar Nachrichten ist es absolut egal, welche Lösung man nimmt.

[mark79]

Ich verstehe schon, wenn man zwei Server zusammen verbindet (BridgeModus), aber zwei getrennte? Muss schon ein Speziallfall sein.
Und wenn man schon ein Mosquitto laufen hat, wozu dann der zweite Server? Mosquitto ist performant genug, Audiodaten samt dem Rest zu übertragen. MQTT2_SERVER ist dafür eher nicht gedacht (und geeignet).

Ich meinte das so, wenn man gerade umstellen will, z.B. vom MQTT_DEVICE oder Generic auf MQTT2_SERVER, dann bindet man einen Tag lang z.B. die Xiaomi Sachen an und am anderen Tag die Tasmota, ESPeasy Sachen. In der Zeit muss man zwei MQTT Server laufen lassen.

Ich bin bei dir, ich halte den MQTT2_Client auch für besser, weil der mosquitto-server performant, schlank und stabil ist. Ich finde es nur etwas schade, das der MQTT2_Client die Devices nicht auch wie MQTT2_Server automatisch anlernt. Man muss erst ein bridgeRegexp setzen.

Aber das ist jammern auf hohen Niveau und ich habe vorher immer die ganzen mqtt_generic Devices per Hand angelegt. Nur wenn man mal neu anfängt, dann sollte es komfortabler werden.

[mark79]

@moonsorrox am besten postest du mal ein list von einem Device was nicht funktioniert oder nicht eingebunden wird. Mit den Screenshots kann man jedenfalls nix anfangen.
So wie ich das verstanden habe, muss man auch bei Tasmota/ESPeasy so was wie eine Client ID setzen, damit es automatisch erkannt wird und angelernt wird. Aber da sind die anderen hier fitter drin. Ich habe das bisher nur einmal getestet.

[Beta-User]

Danke, jetzt wird das Bild klarer, wie die aktuelle Situation aussieht.
So einen Umzug auf Raten wäre nix für mich, daher die Irritationen.

In der konkreten Situation - unter der Annahme, dass nicht wesentlich mehr mqtt-Geräte (v.a. von weiteren fhem-installationen oder mit großem Datenaufkommen) dazu kommen - würde ich auch perspektivisch nur noch den mqtt2-server nutzen und dann eben Gerät für Gerät (bzw Funktionsgruppenweise) in die neue Installation übertragen.

Meine Serverwechsel waren bisher immer so geartet, dass ich fhem unmittelbar komplett umgezogenen habe. Dazu muss man ggf. dann manches vorbereiten - so hätte ich z.B. den mqtt2-client (o. evtl. auch -Server) auf dem Altsystem parallel betrieben, alles mit mqtt2-client+device umgestellt und dann erst beim Wechsel der zentralen Hardware das IO umgebogen auf mqtt2-server und dabei die IP+Port und Zugangsdaten vom bisherigen mosquitto genutzt....
Damit könnte man dann die neue cfg dann - jedenfalls für diesen Part - im Prinzip ohne besondere Perl-Voraussetzungen auf jede andere (Linux-)Plattform umziehen.
Man lernt nie aus.

[hexenmeister]

So wie ich das verstanden habe, muss man auch bei Tasmota/ESPeasy so was wie eine Client ID setzen, damit es automatisch erkannt wird und angelernt wird.

Nein, Jeder Client in MQTT-Netztwerk muss eine ID besitzen. Und zwar eindeutig, sonst gibt es Probleme.
Leider sieht MQTT-Protokoll es nicht vor, die ClientID des Senders mit in die Nachrichten an die Abonennten einzupacken. Daher klappt Autocreate nur begrenzt. Aus meiner Sicht überhaupt kein Verlust. Ich habe 7 FHEM-Instanzen mit Hunderten von unterschiedlichen Topics. Ein Autocreate würde mir in einer Minute alles mit neuen unsinnigen FHEM-Devices zuzuballern. Ich nutze dieses Teufelszeug nicht

[moonsorrox]

Also zur Rückmeldung es ist nicht so das es nicht funktioniert.
Ich habe jetzt zwei Geräte auf meinem alten System auf MQTT2 geändert wobei er mir eines davon ja schon mit autocreate erstellt hat, bis ich die alle so angepasst habe dauert etwas... Und in FTUI muss ich dadurch auch einiges umändern.
Aber funktionieren tun sie...
ich wollte es mir leichter machen mit dem Umzug und der gleichzeitigen Änderung auf MQTT2 

Ich habe auf meinen alten Fhem einfach einen MQTT2 Server mit einem anderen Port 1885 installiert und damit geht das 
Auf dem neuen System später dann gibt es wie gesagt keinen MQTT Server mehr da setze ich dann den MQTT2 Server ein und somit brauche ich dann beim Umzug nichts weiter ändern außer den Port auf den Tasmota/Sonoff Geräten und das sehe ich nicht als Problem.

Oh was macht man denn mit 7 Fhem Instanzen

[hexenmeister]

Oh was macht man denn mit 7 Fhem Instanzen

Die verschiedenen Geräte, Logik etc. voneinander trennen. Kann man als eine Art Multitaskingerweiterung für fhem betrachten. Sie laufen parallel und liefern auf der gleichen Hardware bessere Reaktionszeiten.

[moonsorrox]

OK... verstehe ich nur zum Teil 
Ich hatte mir darüber auch mal Gedanken gemacht, aber dann habe ich Probleme mein FTUI darzustellen. Das funktioniert ja nur auf einem Gerät und dann kann er nur die Geräte auf der Fhem Instanz darstellen.
Sicher arbeitest du mit dem ioBroker und hast dann alle 7 Fhem Instanzen in diesem integriert..?

Mein MQTT2 funktioniert mit den zwei Geräten die ich gestern integriert habe, nur meine FTUI Anzeige will da noch nicht so richtig, muss da mal im FTUI Forum fragen, denn vorher ging das super. Er schaltet zwar wenn ich von Hand dort klicke aber er aktualisiert den Zustand nicht.

[rudolfkoenig]

Um evtl. etwas mehr Klarheit zu schaffen:

- ich habe MQTT2_SERVER gebaut, damit man moeglichst einfach MQTT Geraete in FHEM einbinden kann. Fuer diese Faelle benoetigt man neben MQTT2_SERVER die (automatisch) angelegten MQTT2_DEVICE Instanzen.
- eine Alternative mit weniger autocreate Moeglichkeiten ist mosquitto + MQTT2_CLIENT + (selbst definierte) MQTT2_DEVICE Instanzen.

- einige Benutzer (hexenmeister?) verwenden MQTT als "FHEM2FHEM Ersatz", bzw. um FHEM als Treiber fuer Node-Red/ioBroker/etc einsetzen zu koennen (das war mir Anfangs nicht klar). Fuer diese Benutzer ist sowas wie ein MQTT_GENERIC_BRIDGE notwendig, die (ueber MQTT) die bereits angelegten ZWave/CUL_HM/FS20/dummy/etc FHEM-Instanzen mit entsprechenden Instanzen auf den anderen FHEM/IoBroker/etc Installationen synchronisiert.
- MQTT_GENERIC_BRIDGE funktioniert z.Zt. nur mit dem "alten" MQTT Modul (entspricht in etwa MQTT2_CLIENT), es wird aber daran gearbeitet sie "MQTT2 faehig" zu machen. Damit wird man ueber  MQTT2_SERVER oder (mosquitto + MQTT2_CLIENT) sowohl "richtige" MQTT Geraete bedienen, wie auch andere FHEM-Instanzen miteinander synchronisieren.

[betateilchen]

- einige Benutzer (hexenmeister?) verwenden MQTT als "FHEM2FHEM Ersatz" ... (das war mir Anfangs nicht klar)
...
wie auch andere FHEM-Instanzen miteinander synchronisieren.

Das ist insbesondere dann interessant, wenn die FHEM Installationen nicht innerhalb eines einzelnen lokalen Netzwerkes laufen, sondern räumlich voneinander getrennt sind.

Einfaches Szenario bei mir zuhause:

- In der Wohnung läuft ein FHEM im lokalen Netzwerk mit DSL Anbindung
- Im Schuppen des Carports läuft ein FHEM auf einem RaspberryPi, der mittels UMTS Datenstick ins Internet geht (zu weit entfernt für das eigene WLAN)

Es ist nicht (zumindest nicht ohne immensen Aufwand) möglich, diese beiden Instanzen per FHEM2FHEM zu verbinden, ohne Netzwerkzugänge von außen freigeben zu müssen. Insbesondere die Provider von Mobilfunk-Datendiensten blockieren zudem i.d.R. den Zugriff von aussen komplett.

Also habe ich beide FHEM Instanzen per MQTT an einen mosquitto angebunden, der bei AmazonWebServices auf einer Lightsail Instanz in Irland Frankfurt (Main) läuft. Und schon kann ich aus der Wohnung das Licht im Carport (Homematic Aktor) einschalten. Und mein FHEM in der Wohnung empfängt aus dem Carport die Daten der Wettersensoren und den mit diesem Abstand vom Wohnhaus sehr gut funktionierenden Gewitterwarner.