Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE

[Phantomato]

meine Yeelight sendet auch mit der neue Version nix

[ergerd]

Hallo hexenmeister,

habe die Version gerade eingespielt, sie läuft bei mir. Dann muss das Problem bei Phantomato noch ein anderes sein.
Ich habe leider kein Yeelight, so kann ich da wohl nicht unterstützen.

Danke und Grüße
Rainer

[SamNitro]

Also bei mir läuft es auch mit der neuen Version.

@ Phantomato hast du FHEM neu gestartet nachdem du die Datei kopiert hast?

[hexenmeister]

Dann bin ich erstmal leider ratlos.
Ich habe dein Fall mit einem dummy, soweit es geht, nachgebaut und es funktioniert wie es soll. Alle Werte kommen an.

[hexenmeister]

Probiere mal bitte aus, ob meine Bastelei bei dir auch nicht geht:

Code Auswählen Erweitern

defmod test_SzYeelight dummy
attr test_SzYeelight devStateIcon {my $power=ReadingsVal($name,"power","off");;my $mode=ReadingsVal($name,"color_mode","RGB");;if($power eq "off"){Color::devStateIcon($name,"rgb","rgb","power");;}else{if($mode eq "RGB"){Color::devStateIcon($name,"rgb","rgb","bright");;}elsif($mode eq "color temperature"){Color::devStateIcon($name,"rgb",undef,"bright");;}}}
attr test_SzYeelight group Licht
attr test_SzYeelight mqttPublish rgb|bright|ct|power|state:topic={"stat/$device/$reading"}  rgb|bright|ct|power|state:retain=0
attr test_SzYeelight mqttSubscribe rgb|bright|ct|power:stopic={"cmnd/$device/$reading"}
attr test_SzYeelight readingList rgb bright ct power
attr test_SzYeelight room TEST_Reported
attr test_SzYeelight webCmd rgb:bright:ct:rgb ffffff:rgb ff0000:rgb 00ff00:rgb 0000ff:on:off
attr test_SzYeelight widgetOverride bright:colorpicker,BRI,0,1,100 ct:colorpicker,CT,1700,10,6500 rgb:colorpicker,RGB


[Phantomato]

@ Phantomato hast du FHEM neu gestartet nachdem du die Datei kopiert hast?

ja hatte ich, hauptsächlich "reload 10_MQTT_GENERIC_BRIDGE.pm" (Befehl stimmt oder?) als auch ein "shutdown restart" (keine Ahnung zu welchen Zeitpunkt). Die Datei hatte ich nach "opt/fhem/FHEM" kopiert. War auch der Meinung, dass die Rechte stimmen würde.

Dann den Dummy von Hexenmeister ausprobiert. Ging auch nicht. Also nochmal "update" & "shutdown restart". Und siehe da es läuft. 

Keine Ahnung was sich quer gestellt hat aber jetzt tuts

[hexenmeister]

Ist auch egel, Hauptsache, es läuft

[hexenmeister]

Bin heute endlich dazu gekommen, JSON-Unterstützung für Subscribe anzusehen.
Wie ich es schon vermutet habe, kann diese leicht mit Hilfe von "expression" in mqttSubscribe realisiert werden.
Eine kleine Modifikation im Code machte das noch etwas einfacher und hier ist ein Beispiel für funktionierende Konfiguration:

Code Auswählen Erweitern

json:topic=/TEST/json json:expression={json2nameValue($message)}

Sendet man jetzt z.B. folgende JSON: {"jtest1":"jval1","jtest2":"jval2"} dann werden zwei Readings (jtest1 und jtest2) entsprechend angelegt/aktualisiert.

Jetzt mache ich mich an die Unterstützung von MQTT2

[Billy]

Bin heute endlich dazu gekommen, JSON-Unterstützung für Subscribe anzusehen.
Wie ich es schon vermutet habe, kann diese leicht mit Hilfe von "expression" in mqttSubscribe realisiert werden.
Eine kleine Modifikation im Code machte das noch etwas einfacher und hier ist ein Beispiel für funktionierende Konfiguration:

Code Auswählen Erweitern

json:topic=/TEST/json json:expression={json2nameValue($message)}

Sendet man jetzt z.B. folgende JSON: {"jtest1":"jval1","jtest2":"jval2"} dann werden zwei Readings (jtest1 und jtest2) entsprechend angelegt/aktualisiert.

Bin mal wieder am testen.
Kannst du mir da auf die Sprünge helfen?
Mein Sonoff POW sendet in Json für das Reading ENERGY folgendes.

Code Auswählen Erweitern


{"Time":"2018-11-12T17:20:41","ENERGY":{"Total":0.061,"Yesterday":0.002,"Today":0.002,"Period":0,"Power":7,"Factor":0.39,"Voltage":225,"Current":0.080}}

Wie muss ich das JSON auflösen? Wobei mich das nur ab "ENERGY": interessiert.
Komme mit deinem Beispiel nicht zurecht.

illy

[hexenmeister]

Kannst genauso nehmen, wie es ist (nur Topic wäre noch anzupassen):

Code Auswählen Erweitern

json:topic=/TEST/json json:expression={json2nameValue($message)}
Auswahl von Readings aus JSON ist derzeit nich möglich, werden alle genommen. Wäre das wichtig?

[Billy]

Kannst genauso nehmen, wie es ist (nur Topic wäre noch anzupassen):

Code Auswählen Erweitern

json:topic=/TEST/json json:expression={json2nameValue($message)}
Auswahl von Readings aus JSON ist derzeit nich möglich, werden alle genommen. Wäre das wichtig?

So, hat funktioniert, aber leider nur 1 mal aufgelöst?
d.h. Während das Reading Energy --> "Time":"2018-11-12T19:56:20 refreshed,
passiert keine Json Auflösung mehr.

d.H. 2018-11-12 19:43:00   Zeitstempel bleibt stehen.
Siehe auch List:

Code Auswählen Erweitern

Internals:
   NAME       myTest3
   NR         134
   STATE      off
   TYPE       dummy
   OLDREADINGS:
   READINGS:
     2018-11-12 19:56:21   ENERGY          {"Time":"2018-11-12T19:56:20","ENERGY":{"Total":0.062,"Yesterday":0.002,"Today":0.004,"Power":0,"Factor":0.00,"Voltage":0,"Current":0.000}}
     2018-11-12 19:43:00   ENERGY_Current  0.000
     2018-11-12 19:43:00   ENERGY_Factor   0.00
     2018-11-12 19:43:00   ENERGY_Power    0
     2018-11-12 19:43:00   ENERGY_Today    0.004
     2018-11-12 19:43:00   ENERGY_Total    0.062
     2018-11-12 19:43:00   ENERGY_Voltage  0
     2018-11-12 19:43:00   ENERGY_Yesterday 0.002
     2018-11-12 19:43:00   Time            2018-11-12T19:42:59
     2018-11-12 19:56:53   state           OFF
Attributes:
   devStateIcon on:black_Steckdose.on off:black_Steckdose.off
   eventMap   ON:on OFF:off
   mqttPublish state:topic=cmnd/sonoff_pw2/POWER1
   mqttSubscribe state:stopic=stat/sonoff_pw2/POWER1
ENERGY:topic=tele/sonoff_pw2/SENSOR json:expression={json2nameValue($message)}
   room       MQTT
   setList    on off
   userattr   mqttAlias:textField-long mqttDefaults:textField-long mqttDisable:both,incoming,outgoing mqttForward:all,none mqttPublish:textField-long mqttSubscribe:textField-long
   webCmd     on:off

Parallel mit MQTT2_CLIENT und MQTT2_DEVICE

sieht das so aus.

Code Auswählen Erweitern

READINGS:
     2018-11-12 20:06:00   ENERGY_Current  0.000
     2018-11-12 20:06:00   ENERGY_Factor   0.00
     2018-11-12 20:06:00   ENERGY_Period   0
     2018-11-12 20:06:00   ENERGY_Power    0
     2018-11-12 20:06:00   ENERGY_Today    0.004
     2018-11-12 20:06:00   ENERGY_Total    0.062
     2018-11-12 20:06:00   ENERGY_Voltage  0
     2018-11-12 20:06:00   ENERGY_Yesterday 0.002
     2018-11-12 19:56:53   POWER           OFF
     2018-11-12 20:06:00   Time            2018-11-12T20:06:00
     2018-11-12 19:56:53   state           OFF

Billy

[hexenmeister]

Ah! Ne, die Expression muss zu dem Topic-Namen gehören. Wenn schon "ENERGY:topic=tele/sonoff_pw2/SENSOR", dann auch "ENERGY:expression={json2nameValue($message)}"

P.S. und das eigentliche JSON-String wird gar nicht erst in einem Reading gespeichert.

[Billy]

Ah! Ne, die Expression muss zu dem Topic-Namen gehören. Wenn schon "ENERGY:topic=tele/sonoff_pw2/SENSOR", dann auch "ENERGY:expression={json2nameValue($message)}"

P.S. und das eigentliche JSON-String wird gar nicht erst in einem Reading gespeichert.

Top jetzt alles wie es soll!

Auswahl von Readings aus JSON ist derzeit nich möglich, werden alle genommen. Wäre das wichtig?

Muß nicht sein.

Danke jetzt werde ich wohl langsam die MQTT_GENERIC_BRIDGE auch auf meinen heißen Systemen implementieren.

[HomeAlone]

Ich experimentiere gerade wieder mit der MQTT_GENERIC_BRIDGE, da sie wirklich genial komfortabel in fhem integriert ist - und in der Hoffung auf baldige Unterstützung von TLS-geschützter Kommunikation mit einem externen MQTT-Broker  .

Klappt soweit auch bestens, allerdings stelle ich gerade fest, dass auch ein HM-Device "mitpublished", obwohl es nicht in den Räumen definiert ist, die ich in der Bridge konfiguriert habe.

Die Brigde ist wie folgt konfiguriert:

Code Auswählen Erweitern

defmod mqttGeneric MQTT_GENERIC_BRIDGE mqtt room=ZWave,room=EnOcean
attr mqttGeneric IODev mqtt_smartgulp2
attr mqttGeneric globalPublish *:topic={"fhempub/$device/$reading"}
attr mqttGeneric globalTypeExclude *:power
attr mqttGeneric icon mqtt_device
attr mqttGeneric room MQTT,Zentralen

Für die Geräte in den Räumen ZWave und EnOcean habe ich keine spezifische MQTT-Konfiguration vorgenommen.

Folgende Message fängt mein MQTT.fx auf:

Code Auswählen Erweitern

fhempub/d_rpcBidCos_RF/No events from interface CB2001178072 for 600 seconds

Im Eventlog erscheint (schon vor Einrichtung der Brigde) folgende Mitteilung, welche ich auch als korrekt erachte, wenn ich für 10 Minuten keine HM-Devices bediene (habe nur zwei Funkschalter):

Code Auswählen Erweitern


2018.11.15 10:32:09 2 : HMCCURPCPROC: [d_rpcBidCos_RF] Received no events from interface CB2001178072 for 600 seconds
[...]
2018.11.15 10:42:09 2 : HMCCURPCPROC: [d_rpcBidCos_RF] Received no events from interface CB2001178072 for 600 seconds

Dieses Device ist weder im Raum ZWave noch im Raum EnOcean hinterlegt. Die Definition sieht wie folgt aus:

Code Auswählen Erweitern

defmod d_rpcBidCos_RF HMCCURPCPROC 192.168.178.231 BidCos-RF
attr d_rpcBidCos_RF alias CCU RPC BidCos-RF
attr d_rpcBidCos_RF eventMap /rpcserver on:on/rpcserver off:off/
attr d_rpcBidCos_RF icon cul_cul
attr d_rpcBidCos_RF room HomeMatic,Zentralen
attr d_rpcBidCos_RF stateFormat rpcstate/state
attr d_rpcBidCos_RF verbose 2

setstate d_rpcBidCos_RF running/OK
setstate d_rpcBidCos_RF 2018-11-15 09:12:09 rpcstate running
setstate d_rpcBidCos_RF 2018-11-15 09:12:09 state OK


Laut meinem Verständnis dürften die Nachrichten dieses Devices nicht via MQTT gepublished werden, oder?

[hexenmeister]

Die TLS Unterstützung wird kommen, indem MQTT2_CLIENT als IODev unterstützt wird. Die erste Alpha-Version habe ich bereits, sie ist jedoch noch lange nicht einsatzfähig.

DevSpec, was man im define angeben kann, dient lediglich dazu, die entsprechenden Geräte mit userAttr-Einträgen auszustatten, damit man an den entsprechenen Geräten die mqtt*-Attribute konfigurieren kann. Du verwendest eine globale Publish-Funktion, sie schickt einfach alles weg, was nicht durch exclude ausgeschlossen ist.
Ich schreibe auf die 'Wunschliste' dein Anwendungsfall. Sollte sich durch eine Prüfung gegen devspec realisieren lassen. Bin mir jedoch noch nicht sicher, ob das eine gute Idee ist, kann an der anderen Seite zu Verwirrung führen (nach dem Motto, warum wird etwas NICHT gesendet).