Hallo zusammen,
ich möchte gerne alle Events (oder zumindest alle Einträge, die ins FHEM Log geschrieben werden) auch per MQTT Message übertragen.
Dabei soll - wenn möglich - sowohl der "Initiator" des Events, als auch der Meldungstext des Events selbst als Payload übertragen werden.
Leider stehe ich gerade wie der Ochs vor dem Berg.
Ich hatte schon testweise versucht, ein Notify mit Trigger auf *.* zu setzen, Events so abzufangen, im Notify aufzubereiten (Trennung in Sender und Inhalt), in einen Dummy zu schreiben und für diesen per MQTT_Bridge ein "pub" an den lokalen MQTT Broker (mosquitto) zu initiieren, jedoch kamen da scheinbar nicht alle Befehle an, die auch im Log gelandet sind.
Denke ich hier falsch und es gibt eine elegantere Lösung? Z. B. das Schreiben einer MQTT Message direkt aus dem Notify heraus?
Danke euch für ein paar erhellende Gedanken!
Zitat von: r00t2 am 17 Januar 2020, 11:45:22
Denke ich hier falsch und es gibt eine elegantere Lösung? Z. B. das Schreiben einer MQTT Message direkt aus dem Notify heraus?
Danke euch für ein paar erhellende Gedanken!
Zur Sinnhaftigkeit stelle ich jetzt mal keine Frage und auch nicht, ob das folgende erhellend ist...
Es gibt zwei (mMn.) einfachere Wege:
- Direktes publischen auf das IO sollte gehen:
set <io-Name> publish meinFHEMa/$NAME/$EVTPART1 $EVENTHat nur den Nachteil, dass eventuell der Doppelpunkt bei $EVTPART1 unschön ist und die Payload dann wieder alles beinhaltet und daher vermutlich auf Empfängerseite nachgearbeitet werden muß.
Kann man "verschönern", wenn man etwas Perl dazwischenhängt und vor dem Versenden z.B. den Doppelpunkt entfernt und Readingname und Rest des Events trennt...
- 2. Lösung: MQTT_GENERIC_BRIDGE verwenden.
Das hat den "Nachteil" (mMn. Vorteil), dass du jeweils pro zu übertragendem Gerät via Attribut noch festlegen mußt, was wie zu versenden sein soll. Aber auch das arbeitet ggf. mit zentral vergebenen Wildcards, so dass dort z.B. auch $room zur Verfügung steht (?).
Würde diesen Weg empfehlen!
(MQTT_BRIDGE sollte man heute nicht mehr neu verwenden!)
Wegen dem Doppelpunkt (Verschönern) ;) hatte ich mal sowas gemacht:
set mqtt2c publish -r home/states/$NAME/{((split(":","$EVTPART0"))[0])} $EVTPART1
Die Idee dazu war von Dan (https://forum.fhem.de/index.php/topic,56974.msg484130.html#msg484130).
Ob es wirklich Sinn macht alles von A nach B zu schaffen?
Gruß Otto
@Otto: Danke für den Hinweis, dass man $EVTPART0 nehmen sollte und den Code (war mir nicht klar, dass man das auf diese Weise schreiben kann, hätte "klassisches nur-Perl" genommen, und dort "chop($EVTPART0)" geschrieben...).
Allerdings hat der Code einen Haken: Weiterer Content ($EVTPART2...) ginge verloren ;) . Man bräuchte hier dann mMn. eine split/shift/join-Pipeline für $EVENT...
@Beta-User Hast Du Recht. :)
Ich hatte das (https://heinz-otto.blogspot.com/2019/11/mqtt-ich-muss-das-testen.html) gemacht um Beispielhaft ein paar Werte von A nach B zu schaffen. Um wirklich den kompletten Events zu transportieren muss man es verfeinern ;) Mein Gehirn sprang bei Deiner Bemerkung nach dem Doppelpunkt an - das hatte "ich" doch schon "gelöst" . ;D
Ansonsten sag ich mal: Ob man das per MQTT machen und neu erfinden muss? per FHEM2FHEM geht genau das ja quasi - ohne viel drumherum. Klar MQTT ist ein andere Weg ;)
Gruß Otto
Danke euch beiden für den Input.
Da hab ich das Wochenende ja einiges zu lesen - und hoffentlich auch Zeit zu testen :)
Wegen der Sinnhaftigkeit: FHEM2FHEM ist mir bekannt. Das ganze wird über MQTT in Node-RED noch etwas weiter verarbeitet und teilweise auf einen externen Webserver geschrieben. Das geht dort mit grafisch per JavaScript (für mich) komfortabler, als in FHEM textuell mit Perl.
Naja aber dann erst Recht: Doch nicht alles? Die erste Verarbeitung ist doch Filtern der Informationen ;)
Dazu ein ordentliches, eingeschränktes regExp in den Trigger und das bei Bedarf aufbohren. Übrigens -> Notify mit Trigger auf *.* - ist aus dem Bereich Wildcards :) das richtige regExp für ALLES wäre .*
Gruß Otto