Hilfe: MQTT vs MQTT2

Begonnen von Tungsten, 20 März 2019, 18:34:05

Vorheriges Thema - Nächstes Thema

Tungsten

Hallo Zusammen,

ich habe eine Frage zum Einbinden eines CC2531 Zigbee Sticks. Ich habe bereits Mosquito auf dem Pi laufen und über MQTT Sonoff-S20 Steckdosen in Betrieb.

Nun würde ich gerne den CC2531 Zigbee Sticks auch einbinden. Ich lese nun verschiedene Angaben bzgl Installation. Was muss ich genau machen?

- geht beides parallel? Port 1883 ist durch MQTT bereits belegt. Habe einen MQTT2-Server mal angelegt, der bleibt aber auf 'MQTT2_FHEM_Server initilized'

- Muss ich Mosquito rausschmeißen, einen MQTT2-Server aufsetzen mit Port 1883 und alle bisherigen MQTT Gerät mit MQTT2 neu verbinden?

Wer kann mich aufs richtige Pferd setzen?

rudolfkoenig

Zitatgeht beides parallel?
Klar, mit unterschiedlichen Ports "beliebig" viele.

ZitatMuss ich Mosquito rausschmeißen, einen MQTT2-Server aufsetzen mit Port 1883 und alle bisherigen MQTT Gerät mit MQTT2 neu verbinden?
Also muessen muss man gar nichts, siehe https://wiki.fhem.de/wiki/MQTT#MQTT2
Aber ich wuerde MQTT2_SERVER empfehlen, da es vieles vereinfacht.  Falls man mosquitto stoppt, und 1883 auf dem gleichen Server von MQTT2_SERVER bedient wird, dann muss man an den Endgeraeten nichts aendern. Dieser Server kann auch von anderen "MQTT-Empfaenger" verwendet werden, genauso wie mosquitto, "nur" die FHEM-interne Anbindung wird einfacher.

Wenn in FHEM MQTT und MQTT_DEVICE Instanzen definiert wurden, dann sind diese alle hinfaellig, und durch MQTT2_DEVICE zu ersetzen.

Beta-User

Vielleicht noch eine Anmerkung:

Die "minimalinvasive" Methode dürfte die sein, erst mal den MQTT2_CLIENT zu nutzen, da aber dann das Attribut "subscriptions" zu nutzen und das auf den zigbee-Topic zu beschränken.

Dann sollte es "ungefährlich" sein, autocreate am 2-er Client anzuschalten (simple reicht hier).

