MQTT2_SERVER und MQTT2_DEVICE

[Beta-User]

...auch gut...
Wir sollten halt die user nicht im Regen stehen lassen, die heute die alten Module nutzen. Von daher wäre es m.E. besser, die Namen weiter zu verwenden as is und.das alte client-Modul für legacy zu erklären. Damit bliebe genericbridge auch unangetastet, was sonst ein Problem wäre.
Damit sollte der Bedarf für Sonderlocken gedeckt sein (xiaomi-Modul oder meine alten milight-Versuche)...

[Billy]

Aus meiner Sicht, das Richtige wäre, wir tun uns zusammen und schaffen einen kompatibles Pendant zum MQTT2_SERVER für Anbindung von externen Servern. MQTT2_CLIENT oder so.

Dem kann ich als user nur beipflichten.
Das jetzige Wirrwar dürfte für Anfänger schwierig sein.
Die Generic Bridge zur Anbindung bestehender FHEM-Devices sollte allerdings überleben.
Trotzdem waren die alten Module für mich hilfreich, da es nichts besseres gab.
Hat mich sowieso gewundert wie lange es gedauert hat bis die Profis sich dem Thema Mqtt in FHEM angenommen haben.

[Martin Fischer]

Hola! Da habe ich ja mal ein Faß aufgemacht. Schööööön 

Ich bin nun nicht komplett in Eure Diskussion abgetaucht, sehe aber durchaus gute Argumente auf beiden Seiten. Nun jedoch ein ABER:
Bzgl. MQTT bin ich (noch) ein unbeschriebenes Blatt. Ich habe mich in der Vergangenheit nicht damit befasst / befassen müssen.

Nun habe ich innerhalb der FHEM Welt damit angefangen. Für meinen Anwendungsfall benötige ich derzeit keinen externen Broker; mir würde einer der direkt aus FHEM heraus erzeugt wird reichen. In meinem Szenario möchte ich einfach nur FHEM Devices aus FHEM Instanzen, die in unterschiedlichen Netzsegmenten vorhanden sind an einer anderen Stelle zusammen führen. Und das möglichst nicht mittels FHEM2FHEM. So bin ich letztlich bei MQTT_SERVER (und Mosquito), MQTT_BRIDGE und MQTT_DEVICE gelandet. Das läuft auch "out of the box". Danke an dieser Stelle an den / die Maintainer.

Allerdings stört mich das "Doppeln" der Devices doch arg. Ich bin dann über MQTT2_SERVER und MQTT2_DEVICE gestolpert. Den (für meinen Anwendungsfall) ausreichenden Ansatz auf einen externen Broker verzichten zu können, hielt ich für den ersten Augenblick super. Es kam Ernüchterung als ich sah, das es keinen "Bridgemode" gab (oder ich ihn übersehen habe).

Mein Ziel ist es nicht, die beiden "Lager" MQTT & MQTT2 gegeneinander aufzuwiegeln. Nein! Ich versuche das Ganze aus Sicht des Users zu sehen (in diesem Fall trifft das ja auch auf mich zu.). Je transparenter das Thema ist und je weniger Aufwand betrieben werden muss, desto einfacher ist es.

Ich fände es sinnvoll die Energie der Entwickler zu bündeln und daraus ein Ergebnis zu schaffen, das als "core feature" für FHEM einfliesst. Aus diesem Gedanken resultierte mein erster Beitrag.

Nach meinem Verständnis sollte dabei folgendes entstehen (Namen sind variabel):
MQTT_SERVER als "Proxy" für einen externen Broker oder als eigenständiger Broker konfigurierbar.
MQTT_DEVICE um "externe" Geräte die MQTT "sprechen" in FHEM einzubinden. Das kann auch ein FHEM Device aus einer anderen FHEM Instanz sein.
Neben diesen beiden Modulen werden neue globale Attribute eingeführt, mit denen jedes (beliebiges?) FHEM Device ohne zusätzliches Bridge oder generisches MQTT Device ebenfalls bidirektional über den bereits definierten Broker via MQTT_SERVER kommunizieren kann.

Ohne mir arg Gedanken über die Architektur gemacht zu haben. Also quasi "FHEM core interne notify Funktionalitäten zur Auswertung und dispatchen der Events von MQTT Devices".

[Beta-User]

