LocalTuya - Using Tuya IoT Platform to obtain not only Local Keys, but also DP (data point) IDs

I haven’t seen this elsewhere so I thought I’d save someone else at least part of the trouble I’ve had trying to get my Cocoon (Aldi Aust.) LED lighting strips working with HA 2022.5.5 and Local Tuya. Mind you I still haven’t got fully working functionality beyond on/off; I could adjust color (as brightness without a color wheel) and some of the scenes (but not all). It’s a work in progress, but I digress.

I’ve stumbled across a way to get the DP IDs from Tuya IoT Platform. Since you still need to use that to get the Local Key’s anyway I figure that (at least while you’ve still got an account) this is probably more convenient than using tuya-cli (which afaik needs Node.js installed) or following the instructions on github/localtuya/wiki and using test.py in tuyadebug.tgz package (which I couldn’t get to run anywhere).

FWIW I used the instructions at https://linkdhome.com/articles/local-tuya-device-control-in-homekit to set up my Tuya IoT account and add the devices and discover their Local Key.

Noting that I have a lot more options available than the screen shots in at the instructions linked above, I also discovered in Tuya IoT’s API Explorer you can also extract the DP IDs by using the Device Control > Get Device Specification Attribute form. Here you supply the Device ID and it’ll give you something like the following JSON back; easily read when pasted into something like Notepad++.

{
  "result": {
    "category": "dj",
    "functions": [
      {
        "code": "switch_led",
        "dp_id": 20,
        "type": "Boolean",
        "values": "{}"
      },
      {
        "code": "work_mode",
        "dp_id": 21,
        "type": "Enum",
        "values": "{\"range\":[\"white\",\"colour\",\"scene\",\"music\"]}"
      },
      {
        "code": "colour_data_v2",
        "dp_id": 24,
        "type": "Json",
        "values": "{\"h\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":360,\"step\":1},\"s\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":1000,\"step\":1},\"v\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":1000,\"step\":1}}"
      },
      {
        "code": "scene_data_v2",
        "dp_id": 25,
        "type": "Json",
        "values": "{\"scene_num\":{\"min\":1,\"scale\":0,\"max\":8,\"step\":1},\"scene_units\": {\"unit_change_mode\":{\"range\":[\"static\",\"jump\",\"gradient\"]},\"unit_switch_duration\":{\"min\":0,\"scale\":0,\"max\":100,\"step\":1},\"unit_gradient_duration\":{\"min\":0,\"scale\":0,\"max\":100,\"step\":1},\"bright\":{\"min\":0,\"scale\":0,\"max\":1000,\"step\":1},\"temperature\":{\"min\":0,\"scale\":0,\"max\":1000,\"step\":1},\"h\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":360,\"step\":1},\"s\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":1000,\"step\":1},\"v\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":1000,\"step\":1}}}"
      },
      {
        "code": "countdown_1",
        "dp_id": 26,
        "type": "Integer",
        "values": "{\"unit\":\"\",\"min\":0,\"max\":86400,\"scale\":0,\"step\":1}"
      },
      {
        "code": "control_data",
        "dp_id": 28,
        "type": "Json",
        "values": "{\"change_mode\":{\"range\":[\"direct\",\"gradient\"]}, \"bright\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":1000,\"step\":1}, \"temperature\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":1000,\"step\":1}, \"h\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":360,\"step\":1},\"s\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":255,\"step\":1},\"v\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":255,\"step\":1}}"
      }
    ],
    "status": [
      {
        "code": "switch_led",
        "dp_id": 20,
        "type": "Boolean",
        "values": "{}"
      },
      {
        "code": "work_mode",
        "dp_id": 21,
        "type": "Enum",
        "values": "{\"range\":[\"white\",\"colour\",\"scene\",\"music\"]}"
      },
      {
        "code": "colour_data_v2",
        "dp_id": 24,
        "type": "Json",
        "values": "{\"h\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":360,\"step\":1},\"s\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":1000,\"step\":1},\"v\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":1000,\"step\":1}}"
      },
      {
        "code": "scene_data_v2",
        "dp_id": 25,
        "type": "Json",
        "values": "{\"scene_num\":{\"min\":1,\"scale\":0,\"max\":8,\"step\":1},\"scene_units\": {\"unit_change_mode\":{\"range\":[\"static\",\"jump\",\"gradient\"]},\"unit_switch_duration\":{\"min\":0,\"scale\":0,\"max\":100,\"step\":1},\"unit_gradient_duration\":{\"min\":0,\"scale\":0,\"max\":100,\"step\":1},\"bright\":{\"min\":0,\"scale\":0,\"max\":1000,\"step\":1},\"temperature\":{\"min\":0,\"scale\":0,\"max\":1000,\"step\":1},\"h\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":360,\"step\":1},\"s\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":1000,\"step\":1},\"v\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":1000,\"step\":1}}}"
      },
      {
        "code": "countdown_1",
        "dp_id": 26,
        "type": "Integer",
        "values": "{\"unit\":\"\",\"min\":0,\"max\":86400,\"scale\":0,\"step\":1}"
      },
      {
        "code": "control_data",
        "dp_id": 28,
        "type": "Json",
        "values": "{\"change_mode\":{\"range\":[\"direct\",\"gradient\"]}, \"bright\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":1000,\"step\":1}, \"temperature\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":1000,\"step\":1}, \"h\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":360,\"step\":1},\"s\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":255,\"step\":1},\"v\":{\"min\":0,\"scale\":0,\"unit\":\"\",\"max\":255,\"step\":1}}"
      }
    ]
  },
  "success": true,
  "t": nnn,
  "tid": "xxx"
}

