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.

https://github.com/dresden-elektronik/deconz-rest-plugin/blob/39099c0ae9e078768bf2e18df2844bbd22b6b44c/bindings.cpp#L3072

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 https://github.com/dresden-elektronik/deconz-rest-plugin/issues/4810#issuecomment-983458100

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[bot]]

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:

• [x] show the request send by the API (in help / api information)
• [x] 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)

[Element2]

When pressing the Lidl Silvercrest doorbell TS0211 I get this in the Domoticz logs (Zgateway is my name for the deCONZ-bridge):

2022-01-15 15:17:07.461 (Zgateway - Lidl deurbel) Updating device from 0:'Off' to have values 0:'Off'. 2022-01-15 15:17:07.464 Zgateway: ### WebSocket Data : {'attr': {'id': '19', 'lastannounced': '2021-12-29T21:51:41Z', 'lastseen': '2022-01-15T14:17Z', 'manufacturername': 'LIDL Silvercrest', 'modelid': 'TS0211', 'name': 'Lidl deurbel', 'swversion': None, 'type': 'ZHASwitch', 'uniqueid': 'bc:33:ac:ff:fe:04:9c:01-01-0500'}, 'e': 'changed', 'id': '19', 'r': 'sensors', 't': 'event', 'uniqueid': 'bc:33:ac:ff:fe:04:9c:01-01-0500'} 2022-01-15 15:17:07.465 Zgateway: ### Update device (Zgateway - Lidl deurbel) : {'nValue': 0, 'sValue': 'Off'}, IGNORED , no changes !

[Element2]

Oh and the TS0211 and TS1001 were added to Phoscon after a device request some one year ago.

I have Domoticz and Phoscon here on a full Ubuntu server. If you give me a few pointers I maybe can compile. Although it's a 'production server' so I don't want to 'rock the boat' too hard.

(@Redsandro Sorry man, het was niet mijn bedoeling dit issue zo over te nemen.)

[Smanar]

Ok have probably find something. IDK if it's the same issue for both. Previously the code hack the model id for the TS1001 and use instead "HG06323", it seem according your JSON this is not working anymore. And as all the 3 devices have the same issue with the bind (when turning all light when trying to use a button) it can be a way to explore.

[Element2]

The TS0211 is just not working in Domoticz. It does nothing with the status of all the lights. That is only the with Tuya and the TS1001. However my problem with the TS0211 started at the same time as the other problem with the TS1001. So since the're both switches I thought maybe the (different) problems were related.

[Smanar]

Although it's a 'production server' so I don't want to 'rock the boat' too hard.

It don't impact your zigbee database, but can use a lot the CPU (at least the first time, compilation will be faster after). To rollback fastly you can make a backup of the file /usr/share/deCONZ/plugins/libde_rest_plugin.so in another folder

So what I have done on the code :

• removing the hacking of modelid and manufacture name for lidl remote, so now on the json you will have real one.
• re-enabling code part according to the manufacture name, and there is a binding part inside.

Not all will work on first time, I need the real model id / manufacture name of the not working device to add them in the code

You have the procedure here https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Compiling-the-REST-plugin-for-device-specific-testing So for you, after having installed deconz :

sudo apt install deconz-dev
git clone --branch switch_issue_1 https://github.com/Smanar/deconz-rest-plugin.git
cd deconz-rest-plugin
qmake && make -j2
sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins

You will need to remove not working remote in the API, and re-include them

Before

"manufacturername": "LIDL Silvercrest",

After

"manufacturername": "_TYZB01_bngwdjsr",

Bind stuff is enabled for device

                 sensor->manufacturer() == QLatin1String("_TYZB01_bngwdjsr") ||  // LIDL Remote Control
                 sensor->manufacturer() == QLatin1String("_TZ1800_ladpngdx")) // LIDL Remote Control

and you need too replace the json file /usr/share/deCONZ/devices/button_maps.json by this one https://github.com/Smanar/deconz-rest-plugin/blob/switch_issue_1/button_maps.json

[Element2]

Ok, so here's the result. Let me know if this is what you are looking for.

After deleting and pairing in Phoscon, they now show up in Phoscon as: TS1001: Vendor: _TYZB01_bngwdjs Product: Switch TS0211: Vendor: _TZ1800_ladpngdx Product: Door bell

Removed both switches in Domoticz, updated deCONZ-bridge and added them again in Domoticz. Now the remote switch TS1001 seems to be working again as far as I can remember It shows up as an 8 button selector switch in Domoticz, so lots of buttons and combinations. However, the status of all the lights are still changing when using the 0 and 1 button on the remote. That has not changed.

The TS0211 is still not responding in Domoticz. Here is the Domoticz log when I push the door bell button: 2022-01-17 13:22:22.119 Zgateway: ### WebSocket Data : {'attr': {'id': '18', 'lastannounced': None, 'lastseen': '2022-01-17T12:22Z', 'manufacturername': '_TZ1800_ladpngdx', 'modelid': 'TS0211', 'name': 'Door bell', 'swversion': '2020.8.4', 'type': 'ZHASwitch', 'uniqueid': 'bc:33:ac:ff:fe:04:9c:01-01-0500'}, 'e': 'changed', 'id': '18', 'r': 'sensors', 't': 'event', 'uniqueid': 'bc:33:ac:ff:fe:04:9c:01-01-0500'} 2022-01-17 13:22:22.119 Zgateway: ### WebSocket Data : {'e': 'changed', 'id': '18', 'r': 'sensors', 'state': {'buttonevent': None, 'lastupdated': '2022-01-17T12:22:22.090', 'lowbattery': False, 'tampered': False}, 't': 'event', 'uniqueid': 'bc:33:ac:ff:fe:04:9c:01-01-0500'}

