Tuya 4 button ZigBee 3.0 Wireless Portable Remote Control - Model number: SS6400ZB-V2

[rork-68]

Device

• Product name: Tuya zigbee 4 Gang Remote
• Manufacturer: _TZ3000_ee8nrt2l
• Model identifier: TS0044
• Device type : Remote

Screenshots

Basic

Identify

Alarms

Device Temperature

Groups

Scenes

On/Off

Level Control

Color Control

Simple Metering

Diagnostics

Other clusters that are not mentioned above

[hoodlumj3]

Can i say #metoo i have exact same remote and exact same issue in DECONZ 2.14.1 with CONBEE II FW: 0x26720700 - these remotes do not appear in Phoscon Gateway

[rork-68]

Can i say #metoo i have exact same remote and exact same issue in DECONZ 2.14.1 with CONBEE II FW: 0x26720700 - these remotes do not appear in Phoscon Gateway

Hope Deconz will start to support our remote soon!!!

[hoodlumj3]

Just to stop this from going stale. Prob not much help regarding this controller but more of an FYI... I got one of those sonoff zigbee 3.0 dongles and plugged it in and configured zigbee2mqtt on channel 15 and then paired my/this 4 button remote to the sonoff zigbee network and its working great. I haven't researched running multiple zigbee networks from the same HA server but no detrimental effects experienced so far.

[rork-68]

Just to stop this from going stale. Prob not much help regarding this controller but more of an FYI... I got one of those sonoff zigbee 3.0 dongles and plugged it in and configured zigbee2mqtt on channel 15 and then paired my/this 4 button remote to the sonoff zigbee network and its working great. I haven't researched running multiple zigbee networks from the same HA server but no detrimental effects experienced so far.

Great job! Maybe the time has arrived to switch to an independent Zigbee bridge. I'll give it a try!! Thanks a lot for you time!

[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.

[github-actions[bot]]

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.

[volkerhielscher]

can we reopen this please?

[Smanar]

Hello, can you tru this DDF

{
  "schema": "devcap1.schema.json",
  "manufacturername": "_TZ3000_ee8nrt2l",
  "modelid": "TS0044",
  "product": "TS0044",
  "sleeper": false,
  "status": "Gold",
  "subdevices": [
    {
      "type": "$TYPE_SWITCH",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0x0006"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/buttonevent"
        },
        {
          "name": "state/lastupdated"
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0006"
    },
    {
      "bind": "unicast",
      "src.ep": 2,
      "dst.ep": 1,
      "cl": "0x0006"
    },
    {
      "bind": "unicast",
      "src.ep": 3,
      "dst.ep": 1,
      "cl": "0x0006"
    },
    {
      "bind": "unicast",
      "src.ep": 4,
      "dst.ep": 1,
      "cl": "0x0006"
    }
  ]
}

And you will need too edit the button_maps.json file, (in the same folder than all DDF "devices" to add your model here

"Tuya3gangMap": {
            "vendor": "Tuya",
            "doc": "3-gang remote",
            "modelids": ["_TZ3000_t8hzpgnd", "_TZ3000_wkai4ga5", "_TZ3000_bi6lpsew", "_TZ3400_keyjhapk", "_TYZB02_key8kk7r", "_TZ3400_keyjqthh", "_TZ3400_key8kk7r", "_TZ3000_vp6clf9d", "_TYZB02_keyjqthh", "_TZ3000_peszejy7", "_TZ3000_qzjcsmar", "_TZ3000_owgcnkrh", "_TZ3000_adkvzooy", "_TZ3000_arfwfgoa", "_TZ3000_a7ouggvs", "_TZ3000_rrjr1q0u", "_TZ3000_abci1hiu", "_TZ3000_dfgbtub0"],
            "map": [

Don't take care at name, this part is used for all gangs number

[Pedder007]

Hi @Smanar, great to find this here, as I just received one of these 4-button devices.

I loaded your DDF file and also stored the button_maps.json file in the same directory. Aren't there missing some closing brackets in the end? However I added a "]," and a "}" in the end and did a hot reload in DDF.

But I got the device not working in my deCONZ/ioBroker setup. The datapoints I see in ioBroker are: The battery and the reachable status seems working, but nothing else, thus no reaction when pressing a button on the remote.

I close for today and maybe get a further hint from you.

[Pedder007]

I quickly learned the remote new to deCONZ this morning, after deleting all former entries in deCONZ/ioBroker and also restarting deCONZ and the respective ioBroker deCONZ adapter. I again used your above DDF file and the buttons map file. Last one, as described abvove incl. the two additional brackets.

Now I got the following in deCONZ:

And the following as data points in ioBroker:

But as result, again no status of the data points is changing when pressing a button on the remote.

[Smanar]

There is probably a problem in the button_maps.json, you just need to add around line 1210

"_TZ3000_ee8nrt2l",

To have something like

            "modelids": ["_TZ3000_ee8nrt2l", "_TZ3000_t8hzpgnd", "_TZ3000_wkai4ga5", "_TZ3000_bi6lpsew", "_TZ3400_keyjhapk", "_TYZB02_key8kk7r", "_TZ3400_keyjqthh", "_TZ3400_key8kk7r", "_TZ3000_vp6clf9d", "_TYZB02_keyjqthh", "_TZ3000_peszejy7", "_TZ3000_qzjcsmar", "_TZ3000_owgcnkrh", "_TZ3000_adkvzooy", "_TZ3000_arfwfgoa", "_TZ3000_a7ouggvs", "_TZ3000_rrjr1q0u", "_TZ3000_abci1hiu", "_TZ3000_dfgbtub0"],
            "map": [

Or it's on the DDF where you have added bracket ?

I can give you the complete button_maps.json if needed ? But you have a sample here https://github.com/dresden-elektronik/deconz-rest-plugin/pull/6125/files

[Pedder007]

Ah, now I got it! Thanks for the link, I wasn't aware, that this file contains info for that much other devices in total.

Thus I added now "_TZ3000_ee8nrt2l" in the list in the brackets. In addition I added the lines 1211 - 1225. In addition I added lines 1-136.

To test, I tried then to configure a scenario in Phoscon, but here the remote isn't offered to use, allthough it is listed in the switches overview. Thus I guess there is still something wrong, allthough I additionally paired it newly.

I also found other lines, about devices which I'm already using lengthy, but without that file and they nevertheless work!?

[Smanar]

Thus I added now "_TZ3000_ee8nrt2l" in the list in the brackets. In addition I added the lines 1211 - 1225. In addition I added lines 1-136.

IDK what you have done but, you JUST need to add "_TZ3000_ee8nrt2l"

I also found other lines, about devices which I'm already using lengthy, but without that file and they nevertheless work!?

You let the file, you just add one device (you will have a new manufacture name for the same device every month with tuya, not possible to guess them). So no difference for device that already use this file.

To test, I tried then to configure a scenario in Phoscon, but here the remote isn't offered to use, allthough it is listed in the switches overview.

I can't answer, I never use phoscon, to check if it work need to take a look in the API, in phoscon / help / API Information. The value updated when you use the device is "buttonevent"

[Pedder007]

Hi again, the reason for adding the lines is, that I started with an completely empty file. I never used it before, resp. there wasn‘t such a file in the directory, where also the DDFs are stored. Thus I thought to built such a file (currently) only with the content I need. I guess I will test the whole file then, as it is currently available here.

Regarding testing I will check via the API, but first have to read/remind how to use it :-)

[Smanar]

Can make with this contain for the button_maps.json file https://pastebin.com/C0ivZeiE

but first have to read/remind how to use it :-)

Don't need to use the API, can just take a look in phoscon / help / api information, you can see direclty API or event using phoscon.

[Pedder007]

Ah great! Will test later, as currently I’m not at home.

[Pedder007]

I'm sorry, but it seems further on not working. I used the file you provided above and paired the remote new, but it looks as before. Checking the API outcome in Phoscon looks as following:

//192.168.188.200/api/D5563177CA/sensors/102 REST API

{
    "config": {
        "on": true,
        "reachable": true
    },
    "etag": "a7afb67673020e2137fa3ef144aa01ea",
    "lastannounced": null,
    "lastseen": "2022-06-11T22:00Z",
    "manufacturername": "_TZ3000_ee8nrt2l",
    "mode": 1,
    "modelid": "TS0044",
    "name": "GarageFB",
    "state": {
        "buttonevent": null,
        "lastupdated": "none"
    },
    "type": "ZHASwitch",
    "uniqueid": "a4:c1:38:9c:38:79:86:7f-01-0006"
}

Events (when pressing a button, but has to have a break of ~1 minute btw. pressing. Pressing with a shorter break doesn't produce any output)

    "00:04:44:632": {
        "attr": {
            "id": "102",
            "lastannounced": null,
            "lastseen": "2022-06-11T22:04Z",
            "manufacturername": "_TZ3000_ee8nrt2l",
            "modelid": "TS0044",
            "name": "GarageFB",
            "swversion": null,
            "type": "ZHASwitch",
            "uniqueid": "a4:c1:38:9c:38:79:86:7f-01-0006"
        },
        "e": "changed",
        "id": "102",
        "r": "sensors",
        "t": "event",
        "uniqueid": "a4:c1:38:9c:38:79:86:7f-01-0006"
    }
}

[Pedder007]

Just for completness, as I saw another curious behavior with another 4-button-remote (Moes). I paired the remote now for testing with a Tuya hub and afterwards again paired it to my ConBee/deCONZ environment, but also this didn't bring along any change.

[Smanar]

You have access to deconz log when using the switch ? (with logs "info" and "info_l2"

I m seen 2 possibilities.

• The button_maps.json is not used
• You have a "light" entry created for this device (with the "sensor" entry too)

Are you sure having in the button map

"modelids": ["_TZ3000_ee8nrt2l", "_TZ3000_t8hzpgnd", "_TZ3000_wkai4ga5", "_TZ3000_bi6lpsew",

[Pedder007]

Yes I have access and I checked the logging. When enabling info continously messages are coming in. When enabling info_l2 tonnes of messages are coming in. What can I do with them? One further observation: I think normaly, when pressing a button, the little light in the deCONZ gui shall blink blue, right? But in case of the 4-button-remote it blinks light green.

And "_TZ3000_ee8nrt2l", "_TZ3000_t8hzpgnd", "_TZ3000_wkai4ga5", "_TZ3000_bi6lpsew" are really in the file. I doubled checked it.

Edit: As I was frustrated, I in parallel bought 2 of the Osram Smart+ Mini Switches and run into trouble also with them now, allthough I already have another one running since a couple of weeks. I'm now thinking, that the problem might be something completely other!? e. g. my ConBee II / DeConz is now running with >90 nodes. Might this be the issue? The problem with the Osram Mini Switches is, that when using the buttons, they appear one after another in my house automation (ioBroker), but after that, they do not change their status when pressing the button.

Edit2: Ok, just added the other of the two and saw in Phoscon, that one has the Vers. e.1.9.0M, and the one who has Problems, has the Vers. e.1.11.0M. My older one also has the first Version. So the ones with Vers. e.1.9.0M seems running proper.

[Smanar]

Yeah I know logs are realy talkative, but you need to see something just when you use the button. Something like

[INFO] - No button map for: .............. [INFO] - No button handler for: ............

Can you check if you have not a light entry fo the device (it's visible on phoscon / light) If you have a light entry, it block the buttenvent

[Pedder007]

Hi, in Phoscon I only find this in switches (=Schalter in German) There's absolutely nothing in lights or switches which I do not know, resp. I'm not able to assign to another device. In deCONZ it still looks as above, I pasted in earlier. Only a new ID as I paired it newly at some point of time.

I checked again the debug, but there are no [INFO]s as you wrote. In 'info' nothing comes in, but in 'info_l2', when pressing button 1+2, the following comes in (reproducable):

18:30:08:267 Websocket 127.0.0.1:53450 send message: {"attr":{"id":"98","lastannounced":null,"lastseen":"2022-06-17T17:30Z","manufacturername":"_TZ3000_ee8nrt2l","modelid":"TS0044","name":"Switch 98","swversion":null,"type":"ZHASwitch","uniqueid":"a4:c1:38:9c:38:79:86:7f-01-0006"},"e":"changed","id":"98","r":"sensors","t":"event","uniqueid":"a4:c1:38:9c:38:79:86:7f-01-0006"} (ret = -1094385736)
18:30:08:269 Websocket 192.168.188.20:16830 send message: {"attr":{"id":"98","lastannounced":null,"lastseen":"2022-06-17T17:30Z","manufacturername":"_TZ3000_ee8nrt2l","modelid":"TS0044","name":"Switch 98","swversion":null,"type":"ZHASwitch","uniqueid":"a4:c1:38:9c:38:79:86:7f-01-0006"},"e":"changed","id":"98","r":"sensors","t":"event","uniqueid":"a4:c1:38:9c:38:79:86:7f-01-0006"} (ret = -1094385736)
18:30:08:272 Websocket 127.0.0.1:53450 send message: {"attr":{"id":"95","lastannounced":null,"lastseen":"2022-06-17T17:30Z","manufacturername":"_TZ3000_ee8nrt2l","modelid":"TS0044","name":"Battery 95","swversion":null,"type":"ZHABattery","uniqueid":"a4:c1:38:9c:38:79:86:7f-ff-0001"},"e":"changed","id":"95","r":"sensors","t":"event","uniqueid":"a4:c1:38:9c:38:79:86:7f-ff-0001"} (ret = -1094385736)
18:30:08:274 Websocket 192.168.188.20:16830 send message: {"attr":{"id":"95","lastannounced":null,"lastseen":"2022-06-17T17:30Z","manufacturername":"_TZ3000_ee8nrt2l","modelid":"TS0044","name":"Battery 95","swversion":null,"type":"ZHABattery","uniqueid":"a4:c1:38:9c:38:79:86:7f-ff-0001"},"e":"changed","id":"95","r":"sensors","t":"event","uniqueid":"a4:c1:38:9c:38:79:86:7f-ff-0001"} (ret = -1094385736)

I additionally checked 'error, error_l2 and DDF', but there the remote doesn't show anything.

The battery ID 95 I see also in ioBroker:

Maybe in addition: When deleting the objects in ioBroker and then pressing the buttons of the remote, they come back, so something happens in the backbround. But normally other remotes show then one after another button, when pressing them. Means with each new first press on a button, a new object occures and shows/changes it's status when pressing.

Here as example for the yesterday paired Osram Mini Switch:

[Smanar]

Ok, so you don't have a light entry but a ZHABattery one. There is nothing in DDF or in legacy code to explain that, and ofc no state/buttonevent field ...

BTW I m seing you have a device with the bad endpoint FF

"uniqueid":"a4:c1:38:9c:38:79:86:7f-ff-0001"

Wich one deconz version have you ?

[Pedder007]

It is 2.15.03 / 21.4.2022 Just saw that 2.16.1 is a new stable one, thus I will update

Edit: Deleted the device from deCONZ, did the update, paired the remote newly, but all stays the same....

[Smanar]

You still have a device with this uniqueid ?

a4:c1:38:9c:38:79:86:7f-ff-0001

You need to have only

a4:c1:38:9c:38:79:86:7f-01-0006

Take care, if you have updated your deconz version according the folder you have put the DDF, this one can be removed.

[Pedder007]

This is the ZHAbattery device (also in the debug above), which always appears, when pairing the remote to my setup.

17:22:49:810 Websocket 192.168.188.20:1168 send message: {"attr":{"id":"95","lastannounced":"2022-06-17T20:56:56Z","lastseen":"2022-06-18T16:22Z","manufacturername":"_TZ3000_ee8nrt2l","modelid":"TS0044","name":"Battery 95","swversion":null,"type":"ZHABattery","uniqueid":"a4:c1:38:9c:38:79:86:7f-ff-0001"},"e":"changed","id":"95","r":"sensors","t":"event","uniqueid":"a4:c1:38:9c:38:79:86:7f-ff-0001"} (ret = -1093496904)

But I cannot see it as device. Neither in Phoscon nor in the deCONZ gui (incl. node list) und thus cannot delete it there. It only appears as data point in ioBroker, and in the debug.

So what do you mean by 'if you have updated your deconz version according the folder you have put the DDF, this one can be removed.'? What has the update to do with the DDF folder? - sorry I'm not that deep in.

‼Edit:‼ Okay, now please close your seatbelts!!! 🤣

I deleted the remote again from my setup. Did some other stuff and suddenly in the deCONZ gui a new device appeared. I wondered, took the remote and pressed some buttons. And now, without having it actively paired via Phoscon, the device shows all it's buttons (also as data points in ioBroker) and this ZHAbattery thing (a4:c1:38:9c:38:79:86:7f-ff-0001), doesn't appear again. A few seconds later, also Phoscon showed the remote.

This is really unbelievable 😜🤷‍♂️

[Smanar]

Lol, ok so what we can say at next user that will have the same issue ? Just pray and retry ^^ ?

About the DDF folder.

All DDF provided directly with deCONZ typically reside in /usr/share/deCONZ/devices/ on a Linux system and are loaded first. However, files residing in the home directory of the user running deCONZ (e.g. /home//.local/share/dresden-elektronik/deCONZ/devices) will override the pre-packaged files to allow users to amend and keep their own files if desired.

So there is a folder where all DDF are reseted whaen re-installing deconz, so the DDF used can be deleted.

BTW, so the DDF is working (at least with some mystery) so can make the PR, battery is working too ?

[Pedder007]

Yes pray loud 😅 Ok good to know about DDF I will check tomorrow.

My wife is happy now, as she likes this remote much more than the Osram Minis, which look like large rubbers 😀

Thanks a lot for your support and enjoy your Samedi evening with a good glass of vine - recognised in another chat that you seem to be French 🇫🇷 🍷

Salut from Germany 🙋🏻‍♂️

[Smanar]

Lol, yep I m french and we will test german beer in some month for our holidays.

Tell me if all is working for I make the PR, or you can do it youself if you want.

[Pedder007]

Thats funny, as we are going to spend our holidays this year in France, to have some good wine, near Narbonne. But your French beer is also very good, have been in Lion ~3years ago and tasted Ninkasi there - very nice 😉

But I fear thats the wrong platform here to chat about beer and wine ... 😅

What is PR?

[Smanar]

Lol, can speak about food after drink.

A PR is a Pull request, if the DDF is working need to put it here https://github.com/dresden-elektronik/deconz-rest-plugin/pulls for it will be included in next deconz version.

[Pedder007]

My DDF directory currently contains 3 files: It looks like before - nothing changed.

I now additonally did a hot reload for the remote and checked if there is a battery status, but there isn't one. Also had a look at the Power Config Cluster in the deCONZ gui and pressed 'read', but the battery fields stay empty:

[Smanar]

Oups, my bad, haven't set it in the DDF, and the procedure you have done is perfect (to force an attribute read). Have set the defaut value for battery, but It don't work on lot of devices, if it don't work replace

        {
          "name": "config/battery",
          "awake": true
        },

by

        {
          "name": "config/battery",
          "parse": {"at": "0x0021", "cl": "0x0001", "ep": 1, "eval": "Item.val = Attr.val"},
          "read": {"fn": "zcl", "ep": 1, "cl": "0x0001", "at": "0x0021"},
          "refresh.interval": 4000,
          "awake": true
        },

The new DDF

{
  "schema": "devcap1.schema.json",
  "manufacturername": "_TZ3000_ee8nrt2l",
  "modelid": "TS0044",
  "product": "TS0044",
  "sleeper": false,
  "status": "Gold",
  "subdevices": [
    {
      "type": "$TYPE_SWITCH",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0x0006"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/battery",
          "awake": true
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/buttonevent"
        },
        {
          "name": "state/lastupdated"
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0001",
      "report": [
        {
          "at": "0x0021",
          "dt": "0x20",
          "min": 60,
          "max": 3600,
          "change": "0x00000001"
        }
      ]
    },
    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0006"
    },
    {
      "bind": "unicast",
      "src.ep": 2,
      "dst.ep": 1,
      "cl": "0x0006"
    },
    {
      "bind": "unicast",
      "src.ep": 3,
      "dst.ep": 1,
      "cl": "0x0006"
    },
    {
      "bind": "unicast",
      "src.ep": 4,
      "dst.ep": 1,
      "cl": "0x0006"
    }
  ]
}

[Pedder007]

I'm sorry. Tested as you outlined, incl. using a really new file with the content(s) from above, but no battery is shown. Neither in deCONZ gui nor as data point in ioBroker. When pressing the READ button in deCONZ, the status light in the device flashes in red, which I guess shows that someting isn't right. The rest of the remote funtionality is still available.

But: I in addtion checked the Preview in the DDF window, which doesn't show the additional battery lines. What is this, did the 'hot reload' not work? - I pressed it multiple times. May I drag and drop the ZHABattery item manually into the device section?

Rights of the files are all equal:

Edit: I reproduced now your config myself by the DDF editor:

The ts0044.ddf file now looks as following (previously also tested the config with only two lines variant, as above). but both do not work. So it cannot be an issue of the hot reload any longer, I guess:

{
  "schema": "devcap1.schema.json",
  "manufacturername": "_TZ3000_ee8nrt2l",
  "modelid": "TS0044",
  "product": "TS0044",
  "sleeper": false,
  "status": "Gold",
  "path": "/devices/ts0044.json",
  "subdevices": [
    {
      "type": "$TYPE_SWITCH",
      "restapi": "/sensors",
      "uuid": [
        "$address.ext",
        "0x01",
        "0x0006"
      ],
      "items": [
        {
          "name": "attr/id"
        },
        {
          "name": "attr/lastannounced"
        },
        {
          "name": "attr/lastseen"
        },
        {
          "name": "attr/manufacturername"
        },
        {
          "name": "attr/modelid"
        },
        {
          "name": "attr/name"
        },
        {
          "name": "attr/swversion"
        },
        {
          "name": "attr/type"
        },
        {
          "name": "attr/uniqueid"
        },
        {
          "name": "config/battery",
          "awake": true,
          "refresh.interval": 4000,
          "read": {
            "at": "0x0021",
            "cl": "0x0001",
            "ep": 1,
            "fn": "zcl"
          },
          "parse": {
            "at": "0x0021",
            "cl": "0x0001",
            "ep": 1,
            "eval": "Item.val = Attr.val",
            "fn": "zcl"
          }
        },
        {
          "name": "config/on"
        },
        {
          "name": "config/reachable"
        },
        {
          "name": "state/buttonevent"
        },
        {
          "name": "state/lastupdated"
        }
      ]
    }
  ],
  "bindings": [
    {
      "bind": "unicast",
      "src.ep": 1,
      "dst.ep": 1,
      "cl": "0x0006"
    },
    {
      "bind": "unicast",
      "src.ep": 2,
      "dst.ep": 1,
      "cl": "0x0006"
    },
    {
      "bind": "unicast",
      "src.ep": 3,
      "dst.ep": 1,
      "cl": "0x0006"
    },
    {
      "bind": "unicast",
      "src.ep": 4,
      "dst.ep": 1,
      "cl": "0x0006"
    }
  ]
}

[Smanar]

When pressing the READ button in deCONZ, the status light in the device flashes in red

It's normal, this device is a sleeper, you can only send request when it want, so you generally need to wake it in same time you send the request. Or just wait for it decide to send the value.

But: I in addtion checked the Preview in the DDF window, which doesn't show the additional battery lines.

This is not normal, have you tried to load the DDF direclty in the editor, deconz probably check them only at start. Perhaps I have make a typo, if it's that it's visible on logs when trying to load the DDF using the editor menu. You can too check the DDF file and the path on the editor title.

May I drag and drop the ZHABattery item manually into the device section?

No, you need to do like you have done, just add a config/battery, not a new sensor.

The ts0044.ddf file now looks as following (previously also tested the config with only two lines variant, as above). but both do not work.

You have the config/battery, but miss the bind for battery return,

    {
      "bind": "unicast",
      "src.ep": 1,
      "cl": "0x0001",
      "report": [
        {
          "at": "0x0021",
          "dt": "0x20",
          "min": 60,
          "max": 3600,
          "change": "0x00000001"
        }
      ]
    },

[Pedder007]

Hi, had to do some barbeque today 😋

To your points: Thanks for the additonal info regarding DDF and deCONZ, but: What I'm wondering about is, that you wrote that deCONZ checks the DDF files only when starting. I thought, that with the 'hot reload' deCONZ somehow 'registers' the addtional info. If that only works when deCONZ is restarted, that would not be really convenient, as of the fact that restarting deCONZ often triggers some unwanted actions in my smarthome (moving shutters, switching switches, etc.). Normally I do not restart deCONZ without an urgent need.

Regarding the battery info: Yes when testing I didn't add the ZHABattery item, I only added the 'config/battery' item and configured it manually. What is interesting now, is that somewhen during barbeque, the device seems having decided to start sending a battery status:

1. The little battery icon charging bar (in the gui) switched from 0 (red) to somewhat full (green)
2. The cluster info shows 96% now
3. Also I got a data point in ioBroker which shows the 96%

So seems again whatever magic, I really have no clue, as I really didn't anything, besides barbeque 😅 I also checked the DDF file, but there the section you pasted above is not in.

[Smanar]

What I'm wondering about is, that you wrote that deCONZ checks the DDF files only when starting. I thought, that with the 'hot reload' deCONZ somehow 'registers' the addtional info. If that only works when deCONZ is restarted, that would not be really convenient, as of the fact that restarting deCONZ often triggers some unwanted actions in my smarthome (moving shutters, switching switches, etc.). Normally I do not restart deCONZ without an urgent need.

Hot reaload make a "hot reload" of the DDF actually used/modified. If you replace/edit a DDF file (using test or file editor), not sure deconz will check if the file was modified, I can be wrong but for me it scan the folder at start, load them in memory and only update them if you change it in the editor (Can be wrong, not tested)

Ok, so note for later "next issue, purpose a barbeque."

But for me nothing magic, the device is lazy, it can take time before it decide to send the value.

I also checked the DDF file, but there the section you pasted above is not in.

Strange, perhaps done on previous DDF (binding are not removed, you need to reset the device to remove them). But if it work as it can make a PR with your actual one (not a big issue if battery is missing)

[Pedder007]

If you replace/edit a DDF file (using test or file editor), not sure deconz will check if the file was modified, I can be wrong but for me it scan the folder at start, load them in memory and only update them if you change it in the editor (Can be wrong, not tested)

I guess you are right on this, because before editing with the editior, I edited the file directly with a text editor and nothing happened, despite pressing 'hot reload' and these changes have not been shown in den DDF editor. Thus it seems really keeping the content of a once read DDF file in the memory, regardless if it is replaced.

Ok, so note for later "next issue, purpose a barbeque."

Definitely 😂

Strange, perhaps done on previous DDF (binding are not removed, you need to reset the device to remove them). Yes, isn't it!? I also thought, that maybe there was something during the first pairing, when I got this single battery device (only visible in ioBroker), but now button device.

Maybe there is a kind of fragment somewhere, but also wondering, regarding the 'keeping in memory' strategy, as I did a restart somewhen...

Besides all this mistics the device is properly working and also the battery status has been update this afternoon. And the former 'Only-Battery-Device' didn't come back until now.

PS. I found the very detailled guidance for DDF usage, but cannot find the time to read it ... 😥 ... maybe on vacations, we will see ... 😉

[Smanar]

K, so if it work for you, wana make a PR or wana I make it ? to submit the device officially ?

[Pedder007]

I guess it would be better if you do. I fear I'm not deep enough in to do this properly.

In addtion: I have another remote here, which has a really wondering behavior: https://zigbee.blakadder.com/Moes_ZS-SR4-2169.html After pairing it worked directly well, but drains the batteries within 2-3 days, when it is not connected to an original Tuya hub. I tested this and also had a lenghty conversion with the support staff from Moes ( on Aliexpress) and in the end luckily got back my money. In parallel I also found respective ratings on AMZ, pointing in the same direction.

Would it make sense to try to get this tackled also via a respective DDF?

[Smanar]

PR done have just added your model to another DDF, but its exactly the same code.

Would it make sense to try to get this tackled also via a respective DDF?

I have see a similar issue, but some user have the issue, other not, this device have probably something special, (because its always the same code we are using), but haven't found the reason yet, so IDK if it can be solved using a DDF.

[Pedder007]

Great,thanks!

Ok, good to know that I‘m not alone with this. And I‘m relaxed on this as we do now have an acceptable remote for the garage door 😅 and I got my money back for the Moes remote. Annoying was only the loss of 5 of these 12V batteries while testing.

Thus I can go now on relaxed vacations, as my Smarthome will take care for itself, incl. some neighbours caretaking 😉

vive la France 🎉

[Smanar]

Yeah this issue is boring, need to check other forums to see if there is a special trick (last tuya device need a "unlock sequence"). But not enought time for the moment.

Time is stormy ATM in france ^^, not the good moment to come, we will try our luck for better in september in germany ^^

[Pedder007]

Already saw this bad weather at the moment and wondered, as Spain is extreme hot for June. However, the forcast says better, starting with Sunday, thus it will work. Better 28°C then 38°C 😄 And Septembers in Germany can also have their surprises. Press thumbs and hear you here again soon 🖖

[schumi2004]

Looks like i'm facing the same issue but then for a Tuya 4-gang remote _TZ3000_mh9px7cq How can i have this added aswell? https://www.ebay.com/itm/125444870534

[Smanar]

Hello, he ? Wich one issue ?

Your model is a TS0044 ?

[Pedder007]

Ha! @schumi2004, this looks like the one I have also tested earlier, which drains massively the battery (2-3 days empty) without being conected to a Tuya hub. The design really looks nice, but not usable for me in the end. I meanwhile use these ones, which can be ordered also in France: https://www.domadoo.fr/en/peripheriques/6015-loratap-zigbee-30-4-buttons-remote-control.html

@Smanar, hope you had a nice time in Germany. I guess wether was super in September. Our France trip was really nice, allthough the Tiger Mosquitos and the Cicades, crying the whole day 🤣

[Smanar]

Lol, ha yes the "Tiger Mosquitos", an horror this year, impossible to go outside, need a flame thrower.

And yes, perfect time, we was there during the "berlin marathon", but we didn't run ^^.

We have made some discovery on "battery drain" since the last time, you remember the DDF you was using ? Was this one https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/tuya/_TZ3000_ygvf9xzp_4gang_remote.json ?

[schumi2004]

Hello, he ? Wich one issue ?

Your model is a TS0044 ?

Model reports as TS0044 indeed. So far the battery is still working after a week of lying around not being connected to a Tuya hub.

I will try to create a DDF in my HassIO environment based on the previously submitted PR, that should work for the time being i think.

[Smanar]

@schumi2004 to test the last version, add your model on this file to test https://github.com/dresden-elektronik/deconz-rest-plugin/blob/0d061d6da1782a502e365014bb8ea2a3c9129a72/devices/tuya/_TZ3000_ygvf9xzp_4gang_remote.json

You need to add your manufacture name AND the model id (even it's always the same)

And don't forget the button_maps.json file.