Hallo zusammen,
im Zuge meiner zusammenfassung von verschiedenen Bereichen / Systemen schubse ich grad einige Sachen, die zuvor auf zwei FHEM Systemen waren zusammen. Das beinhaltet eben auch die MQTT Sachen. Nun habe ich auf meinem bestehendem System bereits einen MQTT2Server der autocreate aktiv hat und entsprechende Geräte anlegt und einen MQTT2Device in dem sich der externe Broker befindet.
define brok_ext_MQTT2 MQTT2_CLIENT 192.168.10.125:1883
attr brok_ext_MQTT2 DbLogExclude .*
attr brok_ext_MQTT2 autocreate simple
attr brok_ext_MQTT2 event-on-change-reading .*
attr brok_ext_MQTT2 group MQTT
attr brok_ext_MQTT2 icon mqtt
attr brok_ext_MQTT2 room Verbindungen->Netzwerk
attr brok_ext_MQTT2 username flummy_dev
# BUF
# Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
# ClientsKeepOrder 1
# DEF 192.168.10.125:1883
# DeviceName 192.168.10.125:1883
# FD 24
# FUUID 6792389b-f33f-73c9-abb6-ab6f0eb6dcb83d3a
# FVERSION 00_MQTT2_CLIENT.pm:0.281490/2023-11-11
# NAME brok_ext_MQTT2
# NR 361
# PARTIAL
# STATE opened
# TYPE MQTT2_CLIENT
# WBCallback
# clientId brok_ext_MQTT2
# eventCount 1
# lastMsgTime 1737639529.65224
# nextOpenDelay 10
# nrConnects 1
# MatchList:
# 1:MQTT2_DEVICE ^.
# 2:MQTT_GENERIC_BRIDGE ^.
# OLDREADINGS:
# READINGS:
# 2025-01-23 13:45:27 state opened
#
setstate brok_ext_MQTT2 opened
setstate brok_ext_MQTT2 2025-01-23 13:45:27 state opened
Nun werden aber aktuell gar keine neuen Geräte angelegt. Ich habe damit bereits ein wenig rumgespielt und es wurden bereits einige Geräte angelegt, die ich wieder gelöscht habe. Teilweise war die Zuordnung nicht korrekt (interner / externer MQTT) oder sonstige Fehler, die das Gerät dopppelt dargestellt haben usw. Das gesuchte Gerät (und zum testen auch ein anderes) ist in diesem FHEM nicht vorhanden und wird auch nicht angelegt.
Meine Frage daher: Wie gehe ich in diesem Fall am besten vor? Wenn ich bereits ein vorhandenen MQTT Server habe, autocreate aktiv ist und ein externer eingebunden werden soll, bei dem natürlich neue Geräte auch angelegt werden sollen. Vielleicht auch zusätzlich so vorgehen, dass ich alte Datei / Namens -leichen lösche.
https://wiki.fhem.de/wiki/MQTT2_CLIENT (https://wiki.fhem.de/wiki/MQTT2_CLIENT) habe ich gelesen, aber genau da hört eben mein Verständnis mit dem doppelt anlegen auf ;(
Vielen Dank im Voraus
VG
Andreas
Zitat von: flummy1978 am 23 Januar 2025, 14:45:48Meine Frage daher: Wie gehe ich in diesem Fall am besten vor? Wenn ich bereits ein vorhandenen MQTT Server habe, autocreate aktiv ist und ein externer eingebunden werden soll, bei dem natürlich neue Geräte auch angelegt werden sollen. Vielleicht auch zusätzlich so vorgehen, dass ich alte Datei / Namens -leichen lösche.
Also:
Es gibt zwei wesentliche Unterschiede zwischen "intern" und "extern": MQTT2_SERVER "kennt" seine Gegenstellen anhand der ClientID und kann daraus per autocreate direkt (halbwegs) sinnvolle "Gruppen" (von topics) bilden. Und er macht für interne "set"-Anweisungen keine readingList-Einträge.
Ergo würde ich der Einfachheit halber immer "neue" Geräte an einem FHEM anlernen, das einen MQTT2_SERVER hat - dann aber alles löschen, was mit der ClientID zu tun hat (v.a. in der readingList). Dann kann man sowas per RAW-Definition in jedes beliebige andere FHEM umziehen, egal, ob das Gerät dann über einen internen oder externen MQTT-Server kommt. "autocreate" ist jedenfalls bei MQTT2_CLIENT und großen Installationen m.E. sehr zweischneidig und eher nicht empfehlenswert, schon gleich nicht ohne "Sortierdevice".
Das einzige "Problem" ist: FHEM weist allen neuen Devices, die per dispatch-autocreate angelegt wurden, automatisch immer das letzte in der config stehende IO zu. (MQTT2_.* ist da keine Ausnahme!).
Ergo muss man das händisch grade ziehen, entweder per Attribut, oder per manuellem Setzen des Readings...
Hoffe, das ist halbwegs verständlich und der Rest ergibt sich dann aus dem zitierten Wiki-Artikel (v.a. ignore von set-Topics)?
Hey,
vielen Dank für Deine Erklärungen bis hierhin:
Zitat von: Beta-User am 23 Januar 2025, 14:58:53Ergo würde ich der Einfachheit halber immer "neue" Geräte an einem FHEM anlernen, das einen MQTT2_SERVER hat - dann aber alles löschen, was mit der ClientID zu tun hat (v.a. in der readingList). Dann kann man sowas per RAW-Definition in jedes beliebige andere FHEM umziehen, egal, ob das Gerät dann über einen internen oder externen MQTT-Server kommt.
Hoffe, das ist halbwegs verständlich und der Rest ergibt sich dann aus dem zitierten Wiki-Artikel (v.a. ignore von set-Topics)?
Soweit habe ich das verstanden. Was mich halt verwirrt ist die Tatsache, dass mal was angelegt wurde und vor allem der Satz: "....einem FHEM anlernen, das einen MQTT2_SERVER hat....". Meine Hautpinstallation hat ja einen MQTT2_Server
define brok_MQTT2 MQTT2_SERVER 52709 global
attr brok_MQTT2 DbLogExclude .*
attr brok_MQTT2 alias MQTT Broker lokal
attr brok_MQTT2 autocreate simple
attr brok_MQTT2 disable 0
attr brok_MQTT2 event-on-change-reading RETAIN,state,.*
attr brok_MQTT2 group MQTT
attr brok_MQTT2 icon mqtt
attr brok_MQTT2 keepaliveFactor 12
attr brok_MQTT2 room Verbindungen->Netzwerk
# CONNECTS 59
# Clients :MQTT2_DEVICE:MQTT_GENERIC_BRIDGE:
# ClientsKeepOrder 1
# DEF 52709 global
# FD 22
# FUUID 5cb4d159-f33f-8d79-e538-336765cb048a4d76
# FVERSION 00_MQTT2_SERVER.pm:0.289860/2024-06-18
# NAME brok_MQTT2
# NR 87
# PORT 52709
# STATE Initialized
# TYPE MQTT2_SERVER
# eventCount 74
# MatchList:
# 1:MQTT2_DEVICE ^.
# 2:MQTT_GENERIC_BRIDGE ^.
# READINGS:
# 2024-09-13 14:03:11 attrTemplateVersion 20210528
# 2024-01-30 01:00:36 lastPublish cmnd/NSP_WZ_1BB518/Backlog:StateText1 off; StateText2 on; StateText3 toggle; StateText4 hold; SetOption26 1; SaveData 1
# 2025-01-23 13:49:56 nrclients 44
# 2025-01-23 13:45:27 state Initialized
# clients:
# brok_MQTT2_127.0.0.1_55708 1
# brok_MQTT2_192.168.50.111_58459 1
# brok_MQTT2_192.168.50.112_49483 1
# brok_MQTT2_192.168.50.113_9470 1
# brok_MQTT2_192.168.50.114_61306 1
# brok_MQTT2_192.168.50.115_58559 1
# brok_MQTT2_192.168.50.120_59966 1
# brok_MQTT2_192.168.50.121_60036 1
# brok_MQTT2_192.168.50.122_51207 1
# brok_MQTT2_192.168.50.126_62960 1
# brok_MQTT2_192.168.50.127_62881 1
# brok_MQTT2_192.168.50.130_8712 1
# brok_MQTT2_192.168.50.131_26091 1
# brok_MQTT2_192.168.50.136_50369 1
# brok_MQTT2_192.168.50.138_64604 1
# brok_MQTT2_192.168.50.141_21924 1
# brok_MQTT2_192.168.50.142_17575 1
# brok_MQTT2_192.168.50.143_6518 1
# brok_MQTT2_192.168.50.144_13329 1
# brok_MQTT2_192.168.50.150_58576 1
# brok_MQTT2_192.168.50.151_53546 1
# brok_MQTT2_192.168.50.152_57554 1
# brok_MQTT2_192.168.50.153_12418 1
# brok_MQTT2_192.168.50.159_3534 1
# brok_MQTT2_192.168.50.160_50662 1
# brok_MQTT2_192.168.50.161_15767 1
# brok_MQTT2_192.168.50.162_13361 1
# brok_MQTT2_192.168.50.180_21916 1
# brok_MQTT2_192.168.50.181_15311 1
# brok_MQTT2_192.168.50.185_62955 1
# brok_MQTT2_192.168.50.186_64143 1
# brok_MQTT2_192.168.50.187_59443 1
# brok_MQTT2_192.168.50.189_17187 1
# brok_MQTT2_192.168.50.31_63214 1
# brok_MQTT2_192.168.50.35_64056 1
# brok_MQTT2_192.168.50.51_12385 1
# brok_MQTT2_192.168.50.70_49824 1
# brok_MQTT2_192.168.50.72_58485 1
# brok_MQTT2_192.168.50.74_60110 1
# brok_MQTT2_192.168.50.76_52746 1
# brok_MQTT2_192.168.50.77_52445 1
# brok_MQTT2_192.168.50.78_52441 1
# brok_MQTT2_192.168.50.79_52445 1
# brok_MQTT2_192.168.50.80_14283 1
# retain:
#
setstate brok_MQTT2 2024-09-13 14:03:11 attrTemplateVersion 20210528
setstate brok_MQTT2 2024-01-30 01:00:36 lastPublish cmnd/NSP_WZ_1BB518/Backlog:StateText1 off;; StateText2 on;; StateText3 toggle;; StateText4 hold;; SetOption26 1;; SaveData 1
setstate brok_MQTT2 2025-01-23 13:49:56 nrclients 44
setstate brok_MQTT2 2025-01-23 13:45:27 state Initialized
Diese verarbeitet ja die Informationen, die sich im lokalen MQTT rumtümmeln. Daher ergibt sich für mich die Logik nicht mit der anderen FHEM Installation
VG
Andreas