Also I notice now a repeating deCONZ-bridge error in the Domoticz log: 2022-01-17 13:19:11.025 Error: Zgateway: 'onMessage' failed 'TypeError':'int() argument must be a string, a bytes-like object or a number, not 'NoneType''. 2022-01-17 13:19:11.025 Error: Zgateway: Exception traceback: 2022-01-17 13:19:11.025 Error: Zgateway: ----> Line 1066 in '/home/ userx/domoticz/plugins/Domoticz-deCONZ/plugin.py' 2022-01-17 13:19:11.025 Error: Zgateway: ----> Line 240 in '/home/ userx/domoticz/plugins/Domoticz-deCONZ/plugin.py' 2022-01-17 13:19:11.025 Error: Zgateway: ----> Line 914 in '/home/ userx/domoticz/plugins/Domoticz-deCONZ/plugin.py' 2022-01-17 13:19:11.025 Error: Zgateway: ----> Line 772 in '/home/ userx/domoticz/plugins/Domoticz-deCONZ/fonctions.py'

[Smanar]

Have patched the domoticz plugin (the beta branch, but not realy important) Have made a short modification on code, but I don't think it can have impact on result

cd deconz-rest-plugin
git pull
qmake && make -j2
sudo cp ../libde_rest_plugin.so /usr/share/deCONZ/plugins

Can you show the full device json ? You can find it in the domoticz customl tab, I need to check for the config/group field.

Are you using an headless or desktop OS ? To catch deconz logs when using the TS0211, with the "info" flag, we can see wich one button are checked by deconz, because something happen but badly 'state': {'buttonevent': None,}

Edit: You have replaced the whole json file ?

[Element2]

Recompiled, restarted deconz, updated deCONZ bridge, but no change.

---

I'm using headless, but enabled basic desktop with VNC viewer, In the deCONZ app I see a blue dot in the Door bell node when I push the button. Nothing in Debug view with INFO flag. INFO2 gives a lot of info. I hope I got all and relevant part:

16:15:30:583 0xBC33ACFFFE049C01 (TS0211) create binding for attribute reporting of cluster 0x0001 on endpoint 0x01 16:15:30:583 queue binding task for 0xBC33ACFFFE049C01, cluster 0x0001 16:15:30:583 0xBC33ACFFFE049C01 (TS0211) create binding for attribute reporting of cluster 0x0500 on endpoint 0x01 16:15:30:583 queue binding task for 0xBC33ACFFFE049C01, cluster 0x0500 16:15:30:583 Force binding of attribute reporting for node Door bell 16:15:30:596 Poll APS request to 0x588E81FFFEB3E175 cluster: 0x0006 dropped, values are fresh enough 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 16:15:30:661 Websocket 192.168.1.50:49301 send message: {"e":"changed","id":"18","r":"sensors","state":{"buttonevent":0,"lastupdated":"2022-01-17T15:15:30.658","lowbattery":false,"tampered":false},"t":"event","uniqueid":"bc:33:ac:ff:fe:04:9c:01-01-0500"} (ret = 198) 16:15:30:661 Websocket 127.0.0.1:58862 send message: {"e":"changed","id":"18","r":"sensors","state":{"buttonevent":0,"lastupdated":"2022-01-17T15:15:30.658","lowbattery":false,"tampered":false},"t":"event","uniqueid":"bc:33:ac:ff:fe:04:9c:01-01-0500"} (ret = 198) 16:15:30:662 Websocket 127.0.0.1:58866 send message: {"e":"changed","id":"18","r":"sensors","state":{"buttonevent":0,"lastupdated":"2022-01-17T15:15:30.658","lowbattery":false,"tampered":false},"t":"event","uniqueid":"bc:33:ac:ff:fe:04:9c:01-01-0500"} (ret = 198) 16:15:30:662 Websocket 192.168.1.50:62344 send message: {"e":"changed","id":"18","r":"sensors","state":{"buttonevent":0,"lastupdated":"2022-01-17T15:15:30.658","lowbattery":false,"tampered":false},"t":"event","uniqueid":"bc:33:ac:ff:fe:04:9c:01-01-0500"} (ret = 198)

---

Yes, replaced whole json file 122868 bytes.

---

Domoticz json:

{ "config": { "battery": 100, "group": null, "on": true, "reachable": true }, "ep": 1, "etag": "05bcecb24a4bdd2900f26a25ec8077a5", "lastannounced": null, "lastseen": "2022-01-17T14:25Z", "manufacturername": "_TYZB01_bngwdjsr", "mode": 1, "modelid": "TS1001", "name": "Switch", "state": { "buttonevent": 4002, "lastupdated": "2022-01-17T14:25:39.317" }, "type": "ZHASwitch", "uniqueid": "bc:33:ac:ff:fe:1e:2e:5a-01-1000", "id": "17", "deviceclass": "sensors" }

[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"
    }
}