Lights in group do not turn on (based on rules)

Phoscon App Bug reports
1

I have one light included in one group. The group as a wireless switch associated with it. Manually turning the light on and off works as expected. If i set up the rules (using Phoscon) to toggle the group when the switch is pressed it mostly does nothing although sometimes it works as expected.

Steps to reproduce the behavior
Add one light to one group and associate a switch with it. Create a rule to toggle the group if the button of the switch is pressed once.

Environment

  • Host system: Raspberry Pi
  • Running method: Raspbian
  • Firmware version: 26700700
  • deCONZ version: 2.12.4
  • Device: ConBee II
  • Do you use an USB extension cable: yes
  • Is there any other USB or serial devices connected to the host system? no the case

deCONZ info

the group
"16": { "action": { "alert": "none", "bri": 127, "colormode": "hs", "ct": 0, "effect": "none", "hue": 0, "on": false, "sat": 127, "scene": null, "xy": [0, 0] }, "devicemembership": [], "etag": "40cee7810fff8b08897ef5232e087dee", "id": "16", "lights": ["4"], "name": "Office Group", "scenes": [], "state": { "all_on": false, "any_on": false }, "type": "LightGroup" },

the switch
"26": { "config": { "battery": 100, "on": true, "reachable": true, "temperature": 3300 }, "ep": 1, "etag": "967fa46f2fd96260605cef55b245ebd6", "lastannounced": null, "lastseen": "2021-08-11T12:41Z", "manufacturername": "LUMI", "mode": 1, "modelid": "lumi.remote.b1acn01", "name": "Office Switch", "state": { "buttonevent": 1002, "lastupdated": "2021-08-11T12:47:55.345" }, "swversion": "20180525", "type": "ZHASwitch", "uniqueid": "00:15:8d:00:04:04:e0:5d-01-0012" },

the light
"4": { "etag": "8ec9795ab473bddbf6379f59be60dd2b", "hascolor": false, "lastannounced": "2020-11-10T08:27:53Z", "lastseen": "2021-08-11T13:05Z", "manufacturername": "LUMI", "modelid": "lumi.relay.c2acn01", "name": "Office", "state": { "alert": "none", "on": false, "reachable": true }, "swversion": "09-20-2018", "type": "Dimmable light", "uniqueid": "00:15:8d:00:03:cf:00:89-01" }

the rules
"1": { "actions": [{ "address": "/groups/16/action", "body": { "on": true }, "method": "PUT" }], "conditions": [{ "address": "/sensors/00:15:8d:00:04:04:e0:5d-01-0012/state/buttonevent", "operator": "eq", "value": "1002" }, { "address": "/sensors/00:15:8d:00:04:04:e0:5d-01-0012/state/lastupdated", "operator": "dx" }, { "address": "/groups/16/state/any_on", "operator": "eq", "value": "false" }], "created": "2021-08-11T12:25:27", "etag": "c75f26772895e29cdc143be1a702cede", "lasttriggered": "2021-08-11T12:51:35", "name": "Rule TOOGLE_ON", "owner": "D007A3909D", "periodic": 0, "status": "enabled", "timestriggered": 3 }, "2": { "actions": [{ "address": "/groups/16/action", "body": { "on": false }, "method": "PUT" }], "conditions": [{ "address": "/sensors/00:15:8d:00:04:04:e0:5d-01-0012/state/buttonevent", "operator": "eq", "value": "1002" }, { "address": "/sensors/00:15:8d:00:04:04:e0:5d-01-0012/state/lastupdated", "operator": "dx" }, { "address": "/groups/16/state/any_on", "operator": "eq", "value": "true" }], "created": "2021-08-11T12:25:27", "etag": "e5b9b4a7736acaef41f7a9ac47984072", "lasttriggered": "2021-08-11T12:51:36", "name": "Rule TOOGLE_OFF", "owner": "D007A3909D", "periodic": 0, "status": "enabled", "timestriggered": 2 },

logs
https://pastebin.com/embed_js/VVLQjEC2

i was pointed here from github but i doubt this has something to do with phoscon as i tried more rules with no success

2

Because you mentioned using Phoscon for setting up the rules.

However, please post in the correct area too

Moved from General to Phoscon App / Bug reports.

3

I got something comparable, but with different hardware behind it and upfront: I got no issues with that.

So, the log shows that the light was switches twice as well as the group. For the direct light switch, you see the usual REST API call also affecting the associated groups of the device. Each time after changing the state, the device nicely reports on the on/off cluster.

Now, when using the switch, things apparently go a little different.:

  • Switch is pressed
  • Rules fires
  • A broadcast command for the light is queued
  • Seemingly, the broadcast command was sent (as it got erased from the queue)
  • The light does NOT report on the on/off cluster