Hmmm, also mal meine Gedankenwelt (bin ebenfalls user, habe aber etwas Erfahrung mit den Internas):
Zwei IO-Varianten:
MQTT - Broker ist extern (kann mosquitto über localhost oder ein entferntes FHEM mit MQTT2_Server sein)
MQTT2_Server als Generisches IO und Server von weiteren Installationen zu erreichen.
Generische mqtt-Geräte (z.B. ein Tasmota-ESP) werden über ein Modul, das wie MQTT2_Device in der heutigen Fassung konfiguriert werden kann eingebunden. Kann intern mit beiden Servertypen...

Bestehende Devices werden über Generic_Bridge (as is) angebunden (ein Zusatzmodel pro Fhem-Installation, das diese Option für alle Devices dieses Fhems anbietet).

Damit gäbe es nur zwei Baustellen:
Schnittstelle MQTT zu MQTT2_Device (bereits hier diskutiert)
IO-Funktionalität für Generic_Bridge auf dem FHEM-Rechner, der MQTT2_Server bereitstellt (bisher nicht ausdrücklich thematisiert)

So kann man das m.e. auch Einsteigern halbwegs verständlich machen, warum es jeweils bestimmte Module gibt).

[hexenmeister]

Mit dem meisten völlig einverstanden. Ein Extra-Device (GenericBridge) würde ich vorziehen vor der automatischen Unterstützung MQTT-Funktionalität für alle Devices. Kann man natürlich diese Erweiterung in die MQTT-Instanz einbauen, ich finde jedoch, man sollte sie nicht unnötig überfrachten.

GenericBridge würde ich ggf. erweitern und mit MQTT2 kompatibel machen. Ich könnte auch MQTT2_DEVICE kompatibles MQTT Modul entwickeln, kommen allerdings nicht so schnell dazu.

[Beta-User]

Bei Bedarf kann ich gerne Unterstützung anbieten. Bin aber nicht der Perl-Held... Die MQTT-Module scheinen aber ähnlich aufgebaut zu sein wie MySensors - und die kenne ich... Geht aber auch nicht gleich.

@Martin Fischer:
Das meiste geht übrigens heute schon und würde sich - bis auf die MQTT2-Geschichte auf dem Fhem, das den MQTT2-Server hostet - ohne weiteres umsetzen lassen.
Ergänzend (wenn auch nicht optimal bzw ressourcenschonend): man kann auch MQTT auf den MQTT2-Server auf demselben Rechner konfigurieren. Wenn das setting dann mal so kommt, dass intern der Zwischenschritt wegfallen kann, ist der Umbau schnell gemacht...

[Martin Fischer]

MQTT_GENERIC_BRIDGE ist sicher ein guter Ansatz aber so wie ich das sehe habe ich nur zwei Möglichkeiten:
entweder ich überwache alle FHEM Devices (bei mir zur Zeit 587 Definitionen in einer einzelnen FHEM Instanz) was vermutlich eine gewisse Last (und Latenz) mit sich bringen wird

oder

ich muss via [devspec] einen Rattenschwanz an Devices einzeln auführen oder via RegExp schauen, das ich alles unterkriege. Alternative: mehrere MQTT_GENERIC_BRIDGE Devices für weitere Devices (Devicegruppen).

Ich finde beide Varianten nicht so "benutzerfreundlich". 

Was ist wenn ich ca. 20 bis 30 ausgewählte Devices via MQTT einbinden will. Z.B. um für eine weitere FHEM Insanz ein Display mittels SmartVISU in einem anderen Netzsegment zu "bestücken"? Dies ist z.B. einer meiner aktuellen Anwendungsfälle.

Ein defmod <mqtt.foo> MQTT_GENERIC_BRIDGE mqtt <device01>,<device02>,.......<device29>,<device30> halte ich für nicht praktikalbel, geschweige denn übersichtlich. Was wenn ich <device17> und <device23> nicht mehr benötige? Dann muss ich jedesmal das MQTT_GENERIC_BRIDGE Device anpassen. Hm...

Ein defmod <mqtt.foo> MQTT_GENERIC_BRIDGE mqtt TYPE=<foo>,TYPE=<bar>,<device_x>,<device_y> ist auf Grund der unterschiedlichen Devices die ich auswähle auch nicht möglich. Ebenso kein Regular Expression, die meine Device "einfangen" würde.

