REST-API sends fake status updates when scene switch is clicked

[Redsandro]

Describe the bug

I connected a TS004F aka Tuya ZigBee Wireless 12 Scene Switch found here on Aliexpress to the Raspbee 2.

deconz-rest-plugin/bindings.cpp

Line 3072 in 39099c0

sensor->modelId().startsWith(QLatin1String("TS004F")) || // 4 Gang Tuya ZigBee Wireless 12 Scene Switch

Without assigning the button to any group, button 1 and 2 toggled every single connected light on and off respectively.

A deCONZ user with an Aqara Opple Switch instructed me to reset the switch again, and upon establishing the connection with deCONZ, quickly hit the reset button one more time to "disable 'master' mode". I never heard this before, but indeed it works.

The buttons no longer physically switch everything attached to deCONZ on or off.

The problem is that the REST-API still sends state updates as if everything is switched off and on. Then within half a minute or so, REST-API realizes nothing was changed, and updates the statuses back to the old value.

This causes problems when further processing is done by anything consuming the REST-API, such as OpenHAB or other domotics solutions. For example, if you use deCONZ to switch on a Zigbee light, and use deCONZ > REST-API > OpenHAB to switch on a Wifi light when the Zigbee light turns on, the result is now that only the Wifi light erroneously turns on while the Zigbee light properly stays off.

Steps to reproduce the behavior

1. Hold reset button to bind Tuya 4-gang switch
2. Observe button 1 and 2 function like a master switch and physically turn all groups on and off
3. Observe statuses are communicated over REST-API
4. Hold reset button again, this time after the connection is made (light flash) quickly hit the reset button once more
5. Observe button 1 and 2 no longer physically turn all groups on and off
6. Observe REST-API still sends status updates as if all groups turns on and off

Expected behavior

REST-API follows deCONZ behavior exactly.

Screenshots

Environment

• Host system: PC
• Running method: Docker
• Firmware version: 26610700
• deCONZ version: 2.13.01 / 10/6/2021
• Device: RaspBee II

deCONZ Logs

Additional context

I don't know this behavior. I don't know if this feature is related to the button itself, to Zigbee or to the deCONZ software. I tried to explain it as best as I could, but if I understood what was going on, I would probably explain it better.

[Mimiix]

@Smanar is this a duplicate?

[Smanar]

I don't think, first time I m seing that.
They are other way to disable it for exemple #4810 (comment)

But I don't understand what happen on his situation.

The problem is that the REST-API still sends state updates as if everything is switched off and on

Can you show the request send by the API, if you know how to see websocket notification ? (Can use http://phoscon.de/pwabeta in help / api information)

[Redsandro]

I don't understand what happen on his situation.

The problem is that the REST-API still sends state updates as if everything is switched off and on

I believe this is the exact same issue as @tommydejong reported here:

The top left button turns all lights to 'on' in Phoscon. And in Home Assistant they report as 'on'. But in reality, nothing happens to the lights themselves. So in the real world it works, but Phoscon says the lights state changed.. When I turn everything off with the left bottom button it says everything is off. Then after a few seconds it finds out this isn't what's going on in the real world and recovers. So weird.

So it could be a duplicate issue. If verified to be same, we can close this issue.

[Redsandro]

Can you show the request send by the API, if you know how to see websocket notification ?

Can I get this without using the phoscon.de/pwabeta website?

[Smanar]

Can I get this without using the phoscon.de/pwabeta website?

For me it's the easier way, it s not working on your side ? (Yeah it can be bugged too)
You can see them too in deconz log, on the dekstop application, and on some third app that display complete logs.
You can too use a websocket client plugin in your browser (I m using "Browser websocket client" on firefox on my side)

But I have the line I need on the tommydejong post.

As I m not able to find how create a group that disable the braodcast request, the better solution can be to disable the group entry creation in the API.

The problem is that the REST-API still sends state updates as if everything is switched off and on

But it s only group notification ? the values returned by the device are good no ? Can just ignore the group request for the moment ?

{
  "action": {
    "alert": "none",
    "bri": 128,
    "colormode": "hs",
    "ct": 0,
    "effect": "none",
    "hue": 0,
    "on": false,
    "sat": 128,
    "scene": null,
    "xy": [
      0,
      0
    ]
  },
  "devicemembership": [
    "34"
  ],
  "etag": "2873ab8dc91b838c166a2c88be66c742",
  "id": "6",
  "lights": [],
  "name": "Tuya 4 gang switch",
  "scenes": [],
  "state": {
    "all_on": true,
    "any_on": true
  },
  "type": "LightGroup"
}

[Mimiix]

@Smanar local phoscon also have the help api info. No need for the bet a

[Smanar]

@Smanar local phoscon also have the help api info. No need for the bet a

Lol, yes, first time I see it on local, finally :)
Why I m always the last one notified of important updates ...

[Redsandro]

As I m not able to find how create a group that disable the braodcast request, the better solution can be to disable the group entry creation in the API.

I'm afraid I don't know what this means. I did not create any group or disable any group. All I did was:

1. "Add new switch".
   • This caused all my lights to turn on and off on button press, both in reality and in connected apps.
2. Reset "Add new switch" and this time tap the reset button once after connecting to change the button mode.
   • This caused my lights to stay the same state, but in connected apps they still turn on and off

The problem is that the REST-API still sends state updates as if everything is switched off and on

But it s only group notification ? the values returned by the device are good no ? Can just ignore the group request for the moment ?

I may miss a key piece of knowledge, because I'm not sure I understand. Is there a secret hidden group that everything is a member of? I never added a group, and I don't think I can control what is ignored in phoscon and openhab as they both use the output from the REST API as far as I understand.

I have found the help API info button. I'll get back to you when I am physically there so I can use the hardware switch. I just copy everything that appears in API Events after I press the button?

[Smanar]

I'm afraid I don't know what this means.

Don't worry, need to be done on deconz side.
In fact for the moment on classic device when adding a switch deconz create a group associed to this switch and make bind to it, so broadcast command are send to this group.
It's not working for this device but this group is still created. Just need to prevent the group creation if this one is not working.

I may miss a key piece of knowledge, because I'm not sure I understand.

Websocket notifications are differents, if I m right you have one for group (with "all_on" and "any_on") and one for the device itself (with "buttonevent")

[Redsandro]

@Smanar I hope the following is useful. Let me know if I provided the proper data.

To reiterate, this Tuya 12 scene switch can be connected in two ways. This is the second way (by pressing the reset button directly after connecting). None of the lights turn on or off for real in this mode (good) but in the API they still do.

Pressing button marked •:

{
    "23:01:59:341": {
        "e": "changed",
        "id": "30",
        "r": "sensors",
        "state": {
            "buttonevent": 1002,
            "lastupdated": "2021-12-14T22:01:59.319"
        },
        "t": "event",
        "uniqueid": "84:71:27:ff:fe:0a:87:6e-01-1000"
    },
    "23:01:59:342": {
        "e": "changed",
        "id": "65520",
        "r": "groups",
        "state": {
            "all_on": true,
            "any_on": true
        },
        "t": "event"
    },
    "23:01:59:343": {
        "e": "changed",
        "id": "6",
        "r": "groups",
        "state": {
            "all_on": true,
            "any_on": true
        },
        "t": "event"
    },
    "23:01:59:344": {
        "e": "changed",
        "id": "8",
        "r": "groups",
        "state": {
            "all_on": true,
            "any_on": true
        },
        "t": "event"
    },
    "23:01:59:346": {
        "e": "changed",
        "id": "2",
        "r": "groups",
        "state": {
            "all_on": true,
            "any_on": true
        },
        "t": "event"
    }
}

Pressing button marked •••:

{
    "23:06:07:290": {
        "e": "changed",
        "id": "30",
        "r": "sensors",
        "state": {
            "buttonevent": 2002,
            "lastupdated": "2021-12-14T22:06:07.261"
        },
        "t": "event",
        "uniqueid": "84:71:27:ff:fe:0a:87:6e-01-1000"
    },
    "23:06:07:291": {
        "e": "changed",
        "id": "65520",
        "r": "groups",
        "state": {
            "all_on": false,
            "any_on": false
        },
        "t": "event"
    },
    "23:06:07:292": {
        "e": "changed",
        "id": "1",
        "r": "groups",
        "state": {
            "all_on": false,
            "any_on": false
        },
        "t": "event"
    },
    "23:06:07:293": {
        "e": "changed",
        "id": "3",
        "r": "groups",
        "state": {
            "all_on": false,
            "any_on": false
        },
        "t": "event"
    },
    "23:06:07:294": {
        "e": "changed",
        "id": "6",
        "r": "groups",
        "state": {
            "all_on": false,
            "any_on": false
        },
        "t": "event"
    },
    "23:06:07:295": {
        "e": "changed",
        "id": "8",
        "r": "groups",
        "state": {
            "all_on": false,
            "any_on": false
        },
        "t": "event"
    },
    "23:06:07:296": {
        "e": "changed",
        "id": "2",
        "r": "groups",
        "state": {
            "all_on": false,
            "any_on": false
        },
        "t": "event"
    }
}

[Smanar]

So all seem fine.
To use the switch you need to use only

    "23:06:07:290": {
        "e": "changed",
        "id": "30",
        "r": "sensors",
        "state": {
            "buttonevent": 2002,
            "lastupdated": "2021-12-14T22:06:07.261"
        },
        "t": "event",
        "uniqueid": "84:71:27:ff:fe:0a:87:6e-01-1000"
    },

The ZHAswitch entry, id 30

When you use the switch it still sending order to his group, but you have no device inside, just ignore the group notification.

[Redsandro]

When you use the switch it still sending order to his group, but you have no device inside, just ignore the group notification.

@Smanar I think you misunderstand. All those events that follow (id 2, 3, 4, 6 and 8) turn all the lights off in Phoscon or anything else attached to the API. They are caused by the button press. Those events should not be sent. That is the bug I am reporting.

[Smanar]

"r": "sensors",

This one concern the sensor.

"r": "groups",

Those one concern the group.

In your third app you need to use only the first one, the one that use the parameter buttonevent.
The other are the group state, not the light one, as you have no light inside the group.

But something strange is why it update so much group ? Only group with

  "devicemembership": [
    "30"
  ],

(if 30 is the switch ID) need to be updated. And even the "65520" react at switch command.

IDK if it s possible to get log during the button press, with "info", "info_l2" and "APS" ? Because I think you will have a big amount of lines in a short time.
I can't say if it's the device that make something that update group, or if it s deconz that update them.

[Redsandro]

In your third app you need to use only the first one

But one of my "third" apps is Phoscon. I'm using the deCONZ RaspBee image. I don't have control over what Phoscon should ignore.

But something strange is why it update so much group ?

Exactly! I think all groups turn on because all lights turn on, so the groups get status all_on: true. Except with this hardware 4-gang button connected in non-master mode, lights don't physically turn on, so after ~10 seconds the lights in Phoscon learn they made a mistake and turn off again. In master-mode, the same happens, except all lights really turn on/off and stay on/off.

I can't say if it's the device that make something that update group, or if it s deconz that update them.

Let's see if we can figure it out.

IDK if it s possible to get log during the button press, with "info", "info_l2" and "APS"

Can I do this over ssh without x server?

[Smanar]

But one of my "third" apps is Phoscon

