S Yes, it is mandatory otherwise it would not be able to receive the command. Even from Smart Life it is mandatory that it is turned on for it to receive it.
Ok - same issue with the new version?
It looks great. The only things that are not functioning properly are winddirection (not in text mode but in compass points). It shows 225 degrees but should be a value like
Weerstation Guus via Tuya Local (weather_station)
Last update: 21-8-2026, 11:36:43
DP Value Type
101 240 number
102 580 number
103 200 number
104 850 number
109 10080 number
110 0 number
111 0 number
112 “SW” string
113 0 number
114 520 number
126 “comfortable” string
and the wind gust; cannot be decimal. [fixed this bij changing the Winddivisor form 10 to 1]
Device stays “Connected” while it has stopped answering — commands are silently lost (protocol 3.5)
Hi Andi,
First: thank you for 1.0.177. It fixed a real problem for me, and I can confirm it with measurements. But it uncovered a second failure mode underneath it that 1.0.177 does not catch. Details below, including timestamps and what I measured rather than assumed.
All times are local (CEST, UTC+2) on 21 August 2026.
Setup
| Hub | Homey Pro |
| App | Tuya Local, was 1.0.174 (live), now 1.0.189 (test) |
| Device | RGBIC LED strip, Tuya category dd, modelId g0m1fs |
| Driver | light |
| Protocol | 3.5 (configured and in use — find-protocol-mismatch confirms “protocol version is correct”) |
| Connection | Wi-Fi, fixed IP, reachable, 0% packet loss, port 6668 open throughout |
| Second device | A second Tuya light on 3.4 (Lampen Schutting) on the same app — same network, far fewer problems |
Data model from Tuya IoT (/v2.0/cloud/thing/{id}/model), for reference:
20 switch_led bool 22 bright_value 10..1000 46 light_length ro
21 work_mode enum 23 temp_value 0..1000 47 light_pixel ro
24 colour_data string 26 countdown 51/52/61 raw
The DP mapping in the app is correct. This report is not about DPs.
Part 1 — 1.0.177 works (confirmed)
On 1.0.174 the strip went offline at 11:46:50 and was still offline 40 minutes later. Nothing in the log after the initial disconnect. Only an app restart brought it back. That is exactly the case your 1.0.177 changelog describes.
After updating to 1.0.189, the same device dropped again at ~12:00 and came back on its own at 12:02:51 without any intervention. So CONNECT_TIMEOUT_MS plus the real _closeSocket() do what they promise. Thank you.
Part 2 — the bug: “Connected” with no data for minutes
What I observed
| Time | connection_status |
available |
last_seen |
Reality |
|---|---|---|---|---|
| 12:28:06 | Connected | true | 12:28:06 | fresh |
| 12:35:30 | Connected | true | 12:28:06 | 7m24s stale |
Polling interval is 30 s, so last_seen should never be more than ~30 s old on a healthy connection. During those seven and a half minutes:
- the app reported the device as available and connected;
- the device tile in Homey looked completely normal;
- not a single line was written to the app log — no warning, no reconnect attempt;
- every command sent to the device was accepted by Homey and silently went nowhere.
That last point is what makes it user-hostile. On 3.4/3.5 set() is fire-and-forget by design, so a command dispatched into a dead socket resolves successfully. My flow (Sonoff button → toggle the strip) reported success, Homey updated the capability value, and the lamp did not move. From the outside it looks like the button is broken.
Why I think it happens
_resetHeartbeatWatchdog() is called from three handlers:
js
this._tuya.on('data', ...) → _resetHeartbeatWatchdog()
this._tuya.on('dp-refresh',...) → _resetHeartbeatWatchdog()
this._tuya.on('heartbeat', () => this._resetHeartbeatWatchdog());
The first two mean “the device answered a question”. The third only means “the socket is alive at the transport level”. This device gets into a state where it keeps acknowledging the keep-alive pings but stops answering DP_QUERY entirely. The heartbeat handler then rearms the 30 s watchdog forever, so _handleDisconnect is never reached and no reconnect is ever scheduled.
The information needed to catch this already exists — _lastDataTime in BaseTuyaDevice, and the silentForTooLong check that forces a full GET after 30 s of silence. But that forced GET fails silently too (this._conn?.get().catch(...)), and nothing escalates when it keeps failing.
Suggested fix
A data watchdog next to the heartbeat watchdog. Something like: while connected, if Date.now() - _lastDataTime exceeds a few polling cycles (3× polling_interval, floor ~90 s), treat the connection as dead and go through _handleDisconnect('no data') so the normal reconnect path runs.
Two details that may matter:
- Please keep it independent of the heartbeat watchdog rather than removing the
heartbeathandler — push-only devices genuinely need that one. - Devices where
polling_intervalis 0 have no expectation of data at all, so they would have to be excluded or given a much longer window.
Reproducing it
I could not force the state on demand; it appeared on its own several times a day on this one device. What makes it visible without waiting is comparing last_seen against the wall clock while connection_status says Connected — that gap is the whole bug. If it helps I can run a logger against the device and send you a longer trace.
Part 3 — smaller notes
force reconnect is fast. I measured it three times in a real flow by timing the first fresh data after the action fired: 0.1 s, 0.2 s and 0.4 s on a healthy connection. Useful number for anyone worried about putting it in front of a switch action — see my workaround below.
Changing ip did not drop the live socket. I set the device’s ip to an address where nothing exists, expecting the connection to be released. For the next eight minutes the device kept reporting fresh last_seen values and capability updates, i.e. it kept talking to the old address. Caveat: I wrote that setting through the Homey Web API rather than the settings pane, so this may simply be onSettings not firing on that path. Mentioning it in case it is not.
A suggestion for the log. Disconnected: socket closed appears very often and says little. If the reason could carry how long the connection lasted and whether any data was received during it, a log would separate “dropped after 5 ms, never got anywhere” from “ran fine for an hour and then died” at a glance. Those two want different remedies.
My workaround, for other users reading this
Since the app cannot currently detect the dead-but-connected state, I put the reconnect in front of the command instead of waiting for the app to notice:
WHEN button pressed
THEN Force light reconnect
AND Toggle the light (delay 1 second)
The one second covers the 500 ms initial GET after connecting, with margin. It costs a barely noticeable delay and has made the button reliable.
What I would advise against: a scheduled “reconnect every 15 minutes” flow. I had one, and it made things measurably worse — it tears down healthy connections, and on 3.5 the rebuilt handshake occasionally stalls. Two of my outages that day lined up exactly with its cron ticks. Reconnecting on demand is fine; reconnecting on a timer is not.
Happy to test any change, and happy to supply a diagnostics report if you want one.
Hi, just so you know. I tested the level setting with the Cloud app. In that app, in the flow, to set the level, the string variable ‘level’ is set to 1, 2, or 3, and it works correctly.
Hi Roberto
Did you install the latest TEST version (1.0.195) and checked if it works now?
Yes I installed and tried the latest version, same problem as before, even in the flow I get the red triangle
Hi Roberto
Could you please delete the heater, add it as generic device and test the values and let me know which configuration works for you?
Andi
I tried creating the Tuya device, but I couldn’t set the level, so I removed it and recreated the heater device and now it works properly. With the Olimpia Splendid heater, it seems that the commands can’t be too close together (at least two seconds between one command and the next), but this isn’t an app problem; I had to set the delay with the Cloud app too.
Could you please send a screenshot of the working configuration?
Thanks
Great - Thanks
Does that mean you recreated the device by using the heater device and it worked (not the generic one)?
Yes, correct.
Hello,
Could you please add a “plugged in - solar panel” option?
I am using a Tuya Atorch DT-20 to measure output from my solar panels, and I would like to see this data properly integrated into the Energy dashboard. Currently, the system only counts it as a power consumer/appliance rather than a solar producer.
Thank you!
Hi Mates - Please provide the Cloud DP Table (und App Settings → Cloud Lookup)
Thanks
Note: It’s best to add a delay between every action card when you send multiple commands to the same device; Homey fires these action cards all at once, which can result in (some) missed actions.
Among the missing devices are the current and power measurement systems. I was able to read this type of device with a general check. Below I’ve pasted the dp cluod
contatore
DP 17 add_ele value 364
DP 18 cur_current value 2491
DP 19 cur_power value 4538
DP 20 cur_voltage value 2376
DP 21 test_bit value 0
DP 22 voltage_coe value 0
DP 23 electric_coe value 0
DP 24 power_coe value 0
DP 25 electricity_coe value 0
DP 26 fault bitmap 0
DP 51 power_reactive value 10
DP 52 power_effective
value 30000