Anyway, sorry for the long post. I hope it helps someone. Now I have to figure out how to get my LEDs seen as an RGB lighting with their proper scenes.

5 Likes

I was aware of that page on the tuya cloud, but had no idea I could get the dp id’s there! Thanks! This makes switching over to local so much quicker without trial and error

2 Likes

Extremely useful information to make sense of the number:value options presented in localTuya’s “Add new entity” window.
BTW I also found via Get your Tuya Device Local Key - YouTube in case anyone prefers a video.

I reformatted into a table and saved (with device Id and local_key) for my personal HA project documentation.

FYI there’s also a PR on github that uses the api to find out the DPs automagically now, making this post essentially obsolete. i.e. localtuya does it itself.

I was looking at the Tuya website yesterday … my blind motor has gone from exposing 5 or 7 dp_ids to now only having 2 … anyway I noticed that the Tuya website no longer displays the dp_id numbers in any of the Device Control pages like you showed in your first post above.

{
  "result": {
    "category": "cl",
    "functions": [
      {
        "code": "control",
        "type": "Enum",
        "values": "{\"range\":[\"open\",\"stop\",\"close\"]}"
      },
      {
        "code": "percent_control",
        "type": "Integer",
        "values": "{\"unit\":\"%\",\"min\":0,\"max\":100,\"scale\":0,\"step\":1}"
      },
      {
        "code": "control_back_mode",
        "type": "Enum",
        "values": "{\"range\":[\"forward\",\"back\"]}"
      },
      {
        "code": "border",
        "type": "Enum",
        "values": "{\"range\":[\"up\",\"down\",\"up_delete\",\"down_delete\",\"remove_top_bottom\"]}"
      },
      {
        "code": "position_best",
        "type": "Integer",
        "values": "{\"unit\":\"%\",\"min\":0,\"max\":100,\"scale\":0,\"step\":1}"
      }
    ],
    "status": [
      {
        "code": "control",
        "type": "Enum",
        "values": "{\"range\":[\"open\",\"stop\",\"close\"]}"
      },
      {
        "code": "percent_control",
        "type": "Integer",
        "values": "{\"unit\":\"%\",\"min\":0,\"max\":100,\"scale\":0,\"step\":1}"
      },
      {
        "code": "control_back_mode",
        "type": "Enum",
        "values": "{\"range\":[\"forward\",\"back\"]}"
      },
      {
        "code": "work_state",
        "type": "Enum",
        "values": "{\"range\":[\"opening\",\"closing\"]}"
      },
      {
        "code": "fault",
        "type": "Bitmap",
        "values": "{\"label\":[\"motor_fault\"]}"
      },
      {
        "code": "border",
        "type": "Enum",
        "values": "{\"range\":[\"up\",\"down\",\"up_delete\",\"down_delete\",\"remove_top_bottom\"]}"
      },
      {
        "code": "position_best",
        "type": "Integer",
        "values": "{\"unit\":\"%\",\"min\":0,\"max\":100,\"scale\":0,\"step\":1}"
      }
    ]
  },
  "success": true,
  "t": 1653863419008,
  "tid": "eb624a59df9e11ec872f2aa367714e21"
}