So you need to use the switch editor, not the light group, but depend of what you want to do. Make a group with the device you want to command, then try with the switch editor and add this one.
But I m not sure phoscon can use this device (phoscon don't support all devices)

Can I do this over ssh without x server?

Yep it s possible too using command line, but need to restart to use command line https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/deCONZ-debug-flags

But you can at least check all your groups just using http://IP:PORT/api/KEY/groups or in phoscon/help/api information
If you have no group with

  "devicemembership": [
    "30"
  ],

And with the switch ID

For information the group "65520" is a group "All devices".

[Redsandro]

For information the group "65520" is a group "All devices".

Ah, this makes a lot of sense.

I m not sure phoscon can use this device (phoscon don't support all devices)

Perhaps, but I don't think Phoscon is the problem. Please correct me if I'm wrong in this thought process:

1. The zigbee device (e.g. tuya button) controls the deCONZ hardware, the hardware controls the REST API, and the API controls the Phoscon app and third party apps (and the other way around). So;
2. if the Phoscon app and third party apps have the same problem, that would mean the problem originates one level lower, which is the REST API or lower. So;
3. since the deCONZ hardware does not show the problem (e.g. lights do not physically switch), the problem must be one level higher. Ergo:
4. The problem exists above deCONZ and below Phoscon.

To illustrate, in master pairing mode (step 1 and 2 in issue description), both the physical and the virtual are correct (but unwanted). In non-master pairing mode (step 4 and 5 in issue description), the physical is correct but the virtual is incorrect:

(V for expected "no-change" and X for unexpected "change" behavior.)

you can at least check (...) If you have no group with devicemembership: ["30"]

I have no such group. I will attach an abbreviated copy/paste below. I will get the logs with the button when I am home.

---

/api/${KEY}/groups

{
    "1": {
        "devicemembership": [], 
        "id": "1", 
        "lights": ["1"], 
        "type": "LightGroup"
    }, 
    "2": {
        "devicemembership": [], 
        "id": "2", 
        "lights": ["6"], 
        "type": "LightGroup"
    }, 
    "3": {
        "devicemembership": [], 
        "id": "3", 
        "lights": ["7", "4", "11", "3"], 
        "type": "LightGroup"
    }, 
    "4": {
        "devicemembership": ["18"], 
        "id": "4", 
        "lights": [], 
        "type": "LightGroup", 
    }, 
    "5": {
        "devicemembership": ["19"], 
        "id": "5", 
        "lights": [], 
        "type": "LightGroup"
    }, 
    "6": {
        "devicemembership": [], 
        "id": "6", 
        "lights": ["5", "10"], 
        "type": "LightGroup"
    }, 
    "7": {
        "devicemembership": ["20"], 
        "id": "7", 
        "lights": [], 
        "type": "LightGroup"
    }, 
    "8": {
        "devicemembership": [], 
        "id": "8", 
        "lights": ["8"], 
        "type": "LightGroup"
    }, 
    "9": {
        "devicemembership": ["27"], 
        "id": "9", 
        "lights": [], 
        "type": "LightGroup"
    }
}

[Smanar]

No I m agree, there is a problem with group, but you can just ignore them to use this switch. To use it you need to use the "buttenvent" value in the sensors list and not the group state value in the group lists.

Deconz is able to see "zigbee group request" in the network and update the API according to them.
Deconz is able to change something in API group stuff, and send zigbee request according to them.

So IDK if this reaction is provoked by the device sending a "group zigbee request", or something caused by the API code that impact again the zigbee group stuff

[github-actions]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[Redsandro]

I forgot that there were more tasks. I had to read back to find out. I believe this is it:

• show the request send by the API (in help / api information)
• check If you have no group with devicemembership: ["30"]
• get log during the button press, with "info", "info_l2" and "APS"

I will look into the last one when I'm at the location.

[Element2]

I have exactly the same problem with a (LIDL) Livarno HG06323 (modelid: TS1001) 4-button wireless switch. It worked fine when first added to the API about a year ago. After an update a few months ago it started to behave like the Tuya of Redsandro. I used it with Domoticz. Now it's unusable. Like Redsandro describes: Only 2 buttons do something. One switches the status (but not the lights) of all lights to ON, the other button switch the status to OFF. Other 2 buttons do nothing.

[Smanar]

You don't remember wich one update ?
It's a "_TZ3000_xabckq1v" too ?

[Element2]

Sorry, I don't remember. But nothing has changed at this side otherwise, so I'm pretty sure it was after an update. I also have a (LIDL) Silvercrest remote Zigbee doorbell HG06668, "modelid": "TS0211"
Same happened. After adding it initially to the API it worked for months. At the same time as TS1001 it stopped working. No button is working anymore. Both are switches in Phoscon. Jumped through all the hoops of deleting it in the API and reconfigure it, but no joy. Below is my API information from both out of Phoscon. Not trying to hijack this topic, just thought maybe this is related, since all the LIDL stuff is Tuya rebrand.

                {
"17": {
    "config": {
        "battery": 100,
        "group": null,
        "on": true,
        "reachable": true
    },
    "ep": 1,
    "etag": "acf72ed85f33d0f78c1ef1786dd053ad",
    "lastannounced": null,
    "lastseen": "2022-01-12T16:37Z",
    "manufacturername": "LIDL Livarno Lux",
    "mode": 1,
    "modelid": "TS1001",
    "name": "Switch",
    "state": {
        "buttonevent": null,
        "lastupdated": "none"
    },
    "type": "ZHASwitch",
    "uniqueid": "xxxxxxxxxxxxxx-1000"
},
"19": {
    "config": {
        "battery": 100,
        "enrolled": 1,
        "on": true,
        "pending": [],
        "reachable": true
    },
    "ep": 1,
    "etag": "bbc2d6f448859c61080bcdfd9a905c4d",
    "lastannounced": "2021-12-29T21:51:41Z",
    "lastseen": "2022-01-12T17:18Z",
    "manufacturername": "LIDL Silvercrest",
    "mode": 1,
    "modelid": "TS0211",
    "name": "Lidl deurbel",
    "state": {
        "buttonevent": 0,
        "lastupdated": "2022-01-04T16:45:57.902",
        "lowbattery": false,
        "tampered": false
    },
    "type": "ZHASwitch",
    "uniqueid": "yyyyyyyyyyyyy-01-0500"
}

}

[Smanar]

Don't have idea ...
I will check difference with the actual stable version, and the previous one, but need more time, will check this WE.

[Element2]

One more observation, maybe it's relevant I don't know. I use the Phoscon stable and Beta. Both use the same config. So both switches are visible in Phoscon stable and Beta. If I push any of the 4 buttons on the remote switch TS1001 nothing happens in Phoscon stable and Beta.
If I push the Doorbell TS0211 nothing happens in the stable, but in the Beta I see a a visual indication that the button is pushed.

[Smanar]

Both use the same config

You are sure all use the same database ?
Can you give the version you are using for the beta ?

TS1001 > not result on beta and stable
TS0211 > work on beta but not stable.

[Element2]

How do I check if they use the same database?
For the stable I go to my own server. For the Beta Ik go to http://phoscon.de/pwabeta
In the Beta I see the same devices paired with the stable, so I assume the Beta uses same config?

TS1001 > not result on beta and stable. Domoticz deCONZ bridge: Discovered but only changes status of lights (but does not switch them)
TS0211 > work on beta but not stable. Domoticz deCONZ bridge; Disscovered and does nothing.

I just follow the releases as published in the beta- and stable channels, no self builds.
Stable version: 2.13.04 / 12/18/2021
Beta version: 2.13.04 / 7/20/2021

I see now the Domoticz deCONZ-bridge is also your work. Thank you for this!
(Can I contact you about deCONZ-bridge? , I think maybe I ran into a bug today when upgrading to latest Domoticz Beta)

[Smanar]

Ha yes, so you are speaking about phoscon beta/stable, and they use the same deconz installation.
And phoscon don't support all devices, so not a reference, but it's strange it work on phoscon and not domoticz.

And yes, for the domoticz deconz bridge there is https://github.com/Smanar/Domoticz-deCONZ/issues
But remember domoticz don't support yet correctlty Bullseyes.

For the TS0211 just can make a fast test on domoticz, on the plugin hardware enable "debug info only" and press a button you need to see a log with "websoocket", if realy nothing move in domoticz was the python plugin fault (but strange it have worked before)

For the TS1001 will take a look this WE, someone is able to recompile code to make tests ? (Need a full/real OS)

[Smanar]

Perfect

16:15:30:658 [INFO] - No button handler for: TS0211, unicast to: 0x0000, endpoint: 0x01, cluster: IAS_ZONE (0x0500), command: STATUS_CHANGE (0x00), payload: 010000640000, zclSeq: 1

You can try the new code.
You need too edit the json again

[1, "0x01", "IAS_ZONE", "STATUS_CHANGE", "0x01", "S_BUTTON_1", "S_BUTTON_ACTION_SHORT_RELEASED", "Ring"]

I have used 0x01 because it s the first byte of the payload "010000640000"

"group": null,

So yes, something is not working here, need to check better.

[Element2]

Yes, the doorbell TS0211 is now working in Domotcz. It is represented as an 8 button multi switch, and button B1 is now active when pushed. So Kudos to you!

Let me know when you need more testing for the TS1001 light selection problem.

One more question. Does the version I compiled now also contains your work for the LIDL SilverCrest Smart Radiator Thermostat #5349 ?

[Element2]

When the door bell TS0211 is pushed I do see this in the Domoticz log from deCONZ-bridge:

022-01-17 19:00:23.089 Error: Zgateway: Can't Update Unit > 19 (sensors) : {'nValue': 0, 'sValue': 'Off'}

[Smanar]

Yes, the doorbell TS0211 is now working in Domotcz. It is represented as an 8 button multi switch, and button B1 is now active when pushed. So Kudos to you!

It's because it use a generic widget, can use a specific one but it's a domoticz issue, not a deconz one ^^

Does the version I compiled now also contains your work for the LIDL SilverCrest Smart Radiator Thermostat

Nope, but this one will be merged, it s in the timestone.

022-01-17 19:00:23.089 Error: Zgateway: Can't Update Unit > 19 (sensors) : {'nValue': 0, 'sValue': 'Off'}

But immedialty after, the plugin is asking information to add this sensor, nope ? You are not blocking new device detection in domoticz ?

For the group issue, I realy don't see the issue, so I have added some more debug line.
Can you retest the new code, and get log after a new inclusion, on log with "info" you will have some lines wit "debug switch" and a number

[Element2]

I'm happy with the door bell representation. It IS probably an 8 button switch. I opened it up and there are multiple contacts for switches, but only 1 is used for the push button. Will this change also be merged in the next beta?

About the error. New device detection is not blocked. But I just checked again and when I push the door bell button it's not in the log anymore. So it's fine now.

When I do a 'git pull' I get 'Already up to date' You're sure you updated the code?

[Smanar]

I'm happy with the door bell representation. It IS probably an 8 button switch. I opened it up and there are multiple contacts for switches, but only 1 is used for the push button. Will this change also be merged in the next beta?

Wich one beta ? the deconz one ? I Need tro make the PR, but I m tring to solve the "bind issue" in same time.

When I do a 'git pull' I get 'Already up to date' You're sure you updated the code?

Oups, nope, forget to press a button, you can retry pls ?

[Element2]

Since I have 40+ devices the log is filling up pretty quick. So no guarantee this is from the right device.
When I pair/join/include the switch and search the log for 'Debug' I get:

Debug switch 1
Debug switch 2
create group 12 for sensor 20
Debug switch 3

[Element2]

Not sure if you changed anything else besides the debug line, but as far as I can see now the switch works as it should in Domoticz.
All 4 buttons can be pushed and the Domoticz multiswitch responds without changing the status of the lights.

[Smanar]

Not sure if you changed anything else besides the debug line, but as far as I can see now the switch works as it should in Domoticz.
All 4 buttons can be pushed and the Domoticz multiswitch responds without changing the status of the lights.

Hu ? on your precedent test (the first one), you have re-included the device ?

[Element2]

Yes I did. For this test I did the same, deleted it from Phoscon and included it again.
The only thing different was the first time I also deleted the switch from Domoticz and now I did not.

[Element2]

Cache maybe?

[Smanar]

Strange, perhaps something have missing during the init.
@Redsandro I need your device manufacture name to add it too ?

[Element2]

Btw, I see now the switch is in group 12 ?
I have not added it in any group in Phoscon or Domoticz.
Maybe that is the difference with before?

---

This is the json from TS1001 in Domoticz deCONZ:

{
"config": {
"battery": 100,
"group": "12",
"on": true,
"reachable": true
},
"ep": 1,
"etag": "6cb5c37e2aaa9948a21823c7ecfeeed4",
"lastannounced": null,
"lastseen": "2022-01-20T14:36Z",
"manufacturername": "_TYZB01_bngwdjsr",
"mode": 1,
"modelid": "TS1001",
"name": "Switch",
"state": {
"buttonevent": 3002,
"lastupdated": "2022-01-20T10:15:36.267"
},
"type": "ZHASwitch",
"uniqueid": "bc:33:ac:ff:fe:1e:2e:5a-01-1000",
"id": "20",
"deviceclass": "sensors"
}

---

This is the group 12 json from TS1001 in Domoticz deCONZ:
{
"action": {
"alert": "none",
"bri": 127,
"colormode": "hs",
"ct": 0,
"effect": "none",
"hue": 0,
"on": true,
"sat": 127,
"scene": null,
"xy": [
0,
0
]
},
"devicemembership": [
"20"
],
"etag": "9d4ba87c5ee8e9cea8b4baa007a194ab",
"id": "12",
"lights": [],
"name": "TS1001 20",
"scenes": [],
"state": {
"all_on": false,
"any_on": false
},
"type": "LightGroup",
"uniqueid": "bc:33:ac:ff:fe:1e:2e:5a-01",
"deviceclass": "groups"
}

[Smanar]

Yep, there is a "special stuff" for this device
The code create a group with a special binding (different than for other devices, was probably for that It don't work with defaut code)

But lot of remote have their own group, like the ikea one.

[Redsandro]

@Redsandro I need your device manufacture name to add it too ?

Sorry I haven't been back to physical access to the button. The manufacturer seems anonymous but I can get _TZ3000_xabckq1v the API view from deconz:

{
    "30": {
        "config": {
            "battery": 100,
            "group": "65520",
            "on": true,
            "reachable": true
        },
        "ep": 1,
        "lastannounced": "2022-01-09T13:59:46Z",
        "lastseen": "2022-01-09T23:36Z",
        "manufacturername": "_TZ3000_xabckq1v",
        "mode": 1,
        "modelid": "TS004F",
        "name": "Switch Quad 1",
        "state": {
            "buttonevent": 2002,
            "lastupdated": "2021-12-15T22:41:38.341"
        },
        "type": "ZHASwitch"
    }
}

[Smanar]

Perfect, and have found another issue with exaclty the same device.

So have removed debug line and added the _TZ3000_xabckq1v if someone is able to test the code for this one ?

[Element2]

If you have time can you have a look at my question at #5493 ?

[Element2]

To be clear, the 4 button Lidl TS1001 remote switch works nows as it should.
So I hope you can merge it (together with the Tuya version of Redsandro) with the next Beta.

The Lidl smart extention lead (#5493) is a different device.
I was just getting your attention here, because #5493 is closed and I was not sure if you get an email if a topic is closed.
Maybe we can discuss it further in thread #5493.

[Smanar]

Mimix have reopened it.

[github-actions]

As there has not been any response in 21 days, this issue has been automatically marked as stale. At OP: Please either close this issue or keep it active It will be closed in 7 days if no further activity occurs.

[github-actions]

As there has not been any response in 28 days, this issue will be closed. @ OP: If this issue is solved post what fixed it for you. If it is not solved, request to get this opened again.

[ldvc86]

@Smanar I'm willing to test for _TZ3000_xabckq1v, though I'm not sure whether I'm equipped for this, since I'm running deconz in docker

[Smanar]

Ha yes, I don't remember if the PR was tested for the _TZ3000_xabckq1v since the last time.
But unfortunately PR are locked for the moment, to develop DDF, so not sure if it will be merged a day.

And yes, the procedure on docker is not easy, if you don't know how work dockers, for exemple https://github.com/franciscogouveia/docker-deconz-rest-plugin-test
And I can't help you for that.

[Redsandro]

I have my _TZ3000_xabckq1v model TS004F back. I know it's not merged yet, but when the time comes, is there a relatively simple way to switch to beta channel on Raspbian Buster Headless SD-card image and switch back to stable later? Is there a relatively simple way to test the PR and switch back to stable afterwards?

Also, I'm still curious to understand how it can happen that something (in this case the quad button) can turn on/off all the light indicators on the Phoscon-GW control page, without physically toggling the actual lights. Are both actions (update the light and update the indicator) handled by different plugins?

[Smanar]

Switch from stable to beta is easy, and you can stay with beta, but just don't update next beta version https://phoscon.de/en/conbee2/install#raspbian

Is there a relatively simple way to test the PR and switch back to stable afterwards?

This is more complex, it s no a beta or stable branch but a special one.
But yes the operation just replace 1 file, you can just make a backup of the file in another folder > /usr/share/deCONZ/plugins/libde_rest_plugin.so

To speed the process, when you send an order using the API, deconz update the state, send the request and wait for return to update the sate and correct it.
And you can have the reverse, if the device have native broadcast request.