Nutzung von MQTT in eigenen Modulen

[Kimrio42]

Hallo Zusammen,

Ich möchte ein eigenes Modul schreiben das direkten Zugriff auf den MQTT Server hat. Das heißt, das Modul subscribed sich zu einem expliziten Topic z.B. MeinTopic/* und reagiert auf all dort ankommenden anfragen zusätzlich sendet es auch unter dem topic.

Da die Kommunikation sehr komplex und flexibel ist, möchte ich nicht mit MQTT_DEVICES oder MQTT2_DEVICES arbeiten.

Ich habe mir die Programmierung von MQTT(2)_DEVICES angeschaut und in ein eigenes Modul 98_MeinTest.pm kopiert und so modifiziert das ich direkt auf Topic und Message zugreifen kann. Leider ist mir dabei aufgefallen das mein Modul kein IODev bekommt da im Falle vom Test mit MQTT_DEVICE im Modul MQTT die Modulnamen fest im code eingetragen ist.

Gibt es eine (andere) Möglichkeit eigene Module zu entwickeln die direkt auf den MQTT Server zuzugreifen?

[Gisbert]

Hallo Kimiro42,

ich kann keine Antwort zu deiner Frage liefern, ich kann mir aber nicht vorstellen, dass die vorhandenen FHEM-Module nicht für deinen Zweck ausreichen. Beschreibe doch bitte mal genau, d.h. im Detail, was du vorhast, dann bestehen realistisch gute Chancen, dass du mit den vorhandenen Tool zurecht kommst.

Viele​ Grüße​ Gisbert​

[Beta-User]

Ja, das geht!

Aber: Es ist nicht ganz trivial, v.a., wenn man es "nebenwirkungsfrei" hinbekommen will. Beispielcode dazu ist in RHASSPY und MQTT_GENERIC_BRIDGE zu finden.
Wichtig ist dabei:
- Aus "Dispatch" müssen alle FHEM-Devices (an fhem.pl) zurückgegeben werden, die verändert wurden;
- Wenn das MQTT2-IO noch für was anderes genutzt werden soll, und das Modul die Nachricht nicht abschließend verarbeitet hat, muss [NEXT] zurückgegeben werden;
- clientOrder am IO-Dev muss manuell gesetzt werden, damit das Modul erkannt wird.

Ansonsten hat Gisbert mAn. recht.
Was hindert dich daran, den Rahmen aus MQTT2_DEVICE zu nehmen und pauschal in readingList $TOPIC und $EVENT an eine myUtils-Sub zu übergeben? Auch setList und getList kann man sehr flexibel konfigurieren - das Modul gibt eigentlich alles her, was man braucht, wenn man es mit "MQTT-only"-Kommunikation zu tun hat...

[herrmannj]

wünsch ich mir auch. Ich kanns auch nur per hack, (clientList im physischen Modul überschreiben). Ich frag mal Rudi ob er sich Alternativen vorstellen kann.

[Beta-User]

wünsch ich mir auch. Ich kanns auch nur per hack, (clientList im physischen Modul überschreiben). Ich frag mal Rudi ob er sich Alternativen vorstellen kann.

Es gibt ein Attribut dafür:

Code Auswählen Erweitern

attr m2client clientOrder RHASSPY MQTT_GENERIC_BRIDGE MQTT2_DEVICE
Das setzt dann auch das Internal "Clients" in der IO-Modulinstanz passend.

Oder war das nicht gemeint?

(Ich glaube aber immer noch, dass es nur in Sonderfällen Sinn macht, ein eigenes Client-Modul zu schreiben...).

[herrmannj]

ja stimmt. bei mqtt2 gehts auf diesem weg. Bei einem Cul oder TRX (etc) gehts nicht mehr. Ideal wäre wenn das universeller wäre.

[herrmannj]

btw; in Techem mach ichs anders, ist aber ein Hack (#159-#181): https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/32_TechemHKV.pm#L159

[Beta-User]

Hmm, da kann ich dann nicht ernsthaft mitreden... Im Prinzip müßte sowas eigentlich immer das IO unterstützen, oder?

Ich kenne nur die Diskussionen um MQTT_GENERIC_BRIDGE@MQTT2-IO's (das kam von 00_MQTT her, und das war schon immer "dreckig" gelöst, wie da das IO ermittelt wird) und eben jetzt RHASSPY.
In beiden Fällen macht m.E. ein "spezielles" neues Modul Sinn: MQTT_GENERIC_BRIDGE ist eben auch Event-Handler, RHASSPY macht einen Teil der Kommunikation via HTTP-Calls (und kam auch von 00_MQTT her). Aber für "reine" MQTT-Anwendungen sehe ich den Bedarf nicht so recht, aber ich lass mich mal überraschen, um was es hier geht.

[betateilchen]

Vielleicht könnte jemand, der sich mit sowas auskennt, mal eine Architektur skizzieren, worum es hier in der Diskussion eigentlich geht.

Im Moment klingt mir das hier

Das heißt, das Modul subscribed sich zu einem expliziten Topic z.B. MeinTopic/* und reagiert auf all dort ankommenden anfragen zusätzlich sendet es auch unter dem topic.

sehr danach, dass hier eine API zu einer API herbeigewünscht wird. Aber vielleicht verstehe ich das auch einfach falsch.

Grundsätzlich denke ich schon, dass MQTT innerhalb von FHEM immer mehr Raum einnehmen wird (und das sinnvollerweise auch sollte) wenn es darum geht, in einem möglichst simplen Protokoll mit der ganzen Welt kommunizieren zu können.

[Beta-User]

Hmm, deine Frage hat mich jetzt an "Rooma" erinnert: https://forum.fhem.de/index.php/topic,114166.0.html

Da stellt auch ein externer Dienst einen MQTT-Server bereit und das "alte" Modul hat das dann als "Einheits-Lösung" angezapft. Könnte sein, dass sowas dem TE auch vorschwebt,

da im Falle vom Test mit MQTT_DEVICE im Modul MQTT die Modulnamen fest im code eingetragen ist

klingt ein wenig in diese Richtung...

Na jedenfalls haben wir bis dato im fraglichen Thread zu Rooma auch das Ergebnis, dass MQTT2_CLIENT+MQTT2_DEVICE+myUtils die mittelfristig am einfachsten und flexibelsten zu pflegende Lösung darstellt. Vielleicht hilft der Vergleich ja weiter?

00_MQTT ist jedenfalls mAn. definitiv das falsche Pferd, wenn man heute was neues entwickelt.