Betrieb MQTT_GENERIC_BRIDGE mit MQTT2_SERVER. Autocreate-Bug?

[hexenmeister]

Ich weiß nicht recht, ob das ein Bug oder 'ne Feature ist, aber beim Betrieb der GenericBridge mit MQTT2_SERVER funktioniert 'mqttSubscribe' nur, wenn in dem Server-Device 'autocreate' deaktiviert ist. Ist dies aktiv, wird ggf. ein neues MQTT2_DEVICE angelegt und alle Events dorthin geliefert, die Bridge bekommt nichts mehr mit. Mit deaktivierten autocreate funktioniert bei mir die Bridge, aber das MQTT2_DEVICE bekommt keine Updates mehr.

Ich würde vorschlagen, dass die Bridge in jedem Fall beliefert wird, unabhängig von autocreate und Vorhandensein von entsprechenden MQTT2-Geräte. Aus meiner Sicht wäre es logisch, wenn beide upgedatet werden.

[rudolfkoenig]

Siehe https://forum.fhem.de/index.php/topic,95341.msg882874.html#msg882874

[Beta-User]

Hmm, auch wenn ich die Einschränkung bezogen auf die in dem anderen Thread gestellte Frage nachvollziehen kann:
Das Neuanlegen eines MQTT2-DEVICE-Geräts in dem Fall, dass es bereits einen Abonnenten für das Topic in der Generic-Bridge gibt, ist nach meinem Empfinden suboptimal. Zumal dann, wenn dieses MQTT2-DEVICE dann die Generic-Bridge als Abonnenten im Ergebnis "verdrängt".

Das versteht dann vermutlich keiner mehr... und ist auch ausgesprochen mißlich, wenn man größere Installationen hat und ggf. autocreate nur einschaltet, um neue Geräte hinzuzufügen. Gibt es dann bei allem, was zwischendurch an Traffic stattfindet, haufenweise neue Devices,  die dann die vorhandene Konfiguration zerhageln?!?

Müßte nicht MQTT2-SERVER (bzw. auch Client) aktiv anfragen, ob es einen Generic-Bridge-Client gibt und nur dann den autocreate-MEchanismus starten?

[rudolfkoenig]

Nach etwas nachdenken: MQTT_GENERIC_BRIDGE ist kein "logisches" Geraet, sondern ein notify mit verteilter Konfiguration.

Es sollte nicht per Dispatch/ParseFn benachrichtigt werden, sondern per NotifyFn.

Beide IODevs (MQTT2_SERVER/MQTT2_CLIENT)  stellen alle topics als Event zur Verfuegung, wenn man das rawEvents Attribut setzt.
Ich meine MQTT_GENERIC_BRIDGE sollte diesen Mechanismus verwenden, damit muesste man nicht mit einer Sonderbehandlung anfangen, und es waere moeglich das gleiche topic mehreren Geraeten zuzuweisen.

[Beta-User]

Klingt einerseits logisch, andererseits sollte es (aus Usersicht gedacht, nicht aus Programmiererwarte!) nicht erforderlich sein, irgendein Attribut anzuschalten (wie rawEvents), um eine Sache zum laufen zu bringen, die an sich Standardfunktionalität zu sein scheint.
Gibt's da keine bessere Option - aus Usersicht sollten zusammenhängende Dinge halbwegs nahtlos ineinanderlaufen, und das sehe ich hier - zumindest vom ersten Eindruck her - eher nicht als gegeben an. MQTT2_SERVER (und -Client) und MQTT_GENERIC_BRIDGE sind für mich "zusammenhängende Dinge", da sollte die "linke HAnd" schon wissen, was die "rechte Hand" tut .

[hexenmeister]

Es sollte nicht per Dispatch/ParseFn benachrichtigt werden, sondern per NotifyFn.

Eine gute Idee! Könnte ich umbauen. Performancetechnisch dürfte das gleichwertig sein?

Beide IODevs (MQTT2_SERVER/MQTT2_CLIENT)  stellen alle topics als Event zur Verfuegung, wenn man das rawEvents Attribut setzt.

Das finde ich widerum suboptimal. Könnte natürlich in der Bridge das Attribut setzen, ist aber auch irgendwie unschön...

[rudolfkoenig]

MQTT2_SERVER (und -Client) und MQTT_GENERIC_BRIDGE sind für mich "zusammenhängende Dinge", da sollte die "linke HAnd" schon wissen, was die "rechte Hand" tut

MQTT_GENERIC_BRIDGE passt nicht ganz in die bisherige Welt von FHEM: ein IODev stellt Rohdaten den logischen Modulen zur Verfuegung, diese Verdauen sie, setzen Readings in eine FHEM-Geraete-Instanz und stellen sie als Events dem Rest von FHEM zur Verfuegung.

