XiaomiMQTTDevice zu MQTT2

Begonnen von IcedEarth, 14 August 2020, 12:18:07

Vorheriges Thema - Nächstes Thema

IcedEarth

Hallo zusammen,
vorab: ich weiß, dass es hier einige Thread zu dem Thema gibt, aber da ich ein recht umfangreiches Setup mit vielen Geräten habe, würde ich mich gerne absichern, bevor ich das verhunze ;-)
Meine aktuelle Situation:
Auf meinem RPi läuft zigbee2mqtt und ich hatte es damals als XiaomiMQTTDevice device über einen mosquito mqtt broker eingebunden. Der Service läuft auf 1883.
Als Geräte habe ich ca 46. Darunter sind viele Aqara Temperatur und Fenstersensoren sowie Osram und Innr Plugs. Diese Geräte sind aktuell wie folgt benannt:
Aqara_DS_XXXX_YY
Aqara_TS_XXXX_YY
Aqara_MS_XXXX_YY
Aqara_VS_XXXX_YY
Aqara_WS_XXXX
IKEA_Button_X
Innr_Plug_XX
Tradfri_XX
Osram_SP_X

Ich habe  öfter gelesen, dass Unterstriche in den Namen Probleme verursachen können. Ist das der Fall?
Außerdem würde ich gerne wissen, ob ich alle Devices auf einen Rutsch "migrieren" kann, oder ob FHEM das nicht verträgt?

Mein Plan wäre jetzt,
(1) einen MQTT2 server anzulegen (auf 1884)
(2) die configuration yaml. von zigbee2mqtt anpassen (den Port auf 1884 ändern)
(3) zigbee2mqtt wieder starten
(4) warten bis die devices mit autocreate angelegt werden
(5) hoffen, dass alles ohne größere Zwischenfälle funktioniert
(6) eventuelle Anpassungen durchführen

Habe ich was übersehen, das Probleme verursachen kann?
Gibt es Tipps von jemandem, der das schon mal durchgemacht hat?

Viele Grüße

Beta-User

Dass Unterstriche in Devicenamen ein Problem darstellen sollen, wäre mir neu.

Zum Umzug selbst:

Was läuft denn sonst noch über den mosquitto?

Wenn darüber nur zigbee2mqtt läuft, sollte es einfacher sein, den mosquitto zu stoppen und den M2_SERVER auch auf 1883 anzulegen. Wenn alles klappt, kannst du den mosquitto deaktivieren oder deinstallieren, wenn nicht, änderst du einfach den Port vom Server für den weiteren "Echtbetrieb" und kannst später weitermachen.

Wenn du irgendwo Probleme bekommst, kannst du immer noch hergehen, und einen M2_CLIENT iVm. dem mosquitto verwenden und damit schon mal die "fertig umgezogenene" Devices im FHEM betreiben (du mußt dann nur bei denen das IO umstellen).

Wenn sonst noch einiges über den Broker läuft, wäre es ggf. insgesamt einfacher, mit M2_CLIENT zu arbeiten, du benötigst dann allerdings einen Zwischenschritt mehr (was, ist im Wiki zu M2_CLIENT zu finden, ggf. nochmal nachfragen, falls danach noch was unklar bleibt oder wg. der individuellen Gegebenheiten anzupassen wäre).

Wie umfangreich ggf. die "Nacharbeit" wird, hängt davon ab, was du im Einsatz hast (Lightscene mag es z.B. nicht, wenn Devices gelöscht werden).
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

IcedEarth

Nabend,
danke Dir für die Infos.
Sind alle über zigbee2mqtt angeschlossen - sollte also einfach(er) sein, als wenn man ein wildes Konvolut an Geräten hat.
Wenn ich also den mosquitto Server stoppe, dessen Port auf 1884 ändere, dann den MQTT2 Server (mit autocreate simple) in FHEM mit 1883 starte und dann zigbee2mqtt starte, sollten also alle Geräte nach und nach angelegt werden? Die sind dann ja quasi doppelt vorhanden: Einmal als XiaomiMQTTDevice und dann als MQTTDevice. Übernehmen die dann dann den friendly_name des Gerätes?

Viele Grüße

Beta-User

Hmm, da alle MQTT-Daten sowieso aus einer Quelle kommen, würde ich hier mit MQTT2_CLIENT (autocreate auf simple setzen) arbeiten, dann aber auf das "erste Device" das zigbee2mqtt-Bridge-template anwenden; das ganze ggf. in einer Testumgebung.
Kann sein, dass du hinterher noch was an der CID dieses ersten Geräts ändern mußt, aber das sollte es auch schon gewesen sein, was (in diesem Fall!) an Unterschied zum Einsatz zu MQTT2_SERVER besteht...

