Modul-Vorstellung: MQTT_GENERIC_BRIDGE

Begonnen von hexenmeister, 31 August 2018, 20:53:56

Vorheriges Thema - Nächstes Thema

Billy

#60
Kann ich bestätigen.
Hätte ich heute auch noch gemeldet.
Beim neuen verknüpfen eines device mit der Bridge sind die attr der anderen devices gelöscht.
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

Nachvollzogen, gefunden, gefixt. Morgen per Update :)
Die Steuerattribute werden jetzt auch beim entfernen des Gerätes aus der Liste nicht angefast. Nach dem Restart sind sie natürlich dann weg.

hexenmeister

Ach ja, in der neuen Version wird es jetzt verhindert, dass die Readings-Änderungen durch Empfang per MQTT sofort weitergepublisht werden. Damit kann publish und subscribe mit derselben Readings verwendet werden, ohne dass es zu Loops kommt.

So kann man dann aus dummies leicht Steuergeräte in einer anderen FHEM-Instanz basteln, so eine Art FHEM2FHEM-Ersatz. Diese sehen aus und verhalten sich dann eben wie auch eigentliche Gerätschaften.

Beispiele:
- Switch:
defmod DG_WZ_Licht_Top dummy
attr DG_WZ_Licht_Top devStateIcon off:light_light_dim_00@gray on:light_light_dim_100@#FF5722 .*:hourglass
attr DG_WZ_Licht_Top eventMap {usr=>{'an'=>'on','aus'=>'off'}}
attr DG_WZ_Licht_Top group Beleuchtung
attr DG_WZ_Licht_Top icon light_ceiling
attr DG_WZ_Licht_Top mqttPublish state:topic=dg/wz/licht/top/set
attr DG_WZ_Licht_Top mqttSubscribe state:topic=dg/wz/licht/top/state
attr DG_WZ_Licht_Top room Wohnzimmer
attr DG_WZ_Licht_Top setList on off
attr DG_WZ_Licht_Top webCmd an:aus


- Dimmer:

defmod DG_WZ_Licht_Hoch dummy
attr DG_WZ_Licht_Hoch devStateIcon off:light_light_dim_00@gray 0:light_light_dim_00@gray dark:light_light_dim_10@#FF5722 \d:light_light_dim_10@#FF5722 1\d:light_light_dim_20@#FF5722 2\d:light_light_dim_30@#FF5722 3\d:light_light_dim_40@#FF5722 4\d:light_light_dim_50@#FF5722 5\d:light_light_dim_60@#FF5722 half:light_light_dim_60@#FF5722 6\d:light_light_dim_70@#FF5722 7\d:light_light_dim_80@#FF5722 bright:light_light_dim_80@#FF5722 8\d:light_light_dim_90@#FF5722 9\d:light_light_dim_100@#FF5722 100:light_light_dim_100@#FF5722 on:light_light_dim_100@#FF5722 .*:hourglass
attr DG_WZ_Licht_Hoch eventMap {dev=>{'on'=>'100','off'=>'0'}, \
usr=>{'an'=>'on','aus'=>'off','dunkel'=>'15','hell'=>'70','halb'=>'50'}}
attr DG_WZ_Licht_Hoch group Beleuchtung
attr DG_WZ_Licht_Hoch icon light_ceiling
attr DG_WZ_Licht_Hoch mqttPublish level:topic=dg/wz/licht/hoch/set\
state:topic=dg/wz/licht/hoch/set
attr DG_WZ_Licht_Hoch mqttSubscribe level:topic=dg/wz/licht/hoch/level\
state:topic=dg/wz/licht/hoch/state
attr DG_WZ_Licht_Hoch readingList level
attr DG_WZ_Licht_Hoch room Wohnzimmer
attr DG_WZ_Licht_Hoch setList on off level:slider,0,1,100
attr DG_WZ_Licht_Hoch sortby 10wz_20
attr DG_WZ_Licht_Hoch stateFormat level
attr DG_WZ_Licht_Hoch webCmd an:hell:halb:dunkel:aus:level

hexenmeister

Zitat von: hopgeq am 25 September 2018, 00:35:12
Die Beispiele könnten vielleicht mit in die Doku für mqttSubscribe? Also
Eher in wiki. Irgendwann wollte ich Zeit suchen, so einen Artikel zu erstellen ;D

SamNitro

#64
Zitat von: hexenmeister am 27 September 2018, 22:49:46
Ach ja, in der neuen Version wird es jetzt verhindert, dass die Readings-Änderungen durch Empfang per MQTT sofort weitergepublisht werden. Damit kann publish und subscribe mit derselben Readings verwendet werden, ohne dass es zu Loops kommt.

Bei meinen Lampen funktioniert das auch ganz gut. Aber bei meinem HM_Rolladen nicht.

2018.09.27 23:57:54 1: MQTT_GENERIC_BRIDGE: setUpdate: error in set command: Unknown argument set_80, choose one of assignHmKey:noArg clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all deviceRename down fwUpdate getConfig:noArg getDevInfo:noArg getRegRaw getSerial:noArg getVersion:noArg inhibit:on,off off:noArg on:noArg pair:noArg pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset:noArg sign:on,off statusRequest:noArg stop:noArg toggle:noArg toggleDir:noArg unpair:noArg up
2018.09.27 23:59:17 3: CUL_HM set rollo_ez stop
2018.09.27 23:59:17 1: MQTT_GENERIC_BRIDGE: setUpdate: error in set command: Unknown argument set_stop, choose one of assignHmKey:noArg clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all deviceRename down fwUpdate getConfig:noArg getDevInfo:noArg getRegRaw getSerial:noArg getVersion:noArg inhibit:on,off off:noArg on:noArg pair:noArg pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset:noArg sign:on,off statusRequest:noArg stop:noArg toggle:noArg toggleDir:noArg unpair:noArg up
2018.09.27 23:59:42 3: CUL_HM set rollo_ez 100
2018.09.27 23:59:42 1: MQTT_GENERIC_BRIDGE: setUpdate: error in set command: Unknown argument set_100, choose one of assignHmKey:noArg clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all deviceRename down fwUpdate getConfig:noArg getDevInfo:noArg getRegRaw getSerial:noArg getVersion:noArg inhibit:on,off off:noArg on:noArg pair:noArg pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset:noArg sign:on,off statusRequest:noArg stop:noArg toggle:noArg toggleDir:noArg unpair:noArg up
2018.09.27 23:59:50 1: MQTT_GENERIC_BRIDGE: setUpdate: error in set command: Unknown argument deviceMsg, choose one of assignHmKey:noArg clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all deviceRename down fwUpdate getConfig:noArg getDevInfo:noArg getRegRaw getSerial:noArg getVersion:noArg inhibit:on,off off:noArg on:noArg pair:noArg pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset:noArg sign:on,off statusRequest:noArg stop:noArg toggle:noArg toggleDir:noArg unpair:noArg up
2018.09.27 23:59:50 1: MQTT_GENERIC_BRIDGE: setUpdate: error in set command: Unknown argument level, choose one of assignHmKey:noArg clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all deviceRename down fwUpdate getConfig:noArg getDevInfo:noArg getRegRaw getSerial:noArg getVersion:noArg inhibit:on,off off:noArg on:noArg pair:noArg pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset:noArg sign:on,off statusRequest:noArg stop:noArg toggle:noArg toggleDir:noArg unpair:noArg up
2018.09.27 23:59:50 1: MQTT_GENERIC_BRIDGE: setUpdate: error in set command: Unknown argument motor, choose one of assignHmKey:noArg clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all deviceRename down fwUpdate getConfig:noArg getDevInfo:noArg getRegRaw getSerial:noArg getVersion:noArg inhibit:on,off off:noArg on:noArg pair:noArg pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset:noArg sign:on,off statusRequest:noArg stop:noArg toggle:noArg toggleDir:noArg unpair:noArg up
2018.09.27 23:59:51 3: CUL_HM set rollo_ez pct 100
2018.09.27 23:59:51 3: CUL_HM set rollo_ez on
2018.09.27 23:59:51 1: MQTT_GENERIC_BRIDGE: setUpdate: error in set command: Unknown argument set_100, choose one of assignHmKey:noArg clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all deviceRename down fwUpdate getConfig:noArg getDevInfo:noArg getRegRaw getSerial:noArg getVersion:noArg inhibit:on,off off:noArg on:noArg pair:noArg pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset:noArg sign:on,off statusRequest:noArg stop:noArg toggle:noArg toggleDir:noArg unpair:noArg up
2018.09.28 00:07:09 3: CUL_HM set rollo_ez pct 100
2018.09.28 00:07:09 1: MQTT_GENERIC_BRIDGE: setUpdate: error in set command: Unknown argument set_100, choose one of assignHmKey:noArg clear:readings,trigger,register,oldRegs,rssi,msgEvents,msgErrors,attack,all deviceRename down fwUpdate getConfig:noArg getDevInfo:noArg getRegRaw getSerial:noArg getVersion:noArg inhibit:on,off off:noArg on:noArg pair:noArg pct:slider,0,1,100 peerBulk peerIODev press raw regBulk regSet reset:noArg sign:on,off statusRequest:noArg stop:noArg toggle:noArg toggleDir:noArg unpair:noArg up


EDIT:

allerdings lausche ich komplett alles..
attr rollo_ez mqttPublish *:topic={"/$device/$reading"}
attr rollo_ez mqttSubscribe *:stopic={"/$device/$reading"}


Der Befehl geht an /rollo_ez/pct         (0-100)
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

Billy

Zitat von: hexenmeister am 27 September 2018, 22:38:51
Nachvollzogen, gefunden, gefixt. Morgen per Update :)
Die Steuerattribute werden jetzt auch beim entfernen des Gerätes aus der Liste nicht angefast. Nach dem Restart sind sie natürlich dann weg.
passt!
Zitat von: hexenmeister am 27 September 2018, 22:49:46
Ach ja, in der neuen Version wird es jetzt verhindert, dass die Readings-Änderungen durch Empfang per MQTT sofort weitergepublisht werden. Damit kann publish und subscribe mit derselben Readings verwendet werden, ohne dass es zu Loops kommt.

So kann man dann aus dummies leicht Steuergeräte in einer anderen FHEM-Instanz basteln, so eine Art FHEM2FHEM-Ersatz. Diese sehen aus und verhalten sich dann eben wie auch eigentliche Gerätschaften.

Super, bin zwar gerade auf Kreta habe mich aber per VPN auf mein Testsystem eingeloggt und mit Test-Dummies getestet.
Scheint jetzt alles zu laufen. :)
Danke
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

Zitat von: SamNitro am 28 September 2018, 00:10:08
allerdings lausche ich komplett alles..
attr rollo_ez mqttPublish *:topic={"/$device/$reading"}
attr rollo_ez mqttSubscribe *:stopic={"/$device/$reading"}


Der Befehl geht an /rollo_ez/pct         (0-100)

Ich rate dringend davon, das so zu tun. In diesem Fall werden alle Readings gepublisht und dann wieder empfangen und als SET-Befehl abgesetzt. Das kann nicht passen und wird unweigerlich zu Fehlermeldungen (und ggf. auch zum unerwünschten Verhalten) führen. Es gibt ja (vor allem bei HomeMatic) viele Readings und relativ wenig gültige SET-Befehle.

Außerdem ist hier die Richtung anders. Es wird derzeit verhindert, dass _empfangene_ Nachrichten weiter gepublisht werden, jedoch nicht, dass _gesendete_ wieder empfangen werden. Ist auch nicht so einfach zu verhindern, da in diesem Fall der MQTT-Server beteiligt ist. Eine saubere Lösung würde vermutlich auch Änderungen in 00_MQTT-Modul erfordern (ClientID durchreichen, ich weiß gerade nicht, ob die Verwendete Bibliothek das schon kann).

SamNitro

Ok dann werde ich es so lassen wie bisher. So läuft ja alles.


Mobil unterwegs!
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

SamNitro

Habe doch noch ein kleines problem.

Für Node-Red benötige ich die Rückmeldung. Entweder bekomme ich ein loop oder keine Rückmeldung.
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

hexenmeister

Spricht was dagegen, zwei verschiedene Topics dafür zu nehmen?

SamNitro

#70
jetzt ist überall der wurm drin. Bin im Hausumbau Stress jetzt noch Flitterwochen und jetzt Funktioniert nicht mal mehr der normale Rolladenschalter weil da Rückmeldungen über MQTT kommen die da nicht hin sollen....


Habe versucht 2 topics zu nehmen aber gerade klappt einfach nix mehr. ich versuche auf eine alte version zurück zu kehren
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

hexenmeister

#71
Wenn ich noch verstehen würde, was bei Dir nicht klappt...

Habe gerade mit einem HM Rolladenaktor nachgestellt.

Funktionierendes Beispiel mit zwei (eigentlich sogar 3) Topics.

Steuerdummy:
defmod OG_BZ_Rollo dummy
attr OG_BZ_Rollo devStateIcon runter:fts_shutter_100 \d(.\d)*:fts_shutter_100 hoch:fts_shutter_10 100:fts_shutter_10 1\d(.\d)*:fts_shutter_90 2\d(.\d)*:fts_shutter_80 3\d(.\d)*:fts_shutter_70 4\d(.\d)*:fts_shutter_60 5\d(.\d)*:fts_shutter_50 6\d(.\d)*:fts_shutter_40 schatten:fts_shutter_40 7\d(.\d)*:fts_shutter_30 8\d(.\d)*:fts_shutter_20 9\d(.\d)*:fts_shutter_10 nacht:fts_shutter_10
attr OG_BZ_Rollo eventMap {usr=>{'oeffnen'=>'100','schliessen'=>'0','halb'=>'60','schatten'=>'80','dunkel'=>'30'}}
attr OG_BZ_Rollo group Beschattung
attr OG_BZ_Rollo icon fts_shutter
attr OG_BZ_Rollo mqttPublish position:topic=og/bz/rollo/all/set state:topic=og/bz/rollo/all/set
attr OG_BZ_Rollo mqttSubscribe position:topic=og/bz/rollo/all/position state:topic=og/bz/rollo/all/state
attr OG_BZ_Rollo readingList position
attr OG_BZ_Rollo room Badezimmer
attr OG_BZ_Rollo setList position:slider,0,1,100
attr OG_BZ_Rollo stateFormat position
attr OG_BZ_Rollo webCmd oeffnen:schatten:halb:dunkel:schliessen:position


HM-Aktor:

defmod bz_rollo CUL_HM xxxxxx
attr bz_rollo model HM-LC-Bl1PBU-FM
...
attr bz_rollo mqttPublish pct:topic=og/bz/rollo/all/position state:topic=og/bz/rollo/all/state
attr bz_rollo mqttSubscribe pct:stopic=og/bz/rollo/all/set



Die Bridge kann eine Übersicht ausgeben, wo man gut sehen kann, welche Topics verwendet werden:

Aktor:
Zitat
bz_rollo
  publish:
    pct              => og/bz/rollo/all/position (mode: R; qos: 0)
    state            => og/bz/rollo/all/state (mode: R; qos: 0)
  subscribe:
    pct              <= og/bz/rollo/all/set (mode: S)


Dummy:
Zitat
OG_BZ_Rollo
  publish:
    position         => og/bz/rollo/all/set (mode: R; qos: 0)
    state            => og/bz/rollo/all/set (mode: R; qos: 0)
  subscribe:
    position         <= og/bz/rollo/all/position (mode: R)
    state            <= og/bz/rollo/all/state (mode: R)


SamNitro

#72
Bei mir ist es die Kommunikation zwischen NodeRed und FHEM

z.B. meine wz_stehlampe

attr wz_stehlampe mqttPublish *:topic={"/out/$device/$reading"}
attr wz_stehlampe mqttSubscribe *:stopic={"/in/$device/$reading"}


[/out/wz_stehlampe/state]--------[Schalter]----------------[/in/wz_stehlampe/state]
                                 [Alexa-Stehlampe]---------[/in/wz_stehlampe/state]


oder so

attr wz_stehlampe mqttPublish *:topic={"/out/$device/$reading"}
attr wz_stehlampe mqttSubscribe state:stopic={"/in/$device/set"}


[/out/wz_stehlampe/state]--------[Schalter]----------------[/in/wz_stehlampe/set]
                                 [Alexa-Stehlampe]---------[/in/wz_stehlampe/set]


Das problem ist NodeRed da lasse ich mir einen Schalter anzeigen: der Zeigt mir logischerweise den status vom Input an



Entweder zeigt er mir nicht den richtigen status an oder er lässt sich nich korrekt schalten
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

hexenmeister

Sieht nicht falsch aus. Poste mal die Node-Red Export.

SamNitro

So ist der alte Stand der mit der alten Version Läuft:

[{"id":"af1a4b9a.2f1ac8","type":"alexa-home","z":"9d8c568.24a8628","devicename":"Stehlampe","inputtrigger":false,"x":410,"y":600,"wires":[["110aabab.12ef8c"]]},{"id":"16968764.a59469","type":"mqtt in","z":"9d8c568.24a8628","name":"","topic":"/out/wz_stehlampe/state","qos":"2","broker":"65613e0a.ef6478","x":130,"y":560,"wires":[["a1339df4.6c78c8"]]},{"id":"110aabab.12ef8c","type":"mqtt out","z":"9d8c568.24a8628","name":"","topic":"/in/wz_stehlampe/state","qos":"","retain":"","broker":"65613e0a.ef6478","x":670,"y":560,"wires":[]},{"id":"a1339df4.6c78c8","type":"ui_switch","z":"9d8c568.24a8628","name":"","label":"Stehlampe","group":"df58a679.8acae","order":1,"width":0,"height":0,"passthru":false,"decouple":"true","topic":"","style":"","onvalue":"on","onvalueType":"str","onicon":"","oncolor":"","offvalue":"off","offvalueType":"str","officon":"","offcolor":"","x":410,"y":560,"wires":[["110aabab.12ef8c"]]},{"id":"65613e0a.ef6478","type":"mqtt-broker","z":"","name":"","broker":"localhost","port":"1883","clientid":"","usetls":false,"compatmode":true,"keepalive":"60","cleansession":true,"birthTopic":"","birthQos":"0","birthRetain":"false","birthPayload":"","closeTopic":"","closeRetain":"false","closePayload":"","willTopic":"","willQos":"0","willRetain":"false","willPayload":""},{"id":"df58a679.8acae","type":"ui_group","z":"","name":"Schalter","tab":"dbb46b72.63ce3","order":2,"disp":true,"width":"6","collapse":false},{"id":"dbb46b72.63ce3","type":"ui_tab","z":"","name":"Home","icon":"dashboard","order":1}]
(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)