Use Aqara Wireless Switch via Zigbee binding

I just coupled an Aqara Wireless Switch with Openhab (Openhabian on RPi with CC2531). It was discovered in PaperUI and now shown as below with one Switch channel:

    Status: ONLINE  

hardwareVersion	2
modelId	lumi.sensor_switch.aq2
vendor	LUMI
zigbee_devices	[]
zigbee_lastupdate	
zigbee_logicaltype	END_DEVICE
zigbee_neighbors	[{"joining":"UNKNOWN","address":"0","depth":"0","lqi":"111","macaddress":"00124B001936A642"}]
zigbee_networkaddress	17462
zigbee_powerlevel	FULL
zigbee_powermode	RECEIVER_ON_IDLE
zigbee_powersource	DISPOSABLE_BATTERY
zigbee_powersources	[DISPOSABLE_BATTERY]
zigbee_routes	[]
zigbee_stkcompliance	0
zigbee_zclversion	1

However, the channel was ON since discovery. If I press the switch, nothing happens. If I toggle it OFF in PaperUI and then press the switch, it flips back to ON.

Most people seem to use the Xiaomi Home binding with the Xiaomi Gateway so I couldn’t find a solution for my setup anywhere…

What do the debug logs show is happening?

Do you get a channel triggered event in your log when pressing the button? Than you wouldn’t need to link it to an item at all as you can use those events in rules. If not a work around would be to link the switch channel to a switch item with the expire binding set to expire to off after 1 second. That way yo could use the changed to ON as a rule trigger etc.
Johannes

All I get is

2019-06-26 17:04:54.725 [vent.ItemStateChangedEvent] - zigbee_device_70dd630e_00158d0002041455_00158D0002041455_1_switch changed from OFF to ON

So I’d have to base my rule on this and set the state back to OFF after execution for this work-around. Not my preferred solution because of the more complex code but I’ll keep it in the back of my mind, thank you :wink:

Every time I push the button I get

2019-06-26 17:11:01.913 [DEBUG] [converter.ZigBeeConverterSwitchOnoff] - 00158D0002041455: ZigBee attribute reports ZclAttribute [cluster=ON_OFF, id=0, name=OnOff, dataType=BOOLEAN, lastValue=true, lastReportTime=Wed Jun 26 17:11:01 CEST 2019]
2019-06-26 17:11:01.914 [DEBUG] [converter.ZigBeeConverterSwitchOnoff] - 00158D0002041455: ZigBee attribute reports ZclAttribute [cluster=ON_OFF, id=0, name=OnOff, dataType=BOOLEAN, lastValue=true, lastReportTime=Wed Jun 26 17:11:01 CEST 2019]
2019-06-26 17:11:01.917 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 00158D0002041455: Channel zigbee:device:70dd630e:00158d0002041455:00158D0002041455_1_switch updated to ON
2019-06-26 17:11:01.917 [DEBUG] [converter.ZigBeeBaseChannelConverter] - 00158D0002041455: Channel zigbee:device:70dd630e:00158d0002041455:00158D0002041455_1_switch updated to ON
2019-06-26 17:11:01.921 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0002041455: Updating ZigBee channel state zigbee:device:70dd630e:00158d0002041455:00158D0002041455_1_switch to ON
2019-06-26 17:11:01.922 [DEBUG] [ng.zigbee.handler.ZigBeeThingHandler] - 00158D0002041455: Updating ZigBee channel state zigbee:device:70dd630e:00158d0002041455:00158D0002041455_1_switch to ON

And in regular intervals

2019-06-26 17:12:45.217 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D0002041455: Node SVC Discovery: running
2019-06-26 17:12:53.234 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D0002041455: Node SVC Discovery: ManagementLqiRequest response CommandResult [TIMEOUT]
2019-06-26 17:12:53.239 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D0002041455: Node SVC Discovery: request NEIGHBORS failed. Retry 3, wait 2234ms before retry.
2019-06-26 17:12:55.477 [DEBUG] [iscovery.ZigBeeNodeServiceDiscoverer] - 00158D0002041455: Node SVC Discovery: running

So in fact I think what @JGKK wrote above is probably the correct approach. The events are being received, but the device only ever reports ON state, and in this case it seems you will need to use this to trigger a rule.

Alright, thank you. At least I can make it work for now.
Maybe someone is using this switch and can chime in as well :wink:

What “chime” are you looking for? I’m not sure that there will be a lot more that we can do if the device doesn’t send On and Off, and instead only sends On.

It could be possible to change this to a trigger channel, but ultimately that will still do exactly the same thing.

The possibility of changing the channel type for zigbee buttons to a trigger channel type (like the rocker switch channel type in the enocean binding) would be a nice addition to remove the expire binding workaround.
I don’t know if there is zigbee buttons that support functionality like long press or double press but this would be a great match for a trigger channel like this.
Best regards Johannes

Yes, there are, and I think we already support this in the binding.

1 Like

So is the aquara wireless switch just reporting itself as a switch instead of a pushbutton although it is a button and the fault is on the manufacturers side for implementing the Zigbee standard wrong or should the binding actually be changed to correctly implement this button type? Or are we in a grey area?
Sorry for asking all this. Just trying to wrap my head around the Zigbee stuff in more detail.
Johannes

Yes - it’s reporting an OnOff Switch -:

The important bit here is the cluster=On_OFF part.

Probably there is scope to change the binding. It’s possible to manually define things in the binding, so this could be possible now, or if not if could be added.

As I said though, for this device it would fundamentally still be the same - you’d simply get a rule trigger each time the button is pressed.

Why use the expire binding at all? I guess you’re using it as you’re using this as a switch, but why not simply trigger a rule with the “On Update” trigger and it will be the same as if you had a trigger channel wouldn’t it?

1 Like

Comment: using the expire binding,you can have a linked Switch Item set its state back to OFF after a delay of your choice.
Rules can then use conventional Item state triggers e.g. changed, Group based etc.

1 Like

But can’t rules just use the conventional item state trigger “received update” - it’s the same thing isn’t it and it avoids the expire binding if that’s what you want.

Sure. Sometimes people want things to be visible in UI or affect a Group state. Less likely for a pushbutton, than for say a PIR that only sends ON.

Sure - but that isn’t what we were discussing.

The discussion was about changing the binding to use trigger channels for this switch. I think don’t have a UI do they? I think using a trigger channel in this instance is the same as using the “received update” trigger in the rule?

Nearly. There’s no “Group” equivalent triggering for event channels at this time.
You can hardcode a load of ‘or’ channel triggers, together with receivedEvent to approximate the functionality.

I replied to @zzzZZZzzz who wanted to know how to use his switch now, this wasn’t intended to be any input to binding enhancements,