[APP][Pro] Tuya Local

[Andi]

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.

[Mikko_Vayrynen]

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.

[Andi]

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.

[SunBeech]

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

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, 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.

[Andi]

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 → 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

[Amersfoort]

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:
    
    
  • when the device doesn’t exist in Homey this screen shows up:
    
    
    • 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” )
      
      

What to do? Do I have more settings after the switch from Standard Instruction to DP Instruction? Any other ideas?

[Andi]

Hi,

1. Switching to DP Instruction mode broke the connection

The DP Instruction mode on 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:

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!

[SunBeech]

@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.

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.

[Amersfoort]

@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.

[Andi]

@Amersfoort

Please make the new list more informative.

Could you please let me know which Information should be added?

[Mikko_Vayrynen]

Hi,

In fact yesterday update fix my on/off problem, everything works now how it should

Thnx!

[Amersfoort]

@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?):

Adding Tuya local device in Homey. Which Cloud lookup device belongs to which Ip?

The Tuya IOT project device list is needed to link device with device id:

Instead of using a generic Cloud lookup name, use the Device name from Tuya IOT project devices.

[Andi]

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 → 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.

[SunBeech]

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.

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.

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?

[Andi]

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, 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.

[SunBeech]

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

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	{}

[Andi]

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?

[SunBeech]

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.

[Amersfoort]

Testing v1.0.82

Result of Cloud Lookup:

@Andi

1. Device names

@Andi

I need your help to identify which API field contains the correct name

@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

[Andi]

Thank you for the details - Where can I Set the custom_name?