Läuft: zigbee2mqtt mit MQTT2_SERVER und MQTT2_DEVICE

[supernova1963]

Hallo zusammen,

gerade habe ich im Koenkk/zigbee2mqtt Gateway den fhem MQTT2_SERVER eingetragen und neugestartet.
Damit gepairt sind:

• 1 x Xiaomi Aqara human body movement and illuminance sensor (RTCGQ11LM)
• 1 x Xiaomi Aqara temperature, humidity and pressure sensor (WSDCGQ11LM)

Es hat auch sofort funktioniert. Das zigbee2mqtt gateway wurde sofort erkannt und die als MQTT2_DEVICE angelegt.
Der einzige Wermutstropfen, alle readings der verschiedenen zigbee Devices werden an dem erkannten Gateway (MQTT2_DEVICE) angelegt.

Code: [Auswählen]

Internals:
   CFGFN     
   CID        mqttjs_45746193
   DEF        mqttjs_45746193
   DEVICETOPIC MQTT2_mqttjs_45746193
   IODev      mqttserver
   LASTInputDev mqttserver
   MSGCNT     37
   NAME       MQTT2_mqttjs_45746193
   NR         21781
   STATE      online
   TYPE       MQTT2_DEVICE
   mqttserver_MSGCNT 37
   mqttserver_TIME 2018-09-23 19:04:58
   READINGS:
     2018-09-23 19:04:58   humidity        44.33
     2018-09-23 18:45:33   illuminance     259
     2018-09-23 19:04:58   linkquality     94
     2018-09-23 18:45:33   occupancy       false
     2018-09-23 19:04:58   pressure        978
     2018-09-23 18:39:55   state           online
     2018-09-23 19:04:58   temperature     27.32
Attributes:
   IODev      mqttserver
   readingList mqttjs_45746193:zigbee2mqtt/bridge/state:.* state
mqttjs_45746193:zigbee2mqtt/0x00158d000276e175:.* { json2nameValue($EVENT) }
mqttjs_45746193:zigbee2mqtt/0x00158d00023256f8:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
Gibt es die Möglichkeit den MQTT2_SERVER dazu zu bringen, ein Gateway zu erkennen und die angeschlossenen Devices als einzelne MQTT2_DEVICE anzulegen?

Danke,

Gernot

[rudolfkoenig]

Nicht automatisch, da ich nicht weiss, an welchem Kriterium ich die Geraete unterscheiden soll.Ohne Automatik sollte es aber jetzt schon gehen.

[Beta-User]

Lustig, habe heute auch etwas mit dem Thema rumexperimentiert.

Was nicht so lustig ist: es werden bei jedem Restart des zigbee2mqtt-services wieder neue Devices angelegt. An sich sollte das damit zu erledigen sein, dass man in der configuration.yaml eine "client_id" vergibt. Leider scheint das das Problem aber nicht zu erledigen.

Ist das bei dir ähnlich? Jemand eine Idee für Abhilfe?

Sonst könnte man die Devices ähnlich vereinzeln, wie ich das mit der Sidoh-Bridge schon gemacht hatte, Details um diesen Beitrag herum: https://forum.fhem.de/index.php/topic,86932.msg832336.html#msg832336

Aber wenn man da jedes Mal von vorne anfangen muß, ist das nicht so lustig. (Könnte aber auch daran liegen, dass das Modul von Neumann derzeit auch im Einsatz ist, evtl. kommt sich da was in die Quere).

[supernova1963]

Ja, die neue ClientID bei Neustart des zigbee2mqtt gateway führt bei mir auch zu einer Neuanlage in mqtt2

[Beta-User]

Hast du in der configuration.yaml auch was festgelegt?
Den Teil erledigt hier ein separater reaktivierter PI, der die Daten auch sauber an die erwartete Stelle (zigbee_pi) liefert:

Code: [Auswählen]

zigbee_pi:zigbee2mqtt/bridge/state:.* state
In der yaml steht hier unter mqtt die Angabe "client_id: 'zigbee_pi'".

Nur tauchen daneben weitere MQTT2-Devices auf mit immer wieder anderen Nummern. Bin mittlerweile aber ziemlich sicher, dass es daran liegt, dass ich keinen anderen Broker mehr am laufen habe und für die ersten Geh-Versuche noch ein 00_MQTT-Gerät (mit der externen IP des FHEM-Servers, da es über localhost nicht wollte) und zwei Leuchtmittel als Xiaomi-MQTT-Devices definiert sind. Irgendwie muß man ja rausbekommen, was da an Verkehr stattfindet.

