Xiaomi switch

Hi @veonua

I downloaded your xiaomi switch driver and made a couple of changes, in particular adding the following lines to the ‘device_init’ in the main ‘init.lua’:

device:remove_monitored_attribute(0x0006, 0x0000)
device:remove_monitored_attribute(0x0012, 0x0055)

This seems to have fixed the problem with the spurious ‘held’, without any loss of functionality. The devices still contact the hub regularly. In fact that is how you pick up the temperature status and energy information.

I have this working with several different older switches, all 1-gang. I haven’t tred a 2-gang case yet.

I know that this regular login doesn’t occur with the newer switches (e.g. opple), but cluster: 0xFCC0 attribute: 0xF7 provides the same functionality as the regular (catchall) login and may be worth using as a monitored function with no unfortunate side effects.


Thank you @aonghusmor, Pull Requests are welcome

I’d recommend replacing numbers with human-readable constants like

device:remove_monitored_attribute(OnOff.ID, OnOff.attributes.OnOff.ID)

As far as I remember old switches are not the problem but the Zigbee3.

Without initial on/off cluster monitoring my WS-EUK01 (lumi.switch.l1aeu1) doesn’t notify the hub about switch changes.
Perhaps removing the monitoring later as you suggest will fix the problem.

I agree, of course, about the constants. I was just trying to do a test, rather than publish anything. My main concern was to get rid of the spurious ‘held’ states.

I vaguely remember I had some correspondence about WS-EUK01 and the corresponding US switch, which did behave in an unusual way. The corresponding 2 and 3 button switches seem more well behaved. There’s a software switch, which I assume you’re aware of, on cluster 0xFCC0 attribute 0x09, which changes the behaviour significantly, including changing the button endpoints. Setting it to 1 gives more ‘normal’ behaviour.

Could you please create a pull request, because a simple paste of the snippet did not fix the spurious ‘held’ for me.

I had it after line 71 of your init.lua
device:set_field(“first_button_ep”, configs.first_button_ep, {persist = true})

the version with your proposal is published.
Everything goes well so far.


I have come across another issue/ I’ll try to find a solution, but I just want to check whether you’re aware of it. It is more apparent with a 2 gang switch.

If I try to use a button in an automation, that seems to work. However, if I use it in an app, such as Smart Lighting or ABC Manager, there seems to be a missing value for the button number. This causes Smart Lighting to crash, whereas ABC Manager gets far enough to show an error message in the IDE logs, which refers to ‘button null’. I note that, in the groovy version, the button number appears as a seperate integer parameter, so I’d guess it may to be the same with edge.

Having most of my devices using Edge I have abandoned cloud apps and happy with responsiveness.

If I understand it right ST is sunsetting these, so there will be no updates for the SmartLights app.

I’m puzzled why it was found necessary to change the interface for buttons such as to make the edge DHs incompatible with Groovy smartapps. It may not have been deliberate, of course.

It seems to me that there is a loss of functionality involved. For example, unless I’ve missed something, there doesn’t seem to be a way to define an automation/routine which when a button is pressed turns on a lamp dimmed and turns it off again on a 2nd press. That only works if I don’t want to do anything with dimming, colour or colour temperature.

I can do it by using the state of the lamp as a precondition and introducing another automation to switch the lamp off. To me that is unnecessarily counter intuitive for an ordinary user.

For your example the state storage is required, which is never easy.

Samsung team wants offload as much as possible to your local hub.
And unfortunately there is no good solution for local apps. So you have to rely on the device state.

Some developrs started to add extended logic to the virtual devices and drivers.

There is a lot of work for ST team to make apps that can interact with both local and cloud devices and keep state even on unreliable connections/devices.
Plus the UI need to be improved to display all the intermediate states and various possibilities.