Die Frage klingt vielleicht komisch, aber da ich in der commandref nichts gefunden habe: welche Rolle spielt das Attribut IODev bei einem MQTT2_DEVICE?
Eigentlich war ich der Meinung, IODev sei eine Abkürzung für "Input-/Output-Device" - aber nach meinen heutigen Erfahrungen ist das wohl nicht so. Wenn überhaupt, scheint es nur ein "Output-Device" zu beschreiben. Über welchen MQTT2_CLIENT eine mqtt-Nachricht in FHEM ankommt, scheint völlig egal zu sein. Offenbar landen alle eingehenden Nachrichten in allen MQTT2_DEVICES.
Zum Szenario:
Aktuell teste ich mit alternativen externen mqtt-Servern. Dazu habe ich zwei MQTT2_CLIENT devices in meiner FHEM-Installation angelegt. Dabei ist mir aufgefallen, dass alle ble2mqtt Nachrichten nach der Änderung der mqtt-Adresse auf der Sendeseite trotzdem noch in allen devices ankommen, deren IODev auf einen ganz anderen MQTT2_CLIENT verweisen.
mit dem IODev wird hart definiert uber welchen MQTT2_CLIENT gesendet wird, damit wird "Rudis" Erkennung "Automatik" überschrieben. Reading -> IODev
Wenn man die Empfangenen Nachrichen nur von einem MQTT2_Client in seinem Device haben will, muss man die CID des MQTT2_Client in der readingList voranstellen.
Beispiel CID = localhost
localhost:tele/dose3/STATE:.* { json2nameValue($EVENT) }
Zitat von: LuckyDay am 25 Dezember 2025, 16:24:40Wenn man die Empfangenen Nachrichen nur von einem MQTT2_Client in seinem Device haben will, muss man die CID des MQTT2_Client in der readingList voranstellen.
Danke für den Schubs in die richtige Richtung :)
Das bestätigt aber meine Vermutung, dass das I in IODev in diesem Szenario recht irreführend ist. ( i wie irreführend... 😂 )
... irreführend JA, deine Beobachtung ist richtig, aber im Wiki (https://wiki.fhem.de/wiki/DevelopmentModuleAPI#AssignIoPort) zumindest dokumentiert. 8)
Bei meinem Modul hab ich in der parse-Fn einen "Filter" eingebaut...