Zwei FHEMs mit MQTT2 verbinden?

[FunkOdyssey]

Hallo, ich bin nicht wirklich MQTT-erfahren, aber ich wollte zwei FHEM-Installation mit der neuen MQTT2-Lösung verbinden.

Geht das überhaupt mit der Kombination von MQTT2_DEVICE und MQTT2_SERVER?

Irgendwie fehlt mir die Bridge bzw. die Schnittstelle zwischen den beiden MQTT-Servern. Wie sehen sich die beiden Server?
Oder muss ich beim zweiten MQTT2_DEVICE als IODev einen MQTT2_SERVER mit fremder IP-Adresse angeben? Jedoch scheint die Angabe der IP-Adresse beim Define nur fürs "Listening" zuständig zu sein.

Danke.

[Beta-User]

Interessante Fragestellung.

Vielleicht könntest du etwas genauer schildern, was du genau vorhast?

Eigentlich müßte es reichen, einen der beiden FHEM-Rechner mit MQTT2_SERVER zum Broker zu machen. Der "weiß" dann alles.

Auf dem anderen richtest du "ganz normal" 00_MQTT für das GW ein (mit IP+Port vom ersten, der natürlich auch von dieser IP Daten entgegennehmen muss -> global). Dann bekommen alle Devices bzw. Readings, die du haben willst, mit MQTT_BRIDGE oder der neuen Generic Bridge das "MQTT-Sprechen" beigebracht. Und schon sollten auf dem anderen (mit MQTT2_SERVER) nach und nach die Daten landen und ggf. MQTT2-Devices automatisch angelegt worden sein (sofern autocreate gesetzt war; vielleicht läuft auch alles in ein einziges Groß-Device; dann kann man nachträglich "vereinzeln").

Bitte aufpassen, dass du dir auf diesem Weg nicht versehentlich eine Schleife reinbaust, insbesondere, wenn du zusätzlich den Weg auch noch anders herum gehst. Dazu müßten ggf. mit MQTT/MQTT_BRIDGE auch die Devices auf dem Rechner, auf dem MQTT2_SERVER definiert ist, MQTT-fähig gemacht werden.

Gruß, Beta-User (der zwar etwas MQTT und MQTT2-Erfahrung hat, aber lieber die komplette Installation auf einem Rechner laufen hat)

[FunkOdyssey]

Ich nutze Docker und habe FHEM in einem Container vergraben, der halt nicht im Host-Modus läuft.
Einige Dinge (wie FakeRoku, etc.) benötigen Broadcast und müssen im Netz (Host-Modus) gefunden werden.
Bisher habe ich kleine FHEM-Container gebastelt, die ich mit FHEM2FHEM verdrahtet habe.
Nun will ich das einmal mit MQTT ausprobieren. Generell finde ich den Ansatz viel interessanter.

[rudolfkoenig]

Die Loesung von Beta-User ist vermutlich richtig, getestet habe ich es aber nicht.

MQTT2_SERVER ist "nur ein Server", und MQTT2_DEVICE haengt ueber den FHEM-internen Dispatch Mechanismus an dem MQTT2_SERVER. Man koennte ein MQTT2_DEVICE hoechstens per FHEM2FHEM mit einem anderen MQTT2_SERVER verbinden, ob das sinnvoll ist, sei hingestellt.

[FunkOdyssey]

Danke. Das würde den Rahmen sprengen. Ich nehme es dann vorerst lieber per FHEM2FHEM wieder in Betrieb.

[Beta-User]

Danke. Das würde den Rahmen sprengen. Ich nehme es dann vorerst lieber per FHEM2FHEM wieder in Betrieb.

Klingt nachvollziehbar.

MQTT ist super, wenn die Geräte das bereits sprechen, und mit MQTT2 ist es (nach meinem persönlichen Eindruck) auch noch super-einfach, weil man außer FHEM (und ggf. etwas Spielerei mit den Frontend-Attributen) _nichts_ benötigt. Habe daher jüngst auch meinen Mosquitto wieder entsorgt.

@Rudi: Bei der Gelegenheit ein riesiges DANKE für die MQTT2-Module!

Aber wenn man die Geräte erst noch "ver-MQTT-en" muß, wird es (vermutlich) ziemlich zäh und öde, bis man ein vernünftiges Ergebnis hat.

@FunkOdyssey: Vielleicht schaust du dir zum Einstieg mal https://github.com/maddox/harmony-api an?
Sollte mit der Docker-Option einfach sein, der Harmony MQTT beizubringen. Als Server dann MQTT2_SERVER auf deinem zentralen FHEM .
Da MQTT zwischenzeitlich DAS Protokoll im HA-Bereich ist, und immer mehr Netzwerkgeräte das Sprechen können (bzw. beigebracht bekommen, siehe zigbee2mqtt usw.), ist das sicher mittelfristig sehr interessant und auch einfach zu pflegen.

Just my2ct.

Beta-User

[FunkOdyssey]

@FunkOdyssey: Vielleicht schaust du dir zum Einstieg mal https://github.com/maddox/harmony-api an?
Sollte mit der Docker-Option einfach sein, der Harmony MQTT beizubringen. Als Server dann MQTT2_SERVER auf deinem zentralen FHEM .

Da wollte ich auch schon längst ran. Das Problem ist nur, dass diese Lösung nicht mehr anbietet, als unser FHEM-Harmony-Modul.
Warum also über MQTT gehen, wenn das mit dem Harmony-Modul schneller und besser geht.
Hier geht es anscheinend "nur" darum, Aktionen auszuführen und den Status auszulesen.

FakeRoku ist ein Workaround, um Tasten eines "virtuellen Hifi-Gerätes" per Fernbedienung an FHEM senden zu können.

Es gibt auch noch die HA-Bridge, welche bei mir auch in nem Docker-Container läuft.
Damit kann man ähnliches machen, aber halt keine Tasten über ein Gerät zuordnen und in FHEM mitlesen.

Danke dennoch.

[Beta-User]

Sorry, so tief bin ich nicht in der Materie drin.

Wodurch wird denn das "virtuelle Hifi-Gerät" definiert? Das "Serial"-Attribut? Wenn es "nur" eine Art vordefinierter IR-Kommandos ist, die die Harmony für eine bestimmte ID gespeichert hat, müßte das auch ohne den Umweg gehen, ist aber ggf. ein Ratespiel, bis man alles beieinander hat.

Leider ist sowas (welche Info in welcher Form wohin) in der Regel schlecht dokumentiert, oft helfen aber die http-Requests bzw. die Analyse der UDP-Pakete (bzw. des codes, der das jeweils zusammensetzt).

Aber wie gesagt, soweit bin ich nur für die Geräte vorgedrungen, die ich selber nutze, nicht für die Harmony...

[hexenmeister]

Ich habe die MQTT_GENERIC_BRIDGE auch deswegen geschrieben, um mehrere FHEM-Instanzen miteinander zu verbinden. Da fhem eine single threaded Anwendung ist, macht das performancetechnisch schon viel aus (sprich Antwortzeiten). Aus dem gleichen Grund bevorzuge ich den mosquitto.
So trenne ich die Aktoren-Systeme nach und nach aus dem alten gesamt-fhem aus und gebe denen eine eigene Instanz. Die Oberfläche zum Bedienen ist dann wieder eine per MQTT angebundene Instanz. Da ich keine Dutzende devices und bridges zusätzlich haben möchte, verwende ich die GenericBrigde.

[Wuppi68]

Ich habe die MQTT_GENERIC_BRIDGE auch deswegen geschrieben, um mehrere FHEM-Instanzen miteinander zu verbinden. Da fhem eine single threaded Anwendung ist, macht das performancetechnisch schon viel aus (sprich Antwortzeiten). Aus dem gleichen Grund bevorzuge ich den mosquitto.
So trenne ich die Aktoren-Systeme nach und nach aus dem alten gesamt-fhem aus und gebe denen eine eigene Instanz. Die Oberfläche zum Bedienen ist dann wieder eine per MQTT angebundene Instanz. Da ich keine Dutzende devices und bridges zusätzlich haben möchte, verwende ich die GenericBrigde.

Hast Du dazu mal ein Config Beispiel?

meine Grundidee ist für den Anfang:

eine MQTT Verbindung als zentrales Log zu benutzen

Topic: /log/<Server>/<Device>/<Reading>

dort publishe ich alles was ich möchte entsprechend der Vorgabe rein

und auf der Logging Maschine dachte ich an ein Subscribe /log/+ (natürlich Rekursiv :-8 ) welches die <Devices> mit den Readings automatisch anlegt

wenn solches erst einmal steht, dann sollte der Rest quasi "problemlos" lösbar sein

[hexenmeister]

Hallo,

ein auf Dein Vorhaben abgestimmtes Beispiel habe ichleier nicht zur Hand.
Alles publishen wird kein Problem sein, s. BridgeAttribut 'globalPublish':
Etwa so:

Code Auswählen Erweitern

lobalPublish *:topic={"/log/$name"}

Subscribe in dem anderem FHEM geht natürlich auch, allerdings mit rekursiv war das nicht gedacht. Abonbieren kann man schin alles, aber Aufteilung in Readings funktioniert derzeit nur auf eine Ebene beschränkt. Mehrere Topics mit mehreren Ebenen in ein Reading zu packen geht.

Schau dir Beispiele in Commandref, probiere es aus und stelle gern Fragen, wenn was nicht funktioniert. Gern können wir auch über Erweiterungen reden

[ToKa]

Hallo Hexenmeister,

ich beschäftige mich zum ersten Mal mit MQTT und habe erste Gehversuche mit der generic_bridge und den MQTT2-Modulen gemacht. So wie von Dir geschildert, will ich mein heutiges FHEM Gesamtsystem, das auf einem Raspi läuft aufsplitten:

Ich habe die MQTT_GENERIC_BRIDGE auch deswegen geschrieben, um mehrere FHEM-Instanzen miteinander zu verbinden. Da fhem eine single threaded Anwendung ist, macht das performancetechnisch schon viel aus (sprich Antwortzeiten). Aus dem gleichen Grund bevorzuge ich den mosquitto.
So trenne ich die Aktoren-Systeme nach und nach aus dem alten gesamt-fhem aus und gebe denen eine eigene Instanz. Die Oberfläche zum Bedienen ist dann wieder eine per MQTT angebundene Instanz. Da ich keine Dutzende devices und bridges zusätzlich haben möchte, verwende ich die GenericBrigde.

Mein Ansatz ist auf dem Fhem1 (Raspi) im wesentlichen nur noch die Sensoren / Aktoren (z-wave) anzubinden, die Messwerte (z.B. Ist-Temperatur) an fhem2 (VM mit ubuntu) zu übertragen. Die Visualisierung soll dann auf fhem2 stattfinden und von dort sollen Schaltbefehle an die Aktoren (z.B. neuer Sollwert für Temperatur) gesendet werden. Ggf. benötige ich noch ein paar Readings aus dem fhem2 (z.B. Kalenderinformationen) an den fhem1 zur smarten Steuerung der Heizungsthermostate.

Nach meinen ersten Versuchen würde ich das jetzt so lösen wollen:
fhem1 (raspi)

• MQTT_GENERIC_BRIDGE mit IO-DEV MQTT2-Client
• MQTT2-Client (ohne autocreate) verbunden mit dem mosquitto auf fhem2
• publish der Readings aus den Sensoren über die bridge an fhem2
• subscribe für die Schaltbefehle der Aktoren über die bridge aus fhem2

fhem2 (VM ubuntu)

• mosquitto zum Austausch der Daten zwischen den fhem Instanzen ggf. später für andere MQTT fähige Geräte
• MQTT2-Client (mit autocreate complex) verbunden mit dem mosquitto auf fhem2
• MQTT2-Device (mit autocreate und bridgeRegexp) mit IO-DEV MQTT2-Client als "generic-bridge" auf fhem2
• neue MQTT2-Devices und Readings werden durch das autocreate automatisch angelegt
• für die Schaltbefehle fhem2 an fhem entsprechende setList Einträge in den MQTT2-Devices

Einen Knoten im Kopf habe ich noch für Readings, die ich von fhem2 an fhem1 übertragen will. Macht es Sinn bzw. geht es technisch auf dem fhem2 auch noch ein MQTT2_GENERIC_BRIDGE einzurichten ggf. an ein zweites IO-DEV MQTT2-Client (ohne autocreate)? Auf dem fhem1 dann einen zweiten MQTT2-Client (mit autocreate), der dann seinerseits neue MQTT2-Devices anlegt mit den Readings aus fhem2?

Über eine Rückmeldung, wie Du das gelöst hast, würde ich mich sehr freuen.

Beste Grüße
Torsten

[hexenmeister]

Moin,

