[erledigt] Readings eines FHEM-Devices an MQTT2_Device schicken

Begonnen von Nighthawk, 11 Februar 2019, 02:23:35

Vorheriges Thema - Nächstes Thema

Nighthawk

Hallo zusammen,

ich habe umgestellt von MQTT auf MQTT2_Client und MQTT2_DEVICE.
Es funktioniert alles mittlerweile so wie ich es mir viorstelle, bis auf eine Kleinigkeit:
Ich habe ein OLED Display an welches ich vorher über eine MQTT_BRIDGE die Readings meines Luftdaten.info Sensors übermittelt habe:

define FeinstaubDisplay MQTT_BRIDGE Luftquali
attr FeinstaubDisplay IODev myBroker
attr FeinstaubDisplay publishReading_PM10 fhem/Luftquali/PM10
attr FeinstaubDisplay publishReading_PM2.5 fhem/Luftquali/PM2.5
attr FeinstaubDisplay publishReading_humidity fhem/Luftquali/humidity
attr FeinstaubDisplay publishReading_temperature fhem/Luftquali/temperature
attr FeinstaubDisplay stateFormat transmission-state


Leider habe ich bisher keine Möglichkeit gefunden, dies mit MQTT2 zu lösen.

Hier meine aktuelle Configuration:

MQTT Server ist Mosquitto.

MQTT2_Client
Internals:
   BUF       
   DEF        127.0.0.1:1883
   DeviceName 127.0.0.1:1883
   FD         4
   FUUID      5c5ff2ef-f33f-69d4-d4d5-e0db6a1f0f9c836d
   NAME       mqtt2_client
   NR         83
   PARTIAL   
   STATE      opened
   TYPE       MQTT2_CLIENT
   WBCallback
   clientId   mqtt2client
   lastMsgTime 1549848041.2138
   nextOpenDelay 5
   Helper:
     DBLOG:
       state:
         logdb:
           TIME       1549801695.4976
           VALUE      CONNECTED
   READINGS:
     2019-02-10 20:28:15   state           opened
Attributes:
   autocreate 1
   devStateIcon opened:10px-kreis-gruen closed:10px-kreis-rot
   group      Kommunikation
   icon       mqtt
   keepaliveTimeout 60
   room       System
   subscriptions #


MQTT2_Device:

Internals:
   CFGFN     
   CID        FeinstaubDisplay
   DEF        FeinstaubDisplay
   DEVICETOPIC MQTT2_FeinstaubDisplay
   FUUID      5c60bff4-f33f-69d4-2df1-7587ce73c9c97ed5
   IODev      mqtt2_client
   LASTInputDev mqtt2_client
   MSGCNT     1
   NAME       MQTT2_FeinstaubDisplay
   NR         2528
   STATE      ???
   TYPE       MQTT2_DEVICE
   mqtt2_client_MSGCNT 1
   mqtt2_client_TIME 2019-02-11 08:21:16
   Helper:
     DBLOG:
       LWT:
         logdb:
           TIME       1549844476.44303
           VALUE      Connected
   READINGS:
     2019-02-11 08:21:16   LWT             Connected
     2019-02-11 08:21:08   associatedWith  MQTT_Bridge
Attributes:
   IODev      mqtt2_client
   readingList /FeinstaubDisplay/status/LWT:.* LWT
   room       MQTT2_DEVICE

hexenmeister

Wie das mit mqtt2 Modulen geht, weiß ich nicht aus dem Kopf, du könntest aber auch MQTT_GENERIC_BRIDGE nehmen.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Nighthawk

Hallo Hexenmeister,

danke für die Rückmeldung, mich hat bei der MQTT_GENERIC_BRIDGE bisher abgeschreckt dass 1. das Autocreate abgeschaltet werden muss (einer der Hauptgründe für MQTT2) und auch die Tatsache dass in Kombination mit MQTT2 IOs im Hintergrund das MQTT Modul weiterhin laufen muss, was wertvolle Reccourcen frisst.