MQTT_GENERIC_BRIDGE ist eine spezielle, fuer MQTT hartkodierte  (euphemistisch: optimierte ) Version einer notify, dessen Konfiguration nicht beim notify selbst ist, sondern bei den einzelnen Geraeten, die es synchronisiert. Laut reine "FHEM-Lehre" muesste sie die Events der logischen Module weiterverarbeiten, und diese untereinander synchronisieren, so waere sie allgemeingueltig. Ich verstehe es schon, dass so, wie es jetzt implementiert ist, in bestimmten Szenarien praktischer ist, weil es ohne den Ballast von zusaetzlichen MQTT2_DEVICE Instanzen auskommt. Bin nur nicht sicher, dass ich fuer solche Shortcuts die Architektur aendern soll, und ich weiss auch nicht genau, wie.

Wenn aber jemand eine Loesungsidee ohne Nebenwirkungen hat, dann soll sich bitte melden.

Performancetechnisch dürfte das gleichwertig sein?

Nicht ganz, weil die IODevs zusaetzliche Events erzeugen muessen, die bei anderen Modulen mit fehlenden notifyRegexpChanged() / bzw. NOTIFYDEV sinnlose Aufrufe erzeugen. Ich meine aber, dass man das in Kauf nehmen muss, um es sauber zu haben.

Das finde ich widerum suboptimal. Könnte natürlich in der Bridge das Attribut setzen, ist aber auch irgendwie unschön...

Stimmt, habe aber z.Zt. keine bessere Idee.

[hexenmeister]

MQTT_GENERIC_BRIDGE ist eine spezielle, fuer MQTT hartkodierte  (euphemistisch: optimierte ) Version einer notify, dessen Konfiguration nicht beim notify selbst ist, sondern bei den einzelnen Geraeten, die es synchronisiert. Laut reine "FHEM-Lehre" muesste sie die Events der logischen Module weiterverarbeiten, und diese untereinander synchronisieren, so waere sie allgemeingueltig.

Naja, nicht ganz. Ich sehe es schon als ein logisches Gerät, dass die Events weiter verarbeitet (indem es diese weiter verteilt). Und die Senderichtung gibt es ja auch noch.
Es wäre aus meiner Sicht sauberer, mehrere logische Clients für selbe Topics zuzulassen.

Es mit Notify zu machen ist aucgh irgendwie nicht die reine Lehre... Außerdem befürchte ich gerade Endlosschleifen, wenn am selben Gerät subscribe und publish annotiert sind. Sind ja beides dann über Notify angebunden... Ich muss darüber nachdenken... Eine tolle Lösung fällt mir gerade auch nicht ein.

[rudolfkoenig]

Ich sehe es schon als ein logisches Gerät, dass die Events weiter verarbeitet

Nach den (mW nirgendwo festgehaltenen) Definition representiert ein "logisches Modul" in FHEM ein reales Geraet zum bedienen (z.Bsp. FS20 Zwischenstecker), was man ueber ein physisches Modul (z.Bsp. CUL) steuert. Ein notify ist nach dieser Definition kein logisches Modul. MQTT2_GENERIC_BRIDGE ist in meinen Augen deutlich naeher am notify, als am FS20.

Es wäre aus meiner Sicht sauberer, mehrere logische Clients für selbe Topics zuzulassen.

Damit gibt es konkrekte Probleme z.Bsp. bei FS20: da fischen manche Module (FS20V, USF1000, BS) spezielle Nachrichten von dem generischen (FS20) weg.
Ein anderes Aspekt: Wenn ich ein MQTT2_DEVICE definiert habe, und kein MQTT_GENERIC_BRIDGE haben will, soll fhem.pl trotzdem MQTT_GENERIC_BRIDGE laden, nur damit es feststellt, dass es nicht benoetigt wird? Ich waere damit automatisch von weiteren Modulen abhaengig (GPUtils, etc), mit denen ich nichts zu tun haben will.

Ich will mich nicht komplett sperren, aber ich sehe sowohl in der theoretischen wie auch in der praktischen Realisierung Probleme.

[hexenmeister]

GenericBridge ist ein Zwitter. Beim subscribe kann ich Deine Sicht teilen, aber beim Senden.... Es eher eine Art (zwischengeschaltetes) IODev, eine Verteildrehscheibe.

Schön wäre, wenn man spezielle Module definieren könnte, die trotzdem alle (passenden) Nachrichten erhalten können.
Oder (besser?) die Module entscheiden lassen, ob die Nachricht verschlückt oder weiter gereicht werden soll (mit Defaultverhalten = 'verschlücken', damit es anwärtskompatibel bleibt).
Ich halte es auch nicht für unlogisch, zwei MQTT_DEVICE-Instanzen zu haben, die (teilweise) dieselben Topics verwenden. Bei einem publish/subscribe-Protokoll, wie MQTT ist, ist das genau das erwartete Verhalten.

EDIT:
In fhem.pl wird die Schleife anhand des Return-Wertes ggf. unterbrochen:

Code Auswählen Erweitern

foreach my $m (@{$clientArray}) {
  # Module is not loaded or the message is not for this module
  next if(!$modules{$m} || $dmsg !~ m/$modules{$m}{Match}/i);

  if( my $ffn = $modules{$m}{FingerprintFn} ) {
    ($isdup, $idx) = CheckDuplicate($name, $dmsg, $ffn);
    return rejectDuplicate($name,$idx,$addvals) if($isdup);
  }

  no strict "refs"; $readingsUpdateDelayTrigger = 1;
  @found = &{$modules{$m}{ParseFn}}($hash,$dmsg);
  use strict "refs"; $readingsUpdateDelayTrigger = 0;
  $parserMod = $m;
  last if(int(@found));
}

Was ist, wenn MQTT2_DEVICE und MQTT_GENERIC_BRIDGE in der Parse-Sub einfach immer undef zurück liefern?

[rudolfkoenig]

Schön wäre, wenn man spezielle Module definieren könnte, die trotzdem alle (passenden) Nachrichten erhalten können.

Ich bleibe bei meinem Vorschlag von rawEvents, bis jemandem was Besseres einfaellt.

Ich halte es auch nicht für unlogisch, zwei MQTT_DEVICE-Instanzen zu haben, die (teilweise) dieselben Topics verwenden.

Fuer MQTT_DEVICE kann ich nicht sprechen, bei MQTT2_DEVICE ist das moeglich.

Was ist, wenn MQTT2_DEVICE und MQTT_GENERIC_BRIDGE in der Parse-Sub einfach immer undef zurück liefern?

Dann werden die Events fuer die gefundenen Geraete nicht verteilt.

[hexenmeister]

Fuer MQTT_DEVICE kann ich nicht sprechen, bei MQTT2_DEVICE ist das moeglich.

Dann habe ich irgendwas nicht verstanden. Wenn 2 MQTT2_DEVICEs mit der selben Topic bedient werden (wie?), warum klappt dann nicht mit der BRIDGE?

Ich bleibe bei meinem Vorschlag von rawEvents, bis jemandem was Besseres einfaellt.

Wenn nichts anderes übrig bleibt...

EDIT: Wäre ein zweiter (optionale) Rückgabeparameter in ParseFn, der besagt, dass weitere geräte bedient werden sollen, eine mögliche Lösung?

Dann werden die Events fuer die gefundenen Geraete nicht verteilt.

Ah... Stimmt :/

[rudolfkoenig]

Wenn 2 MQTT2_DEVICEs mit der selben Topic bedient werden (wie?), warum klappt dann nicht mit der BRIDGE?

Weil das innerhalb eines Moduls ist. MQTT2_DEVICE_Parse liefert zwei Geraet zurueck.

EDIT: Wäre ein zweiter (optionale) Rückgabeparameter in ParseFn, der besagt, dass weitere geräte bedient werden sollen, eine mögliche Lösung?

Aus meiner Sicht nicht, weil:
1. es werden jetzt schon N Werte (Array von gefundenen Geraeten) zurueckgeliefert
2. das Problem mit der Abhaengigkeit von Modulen, die ich gar nicht haben will (s.o.), bleibt.

[hexenmeister]

Weil das innerhalb eines Moduls ist. MQTT2_DEVICE_Parse liefert zwei Geraet zurueck.Aus meiner Sicht nicht, weil:

Klar, könnte ich selbst darauf kommen

1. es werden jetzt schon N Werte (Array von gefundenen Geraeten) zurueckgeliefert
2. das Problem mit der Abhaengigkeit von Modulen, die ich gar nicht haben will (s.o.), bleibt.

1. leuchtet ein. Wenn das keine Array-Referen ist, kann man schlecht unterscheiden.
2. Wenn man das für alle Module möglich macht, gibt es ja keine Abhängigkeit.

Aber gut. Mehr fällt mir noch nicht ein.

[Beta-User]

Hmm,
sorry, das meiste hier verstehe ich nicht, aber beim Lesen kam mit als Gedanke: Könnte man nicht ein "spezielles" MQTT2-DEVICE als Brückengerät zur MQTT-Generic-Bridge nutzen?
Also dort einfach alle Subscriptions der Generic-Bridge sammeln? Es geht ja nur um den Subscribe-Teil, soweit ich das verstanden habe. Wäre zwar auch irgendwie unschön, es würde aber nicht die Zahl der zu verarbeitenden Events ganz so in die Höhe treiben wie rawEvents am IO?

Kann natürlich sein, dass das kompletter Unsinn ist...