ja, ich betreibe meine FHEM-Instanzen miteinander gebunden durch MQTT und GenericBridge.
Mein Ansatz ist jedoch etwas anders. MQTT2 benutze ich nicht, da (aus historischen Gründen) das alte MQTT-Modul ganz problemlos läuft. Das ist aber nicht so wichtig, MQTT2 soll genauso tun. Ich halte jedoch nichts davon, in einer Fhem-Instanzen zwei MQTT-Verbindungen zu definieren. Autocreate verwende ich mit MQTT nicht und finde dies in gegebener Form eher hinderlich als nützlich.

Hier ist ein Beispiel für Übertragung der Steuerung von HomeMatic-Wandthermostat in eine andere FHEM-Instanz. Schaue es dir an, frage, wenn was nicht verständlich ist.

Definitionen für Instanz mit HomeMatic-Modulen:
GenericBridge:

Code Auswählen Erweitern

defmod mqttGenericBridge MQTT_GENERIC_BRIDGE
attr mqttGenericBridge IODev mqtt
attr mqttGenericBridge alias MQTT generic bridge
attr mqttGenericBridge debug 1
attr mqttGenericBridge globalDefaults base=home sysbase=sys devbase=dev netbase=net
attr mqttGenericBridge group MQTT
attr mqttGenericBridge icon mqtt
attr mqttGenericBridge room IO_Devices
attr mqttGenericBridge stateFormat dev: device-count in: incoming-count out: outgoing-count


Wandthermostat-Gerät heißt WZ_WT01. Die (Sub)Geräte: Sensoren: WZ_WT01_Weather, Steuerung: WZ_WT01_Climate

mqtt-Bridge-Attribute an WZ_WT01_Weather

Code Auswählen Erweitern

attr WZ_WT01_Weather mqttDefaults roomid="wz" num="01" \
roomname="Wohnzimmer" \
dev_manuf="HomeMatic"
attr WZ_WT01_Weather mqttPublish temperature:topic={"$base/usr/$roomid/sen/temperature/$num/value"} \
\
temperature!json:topic={"$base/usr/$roomid/sen/temperature/$num/json"}  \
temperature!json:expression={toJSON({value=>$value,time=>"$time",reading=>"temperature",num=>"$num",unit=>"°C",\
  valuetype=>"number",format=>"00.0",roomid=>"$roomid",room=>"$roomname",display=>"Zimmertemperatur"})}\
\
temperature!info:topic={"$base/usr/$roomid/sen/temperature/$num/info"} \
temperature!info:expression={toJSON({manuf=>"$dev_manuf",type=>"sensor",categorie=>"clima",\
  reading=>"temperature",num=>"$num",unit=>"°C",valuetype=>"number",format=>"00.0",\
  roomid=>"$roomid",room=>"$roomname",name=>"$device",dev_uid=>"$uid"})}\
\
\
humidity:topic={"$base/usr/$roomid/sen/humidity/$num/value"}\
\
humidity!json:topic={"$base/usr/$roomid/sen/humidity/$num/json"}  \
humidity!json:expression={toJSON({value=>$value,time=>"$time",reading=>"humidity",num=>"$num",unit=>"%",\
  valuetype=>"number",format=>"00",roomid=>"$roomid",room=>"$roomname",display=>"Luftfeuchtigkeit"})}\
\
humidity!info:topic={"$base/usr/$roomid/sen/humidity/$num/info"} \
humidity!info:expression={toJSON({manuf=>"$dev_manuf",type=>"sensor",categorie=>"clima",\
  reading=>"humidity",num=>"$num",unit=>"%",valuetype=>"number",format=>"00",\
  roomid=>"$roomid",room=>"$roomname",name=>"$device",dev_uid=>"$uid"})}\
\



an WZ_WT01_Climate:

Code Auswählen Erweitern

attr WZ_WT01_Climate mqttDefaults roomid="wz" num="01"  roomname="Wohnzimmer"  dev_manuf="HomeMatic"
attr WZ_WT01_Climate mqttPublish desired-temp:topic={"$base/usr/$roomid/act/clima/temperature/$num/value"} \
\
desired-temp!json:topic={"$base/usr/$roomid/act/clima/temperature/$num/json"}  \
desired-temp!json:expression={toJSON({value=>$value,time=>"$time",reading=>"desired-temp",num=>"$num",unit=>"°C",\
  valuetype=>"number",format=>"00.0",roomid=>"$roomid",room=>"$roomname",display=>"Solltemperatur"})}\
