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

[hexenmeister]

Das würde bedeuten, dass MQTT2_DEVICE von MQTT_GENERIC_BRIDGE abhängig wird. Nicht gut.

Saubere Lösung für alles will mir leider nicht einfallen. Keine Ahnung, ob die vielen raw-Events ein problem werden können. Andererseits gibt es mit abgeschalteten autocreate (eimal Commandref lesen ist eh besser als jedes autocreate ) und ohne MQTT2_DEVICEs (mit den gleichen Topics) derzeit auch kein Problem.

[Beta-User]

Das würde bedeuten, dass MQTT2_DEVICE von MQTT_GENERIC_BRIDGE abhängig wird. Nicht gut.

So herum war es nicht gemeint, eher (teilweise!) anders herum:
MQTT_GENERIC_BRIDGE wäre dann _bei Verwendung eines MQTT2-IO_ abhängig von MQTT2_DEVICE. In diesem (einen) MQTT2-DEVICE würden dann alle subscriptions zu sammeln sein und (via bridgeRegexp?) an die MQTT_GENERIC_BRIDGE weiterzugeben.

(Es wird sich nicht vermeiden lassen, dass wir "einzlene" User haben, die nicht vorab die ganze cr lesen und autocreate nicht ausschalten... Dass das in der Wechselwirkung solche Probleme generiert ist daher - nennen wir es - unschön...)

[rudolfkoenig]

es würde aber nicht die Zahl der zu verarbeitenden Events ganz so in die Höhe treiben wie rawEvents am IO?

Ich meine die (nur in bestimmten Faellen!) etwas mehr Last, was rawEvents generiert ist es nicht Wert, durch komplizierte und seiteneffektbehaftete Optimierungen loesen zu wollen.

[hexenmeister]

So herum war es nicht gemeint, eher (teilweise!) anders herum:
MQTT_GENERIC_BRIDGE wäre dann _bei Verwendung eines MQTT2-IO_ abhängig von MQTT2_DEVICE. In diesem (einen) MQTT2-DEVICE würden dann alle subscriptions zu sammeln sein und (via bridgeRegexp?) an die MQTT_GENERIC_BRIDGE weiterzugeben.

Wie das andersrum gehen soll, leuchtet mir leider nicht ein. Aber auch das ist Mist, da die Bridge nicht unbedingt auf MQTT2* angewiesen ist (und sein soll).

(Es wird sich nicht vermeiden lassen, dass wir "einzlene" User haben, die nicht vorab die ganze cr lesen und autocreate nicht ausschalten... Dass das in der Wechselwirkung solche Probleme generiert ist daher - nennen wir es - unschön...)

Unschön ja, andererseits habe ich für Leute, die sich über Probleme beschweren, ohne zumindest Commandref gelesen zu haben, überhaupt kein Verständnis. Ist ja nicht so, dass Entwickler schon einmal ihre Zeit in die Dokumentation investiert haben

[hexenmeister]

Ich meine die (nur in bestimmten Faellen!) etwas mehr Last, was rawEvents generiert ist es nicht Wert, durch komplizierte und seiteneffektbehaftete Optimierungen loesen zu wollen.

Wohl nicht. Ich werde mit NotifyFn versuchen, mal sehen, ob das ohne Seiteneffekte innerhalb von der GenericBridge gelingt.

[Beta-User]

Wie das andersrum gehen soll, leuchtet mir leider nicht ein. Aber auch das ist Mist, da die Bridge nicht unbedingt auf MQTT2* angewiesen ist (und sein soll).

Hmm, ich versuch's mal zu erläutern - bitte seht mir nach, wenn ich das eher von der praktischen Seite her betrachte.

Also: Das MQTT2-IO wird - insbesondere bei eingeschaltetem autocreate, in jedem Fall aber bei allen Subscriptions, bei denen MQTT2_DEVICE und irgendwas anderes miteinander konkurrieren, _nur_ das MQTT2-Device beliefern. Halten wir fest: gibt es ein MQTT2-IO, sollte nach dem derzeitigen Stand auch ein MQTT2-Device vorhanden sein.

