HUE-Bulb mittels Homematic 6-Fach-Taster schalten

Begonnen von darkness, 01 Juli 2021, 12:16:27

Vorheriges Thema - Nächstes Thema

darkness

Hallo Zusammen,

seit einiger Zeit versuche ich mich an MQTT in Verbindung mit zigbee2MQTT. Geräte aus FHEM heraus schalten oder FHEM-Instanzen verbinden klappt auch soweit.
Jetzt würde ich aber gerne eine HUE-Bulb mittels eines Homematic 6-Fachschalter (HM-PB-6-WM55) steuern. Diese hat als Event sowas wie Short 1_140. Kann ich dem Schalter auch sagen, dass er entsprechende Daten auch gleich per MQTT senden soll? Von der Idee hätte ich jetzt gesagt, dass ich mittels einer MQTT_GENERIC_BRIDGE den Schalter MQTT "beibringen" kann.

Internals:
   DEF        mqtt wz.schltr6_Btn_05
   FUUID      60d1edc6-f33f-ed18-f2a9-c7b1220e531b96a0
   IODev      m2_Server
   NAME       mqttGenericBridge
   NR         781
   NTFY_ORDER 50-mqttGenericBridge
   STATE      ???
   TYPE       MQTT_GENERIC_BRIDGE
   devspec    wz.schltr6_Btn_05
   prefix     mqtt
   READINGS:
     2021-06-30 16:05:05   IODev           m2_Server
     2021-06-22 16:26:04   device-count    1
     2021-06-30 16:04:24   incoming-count  0
     2021-06-30 16:04:24   outgoing-count  0
     2021-06-30 16:04:24   updated-reading-count 0
     2021-06-30 16:04:24   updated-set-count 0
   globalDeviceExcludes:
   globalReadingExcludes:
   globalTypeExcludes:
Attributes:
   room       MQTT


Am Schalter kann ich dann in den Attributen mqttPublish mit dem entsprechenden Topic setzen. Aber irgendwie muss ich ja noch ein "on" mitsenden

Aber so richtig sehe ich den Anfang noch nicht. Muss ich hier mit eventMap arbeiten?

Über einen "Denkanstoß" wäre ich dankbar :)

Beta-User

Events an dem HM-PB-6-WM55 kann man schon per MQTT_GENERIC_BRIDGE direkt in eine MQTT-Anweisung umwandeln.

Für die commandref zu MGB wäre wohl dann "expression" das richtige Stichwort, denn du willst ja nur bestimmte "state"-Events abgreifen.

Allerdings hätte ich ein paar Fragezeichen und bin eher unsicher, ob das in diesem Fall der optimale Weg ist, indirekte Schaltungen umzusetzen:
- Wenn du nur den Hauptkanal verwertest, musst du ziemlich viele andere Events (vermutlich in state) vorab aussortieren bzw. auch verschiedene Expressions verwenden, wenn unterschiedliche Topics bedient werden sollen (aus unterschiedlichen Tasten) (evtl. geht es auch, $topic aus expression zu ermitteln, was ggf. etwas übersichtlicher wäre)
- Du könntest auch die einzelnen Tastenkanäle mit unter die MGB bringen, aber auch da gibt es uU. sehr viele (state-) Events, die nicht per MQTT versendet werden sollen. Sprich: auch das macht es nur bedingt einfacher
- zu guter letzt muss am Ende eine Schaltanweisung verschickt werden, nicht einfach nur der (wie auch immer in MQTT dargestellte) Event. Bin nicht sicher, wie zigbee2mqtt das erwartet (ob z.B. ein einfaches toggle geht), aber es erfordert eben einiges an Logik beim Zusammenbauen dessen, was am Ende rauskommen soll.

Anders formuliert: MAn. bist du mit einer "einfachen notify-" Lösung (und "klassischem FHEM-set lamp xy" als Zwischenergebnis) vermutlich schneller und wartungsfreundlicher am Ziel...
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

darkness

Zitat von: Beta-User am 01 Juli 2021, 12:32:48
Anders formuliert: MAn. bist du mit einer "einfachen notify-" Lösung (und "klassischem FHEM-set lamp xy" als Zwischenergebnis) vermutlich schneller und wartungsfreundlicher am Ziel...

