Autor Thema: MQTT Design - Was ist die bridge wo kommen die anderen her - was ist richtig?  (Gelesen 744 mal)

Offline masterpete23

  • Sr. Member
  • ****
  • Beiträge: 551
Hi,

sorry für den verwirrenden Betreff.
Ich habe nun gerade wieder etwas mit mqtt am machen und dabei verwirrte mich, wie ich mit FHEM publishen konnte und warum seltsame Geräte angelegt werden / wurden.

Ich nutze MQTT2Server direkt über FHEM. (define m2s MQTT2_SERVER 11883 global)
Nun habe ich ein device m2s.
Dort habe ich ein mega langes reading auch ein langes retain (habe ich nicht gepostet, da wohl "persönliche Dinge" drin stehen?
Auch sehe ich mein last publish.

dann habe ich noch ein define Mosquitto MQTT 192.168.0.20:1883
Ist das überhaupt nötig? Kann ich alles über einen laufen lassen?

kann es sein, dass die Instanz zigbee2mqtt ansich auch ein device ist? ist es dann die bridge?
vllt versteht einer was ich meine oder kann die richtigen Fragen zur Erklärung stellen!? :)
Danke

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16884
Also...
zu:
define Mosquitto MQTT 192.168.0.20:1883ist es sehr schwierig was zu schreiben, weil völlig unklar ist, was sich hinter dieser IP:Port-Kombination verbirgt.
define m2s MQTT2_SERVER 11883 globalscheint es nicht zu sein, weil da eine andere Portnummer genannt ist...?

Ansonsten ist es bei zigbee2mqtt (in der MQTT2-Modul-Welt) so, dass es ein MQTT2_DEVICE (M2D) gibt, das den "Dienst" an sich repräsentiert, und das auch als "Sortierdevice" fungiert, das aus jeder ZigBee-Hardware wieder ein einzelnes M2D macht.

Du musst also zuerst klären, wohin "Mosquitto" "zeigt", und wer das ggf. nutzt. Wenn du es nicht mehr haben willst, musst du die dazu gehörenden Clients ("list IODev=Mosquitto") identifizieren und durch was anderes ersetzen.
Server: HP-T620@Debian 11, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline masterpete23

  • Sr. Member
  • ****
  • Beiträge: 551
Kann ich die mosquitto devices einfach auf den mqtt2server umschwenken lassen?


und ist dann dieses devices das device was das attrtemplate bridge bekommen sollte: define m2s MQTT2_SERVER 11883 global ?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16884
Ehrlich gesagt verstehe ich die Frage nicht...

Also: bitte FHEM auf den aktuellen Stand bringen. Im Bereich MQTT2.* hat sich sehr viel getan seit "L_02a_zigbee2mqtt_bulb", das du gestern noch hier gezeigt hattest. Da war auch ein "bridge"-Gerät für zigbee2mqtt dabei, das du ja auch gefunden hattest.

Bei MQTT2_SERVER ist ansonsten nur dann ein (weiteres) bridgeRegexp-Gerät erforderlich, wenn sich "hinter" einem "Gerät" dann eigentlich viele andere "verbergen", wie das bei zigbee2mqtt eben der Fall ist.

Jedenfalls ist völlig unklar, was "mosquitto devices" sein sollen. Externe Hardware (Tasmota, z.B.) kann man einfach auf den neuen Server "umhängen", das gibt dann dann aber eben keine MQTT_DEVICE-Instanzen mehr, sondern MQTT2_DEVICE-Instanzen. Insgesamt habe ich den Eindruck, dass du weder die Wiki-Seite(n) (MQTT, "Praxisbeispiele") gelesen hast, noch die "Umstellungsthreads", die zumindest in Teilen auch im Wiki verlinkt sind. Bitte nachholen, dann wird das vermutlich mit etwas eigenem Experimentieren klarer...
Server: HP-T620@Debian 11, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline masterpete23

  • Sr. Member
  • ****
  • Beiträge: 551
Sorry für das Rauswühlen des alten Threads.
Ich habe nun soweit alles umgezogen von meiner alten Instanz - bis auf zigbee2mqtt.
Welches wäre dort das einfachste Umziehen?
Muss ich wieder eine bridge anlegen wie in der alten Umgebung?
Dann kann ich einfach in der zigbee2mqtt config den m2s auf die neue Instanz umbiegen und die Geräte wieder perlist bzw raw übernehmen?

Offline masterpete23

  • Sr. Member
  • ****
  • Beiträge: 551