Dies zu berücksichtigen, heißt aber nicht, darauf angewiesen zu sein.

Die Idee wäre jetzt, (empfangsseitig!) nicht das 2-er-IO direkt abzugreifen, sondern ein weiteres Gerät für eine notifyFn zu nutzen. Eben ein MQTT2-Device, damit es wieder zum IO paßt. Aus Sicht der GenericBridge ist es eigentlich "irgendein" Device, was speziell ist, ist dass darin die relevanten Subscriptions stehen sollten, nämlich in der readingList.
Hat man ein Event des "Zwischen-Geräts", kann man nachsehen, welche Subscription beteiligt war und daraus dann wieder in GenericBridge weitere Aktionen ableiten. Das setzt keine "richtige Abhängigkeit von MQTT2_DEVICE voraus, nur eine bestimmte Struktur in der readingList.

@Rudi (v.a.)
Was ich aber immer noch nicht ganz verstanden habe:
Warum nicht nach dem Start von FHEM seitens der MQTT2-IO's prüfen, ob die Generic-Bridge geladen ist und dann einfach alle eingehenden Nachrichten in einem bestimmten Format (das ggf. noch festzulegen ist) möglichst nonblocking an die GenericBridge zur weiteren Verarbeitung weiterreichen? Was die damit macht, bleibt dann ihr überlassen. Ist die Generic-Bridge nicht geladen, bleibt alles beim alten.... Erhöht bereits das die wechselseitigen Abhängigkeiten auf ein Level, das nicht akzeptabel ist?
Leuchtet mir jedenfalls noch nicht so richtig ein.

[rudolfkoenig]

Warum nicht nach dem Start von FHEM seitens der MQTT2-IO's prüfen, ob die Generic-Bridge geladen ist und dann einfach alle eingehenden Nachrichten in einem bestimmten Format (das ggf. noch festzulegen ist) möglichst nonblocking an die GenericBridge zur weiteren Verarbeitung weiterreichen?

Weil es statt der vorhandenen Schnittstelle einen "hardcoded ShortCut" verwendet.
MQTT macht es auch so, und das war einer der Gruende, warum MQTT2_SERVER nicht als IODev fuer MQTT_DEVICE dienen kann, und ich MQTT2_DEVICE bauen musste.
Es ist ein Hack, und dagegen streubt sich mein "Architekt-Ich".

Wir koennen auch eine neue Schnittstelle bauen, wenn es noetig ist. Aber das Argument: eine Neue ist notwendig, weil die Alte auch von Anderen verwendet wird, finde ich nicht einleuchtend.

Das hoert sich haerter an, als ich es meine: wenn Du unbedingt darauf bestehst, dann baue ich das ein. Schoen finden werde ich es nicht.

[Beta-User]

Tut mir leid, ich bin kein Architekt (eigentlich würde ich meine Perl-Kenntnisse auch eher als rudimentär bezeichnen, und Programmieren habe ich vor Urzeiten mal an der Schule "gelernt"), daher verstehe ich zwar den Hinweis, will und kann aber auf nichts bestehen, sondern bin sehr dankbar, dass du überhaupt drüber nachdenkst und dich mit meinen möglicherweise verqueren Gedankengängen befaßt!

Mir geht es v.A. um die "Handhabbarkeit" durch den halbwegs verständigen "Normaluser":
- Braucht man die vorhandene rawEvent-Schnittstelle, besteht ein nicht unerhebliches Risiko, dass man es als user irgendwann mal wieder verstellt, weil einen ggf. die vielen Events stören, deren Sinn man wieder vergessen hat. Der gedankliche Zusammenhang zwischen den rawEvents und der GenericBridge ist einfach (in meiner Wahrnehmung) sehr lose.
- Benötigt man ein weiteres Zwischendevice (das MQTT2-Device), wird die Strecke sehr unübersichtlich, auch da ist das Risiko groß, dass irgendwann irgendwas nicht mehr zusammenpasst, weil es durch den user unbeabsichtigt/nebenbei verändert wurde. Die Fehlersuche hinterher stelle ich mir schwierig vor.
Weiß nicht, aber evtl. wäre es auch eine Option, zwar kein klassisches Event auszulösen, aber anderen Modulen zu erlauben, sich als Client für die (sonst nicht sichtbaren) rawEvents (insgesamt) zu registrieren? Also generisch, aber irgendwie im Hintergrund?

