logo elektroda
logo elektroda
X
logo elektroda
Dostępna jest polska wersja

Czy wolisz polską wersję strony elektroda?

Nie, dziękuję Przekieruj mnie tam

Extracting DpIDs for TUYA MCU devices

morgan_flint 8550 15

TL;DR

  • Identifying DpIDs for TUYA MCU devices using a multi-function circuit breaker as the main example.
  • The workflow combines Tuya App screen inspection, Tuya IoT Platform device debugging, and Cloud Explorer's Query Things Data Model to map status and instruction sets.
  • One lookup returned DpIDs 1, 6, 9, 11–19, 21, 101, 104–106, and 116–118 for energy, leakage, alarms, switch, voltage, current, and power.
  • Cloud Explorer exposes the model in one step, but the JSON is a single line with Chinese labels and long descriptions that still need cleanup.
ADVERTISEMENT
📢 Listen (AI):
  • Hello all!

    After trying several methods to identify de DpIDs during the "OBKizing" of two devices (a temperature/humidity sensor and a multi-function circuit breaker), and after sharing the idea with @p.kaczmarek2, we thought it would be good to summarize the findings in a stand-alone tutorial.

    Identifying the DPs is crucial to be able to use as many capabilities as possible of a TUYA MCU-based device after flashing OBK, so it's interesting to have as much information as possible. As I have seen, in several cases the process involves finding similar devices in the forum and copying/adapting their information, but it would be better to have a systematic approach so we don't leave away any of them.

    So, in this post, I'll try to summarize the methods I've employed and also, in the following discussion, maybe we can find better options.

    I'll use as an example the aforementioned multi-function circuit breaker, as it's a device with a good deal of DpIDS, so it has enough complexity to be a good reference.

    To start with, we can get an idea of the number of DpIDs of the device by "discovering" it in the Tuya App and exploring its control pages. The most interesting screenshots of them for our example are these:
    Screenshot of an app displaying energy consumption. Screenshot of an energy expense management app with the prepayment switch turned off. Screenshot of an app showing temperature as NaN°C in four fields. Screenshot of an app showing settings for various electrical alarms. Screenshot of app settings showing a leakage alarm with a 30 mA threshold and control toggle enabled. Screenshot of an app with over-voltage alarm settings.

    In the first screen, we can see the device can report power, voltage, current, residual current, total energy, and "balance energy" (remaining prepaid energy). The second one allows setting prepayment on or off and recharging or clearing balance energy. The third one should show temperature, but it's a feature the device doesn't support (clearly, the manufacturer is "recycling" the interface from another device...). The fourth allows testing the residual current protection and gives access to the following ones, where you can activate or deactivate the different alarms (whether they should trip the switch or not) and set their thresholds. Each of these values/settings, or groups of them, should have a DpID that we would want to monitor/control in OBK, once we flash the device with it.

    The first step to finding out more information about our devices is to create an account on the Tuya IoT Platform (not to be confused with the account for the app).

    Then, there are two options: If you want also to use the Tuya integration in Home Assistant (maybe you're already doing that), then follow the instructions here. You need to follow the steps until LINK DEVICES BY APP ACCOUNT, including this one. Alternatively, the same process is also described here (steps 1 to 6).

    From this point, you can jump to the last method described below (search [*]) to obtain DpID numbers and descriptions in one step, but you can also follow the next steps on that page, to find some more information.

    In the last link, we can follow the next steps from 7 onwards to find the DpID numbers and labels. In our example, after using the "automatic" approach in step 8 I got the following results:
    {"1":"Total forward energy","6":"Phase A","9":"Fault","11":"Switch prepayment","12":"Clear energy","13":"Balance energy","14":"charge energy","15":"Leakage current","16":"Switch","17":"Alarm set1","18":"Alarm set2","19":"Breaker id","21":"Leakage current test","101":"Clear Energy","104":"Power Factor","105":"Grid Frequency","106":"刷新上报 (Refresh report)","116":"Voltage","117":"Current","118":"有功功率 (Active power)"}
    (I've added between brackets the Google translation for the two labels in Chinese)

    With this, combined with the previous information from the Tuya App we can already make an idea about the DpID numbers associated with each of the measurements/settings of the device, but we can also get more information from the Tuya developer's website. For example, in step 7 of the previous procedure, instead of "Device Logs", click "Device Debugging", and you'll get the following screen:

    ADVERTISEMENT


    Tuya IoT platform interface screen with device information.

    After selecting the device, you can copy the information under "Standard Instruction Set" and "Standard Status Set" to your favorite JSON editor (I use Notepad++), or hit "Product details" (number 4 above) to get a listing of the DpIDs that you can relate with the numbers you got before, as I did here and in the following posts. The following code shows the "Standard Status Set" for our example:
    Code: JSON
    Log in, to see the code

    As you can see, there we have more detailed information about the contents of the different DpIDs, and how to interpret them. If you have the patience to follow the device's thread from the point I linked before, you can see how I tried to correlate the information and summarize it in tables, but that's not really necessary as, as I also explain there, there's another place in Tuya developer's website where you can find most of the info in just one step.

    [*] And here is where the abbreviated method continues. Copy the "device id" from the 6th step of any of the alternative methods above and go to to https://eu.iot.tuya.com/cloud/explorer/. Then, select Device Control -> Query Things Data Model, paste the copied "device id" in the corresponding field and hit "submit request":
    Screenshot showing the Tuya IoT platform with the Query Things Data Model function open.

    Then, hit "Copy" in the "response" and you get this:
    Code: JSON
    Log in, to see the code

    The interesting part is the one enclosed between quotation marks after "model" :
    Code: JSON
    Log in, to see the code

    The problem is that is all in one line (no carriage returns), so it's not very legible... in the corresponding post of the device's thread I describe a method to make it more legible using Notepad++ but, following @p.kaczmarek2 suggestion, I searched for an online formatter and found this one that makes a good job. If you paste the code above and hit "Auto repair" and then "format" in the messages that appear below, you get quite a good result:
    Code: JSON
    Log in, to see the code

    Still, we have the Chinese parts and some long "description" fields that are complicated to understand. So I did these final steps by hand to get what I consider should be the final product of the process:
    Code: JSON
    Log in, to see the code

    (I left the original Chinese and added the automatic English translation afterwards)

    But we are in 2023, so there must be better ways... I remembered that @fakuivan in his last post here mentioned chatgpt for doing this, so I tried asking it for that and, why not, also the formatting part. The results are promising but there are two problems: It only translates part of the original JSON (you have to keep hitting "continue" or something like that) and I couldn't get it to format correctly the long descriptions that contained \n for carriage return. I also tried with our local elektrodabot, who managed to format and translate in one step, but also partially... there is still work to make, as you can see ;-)

    So I'll keep you updated and try to apply all this to a new device I just received. Bye for now!

    Cool? Ranking DIY
    About Author
    morgan_flint
    Level 14  
    Offline 
    morgan_flint wrote 251 posts with rating 60, helped 4 times. Live in city Sevilla. Been with us since 2018 year.
  • ADVERTISEMENT
  • #2 20859983
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14649
    Help: 655
    Rate: 12661
    Thank you for this informative and helpful tutorial. I wasn't aware about this method for a very long time and I even learned some new stuff from your article. In the past, I always used the longer and harder method, namely my TuyaMCU analyzer:
    https://github.com/openshwprojects/TuyaMCUAnalyzer
    Now, the next step most likely is OpenBeken configuration for extracted dpIDs... maybe we should have a tutorial for that as well? Currently, we have only some autoexec.bat examples here:
    https://github.com/openshwprojects/OpenBK7231T_App/blob/main/docs/autoexecExamples.md
    Helpful post? Buy me a coffee.
  • #3 20860486
    MnM1
    Level 10  
    Posts: 175
    Help: 4
    Rate: 13
    Great idea and a great discussion starting point.
    Normally I get my DPIDs by going to (Tuya IoT):

    Cloud >> API Explorer >> Device Control >> Query Properties
    In there enter the device_id of the the device you want to see the dp_ids for and press submit request:

    Tuya IoT platform interface with Submit Request button highlighted.

    These are the device_ids I get for this particular device:

    {
      "result": {
        "properties": [
          {
            "code": "SetLux",
            "custom_name": "",
            "dp_id": 102,
            "time": 1702173723018,
            "value": 0
          },
          {
            "code": "SetTime",
            "custom_name": "",
            "dp_id": 103,
            "time": 1702173723018,
            "value": 10
          },
          {
            "code": "SetMode",
            "custom_name": "",
            "dp_id": 104,
            "time": 1702173723018,
            "value": "2"
          },
          {
            "code": "SetSens",
            "custom_name": "",
            "dp_id": 106,
            "time": 1702173723018,
            "value": "2"
          },
          {
            "code": "SetOnOff",
            "custom_name": "",
            "dp_id": 107,
            "time": 1702173723018,
            "value": false
          },
          {
            "code": "PIR",
            "custom_name": "",
            "dp_id": 108,
            "time": 1702173723018,
            "value": false
          }
    
  • #4 20861580
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    MnM1 wrote:
    Normally I get my DPIDs by going to (Tuya IoT):

    Cloud >> API Explorer >> Device Control >> Query Properties

    It's another possibility; I see that in that report, you can also see DpIDs labels together with their number and it's more compact, but to me the advantage of Cloud >> API Explorer >> Device Control >> Query Properties is that, apart from labels related to numbers, you get the type (raw, boolean, value...) and a detailed description of the contents. The disadvantage is that you have to work more to elaborate on the information and put it in a legible format
  • ADVERTISEMENT
  • #5 20988258
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @morgan_flint Hmmm... I'm wondering.... Probably we can automate this dpID extraction... My idea is once you have an account on tuya dev site, automatically to logon, add devices by clicking where necessary and collect the necessary information.
    For instance NoIP hosts should be confirmed each 30 days. My home automation server is doing this... automatically - logs on, opens necessary page and confirms all hosts. I'm doing this with Raspberry Pi 3B+, headless chrome driver and Selenium. You can check the idea here

    https://github.com/neothematrix/noip-renew

    Of course after collecting the necessary data from tuya dev page it is possible to add some automatic formatting :)
  • #6 20988446
    divadiow
    Level 38  
    Posts: 5089
    Help: 441
    Rate: 900
    It'd be awesome if this was part of BK easy flasher. Even if the return wasn't parsed and we had to read the results ourselves, it'd still be a step forward
  • ADVERTISEMENT
  • #7 20988483
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    Probably will be better if this is separate app (program) since you must do this first and then flash the device. If it is in OBK flasher people can forget to hit this button for dpID extraction
  • #8 20990285
    p.kaczmarek2
    Moderator Smart Home
    Posts: 14649
    Help: 655
    Rate: 12661
    How does one "add device"? Do I have to physically own the device to be able to access the API? Do I need Tuya keys?

    Or can anyone view dpids of any device?
    Helpful post? Buy me a coffee.
  • #9 20990306
    Angel0fDeath
    Level 13  
    Posts: 118
    Help: 2
    Rate: 33
    @p.kaczmarek2 In order to use tuya dev site, you need to own the device and you need to pair it via SmartLife app. After that when you visit tuya dev web site you will be able to 'ADD' the device with few clicks and extract all dpID's with few more clicks. Of course this scenario includes you already have a created project etc... I'm using one and the same project since few years. Just removing and adding devices. After that it is very easy just with few clicks you receive all features (dpID's) of the device with name, range, scale (i.e. multiplicator) etc.

    But in general - YES. You should own the device and you should paired it with SmartLife app!!!

    EDIT: Work around could be if somebody else posses the device and he/she already paired it with SmartLife app. Then this person can create an account on tuya dev site and share credentials with you.
  • #10 21604881
    blacksun2
    Level 8  
    Posts: 59
    Rate: 1
    p.kaczmarek2 wrote:
    How does one "add device"? Do I have to physically own the device to be able to access the API? Do I need Tuya keys?


    You can share a device in the Tuya app under the properties of the respective device.
    You just need to enter the country and the username (I think the email address).

    Extracting DpIDs for TUYA MCU devicesExtracting DpIDs for TUYA MCU devicesExtracting DpIDs for TUYA MCU devices

    You can send me your account name as a message. I have integrated the following into the Tuya app:

    TH08B (TH08BCBU彩屏)
    TH01 (001TH0202)
    HW400B (HumanMotionSensor)
    P01 (Motion Sensor, 001P02CB3S)
    AirQualityBox (FormaldehydeDetector)
    WiFi carbon Monoxide detector (Carbon monoxide alarm)
  • Helpful post
    #11 21605092
    piotrszulc1
    Level 10  
    Posts: 37
    Help: 3
    Rate: 8
    There are much easier ways of obtaining dpids from tuya.dev side.
    1) Tinytuya (https://github.com/jasonacox/tinytuya) can do it automatically for all your devices. Use the "wizard" option. This requires to have an active tuya.dev account and link it with your tuya app (see the detailed description in Readme)
    2) if you know the product id you can use ltchiptool (https://github.com/libretiny-eu/ltchiptool/releases) to download schema (see the picture below). It is in a form of json with detailed description (usually in chinese) of each dpid. It often even describes the format of "raw" dpids. It does not require to have a tuya.dev account.

    Extracting DpIDs for TUYA MCU devices
  • #12 21605534
    morgan_flint
    Level 14  
    Posts: 251
    Help: 4
    Rate: 60
    >>21605092
    Hi, @piotrszulc1, thanks for the info!

    Regarding method 2: Is there a simple way to get the product id?

    I can get it from Tuya Cloud device management/get device details, but that requires a Tuya developer account...
  • Helpful post
    #13 21605600
    piotrszulc1
    Level 10  
    Posts: 37
    Help: 3
    Rate: 8
    The product id is sent by the tuyamcu itself in response to the "query product information" command (https://developer.tuya.com/en/docs/iot/tuya-cloud-universal-serial-port-access-protocol?id=K9hhi0xxtn9cb#title-6-Query%20product%20information). So if your device is already flashed with custom firmware you can send this command and parse the response. If you use esphome with the tuya component, it does it automatically at startup. I believe OBK does that too.
    If it is not flashed but you can access the serial console, I believe the original firmware usually prints the product id on the serial console at boot.
    Other than that I don't know.
  • #14 21605816
    divadiow
    Level 38  
    Posts: 5089
    Help: 441
    Rate: 900
    piotrszulc1 wrote:
    1) Tinytuya (https://github.com/jasonacox/tinytuya) can do it automatically for all your devices. Use the "wizard" option. This requires to have an active tuya.dev account and link it with your tuya app (see the detailed description in Readme)


    it should be noted though that ltchiptool will try to match with its cached store of ~700 schemas and only reach out to its Tuya dev account if there are no matches. This does mean that sometimes it can return the wrong match for eg if your firmware uses the same fw key as another product but has different product key/factory pin.

    Look out for this
    Extracting DpIDs for TUYA MCU devices
  • ADVERTISEMENT
  • #15 21605938
    blacksun2
    Level 8  
    Posts: 59
    Rate: 1
    @morgan_flint
    When you have a flashdump of the device and you use "Analyze firmware dump", the productkey is added automatically.
  • #16 21832787
    io2345
    Level 9  
    Posts: 269
    Help: 1
    Rate: 7
    >>21605092 For Itchiptool: Is "product id" the same as "Product" in Tuya Dev Page? Like "001TH0202_CB3S" for the TH03 Pro.

    I did read the documentation for TinyTuya, but this tool is definitely not for beginners. In fact I didn't understand how to use it afterwards. It seems to be powerful, though
📢 Listen (AI):

Topic summary

✨ The discussion focuses on methods for extracting DpIDs from TUYA MCU devices, particularly during the "OBKizing" process. Users share various techniques, including using the Tuya IoT API Explorer to query device properties and extract DpIDs, which are essential for utilizing device capabilities after flashing OpenBeken (OBK). Suggestions for automating DpID extraction through scripts and integrating this functionality into existing tools like BK easy flasher are also proposed. Additionally, participants clarify that ownership and pairing of devices with the SmartLife app are prerequisites for accessing the Tuya developer site and extracting DpIDs.

FAQ

TL;DR: For OpenBeken users extracting Tuya MCU dpIDs, one practical route exposed 18 properties in the example breaker, and one expert called it "informative and helpful." The fastest high-detail method in the thread is Tuya IoT Cloud Explorer → Query Things Data Model, which returns dpID numbers, types, ranges, access modes, and raw-field descriptions for mapping after flashing. [#20859564]

Why it matters: Correct dpID mapping is what turns a flashed Tuya MCU device from a basic relay into a usable sensor, meter, alarm, or breaker with its real functions exposed.

Method What it returns Strength Limitation
Tuya IoT → Query Things Data Model dpID number, code, type, scale, unit, access mode, descriptions Most complete schema view JSON is hard to read until formatted
Tuya IoT → Query Properties dpID number + current property values Compact and quick Less schema detail
TuyaMCUAnalyzer Analyzer-based extraction from Tuya MCU traffic Useful older workflow Longer, harder method per thread
TinyTuya wizard Automatic retrieval for all linked devices Fast once account is linked Needs active tuya.dev account linkage
ltchiptool schema download JSON schema by product ID Can work without tuya.dev account Cached match can be wrong

Key insight: If you already linked the device to a Tuya developer project, Query Things Data Model gives the best single-source answer. Use Query Properties or app screens only as cross-checks, not as the final schema. [#20861580]

Quick Facts

  • In the breaker example, the returned model listed 18 properties with ability IDs including 1, 6, 9, 11–19, 21, 101, 104–106, 116–118. That is enough to map switching, alarms, energy, voltage, current, power, and frequency. [#20859564]
  • The phase_a raw field is defined as 8 bytes in big-endian HEX: 2 bytes for voltage at 0.1 V, 3 bytes for current at 0.001 A, and 3 bytes for active power at 0.0001 kW. [#20859564]
  • The fault bitmap example uses 4 bytes in big-endian HEX. The schema lists 17 alarm labels, including short circuit, surge, overload, leakage current, overvoltage, undervoltage, outage, and no-balance alarms. [#20859564]
  • Several value-type dpIDs include explicit ranges: leakage current 0–1000 mA, supply frequency 0–100.0 Hz with scale 1, output voltage 0–400.0 V with scale 1, and output current 0–1000.000 A with scale 3. [#20859564]
  • A supported device can be shared in the Tuya app by entering the recipient’s country and username or email, letting another person inspect the device without physically owning it. [#21604881]

What is a DpID in a Tuya MCU device, and why is it important when configuring OpenBeken after flashing?

A dpID is the numeric data-point identifier that ties a Tuya MCU function to a value, switch, raw payload, or alarm. It matters because OpenBeken needs the correct dpID map to expose real device features after flashing, such as voltage, current, total energy, leakage current, or breaker control. In the breaker example, one device exposed dpIDs from 1 to 118, including switching, metering, and alarm settings. "Identifying the DPs is crucial" is the thread’s clearest summary of why this step matters. [#20859564]

What is the Tuya product ID, and how does it relate to the schema or data model used for dpID extraction?

The Tuya product ID is the identifier used to fetch the device schema that describes its dpIDs. In the thread, ltchiptool can download the schema directly if you know the product ID, and that schema often includes names, ranges, scales, and even raw-format descriptions. For already flashed devices, the MCU returns product information when queried, so custom firmware can read it at startup. That makes the product ID a bridge between the physical device and the Tuya data model JSON. [#21605600]

How do I extract DpIDs for a Tuya MCU device using the Tuya IoT Platform and Cloud Explorer's "Query Things Data Model"?

Use the linked device’s device id in Cloud Explorer’s Query Things Data Model call. 1. Create a Tuya IoT account and link the device through the app-account workflow. 2. Copy the device ID from the linked device view. 3. Open Cloud Explorer → Device Control → Query Things Data Model, paste the ID, and submit. The response contains abilityId values, codes, access modes like ro or rw, units such as V, A, Hz, and JSON descriptions for raw dpIDs. [#20859564]

Where in the Tuya developer site can I find both dpID numbers and their labels, types, ranges, and descriptions for a paired device?

The most complete place is Cloud Explorer / API Explorer → Device Control → Query Things Data Model. That view returns dpID numbers as abilityId, human-readable codes, types such as bool, value, raw, and bitmap, plus ranges, scales, units, and long descriptions. The thread also mentions Device Debugging with Standard Instruction Set and Standard Status Set as another useful place for types and values. If you want one compact schema source, the data-model query is the stronger option. [#20859564]

What's the difference between Tuya IoT "Query Properties" and "Query Things Data Model" when looking up dpIDs?

Query Properties is the compact view, while Query Things Data Model is the full schema view. Query Properties shows current properties with fields like code, dp_id, time, and value, which is fast for spotting numbers such as 102, 103, 104, and 107. Query Things Data Model adds the missing structure: type, scale, unit, access mode, and long descriptions for raw payloads. Use Properties for a quick list and Data Model for final decoding. [#20860486]

How can I decode raw Tuya dpIDs like phase_a, alarm_set_1, or alarm_set_2 when the schema includes long Chinese descriptions?

Decode them by reading the schema description, then translating and formatting the byte layout. "phase_a" is a raw dpID that reports packed electrical measurements, using an 8-byte big-endian HEX payload with fixed byte widths and scaling. In the example, voltage uses 2 bytes at 0.1 V, current uses 3 bytes at 0.001 A, and active power uses 3 bytes at 0.0001 kW. alarm_set_1 and alarm_set_2 use repeated 4-byte alarm records: presence, action mode, and threshold bytes. [#20859564]

Why does the JSON returned by Tuya Cloud Explorer look unreadable on one line, and what tools can format it properly?

It looks unreadable because the model payload is returned as escaped JSON inside one quoted string. The thread shows that pasting it directly leaves it on one long line with embedded escapes and \n markers. Two formatting fixes were tested: Notepad++ and jsoneditoronline, where Auto repair and then format produced a readable structure. Chat tools partly helped too, but they sometimes stopped mid-output or mishandled line breaks in long descriptions. [#20859564]

Which method is better for extracting Tuya dpIDs: TuyaMCUAnalyzer, TinyTuya wizard, ltchiptool schema download, or the Tuya IoT web portal?

The best method depends on what you already have. The thread positions the Tuya IoT web portal as the richest manual method, because it shows dpID numbers, labels, types, ranges, and descriptions in one workflow. TinyTuya’s wizard can fetch data automatically for linked devices, and ltchiptool can download a schema by product ID without a tuya.dev account. TuyaMCUAnalyzer still works, but one expert explicitly called it the "longer and harder method" compared with newer options. [#20859983]

How do I get the Tuya product ID from a device that's already flashed with custom firmware like OpenBeken or ESPHome?

Query the MCU for product information after flashing. The thread says the Tuya MCU sends the product ID in response to the "query product information" command, and ESPHome with the Tuya component reads it automatically at startup. The same post says OpenBeken likely does this too. If the device is still stock but its serial console is accessible, the original firmware often prints the product ID during boot. [#21605600]

What should I check when ltchiptool returns the wrong Tuya schema because of a cached match or shared firmware key?

Check whether ltchiptool matched a cached schema instead of the exact product. The thread warns that its cache holds roughly 700 schemas, and a shared firmware key can cause a false match when the real product key or factory pin differs. In that failure case, compare the returned schema against the device’s actual functions and look for a warning indicator in the tool. If the dpIDs or features do not line up, treat that schema as suspect. [#21605816]

How can I automate Tuya dpID extraction with Selenium, headless Chrome, or another script after linking devices in the Tuya developer portal?

Automate the browser steps after the device is already linked to your Tuya developer project. One poster proposed logging in, clicking through the Tuya developer pages, collecting the dpID data, and then auto-formatting the result with a script. The suggested stack was Raspberry Pi 3B+, headless Chrome driver, and Selenium, modeled on an existing No-IP renewal bot. That approach fits repeated extraction, especially when you already reuse one project for many devices. [#20988258]

What steps are required to add a Smart Life or Tuya app device to a Tuya developer project so its dpIDs become visible through the API?

You must own or control the device, pair it in the Smart Life or Tuya app, and link that app account to a Tuya developer project. 1. Create the Tuya IoT project and complete the app-account linking flow. 2. Pair the device in Smart Life. 3. Add or link the device inside the developer portal so API tools can query it. After that, the portal can expose dpIDs, names, ranges, scales, and other schema details with a few clicks. [#20990306]

How can someone share access to a Tuya device in the app so another person can inspect its dpIDs without physically owning it?

Share the device from the Tuya app to another account. The thread states you can open the device properties, choose sharing, and enter the recipient’s country plus username or email address. Once shared, that second person can access the device through their own Tuya account and inspect its dpIDs through the developer workflow. That is the cleanest workaround when the other person does not physically own the hardware. [#21604881]

Why do some Tuya devices show app pages for features they don't actually support, and how does that affect dpID discovery?

Some Tuya apps reuse a generic panel, so the UI can show controls that the hardware does not implement. In the breaker example, the app displayed a temperature page, but the author states the device clearly did not support temperature and the manufacturer was "recycling" the interface. That can mislead dpID discovery, because a visible screen does not guarantee a real dpID exists behind it. Use the app only to estimate possible functions, then verify them in the schema or properties. [#20859564]

For ltchiptool, is the "product id" the same thing as the "Product" field shown on the Tuya Dev Page, such as "001TH0202_CB3S" for the TH03 Pro?

The thread does not confirm that they are identical. One user asked whether ltchiptool’s product ID matches the Tuya Dev Page Product field, giving 001TH0202_CB3S as an example, but no direct answer followed in the quoted discussion. What the thread does confirm is that ltchiptool needs a product ID, and that Tuya Cloud device details can expose one, while custom firmware may read it from the MCU. Treat the two labels as unverified equivalents until you cross-check the returned schema. [#21832787]
ADVERTISEMENT