Hallo,
ich habe bei einem MQTT2_CLIENT device das Attribut clientOrder folgendermaßen gesetzt:
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
Die Rückgabe muss (auch)
[NEXT]
sein, damit das nächste TYPE per dispatch aufgerufen wird.
Wenn meine ParseFn ('[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.
RHASSPY und MQTT_GENERIC_BRIDGE kennen das Attribut "forceNext".
Vielleicht würde sowas dein Problem auch lösen?
ZitatSollte 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.
Das Problem sieht für mich so aus: Wenn in einer Client-Liste A:B:C:... mit Modulen A, B, C, etc. das erste Modul A ein allgemeines Modul ist, das im Prinzip schon jede MQTT Nachricht verarbeiten kann, dann kann es auch für jede Nachricht ein passendes UNDEFINED liefern und würde so bei aktivem autocreate also entweder verarbeiten oder UNDEFINED triggern lassen. Damit B, C, auch was abkriegen, muss man A also irgendwie einschränken.
Mir hilft da der Hinweis auf das forceNEXT Attribut bei anderen Modulen. Wenn ich das in mein Modul einbaue, dann kann ich Definitionen anlegen, die ihre Nachrichten an die Nachfolger weiterreichen. Das ist möglicherweise nicht super schön, weil man dann Devices hat die nur dafür da sind Nachrichten weiterzureichen, aber es ist ein pragmatischer Ansatz, um nicht auf autocreate verzichten zu müssen.
Es geht imo nicht nur um autocreate!
Und das mit UNDEFINED verstehe ich auch noch nicht; in den fhem.pl-Code mag ich grade nicht selbst schauen.