tuyadebug/test.py for the same device today gives me:

[email protected]:~$ python3 tuyadebug/test.py 38262640e868e7ef17d8 192.168.1.160 d4f4327c3937d269
INFO:localtuya:localtuya version 1.0.0
INFO:localtuya:Python 3.10.4 (main, Apr  2 2022, 09:04:19) [GCC 11.2.0] on linux
INFO:localtuya:Using pytuya version '8.1.0'
INFO:localtuya:Detecting list of available DPS of device 38262640e868e7ef17d8 [192.168.1.160], protocol 3.3.
DEBUG:localtuya.pytuya:Sending command status (device type: type_0a)
DEBUG:localtuya.pytuya:paylod=b'{"gwId":"38262640e868e7ef17d8","devId":"38262640e868e7ef17d8"}'
DEBUG:localtuya.pytuya:DATA RECEIVED!
DEBUG:localtuya.pytuya:decode payload=b'W\x8c<\xacO\xa3\x85\xb4\xe8\x16x<\xf9D\x08\x02h<\x86-\x05/\x9f\xd0Y\x97\x9d\x89\x1cVT\x7f\xc9[\xcd\xbb\x80+\xd5\x88\xd3\x92/?\xed\xf4"\xfb5\x97\xeb9\xf3f<\xb5~\xb4\x1du\x00\xf5H[><\xd1\x1dn\xb4\[email protected]\xbc1\xcb\xd7\xe7b\x14\xdf'
DEBUG:localtuya.pytuya:decrypted result='{"devId":"38262640e868e7ef17d8","dps":{"1":"stop","7":"opening"}}'
AVAILABLE DPS ARE [{'1': 'stop', '7': 'opening'}]
INFO:localtuya:COMPLETE response from device 38262640e868e7ef17d8 [192.168.1.160].

**** deviceInfo returned OK ****

TuyaDebug (Tuya DPs dump) [1.0.0]

Device 38262640e868e7ef17d8 at 192.168.1.160 key d4f4327c3937d269 protocol 3.3 dev_type type_0a:
    DPS [1] VALUE [stop] 
    DPS [7] VALUE [opening] 
[email protected]:~$

Tuya website still shows all dp_id’s, and the Tuya app still has full control - so it looks like either a localTuya bug, or a problem at my end. Time to get out a new SDcard and start from scratch again, maybe ?

I have reported in github as a bug, and I saw another couple which could be related.

Ahh, yes i found the Pull Request for localTuya 4.0 which includes

  • introduced Cloud API connection (for local key retrieval)

Not sure about this … looking up local_key on Tuya website is a real pain … but I though the reason for localTuya was to NOT connect via internet to Tuya. May be OK if it only happens when adding a new device.

Hi @donburch888,

I’m still getting the same results from Device Control > Get Device Specification Attribute form on the Tuya website.

What you’ve posted looks like a call to Device Control > Get the instruction set supported by the device form

/v1.1/devices/{deviceID}/specifications
vs
v1.0/devices/{deviceID}/functions

Have you installed the Samba Share add on? Using that and GitHub Desktop it’s pretty easy to download the LocalTuya 4.0 PR and copy the localtuya folder to custom_components. Or you could just wait for the PR to be rolled into the master; which seems like it might happen soon.

curiouser and curiouser …

Ah-ha !!! found it !
On the Tuya website under the Device Control menu there are two entries called “Get device specific…” and “Get Device Specific…”.

The one at the bottom of the list is titled “Get Device Specification Attribute” (note the capital letters) and contains the DP_IDs - but the one half way down does not.


Of course that still doesn’t explain why localTuya can only see 2 of them.

1 Like