Mehr zur eigenen Doku noch folgendes:
Das letztgenanntes Modul ist so aufgebaut, dass man ein Gerät als Bridge definieren muß, aber an dem gibt es eigentlich nicht viel mehr wie den Befehl "set <Bridge> pair 1", der im mosquitto_sub dann folgendes erzeugt:

Code: [Auswählen]

'zigbee2mqtt/bridge/config/permit_join', ... (4 bytes))
true
'xiaomi/cmnd/bridge/pair', ... (3 bytes))
220

Alles, was nicht direkt mit der Bridge zu tun hat, kommt über

Code: [Auswählen]

zigbee_pi:zigbee2mqtt/<bulb id>:.* { json2nameValue($EVENT) }rein, für das set wird ein set angefügt:

Code: [Auswählen]

zigbee2mqtt/<bulb id>/set:.* {<json> }Der set-Code unterscheidet sich kaum von dem, was die Milights benötigen, sieht z.B. so aus:

Code: [Auswählen]

{"brightness":"135"}
{"state":"ON"}

Dürfte also kein Hexenwerk sein, das vollends nur mit MQTT2 zu machen.

(Spannender wird ggf. der nächste Schritt, auf MQTT ganz zu verzichten, aber das ist was für 2019...)

EDIT: Im Modulcode für Xiaomi-MQTT steht zu den 'xiaomi/cmnd/bridge...'-Messages immer ein "Backwards compability" drin. Scheint also verzichtbar zu sein;

weitere Spezial-Messages:
zigbee2mqtt/bridge/config/remove", message => $hash->{SID} (SID ist wohl das, was oben mit <bulb id> bezeichnet ist)
zigbee2mqtt/bridge/config/devices", message => "" für "update devices"

[supernova1963]

Vielen Dank für deine ausführliche Beschreibung, BetaUser:

Ich habe nun einmal folgende configuration.yaml ausprobiert:
Änderungen zum Original:

• homeassistant: true
• client_id: 'zigbeeStick'
• include_device_information: true
• advanced:
    log_level: debug

Code: [Auswählen]

homeassistant: true
permit_join: true
mqtt:
  base_topic: zigbee2mqtt
  server: 'mqtt://192.168.1.100'
  user: fhem
  password: '*****'
  client_id: 'zigbeeStick'
  include_device_information: true
serial:
  port: /dev/ttyACM0
advanced:
  log_level: debug
devices:
  '0x00158d000276e175':
    friendly_name: 'Bewegungsmelder_01'
    retain: false
  '0x00158d00023256f8':
    friendly_name: 'Raumklima_01'
    retain: falseDiese Konfiguration ergibt folgendes MQTT2_DEVICE per autocreate:

Code: [Auswählen]

Internals:
   CFGFN     
   CID        zigbeeStick
   DEF        zigbeeStick
   DEVICETOPIC MQTT2_zigbeeStick
   IODev      mqttserver
   LASTInputDev mqttserver
   MSGCNT     13
   NAME       MQTT2_zigbeeStick
   NR         3977
   STATE      online
   TYPE       MQTT2_DEVICE
   mqttserver_MSGCNT 13
   mqttserver_TIME 2018-09-24 17:39:06
   READINGS:
     2018-09-24 17:31:40   availability_topic zigbee2mqtt/bridge/state
     2018-09-24 17:39:06   battery         100.00
     2018-09-24 17:31:40   device_class    motion
     2018-09-24 17:31:40   humidity        51.87
     2018-09-24 17:31:40   icon            mdi:speedometer
     2018-09-24 17:39:06   illuminance     62
     2018-09-24 17:31:40   json_attributes_1 battery
     2018-09-24 17:31:40   json_attributes_2 voltage
     2018-09-24 17:39:06   linkquality     68
     2018-09-24 17:31:40   name            Raumklima_01_pressure
     2018-09-24 17:39:06   occupancy       false
     2018-09-24 17:31:40   payload_off     false
     2018-09-24 17:31:40   payload_on      true
     2018-09-24 17:31:40   pressure        994.4
     2018-09-24 17:31:40   state           online
     2018-09-24 17:31:40   state_topic     zigbee2mqtt/Raumklima_01
     2018-09-24 17:31:40   temperature     22.9
     2018-09-24 17:31:40   unit_of_measurement Pa
     2018-09-24 17:31:40   value_template  {{ value_json.pressure }}
     2018-09-24 17:39:06   voltage         3195