So the major difference is the way of addressing the light (unicast, working vs. broadcast, not working).

Has that worked reliably before? Xiaomi devices are not exactly known for adhering the standard, so there’s a good chance that the device is not dealing correctly with broadcasts.

4

I have installed these devices in the walls of my house as i moved in last year during summer time. All was great until a few month ago when lights started working crazy while automations were running.
To the problem above - if i do a manual rest call the light goes on and off as expected (“like the push of a button”). Only when lights are in groups and i trigger these through automations i have this issue.
Sadly i can’t pinpoint a certain release of deconz/phoscon in order to narrow it down.

5

So anything i can do about it? Anything i can debug to help sort this out?

6

Calling in @de_employees :slight_smile:

7

Does it work when you make a REST call directly to the group? So the issue really only occurs when a rule action triggers the group?
Can you perhaps try to use another light e.g. a light bulb from a different vendor? Or try to delete the rules and make new ones.
If you are familiar with Rest API and Rest Clients you could also try to alter the rule that it controls the light directly in its action: Rules - deCONZ REST-API

8

Doing a REST call to the group does nothing as well so there is no difference between a rule and a simple REST call. I deleted and recreated the rules a few times with various tests. I even did the rules by hand with the same result.
I tried adding to the group also a different light (IKEA bulb) - the IKEA bulb turn on as expected but the one controlled by my Aqara relay does not.
The fact tot only i have this issue i guess we can conclude that it’s specific to the devices i own rather then the implementation of the groups.

Edit: if i address the light and NOT the group, the rules workes as expected… Lights work, groups don’t.

9

So it really seems that there is no problem with the rules but with the group commands. And only with the Aquara relays.

I see that there was already an issue on github for these devices and they also had problems with group commands: Aqara 2-gang relay lumi.relay.c2acn01 · Issue #1491 · dresden-elektronik/deconz-rest-plugin · GitHub

Sry, it is to late for me this friday but I will investigate this further next week.

As a workaround you could write your own rules with single light commands instead of group commands. That would be an extra rule for each light. (I see you already know this :slight_smile:

10

I only searched the open bugs on github :slight_smile: As it so seems on the 2 channel relays only one channel toggles. I just tested that is it’s true - i have the dressing and bedroom lights connected to one of these and only the bedroom lights turned on when i turned the group on. Bug confirmed! If you manage to patch something up please give me a ping and i’ll test it.

11

@leonardpitzu @ChrisHae Based on the new details provided above, the root cause is clear: it’s the Xiaomi device and not the rules (or its group command). Looking at the specific detail that for a device with 2 channels, one is working and the other is not from a pure zigbee perspective, that’s something which the relay has in common also with other recently released devices.

I have the WRS-R02 here, and the WS-EUK02 has the same issue. While reverse engineering the 0xFCC0 cluster, I found out that Xiaomi has at least 3 different modes of operation to be set via attribute 0x0009 (already explained that to manup in more detail). The value of 2 seems to be the “zigbee mode”, but also leaving it at 0 seems to mean the same. Regardless, what the devices then have in common is that all commands are sent from endpoint 1 no matter what.

Since I only have the battery powered WRS-R02, which goes into power save mode after around 1 minute, further testing is really cumbersome. A mains powered would be beneficial to eventually identify and attribute value or something else which unleashes the other endpoint(s).

12

@leonardpitzu I just stumbled over this one just recently and that doesn’t sound too encouraging while probably applying for other devices as well…

13

I guess this bug is related to my problem and bugs:

14

@Swoop Have you kept paying attention to this device and can you say if there was any progression regarding this issue?

15

@ChrisHae Well, not really. However, it is also in line with my observations that newer Xiaomi devices (especially switches) seem to have some weaknesses on zigbee level.

E.g. the WRS-R02 wireless switch I have here, you can only use zigbee group bindings on the left button, not on the right. Not sure if there’s any firmware update for the device available sorting that out (intentionally or unintentionally).

What you also have to note is that those devices apparently have 2 modes of operations, set in the 0xFCC0 cluster on attribute 0x0009. Setting it to 1, the device often uses Analog X clusters. Setting it to 2 is usually very close to zigbee standard and eventually lets new standard clusters pop.

16

@leonardpitzu @helipus
from the related z2mqtt forum post: Xiaomi LLKZMK11LM not updating certain exposes after firmware update · Issue #7112 · Koenkk/zigbee2mqtt · GitHub

It seems there is a new firmware for the xiamoi devices available where some users report it solves the not working group commands issue. But it also has the drawback that the energy mesauring is not working anymore.

1 Like