Verständnisfrage (zusätzl) ext Server und autocreate

[flummy1978]

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.

Code Auswählen Erweitern

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 habe ich gelesen, aber genau da hört eben mein Verständnis mit dem doppelt anlegen auf ;(

Vielen Dank im Voraus
VG
Andreas

[Beta-User]

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.

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)?

[flummy1978]

Hey,

vielen Dank für Deine Erklärungen bis hierhin:

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.


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

Code Auswählen Erweitern

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