Ansonsten: nicht so erschrocken; du mußt irgendwann ein Gefühl für diese Sache entwickeln, zu viel vorab Fragen hilft nur bedingt weiter ;) .
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

IcedEarth

Normalerweise bin ich relativ unerschrocken. Ich habe aber keinen Bock alle Sensoren neu zu pairen, wenn irgendwas schief läuft :-D
Ich deaktviere also den mosquitto, aktiviere den MQTT2Server auf 1883, Erstelle ein MQTT2Client als brdige (wie in der Wiki unter dem Punkt "Define eines MQTT2-Devices als "Bridge"" erklärt. und starte dann zigbee2mqtt wieder?

In dem Wiki Artikel ist ja der folgende Block gezeigt:
defmod MQTT2_zigbee_pi MQTT2_DEVICE zigbee_pi
attr MQTT2_zigbee_pi IODev MQTT2_FHEM_Server
attr MQTT2_zigbee_pi readingList zigbee_pi:zigbee2mqtt/bridge/state:.* state\
  zigbee_pi:zigbee2mqtt/0x90fd9ffffe65db16:.* { json2nameValue($EVENT, ) }\
  zigbee_pi:zigbee2mqtt/0x90fd9ffffe0bcd51:.* { json2nameValue($EVENT, ) }\
  zigbee_pi:zigbee2mqtt/bridge/log:.* { json2nameValue($EVENT, 'log_') }
attr MQTT2_zigbee_pi room MQTT2_DEVICE


Mir ist nicht klar, woher diese Zeilen kommen:
zigbee_pi:zigbee2mqtt/0x90fd9ffffe65db16:.* { json2nameValue($EVENT, ) }\
das scheint ja irgendein device zu sein?


Viele Grüße
Oder brauche ich gar den Weg über das MQTTCLIENT Device gar nicht, wenn ich eh auf den MQTT2Server umstellen will?

Beta-User

Gerade weil ich davon ausgehe, dass du möglichst wenig Brüche haben willst, war meine Empfehlung, mit der Umstellung auf MQTT2_SERVER zu warten, bis mehr oder weniger alles fertig ist.
Fange mit mosquitto+MQTT2_CLIENT an. Die Formel ist: MQTT2_SERVER=mosquitto+MQTT2_CLIENT

Und ja, das template braucht irgend eine Chance, den Topic-Pfad zu analysieren, dann werden keine Rückfragen gestellt. Häufig (aber nicht immer) ist es egal, wo das herkommt...
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

ZitatIch habe aber keinen Bock alle Sensoren neu zu pairen, wenn irgendwas schief läuft :-D
Dieses Problem sehe ich nicht, man aendert in zigbee2mqtt (wenn ueberhaupt) nur die Adresse des MQTT Servers.

ZitatDie Formel ist: MQTT2_SERVER=mosquitto+MQTT2_CLIENT
Ich wuerde eher sagen: MQTT2_SERVER=mosquitto+MQTT2_CLIENT+MQTT2_DEVICE(bridge).

Zitatzigbee_pi:zigbee2mqtt/0x90fd9ffffe65db16:.* { json2nameValue($EVENT, ) }\
Das sind die "Anweisungen", die sagen, wie ein MQTT Topic:Message in ein FHEM ReadingName:Wert zu mappen sind.
Im Normalfall werden sie per autocreate einem FHEM-Geraet hinzugefuegt, der Benutzer muss nichts machen.
Es ist aber auch moeglich diese Attribute per attrTemplate zu setzen, wenn man das automatisch angelegte verbessern will.

Beta-User

Zitat von: rudolfkoenig am 16 August 2020, 08:54:59
Ich wuerde eher sagen: MQTT2_SERVER=mosquitto+MQTT2_CLIENT+MQTT2_DEVICE(bridge).
Auch nicht ganz falsch.

Was ich geschrieben hatte ist evtl. auch mißverständlich bzw. nach etwas nachdenken hatte ich meine Meinung geändert: Hier ist es m.E. einfacher, erst mosquitto noch eine Weile am Laufen zu halten und Hardware-Gerät für Hardware-Gerät umzustellen, und dann erst ganz am Ende den Schwenk von M2_CLIENT+mosquitto hin zu M2_SERVER zu machen.
So kann man erst mal beide Wege parallel am Laufen halten und sehen, wie MQTT2_DEVICE "tickt" und welche Unterscheide ggf. bestehen.

Wir sind uns in jedem Fall einig, dass M2_SERVER das Ziel sein sollte.
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

IcedEarth

Ich danke euch für den Input. Werde das dann am Wochenende mal angehen - wenn ich etwas Ruhe habe ;-)
Werde sicherlich noch die ein oder andere Frage haben.
Bis dann!