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
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.
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 ?
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 (https://forum.fhem.de/index.php/topic,124044.msg1185889.html#msg1185889) 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...
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?
Ich glaube nach Recherche diverser Threads, dass die bridge weiter nötig ist - ich teste es einfach.
backup regelt das schon :)
Zitat von: masterpete23 am 17 Januar 2022, 22:56:02
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
Manchmal wünsche ich mir einen Audiosupport oder Shared Screen :)
Wie kommst du denn jetzt auf XIAOMI?
Zitat von: masterpete23 am 19 Januar 2022, 16:01:07
Wie kommst du denn jetzt auf XIAOMI?
Du schreibst hier:
Zitat von: masterpete23 am 17 Januar 2022, 22:06:32
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?!?"
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?
Imo: ja. FHEM ist sehr aktuell?
super. Das klappt doch alles:)
Fhem ist sehr aktuell ja!
Wie meinst du die Frage?
Zitat von: masterpete23 am 19 Januar 2022, 18:51:00
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!)
Achso.
Ich bin da immer recht mutig
attrTemplateVersion
20220114
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).
bei mir läuft alles super gerade.
Mal sehen was so kommt die Tage.
Ich war zwischendurch schon wieder sehr am überlegen nicht doch auf mqtt wieder zu gehen.
Aber: give it a try :)