Ich glaube nach Recherche diverser Threads, dass die bridge weiter nötig ist - ich teste es einfach.
backup regelt das schon :)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16884
Ich glaube nach Recherche diverser Threads, dass die bridge weiter nötig ist - ich teste es einfach.
...kommt darauf an, was "die bridge" sein soll.
Korrekt ist: auch die Lösung für MQTT2_DEVICE sieht eine "bridge" vor, allerdings ist das eine andere wie die aus dem externen XiaomiMQTT-Modul!

Siehe https://wiki.fhem.de/wiki/Zigbee2mqtt
Server: HP-T620@Debian 11, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline masterpete23

  • Sr. Member
  • ****
  • Beiträge: 551
Manchmal wünsche ich mir einen Audiosupport oder Shared Screen :)
Wie kommst du denn jetzt auf XIAOMI?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16884
Wie kommst du denn jetzt auf XIAOMI?
Du schreibst hier:

Ich habe nun soweit alles umgezogen von meiner alten Instanz - bis auf zigbee2mqtt.
Das klang danach, als wären die zigbee2mqtt-Geräte in FHEM noch mit der Kombi 00_MQTT/10_XiaomiMQTTDevice angelegt und unklar, wie es mit denen weitergehen könnte.

Falls das nicht der Fall ist, und wir nur über MQTT2_DEVICE und den Wechsel des Interfaces von MQTT2_CLIENT auf MQTT2_SERVER reden: Das sollte ohne weiteres gehen, das "bridge"-MQTT2_DEVICE-Gerät (attrTemplate: "zigbee2mqtt_bridge") brauchst du dann nicht zwingend, allerdings wird es ohne das "komisch", wenn du mal ein neues Gerät einbinden willst oä.. Dafür ist das hilfreich, von daher würde ich vorsichtshalber auch das anlegen...

Das einzige Device, das man bei einem Wechsel von MQTT2_CLIENT auf MQTT2_SERVER als (alleinigem) Interface-Modul nicht mehr braucht, ist das "Sortierdevice" (attrTemplate: "MQTT2_CLIENT_general_bridge").

Klarer?

PS: Wenn die Frage klarer formuliert gewesen wäre, wäre es uU. auch einfacher zu antworten... Aber das stand schon in meinem letzten Post hier: "Was ist die bridge?!?"
« Letzte Änderung: 19 Januar 2022, 16:20:04 von Beta-User »
Server: HP-T620@Debian 11, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline masterpete23

  • Sr. Member
  • ****
  • Beiträge: 551
Ok. Dann nochmal ausführlich und deutlich hoffe ich

ich habe ein laufendes zigbee2mqtt in einem docker container.
configuration.yaml auszug:
mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://IPFHEM:11883
  client_id: z2mdocker
Dann habe ich eine Proxmox CT mit fhem und darauf m2s - Auszug:
CONNECTS   17
   Clients    :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
   ClientsKeepOrder 1
   DEF        11883 global
   FD         26
   FUUID      61dca4ae-f33f-53cd-d84e-c153f9f8956e0964
   NAME       m2s
   NR         305
   PORT       11883
   STATE      Initialized
   TYPE       MQTT2_SERVER
   MatchList:
     1:MQTT2_DEVICE ^.
     2:MQTT_GENERIC_BRIDGE ^.

In Zigbee2mqtt sind schon mehrere Endgeräte aktiv.