Bitte dann nur darauf achten, bei dem zigbee-Brückengerät eine andere CID zu verwenden als gerade die des MQTTT2_CLIENT (Kopie vom autocreate-Gerät erstellen, analog https://wiki.fhem.de/wiki/MQTT2_CLIENT#Anwendung zum GeneralBridge-template).

Wäre nett, wenn du das austesten könntest; so kannst du ggf. auch einfach deine weiteren Geräte nacheinander auf MQTT2_DEVICE umstellen, (wenn du das magst), und mußt nicht gleich alle anfassen...
Sind alle "auf MQtt2_DEVICE", kannst du zum Schluß den mosquitto durch MQTT2_SERVER ersetzen.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Tungsten

Danke Euch, habe es gestern Abend noch geschafft. Bin aber noch nicht ganz glücklich.

Hatte im MQTTT2_CLIENT nicht auf subscriptions gefiltert und autocreate auf complex.
Somit wurden auch die Sonoff gefunden und angelegt, jedoch alle in einem device.

Hier mal ein list vom MQTTT2_CLIENT, nun aber mit subscriptions und autocreate simple.


Internals:
   BUF       
   CFGFN     
   DEF        127.0.0.1:1883
   DeviceName 127.0.0.1:1883
   FD         53
   FUUID      5c928aee-f33f-2776-fa39-8e88f34400008e36
   NAME       MQTT_via_mosquitto
   NR         3429
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   MQTTviamosquitto
   lastMsgTime 1553152332.52074
   nextOpenDelay 5
   READINGS:
     2019-03-21 08:10:12   state           opened
Attributes:
   DbLogExclude .*
   autocreate simple
   disable    0
   room       MQTT,MQTT2_DEVICE
   subscriptions zigbee

Beta-User

Du kannst das auch nachträglich noch umstellen mit simple und den subscriptions...

Würde jetzt: CLIENT umstellen und zwei Kopien des vorhandenen Devices ("Sammeldevice") machen.
Eine bekommt eine für die zigbee-Bridge passende CID (das kann ein Phantasiewert sein!), die andere eine andere CID. Auf die erste wendest du das zigbee-Bridge-Template an, auf das andere die "00_General-Bridge".

_DANACH_  kannst du die readingList vom "Sammeldevice" löschen und deine ganzen zigbee-Geräte sollten nach und nach erstellt werden.... Wenn nicht, "save" nicht vergessen und ggf. den CLIENT nochmal "anfassen", dass der seine subscriptions abruft (alternativ: einen restart von FHEM durchführen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

ZitatSomit wurden auch die Sonoff gefunden und angelegt, jedoch alle in einem device.
Das ist normal bei MQTT2_CLIENT, da es nicht ueber clientId verfuegt. Hier ist autocreate nur mit einem bridgeRegexp sinnvoll.

MQTT2_SERVER kann Geraete genau trennen, und fuer jedes ein eigenes MQTT2_DEVICE anlegen.
Dafuer kann man nicht Schrittweise umstellen.

Tungsten

Ich muss Euch noch einmal belästigen...

Ich glaube ich werde von MQTT auf MQTT2 umstellen.

Gibt es dafür eine kleine Anleitung welche Schritte in welcher Reihenfolge nötig oder best-practices sind?
Muss man alle Devices neu anlegen und alte löschen? Das heißt auch alle DOIFs usw müssen angepasst werden?
Gibt es eine einfache Migration?

danke Euch

Beta-User

"Anleitung"? Hmm, na ja....

Also hier habe ich neulich mal jemandem geholfen, von TASMOTA_DEVICE nach MQTT2_DEVICE umzustellen.
Bitte erst den ganzen Thread lesen und dann v.a. auch die daraus entstandenen aktuellen Fassungen der Einführung zu den Praxisbeispielen im Wiki (und ggf. zu MQTT2_CLIENT).

Die Umstellung scheint in dem konkreten Fall kein größeres Problem gewesen zu sein, aber ob und wie umfassend ggf. der Nacharbeitsbedarf ist, kommt sehr auf die Eventhandler (notify/DOIF etc.) an. Insbesondere: Die attrTemplates stellen von Groß-auf Kleinschriebung für on/off um.

Ansonsten wird sowieso meistens JSON ausgepackt, und da ist das Ergebnis in der Regel gleich (wenn auch die Device-Namen dann nach der Umstellung den bisherigen entsprechen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Tungsten

Hallo Zusammen,

da die Abende wieder dunkler werden wollte ich das Thema für mich noch einmal angehen und von MQTT auf MQTT2 umstellen.

Habe mir nun folgende Schritte dafür notiert.

Backup erstellen

Mosquito stoppen (port 1883)
- sudo service mosquitto stop

DOIFs sichern für Sonoff Steckdosen
DOIFs deaktivieren für Sonoff Steckdosen

Bisherige MQTT devices löschen
- MQTT device
- 5 Sonoff Geräte mit Tasmota

In Tasmota Geräten das MQTT 'full topic' wieder zu default Wert ändern
%prefix%/%topic% (Aus <https://github.com/arendst/Tasmota/wiki/MQTT-Overview> )


MQTT2 server anlegen (port 1883)
     define MQTT2_SERVER MQTT2_SERVER 1883

Neue MQTT2 devices sollten automatisch angelegt werden

Wenn erfolgreich Mosquito von Pi deinstallieren, oder zumindest autostart deaktivieren


Habe ich etwas vergessen oder übersehe ich etwas?

Danke Euch!

Beta-User

Würde das so sehen:
Backup erstellen

Mosquito stoppen (port 1883)
- sudo service mosquitto stop

DOIFs sichern für Sonoff Steckdosen
DOIFs deaktivieren für Sonoff Steckdosen

Bisherige MQTT devices löschen
- MQTT device
- 5 Sonoff Geräte mit Tasmota

In Tasmota Geräten das MQTT 'full topic' wieder zu default Wert ändern
%prefix%/%topic% (Aus <https://github.com/arendst/Tasmota/wiki/MQTT-Overview> )


MQTT2 server anlegen (port 1883)
     define MQTT2_SERVER MQTT2_SERVER 1883

Neue MQTT2 devices sollten automatisch angelegt werden - die ESP's müssen aber ggf. neu gestartet werden...

Jeweils passendes attrTemplate wählen und anwenden

Wenn erfolgreich Mosquito von Pi deinstallieren (autostart deaktivieren geht notfalls auch, aber sowas vergißt man gerne, und dann reaktiviert sich das zur Unzeit...)


Hinweise:

- Die DOIF reagieren evtl. einfach nicht mehr, wenn nicht mehr passende Events kommen (wg. Kleinschreibung, z.B.). Die müssen/können dann einfach angepaßt werden.
- autocreate setzt voraus, dass Daten kommen, was uU. im laufenden Betrieb nicht passiert.

Gruß und viel Erfolg, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Tungsten

beim define fehlte das global...

auch muss wohl das system autocreate ebenfalls aktiv sein, nicht nur im MQTT2_Server...

Backup erstellen

Mosquito stoppen (port 1883)
- sudo service mosquitto stop

DOIFs sichern für Sonoff Steckdosen
DOIFs deaktivieren für Sonoff Steckdosen

Bisherige MQTT devices löschen
- MQTT device
- 5 Sonoff Geräte mit Tasmota

In Tasmota Geräten das MQTT 'full topic' wieder zu default Wert ändern
%prefix%/%topic% (Aus <https://github.com/arendst/Tasmota/wiki/MQTT-Overview> )


MQTT2 server anlegen (port 1883)
     define MQTT2_SERVER MQTT2_SERVER 1883 global

Neue MQTT2 devices sollten automatisch angelegt werden - die ESP's müssen aber ggf. neu gestartet werden...

Jeweils passendes attrTemplate wählen und anwenden

Wenn erfolgreich Mosquito von Pi deinstallieren (autostart deaktivieren geht notfalls auch, aber sowas vergißt man gerne, und dann reaktiviert sich das zur Unzeit...)

Tungsten

kurzes Update zu den MQTT Settings in Tasmota für S20 und POW:

Die default Einstellungen für Full Topic haben keine Readings geliefert, erst nachdem ich wieder auf /SmartHome/Steckdosen/%topic%/%prefix%/ umgestellt habe kamen alle Readings an.

Beta-User

Vorab mal sorry wg. dem "global". Generell sollte man bei jedem define nochmal in die commandref sehen, solche Kochrezepte interpretiere ich eigentlich immer so, dass ich die Doku "danebenlege" und das dann so mache, wie die Doku sagt, das Kochrezept ist nur für die Stichworte.

Und dass autocreate auch als TYPE aktiv sein muß, steht auch in den Praxisbeispielen, es macht für mich nicht den Riesensinn, alles nochmal jedem einzeln zu schreiben (deswegen schreibt man doch solche Artikel, oder habe ich was verpaßt...?)

Was es mit den "Full Topic"-Problemen auf sich hat, kann ich nicht beurteilen, aber das klingt so, als wäre irgendwo noch was verbogen, kein Neustart erfolgt oä.. Eigentlich sollte es keinen Unterschied machen (die attrTemplates sollten andererseits aber sowieso auch die "Videoblog"-verbogenen Topicpfade erkennen).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Tungsten

So war das nicht gemeint, aber Leute die wie nach so was suchen sollen nicht auf falsche Infos stoßen, daher habe ich es noch einmal erwähnt.

Danke für die Hilfe.

Basti-K

Hallo Zusammen, ich stehe vor einen ähnlichen Problem.
Bis Dato wurde meine Umgebung auf MQTT (Mosquitto) realisiert.
Nun habe ich ein paar Shelly 2.5 für Rollanden und Dimmer installiert. Wenn man mehr als nur ein/ausschalten will (das geht) muss es wohl mqtt2 sein.

Ich machte ein Backup, deaktivierte den Mosquitto Dienst, löschte alle in der fhem config was damit zu tun hatte und führte folgende Befehl aus:
define MQTT2_SERVER MQTT2_SERVER 1883 global
danach blendeten sich alle Fhem Prozesse.
Den fehm Dienst kann ich natürlich neustarten aber die Änderung (Zeile) wurde nicht in die Config übernommen.
Mit einem anderen Port geht es, aber fhem öffnet auf dem Server kein TCP Port.
1883 ist aber auch nicht offen (netstat)
Geht heißt aber nicht das funktioniert, sondern das fhem nicht abstürzt.
Hat jemand eine Idee was ich vergessen habe könnte?
Fhem läuft auf einem Raspi 3 (Buster)

Gruß Sebastian