2 Schalter und eine Lampe :D

tradfri und xiaomi sind doch nur taster oder? die haben dann ja keinen on/off zustand sondern setzen nur einen string ab.
wenn dem so ist, dann wäre die kürzeste variante zwei trigger mit "or" zu nehmen und dann die jeweiligen signale per case auszuwerten. also genau wie du es jetzt schon hast. es muss nur geschaut werden, ob der tradfri auch "SHORT_PRESSED" sendet oder was anderes. wenns was anderes ist dann einfach diesen string per "case" zusätzlich reinnehmen.

was steht denn zum tradfri in deinem [definition='1','0']log[/definition] drin wenn du ihn drückst? muss ja auch was mit "triggered ...." sein oder hat der tatsächlich einen on/off status?

on/off bei taster...total sinnfrei meines erachtens.....naja, dann ist es halt so.
so wie du es weiter oben geschrieben hast, verliert der taster natürlich die on/off funktionalität. wobei das meines erachtens auch völlig egal wäre. das brauchst du für deinen einsatzzweck nicht.
ich würde die anderen drei strings des xiaomi (DOUBLE_PRESSED etc) zusätzlich aus dieser rule entfernen. wenn du diese funktionen nutzen willst, dann nimm ne extra rule. du steuerst damit ja dann auch ein anderes gerät. das dient meines erachtens dann doch der übersichtlichkleit.

beispiel

rule "Hannes Lichtschalter"
when
    Channel "mihome:86sw1:158dxxx710316:ch1" triggered SHORT_PRESSED or
    Item Hannes_switch2Click changed
then
     if (Hannes_Licht.state == OFF){ 
        Hannes_Licht.sendCommand(ON)
     }
     else {
        Hannes_Licht.sendCommand(OFF)
     }
end

so wäre das meiner meinung nach der sauberste und aufgeräumteste ansatz. einziger negativpunkt ist halt, dass du den on/off status beim taster verlierst. der ist aber sowieso überflüssig. an nem taster kann man den status optisch nicht erkennen. also braucht der auch keinen "software" status.

@horschte

Warum sinnfrei? Es muss sich ja nicht um einen Taster handeln, siehe:

Zitat von xSaSx

Jetzt will ich noch einen zusätzlichen Tradfri Schalten in die Rule bauen

Und wenn es bspw. der https://www.ikea.com/de/de/p/tradfr…weiss-70408595/ ist schaltet er ja auch wirklich, wenn es nur so einer ist https://www.ikea.com/de/de/p/tradfr…weiss-40356381/ dann ist es wirklich interessant, aber es ist doch von Vorteil.
Unter der Annahme das der Status "on" nur gesendet wird wenn das dahinter liegende Gerät auch wirklich "on" ist, wäre diese Meldung ja perfekt zur Statusermittlung nutzbar.

Zitat von xSaSx

aber deine rule sieht logisch und einfach aus

genau so solls nach möglichkeit ja auch sein. wenn du mit nem einfach-klick das licht schalten willst, dann brauchste keine receivedEvent variablen um andere klicks auszuwerten. die rule wird einfach nur lang und unübersichtlich.
solltest du andere klicks auswerten lassen um andere geräte zu schalten, dann kommt das halt in eine eigene rule. an codezeilen spart man auch nicht wirklich was wenn man das alles mit einem mal auswerten will.

Zitat von xSaSx

in der neuen rule engine was man so zusammenklicken kann gibt es kein else oder ?

grafische rule engine benutzen??????????????

Zitat von bennySB

Warum sinnfrei? Es muss sich ja nicht um einen Taster handeln, siehe:

ok das es auch "echte" schalter von ikea gibt wusste ich nicht. hat der taster denn eine "mechanische" on/off stellung? erst dann macht es doch sinn den status auch zu auszuwerten. wenn das licht an ist, dann drücke ich ja nicht auf on.

Zitat von xSaSx

ich denke weil es wirklich 2 "knöpfe" an dem tradfri gibt mit on und off oder ?

das war nicht in den ersten beiträgen erkennbar.

Zitat von xSaSx

Configuration model 'hannes_lichtschalter.rules' has errors, therefore ignoring it: [5,5]: no viable alternative at input 'Hannes_switch2Click'

ich denke weil es wirklich 2 "knöpfe" an dem tradfri gibt mit on und off oder ?

ne das hat damit nichts zu tun. beim zusammenstellen deiner rule habe ich beim trigger nur "Item" vergessen. es muss heissen "Item Hannes_switch2Click changed"

Nee die Position wird auch dort nur getastet.
Ob der Schalter dann eine interne Speicherung der Position vornimmt weiß ich nicht.

ok ich hab mir mal den schalter angeschaut. er hat keine "mechanische" on/off stellung. weiterhin:

Zitat von zigbee2mqtt

Triggered action (e.g. a button click). Value can be found in the published state on the action property. It's not possible to read (/get) or write (/set) this value. The possible values are: on, off, brightness_move_down, brightness_move_up, brightness_stop.#

ein command channel ist also nicht vorhanden. damit ist das synchronisieren des tasters mittels command also auch nicht möglich (wenn man bspw nicht mit dem xiaomi taster oder dem shelly das licht steuert)
das ganze bringt ein problem mit sich....schaltet man am ikea taster ein, dann geht das licht und der andere schalter (shelly) ein. schaltet man jetzt am xiaomi aus, dann bleibt der ikea schalter trotzdem auf on. die oben gepostete rule würde also nicht triggern wenn man jetzt wieder beim ikea schaltet...weil sich dessen status (der auf on ist) nicht ändert.
in der o.g. rule würde ich also den trigger von "changed" auf "received update" umstellen.
falls der schalter auch ohne aktion seinen status sendet (kommt ggf beim neustart vor -> changed from NULL to ON/OFF), dann würde das licht ungewollt schalten. um das zu umgehen, könnte der rule trrigger von changed/received update auf:

Channel "mihome:86sw1:158dxxx710316:ch1" triggered SHORT_PRESSED or
    Item Hannes_switch2Click changed from OFF to ON or
    Item Hannes_switch2Click changed from ON to OFF

...abgeändert werden. so triggert die rule wirklich nur, wenn am taster was gedrückt wird.
ein anderer weg (darauf will @bennySB sicher hinaus) wäre mittels "received command" zu triggern und dann auf "SHORT_PRESSED" (vom xiaomi) sowie "ON/OFF" (vom ikea) mittels 3x case (sind ja 3 "zustände") zu reagieren.

Zitat von bennySB

Ob der Schalter dann eine interne Speicherung der Position vornimmt weiß ich nicht.

er hat ein item angelegt. also wird der status ja (zumindest bei openhab) gespeichert.