[hexenmeister]

Die Idee mit dem ZwischenDevice finde ich nicht so gut. Wie du schon sagst, unübersichtlich, fehleranfällig, nicht üblich in fhem. Steigert unnätig die Komplexität.

Die Abhängigkeit zu der GenericBridge in MQTT2* ist auch nicht gut.

Am besten würde ich die Möglichkeit finden, mehrere Clients(Typen) von dem IO parallel zu den selben Topics bedienen zu können. Ich verstehe aber, dass diese Änderung sehr invasiv ist und Probleme bereiten kann (wird).

Das beste von den zur Verfügung stehenden Möglichkeiten ist autocreate abzuschalten. Später versuche ich mit der 'Notify'-Methode. Mal sehen, wie es laufen wird.

[rudolfkoenig]

Am besten würde ich die Möglichkeit finden, mehrere Clients(Typen) von dem IO parallel zu den selben Topics bedienen zu können.

Es ist ja nicht so, dass ich als FHEM-Framework-Dienstleister mich nicht anstrengen will

Ich habe jetzt Dispatch erweitert, damit das moeglich ist, und 00_MQTT2_DEVICE auch angepasst:
- falls ein ParseFn als ersten Devicenamen [NEXT] zurueckliefert (wg. [] ein ungueltiger FHEM-Name), dann wird die Schleife in Dispatch _nicht_ abgebrochen.
- Falls MQTT2_DEVICE_Parse was findet, liefert sie zusaetzlich an erster Stelle [NEXT] zurueck, d.h. MQTT2_GENERIC_BRIDGE wird auch aufgerufen (falls geladen, s.u.)
- das gilt _nicht_ fuer autoloading., d.h. falls MQTT2_GENERIC_BRIDGE nicht definiert ist, dann wird sie nicht automatisch geladen.

Ich habe nur kurz mit MQTT2_GENERIC_BRIDGE getestet, aber es faellt mir auf, das MQTT_GENERIC_BRIDGE schafft subscribe abzusetzen _bevor_ die Verbindung zum MQTT Server steht. Da ich keine Lust habe die Verantwortung fuer die Zwischenspeicherung (vulgo queuen) zu uebernehmen, liefert in diesem Fall IOWrite einen Fehler zurueck: bitte pruefen.

[hexenmeister]

Das klingt gut, vielen Dank!
Sicher nicht die reine Lehre, aber eine funktionierende pragmatische Lösung.
Muss man halt irgendwo gut auf- bzw. beschreiben

Ich werden in der GenericBridge dann auch [NEXT] zurückliefern.

das gilt _nicht_ fuer autoloading., d.h. falls MQTT2_GENERIC_BRIDGE nicht definiert ist, dann wird sie nicht automatisch geladen.

Ist auch gut so.

Ich habe nur kurz mit MQTT2_GENERIC_BRIDGE getestet, aber es faellt mir auf, das MQTT_GENERIC_BRIDGE schafft subscribe abzusetzen _bevor_ die Verbindung zum MQTT Server steht. Da ich keine Lust habe die Verantwortung fuer die Zwischenspeicherung (vulgo queuen) zu uebernehmen, liefert in diesem Fall IOWrite einen Fehler zurueck: bitte pruefen.

Guter Einwand, habe nicht daran gedacht. Werde mir was überlegen (state von DevIO prüfen?)
Bin nächte Woche beruflich unterwegs, werde wohl erst danach dazu kommen.

[pantau]

Es ist ja nicht so, dass ich als FHEM-Framework-Dienstleister mich nicht anstrengen will

Ich habe jetzt Dispatch erweitert, damit das moeglich ist, und 00_MQTT2_DEVICE auch angepasst:
- falls ein ParseFn als ersten Devicenamen [NEXT] zurueckliefert (wg. [] ein ungueltiger FHEM-Name), dann wird die Schleife in Dispatch _nicht_ abgebrochen.
- Falls MQTT2_DEVICE_Parse was findet, liefert sie zusaetzlich an erster Stelle [NEXT] zurueck, d.h. MQTT2_GENERIC_BRIDGE wird auch aufgerufen (falls geladen, s.u.)
- das gilt _nicht_ fuer autoloading., d.h. falls MQTT2_GENERIC_BRIDGE nicht definiert ist, dann wird sie nicht automatisch geladen.

Ich habe nur kurz mit MQTT2_GENERIC_BRIDGE getestet, aber es faellt mir auf, das MQTT_GENERIC_BRIDGE schafft subscribe abzusetzen _bevor_ die Verbindung zum MQTT Server steht. Da ich keine Lust habe die Verantwortung fuer die Zwischenspeicherung (vulgo queuen) zu uebernehmen, liefert in diesem Fall IOWrite einen Fehler zurueck: bitte pruefen.

Hallo Rudi,

ich habe heute ein update all gemacht, dabei wurde unter anderem fhem.pl von 18270 auf 18343 gebracht. Nach einem Neustart gingen keine HM Geräte mehr (evtl. auch andere habe ich nicht getestet):
CUBeStack3: Unknown code A0C248470633B5D00000000C833::-73.5:CUBeStack3, help me!
Ich habe hier einen kurzen Report gemacht: https://forum.fhem.de/index.php/topic,96275.0.html
Inzwischen habe ich diese Änderung als Ursache identifiziert: fhem.pl r18316. Wenn ich in r18343 nur das zurück ändere, läuft meine Installation wieder einwandfrei. (MQTT verwende ich nicht).
Ich habe einen MAX Cube mit 4 CUL ausgerüstet und mit STACKABLE eingebunden:

define CUBe868SL CUL 192.168.99.52:2323 1234
attr CUBe868SL group Gateways
attr CUBe868SL model CUN
attr CUBe868SL rfmode SlowRF
attr CUBe868SL room Server,AZ
attr CUBe868SL sendpool CUBe868SL,rcul,CUL_0,CUBe868HM

define CUBeStack2 STACKABLE CUBe868SL
attr CUBeStack2 room Server

define CUBe868N CUL FHEM:DEVIO:CUBeStack4:9600 0000
attr CUBe868N event-min-interval 300
attr CUBe868N event-on-update-reading state
attr CUBe868N group Gateways
attr CUBe868N model CUN
attr CUBe868N rfmode SlowRF
attr CUBe868N room AZ,Server
attr CUBe868N verbose 0

define CUBe868HM CUL FHEM:DEVIO:CUBeStack3:9600 0000
attr CUBe868HM group Gateways
attr CUBe868HM hmId F11122
attr CUBe868HM hmProtocolEvents 1_dump
attr CUBe868HM icon cul_cul
attr CUBe868HM rfmode HomeMatic
attr CUBe868HM room AZ,CUL_HM,Server

define CUBeStack4 STACKABLE CUBe868HM
attr CUBeStack4 room AZ,Server

define CUBe433SL CUL FHEM:DEVIO:CUBeStack2:9600 0000
attr CUBe433SL group Gateways
attr CUBe433SL longids 1
attr CUBe433SL model CUN
attr CUBe433SL room AZ,Server

define CUBeStack3 STACKABLE CUBe433SL
attr CUBeStack3 room AZ,Server

In dieser Reihenfolge wird die Cfg abgearbeitet, das ist nicht "aufsteigend" sortiert, da es in Wirklichkeit meherer include cfg sind, die nach Geräteklassen sortiert sind.
Alle STACKABLE Device werden mit und ohne r18316 als Initialized im web frontend angezeigt.
Bin etwas ratlos wie das Verhalten mit der Änderung zusammenhängt. Wie kann ich das Problem weiter eingrenzen, oder welche Infos fehlen noch?