Gruß
Alex

rudolfkoenig

autocreate ist mit MQTT2_CLIENT nur ueber ein bridge-Device sinnvoll verwendbar, da FHEM die clientIDs nicht mitkriegt.
Eine Weiterleitung kann man mit notify auch einrichten, ist halt etwas Bastelei.

Beta-User

Da ich grade am Basteln war, ungetestet etwa so:

defmod test1 notify Luftquali:(PM10|PM2.5|humidity|temperature).* set mqtt2_client publish fhem/Luftquali/$NAME $EVTPART1
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Nighthawk


Nighthawk

Es geht in die richtige Richtung, leider ist der STring der beim Notify rauskommt nicht ganz sauber:

ich habe es jetzt abgeändert in
defmod test1 notify Luftquali:(PM10|PM2.5|humidity|temperature).* set mqtt2_client publish fhem/$NAME/EVTPART0 $EVTPART1

dabei kommt folgender string raus, als Beispiel PM10:

set mqtt2_client publish fhem/Luftquali/PM10:47.60

wie bekomme ich den Doppelpunkt weg und stattdessen ein Leerzeichen?

Beta-User

Hmm, da wirst du etwas Perl+regex brauchen, um den Doppelpunkt wegzumachen (siehe z.B. chop()), und vermutlich benötigst du einen weiteren Doppelpunkt, um $EVTPARTx sauber zu erzeugen. Das sieht mir so aus, als gäbe es nur $EVTPART0, das müßte eigentlich aus dem log zu sehen sein. Nimm ggf. den Event-Monitor zu Hilfe.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

hexenmeister

Zitat von: Nighthawk am 11 Februar 2019, 09:24:03
danke für die Rückmeldung, mich hat bei der MQTT_GENERIC_BRIDGE bisher abgeschreckt dass 1. das Autocreate abgeschaltet werden muss (einer der Hauptgründe für MQTT2) und auch die Tatsache dass in Kombination mit MQTT2 IOs im Hintergrund das MQTT Modul weiterhin laufen muss, was wertvolle Reccourcen frisst.
Beim autocreate teilen sich die Meinungen, ich selbst nutze es nicht und denke, es schadet mehr, als es bringt (wer 'per Hand' Geräte anlegt, weiß wie es geht und erlebt weniger Überraschungen).
Mit den Ressoucen stimmt so nicht. Der alte Modul läuft keineswegs mit. Wegen den (noch) vorhandenen harten Abhängigkeiten wird das MQTT-Modul lediglich passiv vorgehalten.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Nighthawk

#9
Hallo Alexander,

danke für die Aufklärung, das dass MQTT Modul laufen muss habe ich irgendwo hier im Forum aufgeschnappt.
Habe es jetzt mal mit der Gemeric_Bridge umgesetzt, mal sehen wie es läuft.

Was Autocreate angeht, musste ich leider auch feststellen dass es mehr Probleme mitbringt als es Arbeit abnimmt, da mir nach einem Umbenennen eines Devices immer wieder neue Devices angelegt wurden.

Trotzdem wüsste ich gerne ob die MQTT2 Module es auch ohne Zusatzmodule könnten..

hexenmeister

#10
Zitat von: Nighthawk am 11 Februar 2019, 14:23:43
Trotzdem wüsste ich gerne ob die MQTT2 Module es auch ohne Zusatzmodule könnten..
Ohne 'Zusatzmodule' kann es prinzipiel nicht gehen.
Du benötigst ein IO-Device und Devices, die die Daten 'transportieren'. Das können entweder N-Stück MQTT(2)_DEVICE-Instanzen sein, oder eine einzige GenericBridge.
Maintainer: MQTT_GENERIC_BRIDGE, SYSMON, SMARTMON, systemd_watchdog, MQTT, MQTT_DEVICE, MQTT_BRIDGE
Contrib: dev_proxy

Nighthawk

OK, danke.
Für mich funktioniert es mit der Generic Bridge, daher erledigt.

Gruß
Alex