Modul-Diskussion/Hilfe: MQTT_GENERIC_BRIDGE

Begonnen von Master_Nick, 11 Oktober 2018, 17:23:24

Vorheriges Thema - Nächstes Thema

Phantomato

meine Yeelight sendet auch mit der neue Version nix :(
Server: RaspberryPi4 4GB @Raspbian GNU/Linux 10 (buster), Docker, FHEM Docker | Homematic nanoCUL868 (VCCU) | Tasmota Switch & Sensors | Tasmota Zigbee | Zigbee2mqtt | SIGNALduino | Alexa & GoogleHome

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
FHEM auf RasPi 4, CUNO, ZigBee, 1Wire2WLAN, DS2423, Buderus KM200, LaCrosseGateway, PCA301, ConBee II, LuftdatenInfo, OneWireGW, Div. ESPs u. Shellys

SamNitro

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

@ Phantomato hast du FHEM neu gestartet nachdem du die Datei kopiert hast?
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

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:
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

Zitat von: SamNitro am 04 November 2018, 21:36:03
@ 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.  :D :D :D

Keine Ahnung was sich quer gestellt hat aber jetzt tuts 8)
Server: RaspberryPi4 4GB @Raspbian GNU/Linux 10 (buster), Docker, FHEM Docker | Homematic nanoCUL868 (VCCU) | Tasmota Switch & Sensors | Tasmota Zigbee | Zigbee2mqtt | SIGNALduino | Alexa & GoogleHome

hexenmeister


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. 8)
Eine kleine Modifikation im Code machte das noch etwas einfacher und hier ist ein Beispiel für funktionierende Konfiguration:
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

Zitat von: hexenmeister am 11 November 2018, 23:18:54
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. 8)
Eine kleine Modifikation im Code machte das noch etwas einfacher und hier ist ein Beispiel für funktionierende Konfiguration:
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.

{"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
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

hexenmeister

Kannst genauso nehmen, wie es ist (nur Topic wäre noch anzupassen):
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

Zitat von: hexenmeister am 12 November 2018, 18:13:49
Kannst genauso nehmen, wie es ist (nur Topic wäre noch anzupassen):
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:

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.
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
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

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

Zitat von: hexenmeister am 12 November 2018, 20:14:17
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! :)
ZitatAuswahl 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. 8)
FHEM immer akt. auf 3 BeagleBoneBlack: 2xHMLAN 2xJeelink ;10x HM-CC-TC, 13x HM-CC-VD, 1x HM-ES-PMSw1-Pl, 3x HM-LC-SW1-PL2, viele ESP8266, Tasmota Scripting, Mqtt*

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:
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:
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):

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:
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).