Daher der Gedanke das über globale Attribute zu Regeln. Dann kann ich gezielt bereits bestehende Devices über das Setzen der entsprechenden Attribute am betroffenen Device selbst festlegen. Ich finde den Ansatz über eine Bridge nicht notwendig, wenn man die Philosophie "Standardprotokoll für das Internet der Dinge" in den Fokus nimmt und diese für FHEM als "Kernbestandteil" aufgreift.

[hexenmeister]

Ich verstehe nicht, wie sich dein Ansatz davon unterscheidet, alle Devices mit der GenericBridge zu überwachen? Auch ihne Bridgeinstanz müsste man das selbe tun. Weil alle Geräte potenziell betroffen sein können, müssen alle überwacht werden.
Aber besonders viel Last erzeugt das nicht. Die Bridge merkt schnell, dass es sich ggf. un einen 'fremden' Gerät handelt. Sollte es hier dennoch Performanceprobleme geben, hätte ich noch eine oder andere Optimierung einbauen können.

Meine älteste FHEM-Instanz (die räume ich nach und nach auf und verlagere einzelne Gerätegrupper (per MQTT angebunden) in andere FHEMs) hat aktuell 831 Geräte. Und keine Performanceprobleme mit der Bridge. 

Unten ein Auszug aus apptime-Ausgabe. Da sind einige 'böse' Kandidaten. GenericBridge ist das aber nicht (s. letzte Zeile). Trotz dem, dass alle Geräte pauschal überwacht werden.

Code Auswählen Erweitern

fhem> apptime
active-timers: 92; max-active timers: 94; max-timer-load: 15  min-tmrHandlingTm: 0.3ms; max-tmrHandlingTm: 1958.8ms; totAvgDly: 27.9ms

name                                     function                               max    count      total  average   maxDly   avgDly TS Max call     param Max call
tmr-myCtrlBase_ProcessTimer              HASH_unnamed                          1958      217    7536.94    34.73  1143.21    45.39 06.11. 21:34:20 HASH(0x211c940)
hmlgw                                    HMUARTLGW_Read                         652      111    9378.47    84.49     0.00     0.00 06.11. 21:33:01 HASH(hmlgw)
HC_Test                                  HourCounter_Notify                     448      261    1565.36     6.00     0.00     0.00 06.11. 21:33:02 HASH(HC_Test); HASH(EG_HA_SA01.Zirkulationspumpe)
HMLAN1                                   HMLAN_Read                             407       80    3321.64    41.52     0.00     0.00 06.11. 21:31:21 HASH(HMLAN1)
tmr-at_Exec                              HASH(0x422d140)                        387        1     387.03   387.03    78.67    78.67 06.11. 21:33:00 HASH(T.AT.Steuerung_Zirkulationspumpe)
tmr-SYSMON_Update                        HASH(0x4541890)                        354        4    1139.57   284.89   819.84   283.07 06.11. 21:34:21 HASH(sysmon)
EG_HA_SA01.Zirkulationspumpe             CUL_HM_Set                             256        2     263.90   131.95     0.00     0.00 06.11. 21:33:00 HASH(EG_HA_SA01.Zirkulationspumpe); EG_HA_SA01.Zirkulationspumpe; on
tmr-at_Exec                              HASH(0x44c7b08)                        246        1     246.87   246.87     2.52     2.52 06.11. 21:32:43 HASH(TE_NN_SAVE_STATE)
hmusb                                    HMLAN_Read                             157       64    1044.76    16.32     0.00     0.00 06.11. 21:33:01 HASH(hmusb)
FGW14                                    TCM_Read                               126     2899   12958.98     4.47     0.00     0.00 06.11. 21:30:49 HASH(FGW14)
GC.notify                                notify_Exec                            122        5     279.13    55.83     0.00     0.00 06.11. 21:31:37 HASH(GC.notify); HASH(GC)
tmr-SYSMON_Update                        HASH(0x4785080)                        114        4     284.16    71.04   724.65   283.22 06.11. 21:33:21 HASH(sysmon_r3)
tmr-CUL_HM_respPendTout                  respPend                               112        4     120.57    30.14    36.60    10.70 06.11. 21:32:41 respPend:286734
mqtt                                     MQTT::Read                             107       47    1878.67    39.97     0.00     0.00 06.11. 21:32:20 HASH(mqtt)
tmr-at_Exec                              HASH(0x4540e40)                        106        4     391.74    97.94   466.06   119.68 06.11. 21:34:00 HASH(tickHeartbeat)
tPort_127.0.0.1_45797                    telnet_Read                             92       96     449.03     4.68     0.00     0.00 06.11. 21:33:03 HASH(tPort_127.0.0.1_45797)
mqttGeneric                              MQTT::GENERIC_BRIDGE::Notify            91      261     211.02     0.81     0.00     0.00 06.11. 21:32:21 HASH(mqttGeneric); HASH(DG_WZ_KS01)


