Best practise gesucht: Wie alle Events (des FHEM-Logfiles) per MQTT senden?

Begonnen von r00t2, 17 Januar 2020, 11:45:22

Vorheriges Thema - Nächstes Thema

r00t2

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!
FHEM 6.0 (Raspberry Pi 2 B | Raspberry Pi OS Lite | Perl 5.28.1 | UZB Z-WAVE.Me | Hue Bridge V1 | SIGNALDuino 433 MHz | FritzBox | Kodi | Pioneer AVR | MQTT | Node-RED | Diverse Google Dienste)

Beta-User

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 $EVENT
Hat 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!)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Otto123

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.
Ob es wirklich Sinn macht alles von A nach B zu schaffen?

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

@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...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Otto123

@Beta-User Hast Du Recht. :)
Ich hatte das 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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

r00t2

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.
FHEM 6.0 (Raspberry Pi 2 B | Raspberry Pi OS Lite | Perl 5.28.1 | UZB Z-WAVE.Me | Hue Bridge V1 | SIGNALDuino 433 MHz | FritzBox | Kodi | Pioneer AVR | MQTT | Node-RED | Diverse Google Dienste)

Otto123

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
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz