MQTT gegen MQTT2 tauschen?

Begonnen von Jogi, 25 Januar 2021, 14:42:50

Vorheriges Thema - Nächstes Thema

Jogi

Vorab: Habt Rücksicht mit mir, ich kenne mich mit MQTT nicht gut aus und werde -trotz Recherchieren in Commandref & Co.- nicht wirklich schlau.
Ich habe mir vor ein paar Jahren mehrere Homestatusdisplays nach diesem Muster gebaut: https://forum.fhem.de/index.php/topic,68948.0.html
Seitdem habe ich mich nicht mehr mit MQTT beschäftigt.
Ich habe ein paar Shellies, die ich mit dem Shelly-Modul betreibe.

Jetzt wollte ich einfach mal etwas freie Zeit nutzen und probieren einen Shelly per MQTT zu steuern.
Vorab, das habe ich hinbekommen.
ABER: Bei meinen Recherchen habe ich festgestellt, dass es jetzt MQTT2 gibt und das wohl der modernere Weg ist. Den Shelly habe ich damit auch eingebunden.
Das bedeutet, ich habe jetzt MQTT
defmod mqtt MQTT raspberrypi:1883
attr mqtt room MQTT

mit der Ansteuerung der LED´s für das Statusdisplay, z.B.:
defmod mqtt_Garage MQTT_BRIDGE Garage
attr mqtt_Garage IODev mqtt
attr mqtt_Garage publishState fhem/status/door/Garage
attr mqtt_Garage retain 1
attr mqtt_Garage room MQTT
attr mqtt_Garage stateFormat transmission-stat


als auch MQTT2
defmod MQTT2_Server MQTT2_SERVER 1884 global
attr MQTT2_Server group Shelly_MQTT


Macht das Sinn, oder sollte ich alles auf MQTT2 umstellen. Geht das überhaupt? Oder never change a running system?

Prinzipiell funktioniert alles, aber wenn man schon mal -Corana sei Dank :(-Zeit hat, kann man ja auch optimieren, falls es sinnvoll ist.

Natürlich habe ich bei dem oben erwähnten Beitrag für das Homestatusdisplay mal nachgeschaut, ob da im ersten Post eine Aktualisierung ist, aber der letzte Eintrag dort ist von 2017.
Daher frage ich jetzt hier.


Beta-User

Vermutlich gibt es für diese Frage keine allgemeingültige Antwort, und sich jeweils wieder in eine andere Lösung einzudenken, erfordert eben u.A. auch etwas Zeit...

Tendenziell ist es so, dass bisher praktisch bei allen Umsteigern in Richung MQTT2-Module relativ schnell Erleichterung eingekehrt ist und diese als echte Verbesserung empfunden werden.

Die MQTT2-Module können (zumindest derzeit) nicht alles (QoS Level 2 z.B. nicht), aber für die meisten Anwender ist die Funktionalität völlig ausreichend, von daher wäre meine Empfehlung, alles umzustellen. Siehe dazu auch https://forum.fhem.de/index.php/topic,117980.0.html als eine Usermeinung...

Im ersten Schritt müßte es bereits möglich sein, den mosquitto schlicht durch den MQTT2_SERVER zu ersetzen, den solltest du auch (vorerst) ohne weiteres für das bisherige Interface ("defmod mqtt MQTT raspberrypi:1883" bzw.: warum extern und nicht "localhost"; der läuft doch auf derselben Hardware, oder?) weiterverwenden können, dann kannst du das nach und nach machen...

MQTT_BRIDGE ist etwas "angestaubt", das würde ich so oder so durch einen anderen Mechanismus ersetzen. Dafür gibt es mehrere Möglichkeiten, zwei davon:
- entweder durch eine notify/publish-Lösung (direkt über eines der MQTT-Interfaces, das geht mit 00_MQTT und MQTT2_(CLIENT|SERVER), oder
- MQTT_GENERIC_BRIDGE.

Letztere funktioniert ziemlich ähnlich wie das Modul MQTT_BRIDGE, aber eben nicht 1:1 mit einem anderen FHEM-Device (hier: Garage), sondern es reicht eine Modulinstanz, um beliebig viele FHEM-Devices mit einem MQTT-Interface zu verbinden. Die "minimalinvasive Lösung" für dich wäre, erst mal das Display über die MQTT_GENERIC_BRIDGE zu befüllen. Wenn du damit fertig bist, könntest du diesen ganzen Zweig recht einfach auch über den MQTT2_SERVER abbilden, indem du schlicht den ESP auf 1884 umbiegst und die MQTT_GENERIC_BRIDGE dann über diesen Server als IODev anbindest.

Damit (Umhängen) solltest du aber ggf. noch kurz warten, wir sind grade dabei, das Zusammenspiel noch etwas zu verbessern, so dass auch autocreate ohne Umstände aktiv bleiben kann...

Sag' einfach Bescheid, ob und wie du es haben willst, dann findet sich bestimmt der eine oder andere Helfer!
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

Jogi

Vielen Dank für die ausführliche Antwort.
Da habe ich schon mal was zum Reindenken und Experimentieren.
Ich fang einfach die nächsten Tage mal an und wenn ich Fragen habe melde ich mich.
Bevor ich das komplett umhänge dauerte es eh noch etwas.

Eins habe ich nicht verstanden:
("defmod mqtt MQTT raspberrypi:1883" bzw.: warum extern und nicht "localhost"; der läuft doch auf derselben Hardware, oder?)
Du meinst
localhost Richtig oder verstehe ich was falsch?

Warum ich das so gemacht habe weiß ich nicht.
Wahrscheinlich, weil ich das in einem Beispiel mal so gesehen habe und es nicht besser wusste.




Beta-User

Gemeint war: Wenn mosquitto auf derselben Hardware läuft, sollte es gehen mit
defmod mqtt MQTT localhost:1883
oder direkt via IP:
defmod mqtt MQTT 127.0.0.1:1883

Kannst du ja mal testweise umstellen und sehen, ob dann noch was ankommt...
(Oder auch mal an den M2_SERVER umstellen mit
defmod mqtt MQTT 127.0.0.1:1884
Dann müßtest du halt auch die externe Stelle (den ESP für das display) auf 1884 umbiegen (über dessen Web-Interface, falls er eines hat)...)
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

Jogi

#4
Alles klar, Danke. Habe es gerade mal ausprobiert:
Das funktioniert:
defmod mqtt MQTT 127.0.0.1:1883
Das auch:
defmod mqtt MQTT localhost:1883

Letzteres lasse ich jetzt so.