# \[APP\]\[Pro\] Tuya Local **URL:** \ **Category:** Apps\ **Created:** [April 21, 2026, 10:24pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077 "2026-04-21T22:24:35Z")\ **Posts on this page:** 20\ **Page:** 5
**Author:** ![Andi](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/andi/32/160466_2.png) [@Andi](https://community.homey.app/u/Andi)\ **Post date:** [June 27, 2026, 11:03pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/82 "2026-06-27T23:03:30Z")
Hi, The DP specification you shared explains it perfectly — your device simply **does not have a mode data point**. It only has: | DP | Code | Function | | --- | --- | --- | | — | `switch` | On / Off | | — | `temp_set` | Target temperature (0–40 °C) | | — | `temp_unit_convert` | Temperature unit (°C / °F) | | — | `temp_set_f` | Target temperature in °F | There is no `mode` DP (heat/cool/auto) — so when the app tries to send a mode change, the device ignores it and the value snaps back. **Fix:** Go to your device → **Settings** → set **DP Mode** to **0** (disabled). The mode picker tile will disappear, and you won’t get the useless mode switching anymore. Your device is a heating-only unit — it heats to the target temperature and that’s it. Temperature control works (as you confirmed), which is all this device supports over LAN. **One more thing:** Could you share the **full DP specification** from the Cloud Lookup? Go to Tuya Local → Settings → ☁ Cloud Lookup → click your device name → **Copy DP Table** and paste it here. The snapshot above only shows 4 DPs — your device likely has more (like a current temperature sensor, fault alarm, etc.) that we might be able to map to useful tiles. ---
**Author:** ![Mikko\_Vayrynen](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/mikko_vayrynen/32/56553_2.png) [@Mikko\_Vayrynen](https://community.homey.app/u/Mikko_Vayrynen)\ **Post date:** [June 28, 2026, 7:05am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/83 "2026-06-28T07:05:54Z")
Hi, Thanks, but sadly none of those not worked. Every step do same, device goes unavailable couple of seconds and goes back to available, smart plug is still on. ---
**Author:** ![Andi](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/andi/32/160466_2.png) [@Andi](https://community.homey.app/u/Andi)\ **Post date:** [June 28, 2026, 8:17am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/84 "2026-06-28T08:17:36Z")
Hi Mikko, Please submit a Diagnostic Log: I need to see what happens at the exact moment you press the off button - Press the off button in Homey - Wait min. 30 seconds - Go to Settings and Submit a Diagnostic Report I hope the log will show the exact error that causes the disconnect — this tells me whether it’s an encryption error, a timeout, or a protocol rejection. Try protocol 3.1: Some older outdoor plug firmware only accepts SET commands on protocol 3.1 even though they respond to GET on 3.3/3.4. Set Protocol Version → 3.1 in device settings. ---
**Author:** ![SunBeech](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/sunbeech/32/111391_2.png) [@SunBeech](https://community.homey.app/u/SunBeech)\ **Post date:** [June 28, 2026, 9:25am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/85 "2026-06-28T09:25:15Z")
Just a thought. I was reading along with this troubleshooting. If the device does support more commands than the current DP set suggests, then there might be another thing to try. Maybe the instruction mode of the device needs to be changed in the Tuya IoT Portal: > [@\[APP\]\[Pro\] Tuya Cloud - This app allows you to connect Homey to the Tuya cloud](https://community.homey.app/t/app-pro-tuya-cloud-this-app-allows-you-to-connect-homey-to-the-tuya-cloud/21313/2668): > > I think you are right. I did some further digging. And learned something I was not aware of / which was not mentioned in the instruction in order to get raw commands to work. The TLDR is that I had to change the instruction set/mode applied to my dehumidifier in the Tuya Development Platform in order to get raw commands to work. Initially the raw command option did not seem to work. Using your [instructions on how to intercept the command messages](https://community.homey.app/t/app-pro-tuya-cloud/21313/765), Homey seemed to only receive a few functions/pr… It does require the creation of a (free) account on Tuya’s IoT Portal though and the intial setup of a project over there in order to be able to access the Tuya device. I only have two Tuya devices, but non of them expose all commands via their default Standard Instruction set. I need to switch them to the DP Instruction set in order to become available. ---
**Author:** ![Andi](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/andi/32/160466_2.png) [@Andi](https://community.homey.app/u/Andi)\ **Post date:** [June 28, 2026, 10:12am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/86 "2026-06-28T10:12:46Z")
Great find — this is a really valuable tip that I should have mentioned in the documentation! You’re absolutely right. On the Tuya IoT Platform, each device has two instruction modes: - **Standard Instruction Set** — Exposes only a curated subset of DPs with named codes (like `switch`, `temp_set`, `mode`). Some DPs may be hidden or read-only under this mode. - **DP Instruction Set** — Exposes **all raw DP numbers** the device supports, with full read/write access. Many devices — especially cheaper or OEM-branded ones — only show a limited set of functions under the Standard mode. Switching to DP mode can reveal additional DPs that are essential for local control. **How to switch:** 1. Go to [iot.tuya.com](https://iot.tuya.com/) → **Cloud** → **Project Management** → open your project 2. **Devices** → **All Devices** → click the device 3. Look for **“Instruction Mode”** or **“DP Instruction Mode”** 4. Switch from **Standard Instruction** to **DP Instruction** This could also explain why some users see SET commands failing — if the Standard Instruction Set marks a DP as read-only, the device may reject write commands over LAN even though the DP itself is technically writable. I’ll add this to the troubleshooting section in the app. Thanks for sharing! @Mikko_Vayrynen @JaccoStraaijer ---
**Author:** ![Amersfoort](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Amersfoort](https://community.homey.app/u/Amersfoort)\ **Post date:** [June 28, 2026, 1:42pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/87 "2026-06-28T13:42:25Z")
Testing the latest version v1.0.76 as a newbie. Some issues: - I changed in Tuya IOT my device setting from Standard Instruction to DP Instruction for my Curtain Motors. Restarted the Tuya Local app, but the curtains won’t respond anymore in Homey. In the Android Smart Life app they respond. - Deleted one motor in Homey settings and try to install the curtain motor again with v1.0.76: - after device and local key and Protocol version Auto detect, Test and Connect → connection failed. After selecting protocol version 3.1 manually the test is successful. - then the screen below shows up when the device already exists in Homey, which could be more informative: ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/0/e/0e2c5afc24612f3fff9d26a1f94605c7bdb2f3de.png) - when the device doesn’t exist in Homey this screen shows up: ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/0/7/071022191e06453192127cb6a489e2a4a8dee1af.png) - Unclear to me: what is the meaning of Current value column - instead of a generic Device name, could the custom\_name from Tuya IOT be used. - after adding the new device to Homey, the status of this device is unavailable. After app restart it become available, but trying to close the curtain it becomes unavailable again. The app log (see curtain with name “Curtain motor” ) ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/c/a/cab61a686d2f760ab60ee9f1c3f38f9648e2ccd2.png) What to do? Do I have more settings after the switch from Standard Instruction to DP Instruction? Any other ideas? ---
**Author:** ![Andi](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/andi/32/160466_2.png) [@Andi](https://community.homey.app/u/Andi)\ **Post date:** [June 28, 2026, 1:53pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/88 "2026-06-28T13:53:40Z")
Hi, **1. Switching to DP Instruction mode broke the connection** The DP Instruction mode on [iot.tuya.com](http://iot.tuya.com) only affects the **cloud API** — it does not change how the device communicates over LAN. However, changing device settings on the Tuya platform can sometimes **rotate the Local Key**. This is most likely why your curtains stopped responding. **Fix:** Go to **Settings → ☁ Cloud Lookup** → Fetch Devices → copy the **Local Key** for each curtain motor and update it in the device settings in Homey. **2. Auto-detect fails, 3.1 works** This is normal for some curtain motors — they use protocol 3.1 which is the legacy protocol. Auto-detect tries 3.3 first and may time out before reaching 3.1. Setting it manually to 3.1 is the correct approach. **3. Device becomes unavailable when sending commands** The log shows: ```auto Set DP 2 timed out (value may still have applied) Disconnected: Timeout waiting for status response ``` Your curtain motor disconnects after receiving a SET command. This is common with protocol 3.1 Zemismart motors. **Fix:** Enable **“Fire and Forget”** in device settings. This sends the command without waiting for a response, so the timeout/disconnect won’t happen. The command itself is usually still processed by the motor — the device just doesn’t acknowledge it over TCP. **4. “Current value” column** This shows the **live DP value** detected from the device during pairing. For example, if the curtain position is at 50%, it would show `50` next to the Position DP. A dash (—) means no value was received for that DP during the connection test. This is normal for write-only DPs like the control command. **5. Device name from Tuya cloud** Good suggestion — currently the pairing wizard uses a generic name (“Curtain Motor”). Using the custom name from the Tuya cloud would require an additional API call during pairing, which I’ll consider for a future update. **Summary — what to do now:** 1. **Refresh Local Key** for all curtain motors (Cloud Lookup → Copy → paste into device settings) 2. Set **Protocol Version → 3.1** 3. Enable **Fire and Forget → Yes** 4. Test opening/closing the curtain Let me know if the commands go through after these changes! ---
**Author:** ![SunBeech](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/sunbeech/32/111391_2.png) [@SunBeech](https://community.homey.app/u/SunBeech)\ **Post date:** [June 28, 2026, 1:58pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/89 "2026-06-28T13:58:40Z")
> [@Amersfoort](#): > > Do I have more settings after the switch from Standard Instruction to DP Instruction? You can actually see this when you are on Tuya’s IoT portal. First ensure that you device is set to the Standard Instruction set. Then, check the ‘Table of Instructions’ in the screen in which you can change the instruction set. As an example, the below image of a dehumidifier. ![ProBreeze 11](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/5/e/5eeed16cf12ac373ee0849ae25bcb5b830b53677.png) On the righthand side of the table you can see the available instructions in the Standard Instruction set: only a few. On the lefthand side the available instructions in DP Instruction set: many more are available. After switching to the DP Instruction set, the ones on the left are added to the righthand side and become available for Homey/the Tuya Local app. So your question depends on how your table for your device looks like. If, in your case the Standard Instruction set already contains all available datapoints, then I suppose you would stick to the Standard Instruction set. ---
**Author:** ![Amersfoort](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Amersfoort](https://community.homey.app/u/Amersfoort)\ **Post date:** [June 28, 2026, 3:29pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/90 "2026-06-28T15:29:54Z")
> [@Andi](#): > > copy the **Local Key** for each curtain motor and update it in the device settings in Homey. All values were unchanged. Please make the new list more informative. I have 4 curtain motors named RD Intelligent BlindMotor [number]; now I still don’t know which ip address belongs to which id. ---
**Author:** ![Andi](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/andi/32/160466_2.png) [@Andi](https://community.homey.app/u/Andi)\ **Post date:** [June 28, 2026, 6:51pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/91 "2026-06-28T18:51:55Z")
> [@Amersfoort](#): > > Please make the new list more informative. Could you please let me know which Information should be added? ---
**Author:** ![Mikko\_Vayrynen](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/mikko_vayrynen/32/56553_2.png) [@Mikko\_Vayrynen](https://community.homey.app/u/Mikko_Vayrynen)\ **Post date:** [June 29, 2026, 4:41am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/92 "2026-06-29T04:41:05Z")
Hi, In fact yesterday update fix my on/off problem, everything works now how it should Thnx! ---
**Author:** ![Amersfoort](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Amersfoort](https://community.homey.app/u/Amersfoort)\ **Post date:** [June 29, 2026, 5:41am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/93 "2026-06-29T05:41:51Z")
> [@Andi](#): > > Could you please let me know which Information should be added? Cloud lookup (please note the slidebars) with generic names (EDIT: where are the local keys?): ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/f/5/f578e20288514e2ab75126aea0b3d9ea6229c0b5.png) Adding Tuya local device in Homey. Which Cloud lookup device belongs to which Ip? ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/8/2/82550d4b7d1ded439aad0cab8f556d3258595266.png) The Tuya IOT project device list is needed to link device with device id: ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/8/2/824276ec9f4798bd77422a8db3e437f43f1d5255.png) Instead of using a generic Cloud lookup name, use the Device name from Tuya IOT project devices. ---
**Author:** ![Andi](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/andi/32/160466_2.png) [@Andi](https://community.homey.app/u/Andi)\ **Post date:** [June 29, 2026, 3:31pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/94 "2026-06-29T15:31:11Z")
Hi, Thanks for the detailed feedback — very helpful! **1. Device names** I’ve updated the Cloud Lookup in **v1.0.78** to show three pieces of information per device: - **Device name** (the name from your Tuya/Smart Life app) - **Custom name** (if set and different from the device name) - **Product name** (model/product in grey underneath) Please update to v1.0.78 and click **Fetch Devices** again — the names should now match what you see in your Tuya app. If the names still don’t match, I need your help to identify which API field contains the correct name. Could you please: 1. Go to [iot.tuya.com](https://iot.tuya.com/) → **Cloud** → **API Explorer** 2. Select **Device Management** → **Query Device Details in Bulk** 3. Enter one of your device IDs and click **Submit Request** 4. Copy the full JSON response and share it here I need to see which field (`name`, `custom_name`, or something else) contains the name you expect — for example “Verwarming kantoor” or “Gordijn 3”. **2. Matching devices to IP addresses** Unfortunately there is no way to link the Cloud Lookup devices to the local IP addresses from the network scan. The Tuya cloud only stores the device’s **public IP** (your router’s external address), not the local LAN IP. Since all devices on the same network share the same public IP, this doesn’t help with identification. **3. Missing Local Keys** Please try fetching again with v1.0.78 — the batch enrichment has been improved. If Local Keys still don’t appear, let me know and I’ll investigate further. ---
**Author:** ![SunBeech](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/sunbeech/32/111391_2.png) [@SunBeech](https://community.homey.app/u/SunBeech)\ **Post date:** [June 29, 2026, 5:40pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/95 "2026-06-29T17:40:30Z")
Hi @Andi, I have a question related to my mobile airconditioner. I have set the polling interval to 5 seconds, as the airconditioner does not seem to send updates by itself. ![IMG_2729](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/e/7/e72b110a6a85cb5fba9524ca8cc4fd912b34e6ea.jpeg) However, if I look into the log, it seems that the app does not reconnect and poll every 5 secs but every 20-30 secs. ![IMG_2730](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/2/4/2465057c57a0be6ee67572da2670843fe36c0a9d.jpeg) Maybe I am misinterpreting the log, but the log entries do no seem to align with a 5 sec polling interval. Any idea what is going on? ---
**Author:** ![Andi](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/andi/32/160466_2.png) [@Andi](https://community.homey.app/u/Andi)\ **Post date:** [June 29, 2026, 6:45pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/96 "2026-06-29T18:45:37Z")
Hi, The polling IS happening every 5 seconds — but poll requests don’t appear in the log. The log only shows **connection events** and **warnings** , not every poll tick. What you’re actually seeing is a different problem: your air conditioner **never responds with data** after connecting. Here’s what happens: 1. Device connects (TCP handshake OK) → log shows `Connected` 2. App polls every 5 seconds (silently, no log entry) 3. After 15 seconds (3 × 5s interval) with no data received, the watchdog triggers → log shows `No data received for extended period — reconnecting` 4. App reconnects → back to step 1 The 20–30 second gaps you see are the 15-second watchdog threshold plus reconnection overhead. **The real issue:** Your AC unit connects but doesn’t respond to data requests. This can be caused by: **1. Wrong Protocol Version** Go to device **Settings → Protocol Version**. Try switching to **3.4** or use **Auto-detect**. **2. DP Instruction mode** On [iot.tuya.com](https://iot.tuya.com/), open your device under Devices → click on the AC → check if the **Instruction Mode** is set to **DP Instruction** (not Standard Instruction). **4. Increase polling to 30 seconds** Even if the above fixes work, 5-second polling is very aggressive for an AC unit. AC state changes rarely — 30 seconds is sufficient and reduces network load. \*\*5. Could you also share the DP specification? In **Settings → ☁ Cloud Lookup** → click the device name → **Copy DP Table** and paste it here. This will help me check if the AC requires a specific query approach. ---
**Author:** ![SunBeech](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/sunbeech/32/111391_2.png) [@SunBeech](https://community.homey.app/u/SunBeech)\ **Post date:** [June 29, 2026, 7:20pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/97 "2026-06-29T19:20:33Z")
Yes, you indicated that earlier to me, when you created the airco driver, that my unit does not pro-actively send updates on changes via LAN (it does via the cloud connection though instantly). The only capability that the unit communicates instantly via LAN is the on/off command. I assume I cannot change that behavior, so that it does the same for the other capabilities? Thanks for clarifying how the polling interval works and how it relates to the log 😀. Note that I do receive updates, but after a delay. Hence I set the polling interval to 5 secs. The protocol used is v3.4 and only that version seems to work. For your info, I ran the cloud lookup and included the details below. Not sure whether that provides any new insights. > **Cloud lookup results** > > ```auto > EVO-14000CHW > DP 1 Power Boolean false {} > DP 2 temp_set Integer 25 16–31 step 1 ℃ > DP 3 temp_current value 18 0–35 step 1 ℃ > DP 4 mode Enum cold cold, wet, wind, hot > DP 5 windspeed Enum low low, med, high > DP 11 anion Boolean false {} > DP 15 windshake Enum off off, on > DP 20 Fault bitmap 0 maxlen 3 > DP 103 Sleeping_mode Boolean false {} > DP 104 TimerOn Integer 0 0–1440 step 1 分钟 > DP 105 TimerOff Integer 0 0–1440 step 1 分钟 > DP 107 temp_set_f Integer 77 61–88 step 1 ℉ > DP 108 temp_current_f Integer 32 32–95 step 1 ℉ > DP 109 funcTag bitmap 26 maxlen 6 > DP 110 windshakeH Boolean false {} > > ``` ---
**Author:** ![Andi](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/andi/32/160466_2.png) [@Andi](https://community.homey.app/u/Andi)\ **Post date:** [June 29, 2026, 8:15pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/98 "2026-06-29T20:15:53Z")
I checked the DP specification of your EVO-14000CHW against the Air Conditioner driver — it’s **fully compatible**. The core DPs (1–5, 20) match the defaults perfectly. You just need to configure a few settings: **Required settings changes:** 1. `mode_values` → **`cold,wet,wind,hot`** (your device uses “cold” instead of “cool”, “hot” instead of “heat”, etc.) 2. `fan_speed_values` → **`low,med,high`** **Optional DPs to enable:** | Setting | Set to | Function | | --- | --- | --- | | `dp_swing` | **15** | Vertical swing (off/on) | | `dp_swing_h` | **110** | Horizontal swing | | `dp_sleep` | **103** | Sleep mode | | `dp_anion` | **11** | Ionizer | | `dp_countdown_timer` | **104** | Timer on (minutes) | | `dp_fault` | **20** | Fault alarm | Also set `swing_values` → **`off,on`** After making these changes, restart the Tuya Local app for the pickers to update. Regarding the polling issue — once the mode and fan speed values are correctly configured, the device should start responding to data requests properly. The “No data received” loop was likely caused by the device rejecting queries? ---
**Author:** ![SunBeech](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/sunbeech/32/111391_2.png) [@SunBeech](https://community.homey.app/u/SunBeech)\ **Post date:** [June 29, 2026, 8:49pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/99 "2026-06-29T20:49:51Z")
Thanks for looking into it. I have been using the device with your airco driver since the beginning, as you created it based on my DP input back then 😉. So indeed I can control all the available options (not all of the optional DPs are available on my unit). Sending commands works almost instantly, receiving updates only after a poll. I suppose that is just how the firmware of the airco unit has been set up to work in LAN mode. ---
**Author:** ![Amersfoort](https://avatars.discourse-cdn.com/v4/letter/a/94ad74/32.png) [@Amersfoort](https://community.homey.app/u/Amersfoort)\ **Post date:** [June 30, 2026, 6:19am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/100 "2026-06-30T06:19:36Z")
Testing v1.0.82 Result of Cloud Lookup: > [@Andi](#): > > 1. Device names ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/e/8/e85a7d936eab732d5067f338acafb61e1e4fdb3c.png) > [@Andi](#): > > I need your help to identify which API field contains the correct name ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/7/5/7577a0de0dc74a294ad608d41d68f2f5f6dae9ba.png) > [@Andi](#): > > - **Product name** (model/product in grey underneath) Seems to be the Category. > [@Andi](#): > > **3. Missing Local Keys** No local keys visible for me. Could this be a setting in the Tuya platform I’m missing? The local\_key is visible in the “Query Device Details in Bulk” result ---
**Author:** ![Andi](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/andi/32/160466_2.png) [@Andi](https://community.homey.app/u/Andi)\ **Post date:** [June 30, 2026, 10:29pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/101 "2026-06-30T22:29:56Z")
Thank you for the details - Where can I Set the custom\_name? [Previous page](https://community.homey.app/t/app-pro-tuya-local/154077.md?page=4) [Next page](https://community.homey.app/t/app-pro-tuya-local/154077.md?page=6)