Notify ist mir auch recht  ;D Dachte nur, dass es auch einen eleganten Weg über MQTT gibt.  Danke!

Beta-User

Zitat von: darkness am 01 Juli 2021, 12:53:18
Notify ist mir auch recht  ;D Dachte nur, dass es auch einen eleganten Weg über MQTT gibt.  Danke!
Na ja, es kommt immer drauf an, hätte schon sein können, dass es eleganter möglich gewesen wäre. Höngt halt auch immer von dem ab, was die beteiligten Geräte brauchen bzw. liefern. Das passt hier halt schlecht zusammen...

Bzgl. des Event-Handlings:
Zwar sind weder der 6-fach HM noch die ursprünglich mal verwendete MiLight-Bulb noch im Einsatz (ist beides durch ZigBee-Varianten ersetzt), aber evtl. hilft dir (u.A.) der "toggle_indirect"-Code aus https://forum.fhem.de/index.php/topic,103493.msg972085.html#msg972085 (dort enthalten in: 99_attrT_MiLight_Utils.pm) weiter.
Um die Verbindung zwischen dem Leuchtmittel und einer Taste herzustellen, wurde ein userAttr (Target_Device) verwendet, in dem dann der Name des zu adressierenden Leuchtmittels stand. Etwas Erläuterung steht unten in der cref der Datei.

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

darkness

#4
Danke, gucke ich mir mal an.

OT
Kann man ZigBee-Geräte auch ala Homematic "peeren" und ohne Zentrale schalten?

Hat sich erledigt.

Beta-User

#5
Zitat von: darkness am 01 Juli 2021, 13:36:06
OT
Kann man ZigBee-Geräte auch ala Homematic "peeren" und ohne Zentrale schalten?
Kurze Antwort: Ja, geht.

Lange Antwort: Ich bin mir nicht so recht sicher, ob das auch gilt, wenn eine Zentrale involviert ist, und habe derzeit auch noch keine Idee, wie man das (dauerhaft abgesichert) jeweils checken kann...

Hintergrund: Wenn man "früher" so ein "IKEA-Set" gekauft hat mit FB+Leuchtmittel, dann funktionierte das OOTB auch ohne Zentrale. Man musste die beiden Geräte sogar jeweils zurücksetzen, um sie über die Zentrale (hier: deconz) einbinden zu können. Ergo: Es ist auch unter ZigBee möglich, sowas wie Gruppen zu bilden, die direkt miteinander reden.
Wäre an sich interessant, mal auszutesten, was noch geht, wenn man den ConBee II schlicht abzieht. Habe das mal ansatzweise versucht, aber - soweit ich mich grade entsinne - auch kein klares Muster ausgemacht. Im Moment lebe ich halt damit, dass deconz laufen muss (schon alleine, weil bestimmte Reaktionen Licht-abhängig sind), was einer der Gründe ist, warum ich bestimmte Hardware-Schalter noch nicht hart verdrahtet habe...
Kann auch sein, dass deconz und zigbee2mqtt (und welche Bridges es ggf. noch gibt...) da sogar unterschiedliche Wege gehen, so dass man auch da nochmal ins Detail gehen müßte...

Wäre sicher einen (oder mehrere Bridge-spezifische) Thread(s) wert, in dem man das mal etwas strukturierter aufarbeitet ;) .

EDIT: bei ZigBee (jedenfalls bei zigbee2mqtt) scheint das unter "binding" zu firmieren: https://www.zigbee2mqtt.io/information/binding.html
(Mind.) deCONZ-GUI unterstützt das auch, es hängt aber wohl auch (ncht nur für deconz) vom jeweiligen Gerät ab, was geht (und was nicht), siehe z.B. ab hier https://github.com/dresden-elektronik/deconz-rest-plugin/issues/1137#issuecomment-454872597 und allg. https://www.dresden-elektronik.com/wireless/software/deconz.html:
ZitatWith the PC-based platform-independent application, you can easily and uncomplicated record all nodes in a network. All basic node information, the endpoints and their clusters are automatically read out and graphically displayed. Each node is controlled via the graphical user interface. You can easily create bindings using "Drag and Drop". The network can also be controlled via the Internet via a remote connection.
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