[Martin Fischer]

In der Tat lässt hier apptime auf wenig Last schliessen. Das ist doch dann gut und somit spräche ja auch (vermutlich) nichts gegen eine Überwachung aller Devices. Ich möchte an dieser Stelle nicht missverstanden werden: Ich versuche hier nicht die Bridge schlecht zu reden. Ich hinterfrage und beleuchte nur verschiedene Ansätze.

Einer davon ist:
Wenn ich 587 oder 831  Devices definiert habe aber nur 20, 30 Devices via MQTT kommunizieren lassen will, warum sollen dann permanent 587 / 831 Devices "überwacht" werden. Ein Grossteil ist da ja nicht involviert.

Ein anderer Ansatz ist:
Die 20, 30 Devices gezielt mittels Attribut am Device selbst (weil ich gerne die entsprechenden Informationen am Device vorhalten würde ) zu konfigurieren und dann auf nur diese zu überwachen.

Meine Anmerkungen zum Thema Last und Latenz beziehen sich u.a. auf die commandref:

The second parameter ('devspec') allows to minimize the number of devices to be monitored (otherwise all devices will be monitored, which may cost performance).

Aber das scheint hier dann ja so nicht der Fall zu sein. Letztlich suche ich gerade nur den richtigen Weg für meinen Einstieg in MQTT und werde mich Euren Vorgaben fügen  und vielleicht das eine oder andere mal laut denken. Da ich im Moment wenig bis gar keine Zeit zum coden habe, werde ich auch kein MQTT3 auf den Markt schmeissen 

Schön fände ich wenn das Zusammenspiel der FHEM Module "harmonisiert" und transparenter wird.

[hexenmeister]

Ich habe zunächst auch Probleme an der Stelle (Notify) erwartet und hatte schon mal Optimierungsstrategien überlegt. Man könnte natürlich auch dynamisch die Liste der zu überwachenden Devices erweitern etc. Allerdings habe ich erstmal alle Optimierungspläne verworfen, da derzeit es nichts zu optimieren gibt.
Es passiert ja auch nicht viel - in der notify-sub wird geprüft, ob das Gerät bekannt ist, wenn nicht - fertig. Vereinfacht dargestellt - ein kurzes Lookup in einem Hash.

[Martin Fischer]

So wie ich es im Moment durchblicke, scheint es da auch keinen Stress zu geben.

Im Moment rätsel ich allerdings warum meine MQTT_GENERIC_BRIDGE nicht an das entsprechene MQTT_DEVICE published... und finde oder sehe den Fehler gerade nicht... *grummel*

[hexenmeister]

Meinst du ein mqtt_device in einer anderen fhem Instanz?
Posten mal bitte deine Konfiguration für die betroffenen devices.

[Martin Fischer]

Danke für Dein Interesse, Alex. Es lag wohl an dem vermeintlich fehlerhaften Modul mit Datum Ende Oktober. Ich bin in einem anderen Thread fündig geworden, wo Du bereits aktiv wurdest. Ein Update löste dann das Problem und bestätigte mir, das ich doch nicht blind war 

[rudolfkoenig]

Ich habe ein/das(?) MQTT2_CLIENT Modul eingecheckt, im wesentlichen ist es eine Alternative fuer MQTT2_SERVER, falls man externe MQTT-Server verwenden will.

Da ich es nicht ausgiebig getestet habe, bin ich auf Feedback angewiesen.

Achtung: da MQTT2_CLIENT keinen Zugriff auf das urspruengliche clientId hat, ist autocreate nur begrenzt moeglich.

[hexenmeister]

Prima Sache
Werde ich die Tage unbedingt testen (und mich daran machen, GenericBridge-Kompatibilität herzustellen )