MQTT2_DEVICE - welche Rolle spielt das Attribut IODev?

[betateilchen]

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.

[LuckyDay]

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

Code Auswählen Erweitern

localhost:tele/dose3/STATE:.* { json2nameValue($EVENT) }

[betateilchen]

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.

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... 😂 )

[erwin]

... irreführend JA, deine Beobachtung ist richtig, aber im Wiki zumindest dokumentiert. 
Bei meinem Modul hab ich in der parse-Fn einen "Filter" eingebaut...