\
desired-temp!info:topic={"$base/usr/$roomid/act/clima/temperature/$num/info"} \
desired-temp!info:expression={toJSON({manuf=>"$dev_manuf",type=>"actor",categorie=>"clima",\
  reading=>"desired-temp",num=>"$num",unit=>"°C",valuetype=>"number",format=>"00.0",\
  roomid=>"$roomid",room=>"$roomname",name=>"$device",dev_uid=>"$uid",display=>"Solltemperatur",act_topic="set"})}\
\

attr WZ_WT01_Climate mqttSubscribe desired-temp:stopic={"$base/usr/$roomid/act/clima/temperature/$num/set"}



Definitionen an der entfernten FHEM-Instanz

Die GenericBridge:

Code Auswählen Erweitern

defmod mqttGenericBridge MQTT_GENERIC_BRIDGE
attr mqttGenericBridge IODev mqtt
attr mqttGenericBridge alias MQTT generic bridge
attr mqttGenericBridge debug 1
attr mqttGenericBridge globalDefaults base=home sysbase=sys devbase=dev netbase=net
attr mqttGenericBridge group MQTT
attr mqttGenericBridge icon mqtt
attr mqttGenericBridge room IO_Devices
attr mqttGenericBridge stateFormat dev: device-count in: incoming-count out: outgoing-count
attr mqttGenericBridge verbose 3


Gerät für die Stuerung:

Code Auswählen Erweitern

defmod WZ_WT01X dummy
attr WZ_WT01X mqttDefaults roomid="wz"\
num="01"\
roomname="Wohnzimmer"\

attr WZ_WT01X mqttForward none
attr WZ_WT01X mqttPublish desired-temp:topic={"$base/usr/$roomid/act/clima/temperature/$num/set"}\

attr WZ_WT01X mqttSubscribe desired-temp:topic={"$base/usr/$roomid/act/clima/temperature/$num/value"} \
temperature:topic={"$base/usr/$roomid/sen/temperature/$num/value"} \
humidity:topic={"$base/usr/$roomid/sen/humidity/$num/value"}\

attr WZ_WT01X readingList desired-temp temperature humidity
attr WZ_WT01X room Wohnzimmer
attr WZ_WT01X setList desired-temp:12.0,12.5,13.0,13.5,14.0,14.5,15.0,15.5,16.0,16.5,17.0,17.5,18.0,18.5,19.0,19.5,20.0,20.5,21.0,21.5,22.0,22.5,23.0,23.5,24.0,24.5,25.0,25.5,26.0,26.5,27.0,27.5,28.0,28.5,29.0,29.5,30.0
attr WZ_WT01X stateFormat Soll: desired-temp Ist: T:temperature H:humidity
attr WZ_WT01X webCmd desired-temp


Ich habe die Konfiguration  einfach aus meinem System herauskopiert, daher ist etwas mehr drin, als eigentlich nötig. Die Definitionen für Übertragung von 'json'- und 'info'-Topics kannst du ignorieren, sie dienen einem anderen Zweck (u.a. für InfluxDB/Grafana).

[ToKa]

Hi,

vielen Dank für Dein reales Beispiel, das hilft mir sehr und sind ein paar gute Hinweise für mich bevor ich weitermache.

Hättest Du noch ein Beispiel für atopic, wie man Attribute von einer zur anderen Instanz übertragen kann?

Beste Grüße
Torsten

[hexenmeister]

Hallo,

reelen Beispiel für atopic habe ich leider nicht. Ich habe das zwar mal implementiert, praktisch verwendet habe ich das bis jetzt noch nie. War wäre denn dein Anwendungsfall dafür und wo liegend die Schwierigkeiten?

[ToKa]

N'abend,

es geht mir um Userattribute, die ich bei meinen Thermostaten verwende, um die comfort und eco Temperaturen individuell pro Thermostat festzulegen. Diese verwende ich dann in meinem Heizungssteuerungsprogramm. Da ich die Steuerung auf dem fhem1 lassen will, wäre es ganz gut, wenn ich aber die Einstellung des Attributs auf fhem2 machen könnte und dann das Attribut an fhem1 übertragen wird.

Beste Grüße
Torsten

[hexenmeister]

Ok, kann man so machen. Gleiches Vorgehen, wie bei den Readings nur mit 'atopic' anstatt 'topic' bzw. 'stopic'.

[ToKa]

Danke, ich probier es aus.