Gruß

Peter 

[rudolfkoenig]

Kannst du bitte ein "attr global verbise 5 Log eines "Fehlverhaltens" hier anhaengen?
Insb. die erste Zeile mit "CUBe868SL: dispatch ..." interessiert mich, aber auch die folgenden dispatch Zeilen.
Helfen wuerde auch das gleiche Log mit der funktionierenden Version.

[pantau]

Angehängt die gewünschten Logfiles.
fhem_nok.log ist mit der fhem.pl r18343 erzeugt
fhem_ok.log hat nur fhem.pl geändert, gemäß angehängtem diff_against_r18343. Habe bemerkt, das ich doch 2 zurückgenommene Änderungen drin habe und nicht nur die gestern angemerkte.
Außer dem Austausch der fhem.pl habe ich nichts geändert zwischen den 2 Starts von fhem (abgesehen von dem neuen Logfilenamen im attr global logfile...).
FHEM wurde jeweils mit systemctl start fhem gestartet und mit stop beendet.
Bei der nok Version hat stop auch nicht funktioniert, ich mußte den Prozess mit kill -9 abschießen.
Entschuldige den "Datenmüll" drum rum, ich wußte nicht was ich wegfiltern sollte und hoffe das Problem ist nicht zu gut versteckt.
Danke für die Hilfe!

[Beta-User]

@Rudi

wenn das von pantau hier korrekt gemeldet wurde, könnten damit auch weitere Effekte zusammenhängen? Insbesondere:
https://forum.fhem.de/index.php/topic,96372.0.html (Kommunikationsschwierigkeiten beim CUL)
https://forum.fhem.de/index.php/topic,96301.0.html (help-me-Meldungen bei Original-HM-Interfaces via VCCU)

[rudolfkoenig]

Leider bin ich aus den Logs nicht wirklich schlau geworden, aber ich meine einen Bug gefunden und gefixt zu haben.
Bitte um Feedback.

[pantau]

Leider bin ich aus den Logs nicht wirklich schlau geworden, aber ich meine einen Bug gefunden und gefixt zu haben.
Bitte um Feedback.

Du bist schlau genug geworden für mein Problem Danke!
Disclaimer 1: Habe nur den fix aus r18393 auf meine nok Version angewendet => Änderungen zw. meiner Version und Deinem Fix sind nicht (alle) drin.
Disclaimer 2: Quicktest 5min Laufzeit, laut log aber alles normal und HM Devices funktionieren.

Ich werde morgen mal ein update all machen und mich wieder melden, falls dann ein Problem auftritt.
Danke nochmal!

Peter

EDIT: "update all" am 23.01.2019 => alles (immer) noch ok => Problem gelöst!

[hexenmeister]

Ich habe jetzt Dispatch erweitert, damit das moeglich ist, und 00_MQTT2_DEVICE auch angepasst:
- falls ein ParseFn als ersten Devicenamen [NEXT] zurueckliefert (wg. [] ein ungueltiger FHEM-Name), dann wird die Schleife in Dispatch _nicht_ abgebrochen.
- Falls MQTT2_DEVICE_Parse was findet, liefert sie zusaetzlich an erster Stelle [NEXT] zurueck, d.h. MQTT2_GENERIC_BRIDGE wird auch aufgerufen (falls geladen, s.u.)

Done for GenericBridge too:)

Ich habe nur kurz mit MQTT2_GENERIC_BRIDGE getestet, aber es faellt mir auf, das MQTT_GENERIC_BRIDGE schafft subscribe abzusetzen _bevor_ die Verbindung zum MQTT Server steht. Da ich keine Lust habe die Verantwortung fuer die Zwischenspeicherung (vulgo queuen) zu uebernehmen, liefert in diesem Fall IOWrite einen Fehler zurueck: bitte pruefen.

a TODO for me