komisches IODev

[rabehd]

Aufgefallen ist mir, dass meine OSRAM-Plugin (zigbee) nicht mehr richtig funktionieren.
Diese hatte ich vor einigen Wochen von deconz zu Zigbee2mqtt umgezogen, incl. einiger Sensoren. deconz gibt es auch nicht mehr.

Es gibt den MQTT2-Server, 2 MQTT2-Client (für thethings.network und zendure).
Bei meinen Shelly steht der MQTT2-Server als IODev drin, bei zendure der passende Client.

Es gibt noch ein "MQTT2_zigbee2mqtt" (IODev: der MQTT2-Server, verbinden mit der IP von zigbee2mqtt).

Bei den zigbee2mqtt-Geräten steht als IODev der MQTT2-Client für thethings.network drin, bei anderen der von zendure.
Ich vermute deshalb reagieren die OSRAM-Plugin nicht mehr.

Habe ich da mal was kaputtgemacht? Kann man das reparieren?
 

[frober]

Beim Fhem Start wird versucht automatisch das richtige IODev zu finden.
Klappt nicht immer...

Deswegen gibt es das Attribut IODev, damit kannst du das Richtig festlegen.

[Beta-User]

Klappt nicht immer...

Es ist bei MQTT2 wie bei allen "echten" zweistufigen Modulen: wird (z.B. per Dispatch-autocreate) ein neues Client-Device angelegt, wird erst mal das letzte in der Konfiguration stehende (generell) passende IO herangezogen....

Klappt also streng genommen eher nur zufällig, wenn man mehrere MQTT-Server im Einsatz hat.

[rudolfkoenig]

Klappt also streng genommen eher nur zufällig, wenn man mehrere MQTT-Server im Einsatz hat.

Das stimmt sicher fuer etliche Module, aber nicht fuer MQTT2.
Das UNDEFINED Event wird mit IODev als letzter Parameter generiert, und Define setzt das IODev Reading entsprechend.
Readings werden gespeichert, das sollte also ein Neustart ueberleben.
Das IODev Reading kann man als Benutzer mit dem IODev Attribut natuerlich ueberschreiben.