clientOrder und autocreate

[kgie]

Hallo,

ich habe bei einem MQTT2_CLIENT device das Attribut clientOrder folgendermaßen gesetzt:

Code Auswählen Erweitern

D10_MQTT_Device:MQTT2_DEVICE:MQTT_GENERIC_BRIDGE
dabei ist D10_MQTT_Device mein eigenes Modul. Ich habe unter den Modulen D10_MQTT_Device und MQTT2_DEVICE Devices angelegt.
Ohne autocreate (autocreate=no am MQTT2_CLIENT) werden Nachrichten so zuerst an die D10_MQTT_Devices und danach - wenn sie nicht verarbeitet werden konnten - an die MQTT2_DEVICEs gesendet.

Mit autocreate liefert aber die ParseFn des D10_MQTT_Device bereits ein 'UNDEFINED ...'. Dieses UNDEFINED wird gnadenlos getriggert und legt ein passendes Device an, welches dann auch fleißig die Nachrichten verarbeitet, egal ob es unter MQTT2_DEVICE schon ein Device dafür gibt.

Ist dieses Verhalten von autocreate so beabsichtigt?
Sollte FHEM's main::Dispatch nicht eigentlich erstmal alle Module in clientOrder durchprobieren, ob eins die Nachricht verarbeiten kann, und nur wenn nicht ein autocreate anwerfen?

Gruß
Kai
 

[Beta-User]

Die Rückgabe muss (auch)
 

Code Auswählen Erweitern

[NEXT]
sein, damit das nächste TYPE per dispatch aufgerufen wird.

[kgie]

Wenn meine ParseFn

Code Auswählen Erweitern

('[NEXT]', 'UNDEFINED ...') zurück liefert, dann wird doch aber auch das UNDEFINED getriggert, oder? Nur das dann auch noch zusätzlich die ParseFn von MQTT2_DEVICE aufgerufen wird. Was ja ggf. auch da noch autocreate (ähnliche) Aktionen auslöst.

So wie es ist, müsste ich in der ParseFn von D10_MQTT_Device schon wissen, ob es in der weiteren Client-Liste noch ein Modul mit einem device gibt, das die Nachricht verarbeiten kann. Das ist aber allgemein kaum möglich, da da ja beliebige Module als Nachfolger sein können.

Wenn dieser Anwendungsfall nicht vorgesehen ist, dann muss ich mir was ausdenken - will nur gerne verstehen, wie das autocreate gedacht ist.

[Beta-User]

RHASSPY und MQTT_GENERIC_BRIDGE kennen das Attribut "forceNext".
Vielleicht würde sowas dein Problem auch lösen?

[rudolfkoenig]

Sollte FHEM's main::Dispatch nicht eigentlich erstmal alle Module in clientOrder durchprobieren, ob eins die Nachricht verarbeiten kann, und nur wenn nicht ein autocreate anwerfen?

Ich verstehe das Problem vermutlich nicht: entweder fuehlt sich ein Modul fuer eine Nachricht zustaendig, oder nicht.
Wenn nicht: dann wird mit [NEXT] das Naechste in der Kette befragt.
Wenn doch, dann kann man immer noch entscheiden, ob man eine neue Instanz anlegen will, oder nicht.

Mit "[NEXT], UNDEFINED" kann man sogar die Nachricht weiterreichen und eine eigene Instanz anlegen lassen, wobei mir dieser Anwendungsfall noch nicht wirklich einleuchtet.