Betrieb MQTT_GENERIC_BRIDGE mit MQTT2_SERVER. Autocreate-Bug?

[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)