Nun habe ich die ziggbee2mqtt Config angepasst und den Container neu gestartet
Nun taucht dieses Devices auf (readings gekürzt:
Internals:
   CFGFN     
   CID        z2mdocker
   DEF        z2mdocker
   DEVICETOPIC MQTT2_z2mdocker
   FUUID      61e846db-f33f-53cd-eb5e-cb9c0e377144cb2c
   IODev      m2s
   LASTInputDev m2s
   MSGCNT     3
   NAME       MQTT2_z2mdocker
   NR         1372
   STATE      ON
   TYPE       MQTT2_DEVICE
   m2s_CONN   m2s_192.168.0.146_50876
   m2s_MSGCNT 3
   m2s_TIME   2022-01-19 18:14:03
   READINGS:
     2022-01-19 18:14:03   1_friendly_name default_bind_group
     2022-01-19 18:14:03   1_id            901
     2022-01-19 18:14:03   IODev           m2s
     2022-01-19 18:14:03   battery         100
     2022-01-19 18:14:03   battery_low     false
     2022-01-19 18:14:03   brightness      254
     2022-01-19 18:14:03   color_mode      color_temp
     2022-01-19 18:14:03   color_temp      454
     2022-01-19 18:14:03   devices     
2022-01-19 18:14:03   extensions      []
     2022-01-19 18:14:03   humidity        53.14
     2022-01-19 18:14:03   info         
2022-01-19 18:14:03   level           info
     2022-01-19 18:14:03   linkquality     21
     2022-01-19 18:14:03   message
2022-01-19 18:14:03   power_on_behavior previous
     2022-01-19 18:14:03   pressure        1015
     2022-01-19 18:14:03   state           ON
     2022-01-19 18:14:03   subscriptions   zigbee2mqtt/#
     2022-01-19 18:14:03   tamper          false
     2022-01-19 18:14:03   temperature     17.99
     2022-01-19 18:14:03   update_available true
     2022-01-19 18:14:03   update_state    idle
     2022-01-19 18:14:03   voltage         3685
     2022-01-19 18:14:03   water_leak      false
Attributes:
   readingList z2mdocker:zigbee2mqtt/bridge/state:.* state
z2mdocker:zigbee2mqtt/bridge/info:.* info
z2mdocker:zigbee2mqtt/bridge/devices:.* devices
z2mdocker:zigbee2mqtt/bridge/groups:.* { json2nameValue($EVENT) }
z2mdocker:zigbee2mqtt/bridge/extensions:.* extensions
z2mdocker:zigbee2mqtt/bridge/logging:.* { json2nameValue($EVENT) }
z2mdocker:zigbee2mqtt/STYRBAR01:.* { json2nameValue($EVENT) }
z2mdocker:zigbee2mqtt/IKEA_TRADFI_WZ_KUECHE:.* { json2nameValue($EVENT) }
z2mdocker:zigbee2mqtt/IKEA_TRADFI_WZ_FENSTER:.* { json2nameValue($EVENT) }
z2mdocker:zigbee2mqtt/IKEA01:.* { json2nameValue($EVENT) }
z2mdocker:zigbee2mqtt/WATER1:.* { json2nameValue($EVENT) }
z2mdocker:zigbee2mqtt/AQARA1:.* { json2nameValue($EVENT) }
z2mdocker:zigbee2mqtt/AQARA2:.* { json2nameValue($EVENT) }
z2mdocker:zigbee2mqtt/IKEA_TRADFI_WZ_MITTE:.* { json2nameValue($EVENT) }
z2mdocker:zigbee2mqtt/IKEA_TRADFI_GU10_03:.* { json2nameValue($EVENT) }
z2mdocker:zigbee2mqtt/IKEA_TRADFI_GU10_01:.* { json2nameValue($EVENT) }
z2mdocker:zigbee2mqtt/IKEA_TRADFI_GU10_02:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
.
Das gebe ich von meinem Verständis das attr template zigbee2mqtt bridge.
Danach schalte ich etwas die Geräte damit sie auftauchen.
Nun weise ich diesen die richtigen Attrtemplates und Eigenschaften wie auf meiner alten FHEM Umgebung zu.

Alles so korrekt?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16884
Imo: ja. FHEM ist sehr aktuell?
Server: HP-T620@Debian 11, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline masterpete23

  • Sr. Member
  • ****
  • Beiträge: 551
super. Das klappt doch alles:)
Fhem ist sehr aktuell ja!
Wie meinst du die Frage?

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16884
Wie meinst du die Frage?
Das Reading "attrTemplateVersion" sollte dir die Antwort geben, wann das von dir genutzte zigbee2mqtt-bridge-attrTemplate das letzte Mal angefasst wurde. (Soweit ich mich entsinne: vor 3 oder 4 Tagen...). In der Regel sind Aktualisierungen Verbesserungen ;) . (Speziell heute wäre ich aber vorsichtig! Derzeit: Warten, bis fhem.pl wieder angefaßt wurde, notfalls die attrTemplate-File separat aus dem svn holen!)
Server: HP-T620@Debian 11, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

Offline masterpete23

  • Sr. Member
  • ****
  • Beiträge: 551
Achso.
Ich bin da immer recht mutig
attrTemplateVersion
20220114

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16884
OK, also wirklich das letzte: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/lib/AttrTemplate/mqtt2.template#L184

Normalerweise bin ich auch sehr mutig, aber wie gesagt: Im Moment scheint was mit "Dispatch" nicht zu stimmen, weswegen u.A. "autocreate" kaputt ist, und HUE.* hat heute auch jede Menge updates bekommen => frühestens (!) morgen (je nachdem, ob fhem.pl gefixt wurde oder nicht).
Server: HP-T620@Debian 11, 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:MySensors, Weekday-&RandomTimer, Twilight,  AttrTemplate {u.a. mqtt2, mysensors, zwave}

 

decade-submarginal