Attributes:
   IODev      mqttserver
   readingList zigbeeStick:zigbee2mqtt/bridge/state:.* state
zigbeeStick:homeassistant/binary_sensor/0x00158d000276e175/occupancy/config:.* { json2nameValue($EVENT) }
zigbeeStick:homeassistant/sensor/0x00158d000276e175/illuminance/config:.* { json2nameValue($EVENT) }
zigbeeStick:homeassistant/sensor/0x00158d00023256f8/temperature/config:.* { json2nameValue($EVENT) }
zigbeeStick:homeassistant/sensor/0x00158d00023256f8/humidity/config:.* { json2nameValue($EVENT) }
zigbeeStick:homeassistant/sensor/0x00158d00023256f8/pressure/config:.* { json2nameValue($EVENT) }
zigbeeStick:zigbee2mqtt/Bewegungsmelder_01:.* { json2nameValue($EVENT) }
zigbeeStick:zigbee2mqtt/Raumklima_01:.* { json2nameValue($EVENT) }
   room       MQTT2_DEVICE
Das zigbee2mqtt log-file enthält im debug modus:

Code: [Auswählen]

2018-9-24 17:31:36 - info: Logging to directory: '/opt/zigbee2mqtt/data/log/2018-09-24.17-31-36'
2018-9-24 17:31:36 - debug: Removing old log directory '/opt/zigbee2mqtt/data/log/2018-09-24.16-38-31'
2018-9-24 17:31:36 - debug: Using zigbee-shepherd with settings: '{"net":{"panId":6754,"channelList":[11]},"dbPath":"/opt/zigbee2mqtt/data/database.db","sp":{"baudRate":115200,"rtscts":true}}'
2018-9-24 17:31:36 - debug: Loaded state from file /opt/zigbee2mqtt/data/state.json
2018-9-24 17:31:36 - info: Starting zigbee2mqtt version 0.1.5 (commit #7d49e13)
2018-9-24 17:31:36 - info: Starting zigbee-shepherd
2018-9-24 17:31:40 - info: zigbee-shepherd started
2018-9-24 17:31:40 - info: Coordinator firmware version: 'undefined'
2018-9-24 17:31:40 - debug: zigbee-shepherd info: {"enabled":true,"net":{"state":"Coordinator","channel":11,"panId":"0x1a62","extPanId":"0xdddddddddddddddd","ieeeAddr":"0x00124b0014d9e066","nwkAddr":0},"firmware":{"error":"Unable to get firmware version"},"startTime":1537803100,"joinTimeLeft":0}
2018-9-24 17:31:40 - info: Currently 2 devices are joined:
2018-9-24 17:31:40 - info: Bewegungsmelder_01 (0x00158d000276e175): RTCGQ11LM - Xiaomi Aqara human body movement and illuminance sensor (EndDevice)
2018-9-24 17:31:40 - info: Raumklima_01 (0x00158d00023256f8): WSDCGQ11LM - Xiaomi Aqara temperature, humidity and pressure sensor (EndDevice)
2018-9-24 17:31:40 - warn: `permit_join` set to  `true` in configuration.yaml.
2018-9-24 17:31:40 - warn: Allowing new devices to join.
2018-9-24 17:31:40 - warn: Set `permit_join` to `false` once you joined all devices.
2018-9-24 17:31:40 - info: Zigbee: allowing new devices to join.
2018-9-24 17:31:40 - info: Connecting to MQTT server at mqtt://192.168.1.100
2018-9-24 17:31:40 - debug: Using MQTT client ID: 'zigbeeStick'
2018-9-24 17:31:40 - info: zigbee-shepherd ready
2018-9-24 17:31:40 - info: Connected to MQTT server
2018-9-24 17:31:40 - info: MQTT publish, topic: 'zigbee2mqtt/bridge/state', payload: 'online'
2018-9-24 17:31:40 - info: MQTT publish, topic: 'homeassistant/binary_sensor/0x00158d000276e175/occupancy/config', payload: '{"payload_on":true,"payload_off":false,"value_template":"{{ value_json.occupancy }}","device_class":"motion","json_attributes":["battery","voltage"],"state_topic":"zigbee2mqtt/Bewegungsmelder_01","availability_topic":"zigbee2mqtt/bridge/state","name":"Bewegungsmelder_01_occupancy"}'
2018-9-24 17:31:40 - info: MQTT publish, topic: 'homeassistant/sensor/0x00158d000276e175/illuminance/config', payload: '{"unit_of_measurement":"lx","icon":"mdi:theme-light-dark","value_template":"{{ value_json.illuminance }}","json_attributes":["battery","voltage"],"state_topic":"zigbee2mqtt/Bewegungsmelder_01","availability_topic":"zigbee2mqtt/bridge/state","name":"Bewegungsmelder_01_illuminance"}'
2018-9-24 17:31:40 - info: MQTT publish, topic: 'homeassistant/sensor/0x00158d00023256f8/temperature/config', payload: '{"unit_of_measurement":"°C","icon":"mdi:temperature-celsius","value_template":"{{ value_json.temperature }}","json_attributes":["battery","voltage"],"state_topic":"zigbee2mqtt/Raumklima_01","availability_topic":"zigbee2mqtt/bridge/state","name":"Raumklima_01_temperature"}'
2018-9-24 17:31:40 - info: MQTT publish, topic: 'homeassistant/sensor/0x00158d00023256f8/humidity/config', payload: '{"unit_of_measurement":"%","icon":"mdi:water-percent","value_template":"{{ value_json.humidity }}","json_attributes":["battery","voltage"],"state_topic":"zigbee2mqtt/Raumklima_01","availability_topic":"zigbee2mqtt/bridge/state","name":"Raumklima_01_humidity"}'
2018-9-24 17:31:40 - info: MQTT publish, topic: 'homeassistant/sensor/0x00158d00023256f8/pressure/config', payload: '{"unit_of_measurement":"Pa","icon":"mdi:speedometer","value_template":"{{ value_json.pressure }}","json_attributes":["battery","voltage"],"state_topic":"zigbee2mqtt/Raumklima_01","availability_topic":"zigbee2mqtt/bridge/state","name":"Raumklima_01_pressure"}'
2018-9-24 17:31:40 - info: MQTT publish, topic: 'zigbee2mqtt/Bewegungsmelder_01', payload: '{"illuminance":174,"linkquality":76,"occupancy":true,"battery":"100.00","voltage":3195}'
2018-9-24 17:31:40 - info: MQTT publish, topic: 'zigbee2mqtt/Raumklima_01', payload: '{"temperature":22.9,"linkquality":86,"humidity":51.87,"pressure":994.4,"battery":"100.00","voltage":3045}'
2018-9-24 17:31:56 - debug: Recieved zigbee message of type 'attReport' with data '{"cid":"msIlluminanceMeasurement","data":{"measuredValue":62}}' of device 'lumi.sensor_motion.aq2' (0x00158d000276e175)
2018-9-24 17:31:56 - info: MQTT publish, topic: 'zigbee2mqtt/Bewegungsmelder_01', payload: '{"illuminance":62,"linkquality":63,"occupancy":true,"battery":"100.00","voltage":3195}'
2018-9-24 17:31:56 - debug: Recieved zigbee message of type 'devChange' with data '{"cid":"msIlluminanceMeasurement","data":{"measuredValue":62}}' of device 'lumi.sensor_motion.aq2' (0x00158d000276e175)
2018-9-24 17:31:56 - debug: Recieved zigbee message of type 'attReport' with data '{"cid":"msOccupancySensing","data":{"occupancy":1}}' of device 'lumi.sensor_motion.aq2' (0x00158d000276e175)
2018-9-24 17:31:56 - info: MQTT publish, topic: 'zigbee2mqtt/Bewegungsmelder_01', payload: '{"illuminance":62,"linkquality":60,"occupancy":true,"battery":"100.00","voltage":3195}'
2018-9-24 17:31:56 - debug: Recieved zigbee message of type 'devChange' with data '{"cid":"msOccupancySensing","data":{"occupancy":1}}' of device 'lumi.sensor_motion.aq2' (0x00158d000276e175)
2018-9-24 17:33:26 - info: MQTT publish, topic: 'zigbee2mqtt/Bewegungsmelder_01', payload: '{"illuminance":62,"linkquality":60,"occupancy":false,"battery":"100.00","voltage":3195}'
Vielleicht kann man mit diesen zusätzlichen Informationen etwas anfangen.

Danke,

Gernot

[Beta-User]

An sich sollte es jetzt nicht mehr das große Problem sein, das zu "vereinzeln":

Mal angenommen, du hast 2 zigbee-Geräte (Bewegungsmelder und einen Temp/Hum-Sensor).

Dann brauchst du im Ergebnis 4 MQTT2-Devices:

- Das "Großdevice", an das alle Infos auch weiterhin (auch) kommen; das kann irgendwo in einen "Sammelraum". Davon machst du dann 3 "Klone", die aber nicht alle bzw. weitere Angaben enthalten, nämlich
- die "Bridge", die zur Steuerung des Java-Daemons samt CC2531 dient (zigbeeStick:zigbee2mqtt/bridge/...); da sollten dann die zusätzlichen set-Angaben rein; dient auch nur der Verwaltung, sowas landet bei mir in der Gruppe Interfaces im Raum Steuerung
- Jedes der beiden anderen als seperates MQTT2-Device's, wobei es reichen dürfte, den "friendly name" zu nutzen. Das sind die eigentlichen Nutzdevices.
Solange es nur Sensoren sind, braucht es (ggf. außer dem "unpair") keine set's. Ein Beispiel, wie man set-JSON-Blobs zusammensetzt, ist im verlinkten Beitrag (bzw. irgendwo in der Ecke) zu MiLight.

Vielleicht komme ich die Tage mal dazu, das für meine Tradfri's zu testen und dann zu posten. Aber hoffentlich bist du schneller...

Gruß und gutes Gelingen!

[Beta-User]

So, erste Tests mal gemacht, kurzer Zwischenstand:
Wenn man das "Großdevice" auch als Bridge (nach alter Lesart) nutzen will, sollte es eigentlich genügen, folgende Einstellungen für setList und widgetOverride zu nehmen (RAW-Definitionen):

Code: [Auswählen]

attr MQTT2_zigbee_pi setList permit_join {"zigbee2mqtt/bridge/config/permit_join $EVTPART1"}\
remove {"zigbee2mqtt/bridge/config/remove $EVTPART1"}\
log_level {"zigbee2mqtt/bridge/config/log_level $EVTPART1"}\
rename {"zigbee2mqtt/bridge/config/rename  " . toJSON({ 'old' => "$EVTPART1", 'new' => "$EVTPART2"})}\
network_map {"zigbee2mqtt/bridge/networkmap  $EVTPART1"}\


Code: [Auswählen]

attr MQTT2_zigbee_pi widgetOverride permit_join:true,false remove:textField rename:textField log_level:debug,info,warn,error network_map:raw,graphviz
Für die Bulb-Devices sollte es noch einfacher gehen...

Wenn du nur Sensoren hast, könnte das Vereinzeln über ReadingsProxy auch eine Variante sein.

EDIT: widgetOverride-Attribut geändert

[Beta-User]

Anbei noch eine Bulb-Definition:

Code: [Auswählen]

defmod IKEA_Bulb1 MQTT2_DEVICE
attr IKEA_Bulb1 IODev MQTT2_FHEM_Server
attr IKEA_Bulb1 eventMap on:ON:off off:OFF:on
attr IKEA_Bulb1 readingList zigbee_pi:zigbee2mqtt/0x90fd9ffffe0bcd51:.* { json2nameValue($EVENT) }
attr IKEA_Bulb1 setList on {"zigbee2mqtt/0x90fd9ffffe0bcd51/set " . toJSON({ 'state' => 'ON'})}\
off {"zigbee2mqtt/0x90fd9ffffe0bcd51/set " . toJSON({ 'state' => 'OFF'})}\
brightness {"zigbee2mqtt/0x90fd9ffffe0bcd51/set " . toJSON({ "$EVTPART0" => "$EVTPART1"})}

attr IKEA_Bulb1 webCmd brightness
attr IKEA_Bulb1 widgetOverride brightness:colorpicker,BRI,0,15,255
Fehlt eigentlich nur noch ein DevStateIcon, das den aktuellen Dim-Level sauber wiedergibt .

Damit fliegen meine Übergangs-Devices aus der klassischen MQTT-Welt wieder raus , bis zum nächsten Step (direkte serielle Einbindung der TI-Chips) ist das erst mal eine Sache, mit der ich gut leben kann, ggf. mit geringfügigen Verbesserungen.

EDIT: Code leicht geändert

[Beta-User]

Hmm, jetzt ist doch noch eine seltsame Sache aufgetaucht:

2. Bulb mit anderer IEEE-Adresse angelegt, ansonsten sind es dieselben Einstellungen wie Bulb1.

Schaltet man Bulb1, ist alles ok, der Status der beiden Bulbs ist unabhängig voneinander.

ABER: Schaltet man Bulb2, ändert sich auch der Status (on/off und Brightness) von Bulb1.

Nicht schön... Am mosquitto_sub gibt es keine Auffälligkeiten, da kommt nach dem "set" artig nur die Rückmeldung zu der einen geschalteten Bulb, nicht zur anderen (was auch dem tatsächlichen Verhalten der beiden Bulbs entspricht).

Ideen dazu?

[dev0]

ABER: Schaltet man Bulb2, ändert sich auch der Status (on/off und Brightness) von Bulb1.

Falls Du das Device kopiert hast, dann könnte es vllt. daran liegen. Hier wurde Ähnliches beschrieben.

[Beta-User]

Falls Du das Device kopiert hast, dann könnte es vllt. daran liegen. Hier wurde Ähnliches beschrieben.

Danke für den Hinweis, dürfte dieselbe Ursachen haben; Bulb1 ist eine "copy" des Großdevices mit anschließender "Ausdünnung", Bulb2 wurde im RAW-Editor auf Basis von Bulb1 angelegt.

Werde wohl FHEM mal neu starten .

[Beta-User]

Falls Du das Device kopiert hast, dann könnte es vllt. daran liegen. Hier wurde Ähnliches beschrieben.

Danke, das war es tatsächlich; ein simpler reload von 10_MQTT2_DEVICE hat es auch getan...

[Beta-User]

@rudolfkoenig
(Ich gehe mal davon aus, dass du hier noch mitliest)

Wie kurz beschrieben, hatte ich übergangsweise an dem MQTT2-Server auch einen 00_MQTT-Client gehängt, um das angepaßte Xiaomi-MQTT-Modul nutzen zu können, also genau die Konstruktion aufgebaut, die wir neulich in einem anderen Thread (mit "normalen 10_MQTT_DEVICE-Geräten) als "vermutlich möglich" diskutiert hatten. Autocreate am MQTT2_SERVER war an.
Zunächst war für 00_MQTT die externe IP des FHEM-Servers verwendet worden. Dabei wurden ständig neue MQTT2_DEVICE-Geräte angelegt. Dies geschah nach meiner Wahrnehmung auch noch, nachdem der zigbee2mqtt-Pi (der die eigentliche Informationsquelle darstellt) dann eine eindeutige Kennung erhalten hatte.

Ohne das jetzt ausführlich ausgetestet zu haben, scheint mir die Ursache hierfür das 00_MQTT-Gerät zu sein, und zwar unabhängig davon, ob es über die externe IP oder über localhost (auf das ich kurz umgestellt hatte) kommuniziert.

Frage: wäre es möglich, das Autocreate (optional?) für localhost auszuschalten (in der Annahme, das es keine andere Methode gibt, ein 00_MQTT-Gerät anderweitig von "echten" externen Informationsquellen (weiterer MQTT-Server oder Client) zu unterscheiden?)
Ist für den Fall hier m.E. nicht mehr relevant, aber evtl. eine Sache, über die zukünftig evtl. noch mehr Leute stolpern, die aus welchen Gründen auch immer beides haben wollen.

[rudolfkoenig]

Bei gesetzten autocreate wird dann eine neue MQTT2_DEVICE Instanz angelegt, falls die aktuell gesendete clientId unbekannt ist, d.h. kein MQTT2_DEVICE mit diesem clientId existiert. Wenn deine Beschreibung zutrifft, dann sendet die bei MQTT verwendete Bibliothek fuer jede neue Verbindung eine neue clientId.

Die von Dir vorgeschlagene Aenderung ist natuerlich machbar, ich wuerde es aber vorziehen, wenn MQTT clientId konstant bleibt (vulgo: es soll da gefixt werden). Abgesehen davon: eine FHEM-interne Kommunikation ueber MQTT ist ineffizient, man sollte beim Einsatz von MQTT2_SERVER die dafuer vorgesehene MQTT2_DEVICE verwenden, dann gibt es diese Probleme nicht, und die Konfiguration ist deutlich einfacher.

Falls aber mehrere Benutzer hier einfinden, die "autocreate remoteonly" haben wollen, dann baue ich es ein.