New device: Tuya smart plug 16a

[tomvanderduin]

Device

Product name: Tuya smart plug 16a Manufacturer: _TZ3000_dpo1ysak Model identifier: TS011F

Device type : Smart plug with power metering

Screenshots

[oywino]

I dont' understand (?) First you write that you did add your device, and now you write that you did not have to add your device ?! Could you please provide an explanation that is possible to understand?

[JustNZ]

sorry for the confusion - what I meant with adding was pairing it to my conbeeII

So if already paired - remove and repair after placing the ddf in the correct directory

[oywino]

Ok, I see. But the DDF should be edited to match the device with the correct settings, right? Or did you have an identical device to @torandreroland so no editing was needed?

[JustNZ]

I did not edit anything - I copied the file like it is and it was working right away

In this ddf is the manufacturername set which matches with my smart-plug "manufacturername": "_TZ3000_w0qqde0g",

[oywino]

So perhaps just changing the manufacturer name is enough ?

[JustNZ]

What you have do to is:

1. remove the device if already paired
2. place the ddf /usr/share/deCONZ/devices/neo/NAS-WR01B.json
3. what I also did is changed deconz to hybrid mode (don't know if that is required)
4. pair your device again

[oywino]

Ok, but the manufacturer name must match, right?

[JustNZ]

yes and also the "modelid": "TS011F",

but no guarantee from my side - I'm not an expert in that topic

[oywino]

Exactly, so the steps should be:

1. remove the device
2. edit the manufacturer name and model-ID in the DDF file
3. place the DDF in /usr/share/deCONZ/devices/neo/NAS-WR01B.json
4. pair the device again

But how do you change deCONZ to "hybrid" mode ?

[JustNZ]

for step 2. I'm not sure - as I said I'm not an expert and never created/edited any ddf

for the hybrid mode:

1. open deconz (vnc)
2. click on panel and control
3. select hybrid (will be changed back to default after a reboot)

[oywino]

What made you think that "hybrid" was needed, and what does it actually mean?

[Smanar]

I don't think this mode correclty working but : "Basic" use legacy code + DDF is possible "Strict" disable legacy code and use only DDF "Hybrid" is a mix

If you set the status to gold, It will work too on "basic" (Not sure)

[torandreroland]

Hi! Sorry for not responding for a while.

I think you need the latest beta version of the deconz-rest-plugin (see https://github.com/dresden-elektronik/deconz-rest-plugin/releases/tag/v2.13.3-beta) because of changes to DDF not least to which DDF-statuses are loaded automatically (see https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5565).

For the time being the DDF has a status of silver, meaning that it's tested but more testing should be done. You can set which statuses are loaded automatically in the Control-panel in the Deconz GUI. If that is too complicated, you can also edit the status of the DDF yourself in the json from silver to gold, and then on v2.13.3-beta of the deconz-rest-plugin, the DDF should be loaded automatically.

Glad to hear that it works for some at least. The manufacturer and modelid must match, but you can also try to edit it manually to what plug you may have. It may work. Basically the manufacturer and modelId is used to match the DDF with the device. But I would assume that the handling describes in the DDF may be valid for also other manufacturers of the same modelId.

Off topic, I got a "lemon" of the smart plug with a range of about 10 centimeter, so I decided to remove it from my setup.

[oywino]

And BTW, are you sure this device support power measurement ? it s not present in z2m too https://www.zigbee2mqtt.io/devices/SM-SO306EZ-10.html

Officially it doesn't support electrical measurements. That's why I was somewhat surprised to see that the following sensor is reported:

{
    "config": {
        "on": true,
        "reachable": false
    },
    "ep": 1,
    "etag": "ed437d31b36cae52190012d354a502c4",
    "lastannounced": null,
    "lastseen": "2021-12-18T10:25Z",
    "manufacturername": "_TZ3000_o005nuxx",
    "modelid": "TS011F",
    "name": "Consumption 39",
    "state": {
        "consumption": null,
        "lastupdated": "none",
        "power": null
    },
    "type": "ZHAConsumption",
    "uniqueid": "60:a4:23:ff:fe:80:2b:dd-01-0702"
}

And I have more than one power strip, and they all report the same sensor but with different names (Consumption XX). But as you can see, they are all reported as "unreachable". These sensors can be seen in HA, but also as unreachable.

[Smanar]

if your device is this one https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5334#issuecomment-991181369

The sensor created are not for the one n the capture, not the same mac adress

If the device have the good cluster, the sensor will be created, even not working, but without report it will be marked as "unreacheable" naturally.

[oywino]

As I said: I have three identical units. Of course they have different MAC-adresses.

[Smanar]

Ok, so your device don't have cluster 0x0702 and 0x0b04 but still create the sensors entries, you have a special setting on DDF stuff side ?

[oywino]

I have not done any DDF stuff at all (yet). And I cannot find any cluster info to explain how they seem to have power and consumption sensors. But they do!

[Smanar]

I have checked the code again, no clue, perhaps clusters are hidden but the device use them at a moment ...

[oywino]

So there's nothing to be done? We just have to accept that these "orphan" sensors exist, but are unreachable?

[Smanar]

If you use DDF it s possible to block them. And I think it will be the "autorised" work around. But I m curious to know why you have them.

[oywino]

Just tell me exactly what you'd like me to do, and I will do my best. It is definitely also in my interest to find out. As it is now, it appears clear that the plug strip was designed with support for electrical measurements. Both Power Out as well as Consumption is reported by every unit. But there may be a reason why the supplier decided not include these features in the specification (?) Sometimes, this is because they want to sell two different versions at different price points. So, even if they are identical, they just block some features in the firmware on one model and offer it at a lower price. This is just my guess. Another possibility, is that it was designed to support electrical measurements, but that some bug prevented it from functioning as expected. So they just decided to drop this from the spec, and sell it as-is.

[Smanar]

I have take a look on other project, they don't have others clusters too. For me this device don't support power measurment, or you have used it on the official tuya app ?

Just tell me exactly what you'd like me to do, and I will do my best.

Just by curiosity, you can delete it and try to re-include it with debug logs "info" and "info_l2" we will perhaps see the action that trigger thoses sensor creation.

But I suspect the DDF stuff, some others users have the reverse, measurement sensors was removed.

[libussa]

hello, I am also using a Tuya plug with power monitoring features, manufacturer model is _TZ3000_gjnozsaz , identifier is also TS011F. Is it also covered by the proposed changes? Do I need to anything more than waiting for next version?

[iisworks]

@torandreroland Are you running 2.13.4 with a few of these _TZ3000_w0qqde0g NEO plugs without issues? I do not seem to get reporting working right, and I am experiencing deconz slowdowns when I use the DDF file (Using Basic - Gold mode)? I am using Docker on my NAS (I put DDF files in /docker/deconz/data/devices) and have to note I am also using other Tuya plugs (BW-SHP15, also TS011F), and activating DDF also seems to interfere with them.

BTW: I upgraded my _TZ3000_w0qqde0g plugs to FW 1.0.10 (with a Tuya Hub and Tuya Smart Home app), which enables reporting instead of polling.

[oywino]

BTW: I upgraded my _TZ3000_w0qqde0g plugs to Tuya FW 1.0.10, which enables reporting instead of polling. How did you perform the actual upgrade?

[iisworks]

BTW: I upgraded my _TZ3000_w0qqde0g plugs to Tuya FW 1.0.10, which enables reporting instead of polling. How did you perform the actual upgrade?

A tuya hub + Tuya Smart Home app.

[oywino]

A tuya hub + Tuya Smart Home app. Aha, is there a way to update if I don't have the Tuya HUB ?

[iisworks]

Don't think so. You can get one for €15 on Aliexpress.

[oywino]

I know, but I don't want a Tuya HUB set up in my network. I'm afraid it might interfere with all the Tuya devices I already have integrated via deConz into Home Assistant. (Autodetection). Besides, my understanding is that you need a Tuya Cloud account to get it running, right?

[steljwagh]

So let me get this straight, we can OTUA firmware update Ikea devices with Deconz, but you have to buy a Tuya bridge to update Tuya devices? If we can obtain the actual firmware image, I would like to try a OTUA update of the plug.

Where in Deconz did you got the option to set power on state after the firmware upgrade? It's the main disadvantage for this plus atm, it's highly unwanted after a power outage that all the plugs are off.

Also, I can imagine the plug automatically reporting attributes is more friendly to a zigbee network then pulling information out of the plug(s).

I have the _TZ3000_gjnozsaz, I had to create a custom DDF to get these working, so my guess is this one is not in the core build. Would it be possible to identify these plugs in the core with "_TZ3000_* + TS011F" ? That would solve a lot of user fiddling I think.

[thomas-svrts]

Where in Deconz did you got the option to set power on state after the firmware upgrade? It's the main disadvantage for this plus atm, it's highly unwanted after a power outage that all the plugs are off.

on the on/off cluster you can see and change that behaviour:

[Smanar]

I have the _TZ3000_gjnozsaz, I had to create a custom DDF to get these working, so my guess is this one is not in the core build. Would it be possible to identify these plugs in the core with "TZ3000* + TS011F" ?

We will remove all device from core soon, to use only DDF. It's possible too adding more than 1 device by DDF file, but for the moment they have choose to use only 1 DDF by device.

[steljwagh]

So I have that option already availiable! But it's not working, the setting is not honoured by the bootup proces of the plug.

So a f/w update is mandatory for me to use these plugs :(

[oywino]

@steljwagh - Sorry for interrupting; I have a vague idea of what DDF is but no idea how to use it. Can you point me in the right direction for me to educate myself and become able to configure/script/make/develop (whatever it takes) my own DDF ?

[Smanar]

The basic is here https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/DDF-cheat-sheet

You can editing an already working one, it's just json file, can work just with editing the model id and the manufacture name.

Else no problem, just start from scratch with drag and drop procedure, and give your not working DDF, we can help to finish it.

[steljwagh]

@oywino what Smanar said indeed, there is a TS011F DDF file available here https://github.com/dresden-elektronik/deconz-rest-plugin/pull/5577, but drag and drop to create a DDF is so easy and simple, just do some research.

@thomas-svrts what did you had to change in the DDF to make it report only and remove the polling?

[thomas-svrts]

I didnt change anything, I even think it’s using the main code, not yet DDF. It just worked for my device: Product name: Tuya smart plug 16a Manufacturer: _TZ3000_ew3ldmgx Model identifier: TS011F

[steljwagh]

Ah my bad, I mistakenly took you for @iisworks , he is the one that announced a fw update introduced reporting back.

[oywino]

@steljwagh - thanks for you reply, but regretfully - I'm still a bit lost. Is it so that a DDF file is specific for each device (item) and brand (model)? So in the case #5570, that file will only work for a _Tua Smart Plug TZ3000w0qqde0g , right?

[steljwagh]

@oywino you're welcome. Indeed, you have to change the "manufacturername" in the DDF to get it applied on your specific device. Also the ID is used, but since TS011F is maintained by the different models of these plugs (so it seems), that's probably also kept the same with your plugs.

[iisworks]

Ah my bad, I mistakenly took you for @iisworks , he is the one that announced a fw update introduced reporting back.

I also created a new DDF for the TZ3000_w0qqde0g and it worked, but had serious issues with DDF in general (slowing deconz to a crawl and eventually crashing it), so I am holding off for now. There are 15 brand new updated plugs waiting for the next Beta, will try again then. :)

[oywino]

On the DDF cheat sheet Dresden writes "All DDF coming with deCONZ typically reside in /usr/share/deCONZ/devices/generic/" But in my installation, this folder contains no DDF files at all. This is the content of that folder on my system:

#/usr/share/deCONZ/devices/generic 
# ls

total 24
drwxr-xr-x5 root root 4096 Dec 29 10:29 ./
drwxr-xr-x 13 root root 4096 Dec 29 10:29 ../ 
drwxr-xr-x2 root root 4096 Dec 29 10:29 color_control_cluster/
-rw-r--r--1 root root 1824 Dec 18 15:54 constants.json
drwxr-xr-x2 root root 4096 Dec 29 10:29 items/
drwxr-xr-x2 root root 4096 Dec 29 10:29 subdevices/

(I'm not sure why it says: total 24)

[Smanar]

All DDF coming with deCONZ typically reside in /usr/share/deCONZ/devices/generic/ on a Linux system and are loaded first

Thoses one will be modified every time you update deconz.

However, files residing in the home directory of the user running deCONZ (e.g. /home/deconzuser/.local/share/dresden-elektronik/deCONZ/devices) will override the pre-packaged files to allow users to amend and keep their own files if desired.

But the path can change on docker

https://github.com/dresden-elektronik/deconz-rest-plugin/tree/master/devices/generic

You are 1 folder too hight ^^.

[oywino]

@Smanar - do you mean this folder:

/usr/share/deCONZ/devices 
# ls
total 172 
drwxr-xr-x 13 root root 4096 Dec 29 10:29 ./
drwxr-xr-x 10 root root 4096 Dec 29 10:29 ../ 
-rw-r--r--1 root root 120646 Dec 18 15:54 button_maps.json
drwxr-xr-x2 root root 4096 Dec 29 10:29 dresden_elektronik/ 
drwxr-xr-x5 root root 4096 Dec 29 10:29 generic/
drwxr-xr-x2 root root 4096 Dec 29 10:29 ikea/ 
drwxr-xr-x2 root root 4096 Dec 29 10:29 immax/
drwxr-xr-x2 root root 4096 Dec 29 10:29 innr/ 
drwxr-xr-x2 root root 4096 Dec 29 10:29 lutron/ 
drwxr-xr-x2 root root 4096 Dec 29 10:29 philips/
drwxr-xr-x2 root root 4096 Dec 29 10:29 samsung/
drwxr-xr-x2 root root 4096 Dec 29 10:29 tuya/ 
drwxr-xr-x2 root root 4096 Dec 29 10:29 wiser/
drwxr-xr-x2 root root 4096 Dec 29 10:29 xiaomi/ 

[Smanar]

Yep you can use this one, make a folder for exemple "personnal_DDF" inside this one, but remember this folder is for deconz, so you can use it for test, but the next time you will update deconz, the folder will be deleteds

[oywino]

@Smanar, your contribution and knowledge is highly appreciated. Thank you for sharing.

[Flight777]

I've got the same issue now with:

_TZ3000_typdpbpg

[Smanar]

Can do same fo all plugs https://github.com/dresden-elektronik/deconz-rest-plugin/issues/5633#issuecomment-1008266360

[steljwagh]

Today I received the Tuya gateway, which solely purpose was only to update all of my Tuya zigbee plugs to get them remember the last state they were in. Well, It worked perfectly, every plug was updated to version V1.0.10 (298.81KB), which I tried to obtain by decrypting SSL, but unfortunately that failed. If somebody can sniff that image, an update though Deconz could be made easily as well.

But, for 15 dollar you can update all of your slimline Tuya zigbee plugs. Beware btw, they are lacking of quality control, you can see much signal difference between some plugs.