Hello…
I found this subject in my saerch how to control my non flashable tuya devices via hass…
Does this still work? In the past i was able to get the info from the json but thats historie i thought.
I have a bunch if devices that i would kike to use.
Looked on tuya development page but did not understand how the how thing would actually work with cloud project and such.
Thx alot for any help

It’s a shame !

When querying the details of this device, the localKey field will be reported. For more details you can see: Device Management-Cloud Services API Reference-Tuya Developer. If you still cannot get the localKey of your device according to the manual, this is because we have temporarily stopped providing the localKey for personal use in order to maintain the security of such devices (the leaked localKey will make it easy for hackers to hack into it. And it will cause great loss to your privacy and security), thank you for your understanding and support.

Source : https://support.tuya.com/en/help/_detail/K9tndtl21hlin

Darn that’s a set back.

There are several different methods to use Tuya devices from Home Assistant. My very simplified understanding is

  • The easiest is to simply use the official Tuya HA integration … but this sends all the communications through tuya’s cloud servers
  • You can flash different firmware (program) such as tasmota or ESPHome into the device. A couple of years back this was easy and reliable … but these days it tends to require opening the device and using a soldering iron … and more of the devices are using newer chips that this method doesn’t work for.
  • LocalTuya uses the Tuya firmware already in the device, so no hacking your device. To over-simplify, I believe the LocalTuya integration on your HA server pretends to be Tuya cloud server without actually sending any communication to the cloud.

You still need to configure LocalTuya with each device’s local key, and tell it which DP_IDs to use … and this is the reason for this thread. I just now checked the procedure I used to get local key and dp_id info (from YouTube video) from Tuya website, and it still works.

I believe it is still very useful to do the “Get Device Specification Attribute” (note the capital letters) described here, because it gives some description about the different dp_ids. I understand why so many people get stuck when faced with only a list of dp_id numbers and current values

trevee, I believe the article you linked to is about programmatically getting Local Key through an API. I am not sure if LocalTuya attempts to do this to simplify the add new device procedure.

1 Like

Just be sure to select all DP_IDs as you step through the process. You can then choose to ignore them after. As of right now, I do not see any other way. Like I forgot to add the battery to my iBBQ-4T integration. If I try to redo the integration, it will only give me the DP_IDs I defined before and not everyone from the device. So the only workaround I see is to redo it all again.

Pain in the you-know-what … re-entering 4 probes plus four other sensor information … just to add one I forgot. It did not work that way in the past and it is not a bug, just a pain.

I think I have finally just decided to NEVER buy a Tuya device again. Horrible experiences.

1 Like

Thanks @EnsignR ! :clap:
I wish I knew this earlier and that it was in the docs for the localtuya integration… I might add it when this year’s Hacktoberfest comes around :slight_smile:
I too found a few “almost” pages in the API Explorer so I thought the DPs were not there… until I found the right one. It doesn’t help that the names are all cut off and so similar.

It seems like the TuyaLocal is now broken and really no longer working, and almost seems like what used to be local is not really so local anymore. I had been using my smart coffee maker for months and up until today didn’t have any major problems. Now the device is just “unavailable” in Home Assistant with no more control. I think I might just cut my losses and get a smart plug and a dumb coffee maker with a toggle switch. :-/

Can’t say I experience the same issue. Every device in LocalTuya (sockets / ledstrips / lightbulb) work just fine.

Maybe this is manufacturer related. There are many devices made under all sort of brands that are using Tuya under the hood and maybe it’s a problem with how those companies have implemented Tuya into their devices.

I did manage to just completely remove my device and reinstall the entire Tuya Local integration. Then went through the process of re-adding the device along with all entities, except I missed one(blah). Now it seems to be working again. Perhaps this is also related to the 3.x to 4.x conversion.

Ye that sux, forgetting one. Removing is no issue, but adding is one shot… really annoying. Good to hear it works again!

So I’m thinking from what I saw over on another thread that my device just has a weird wrong setup by the manufacturer.

My in the IoT platform I can’t really get much of the correct data out for my device. Even when I go to device debugging I get nothing for an instruction set. So my testing becomes trial/error on how to configure the DPs. For the most part all I really care about based on what is in the smart controls is just starting the coffee brewing, and knowing when it shut off. That’s why I’m almost considering just getting a dumb coffee maker with a smart plug. :man_shrugging: