Q: How to deal with Tuya rebranded plugs?

deCONZ General Support
1

This folder now contains 2 DDF files for NEO TS011F Tuya smart plugs:

BTW: I noted one is still in “Silver” DDF state?

I created my own DDF, supporting my plugs and tuning the timings a bit.
“manufacturername”: [
“_TZ3000_gjnozsaz”,
“_TZ3000_w0qqde0g”
],
“modelid”: [
“TS011F”,
“TS011F”
],

I guess a generic DDF could also support certain types of Blitzwolf plugs I think.
MQTT has 2 config files, a polled and a reporting version:

I was wondering:

  1. Should not be placed in the Tuya folder?
  2. How to prevent duplicates: where to add new TS011F plug types to the array of manufacturername?
  3. What happens if a duplicate manufacturername is found in another DDF?
2

All good questions. Only the first i can answer: They are bought as NEO plugs and branded that way. Its easier for end-users to recognize that.

On the others, @de_employees must answer :slight_smile:

3

Deconz check model ID and Manufacture name, so it s not a problem if it’s same model id.

But if you have too the same Manufacture name, it s a problem, only 1 DDF will be used.

If you have different firmware on the device (but same model id and manufacture name as it’s the same device) you can add a check in the DDF for exemple this one https://github.com/dresden-elektronik/deconz-rest-plugin/blob/master/devices/xiaomi/xiaomi_zncz04lm_smart_plug_v24.json check for endpoint present on the node.

For your situation it s not a problem, because deconz will try first the reporting, and if it don’t work it will use automatically the pooling.

4

Correct, the DDF is always matched against manufacturername and modelid as a pair. We have a few DDFs where additionally other fields are checked to differentiate for firmware versions.

5

Yeah, I know the plugs had different polling/reporting behavior on different FW levels, sometimes even reverting to polling after an official upgrade (or the other way around). But if both polling and reporting are supported by the same DDF (different manufacturername + modelid combination in array) that should not be an issue.

I’m still not sure how to deal with all these rebranded plugs though, because for example I also bought the same NEO plugs without an explicit brand (described as Tuya Zigbee Smart plug). IMO real end users are not going to mess with DDF files anyway, it just needs to work. :slight_smile:

Maybe it is better to have them all listed under Tuya (something like Tuya Smart Plug TF011), because in the end if a DDF needs to be created you need to did a bit further and know the exact name + modelid anyway!

Or maybe: under the Tuya folder: create a separate DDF for each manufacturername, essentially duplicating the DDF every time.

6

Yeah it ’ s a problem, there is too much tuya …
But as have said Mimixx, this one is branded NEO, and no other brand will use this manufacture name. I m sure it will be the same DDF than an other tuya plug, but it’s less DDF in the tuya folder.

I also bought the same NEO plugs without an explicit brand

Oups, are you sure its the same manufacture name ? So I m wrong.

We can make subfolder in the tuya folder, but most of them are “no name” brand.

But the good news is we can move all DDF in the devices folder when we want, it will not impact deconz ^^.

7

Sorry abou the confusion. Might be that manufacturername is always unique to a brand. I just meant to say that I bought 2 types of this plug, one of which had no NEO logo on the plug itself:

But it might still be NEO so in that case the folder makes sense.

I will just keep my own tweaked DDF for this and any future plug. :slight_smile: