# \[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:** 16
**Author:** ![Roberto\_Mario](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/roberto_mario/32/68051_2.png) [@Roberto\_Mario](https://community.homey.app/u/Roberto_Mario)\ **Post date:** [August 20, 2026, 7:53pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/306 "2026-08-20T19:53:09Z")
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. ---
**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:** [August 20, 2026, 7:57pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/307 "2026-08-20T19:57:25Z")
Ok - same issue with the new version? ---
**Author:** ![Roberto\_Mario](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/roberto_mario/32/68051_2.png) [@Roberto\_Mario](https://community.homey.app/u/Roberto_Mario)\ **Post date:** [August 20, 2026, 8:08pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/308 "2026-08-20T20:08:52Z")
![1000047416](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/0/b/0b388cb286254bbcc993b794b0c8bda0c50182a0.jpeg) It doesn’t work, I tried the flow I wrote and this is the result when I try it ---
**Author:** ![Guus\_Dijkstra](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/guus_dijkstra/32/121124_2.png) [@Guus\_Dijkstra](https://community.homey.app/u/Guus_Dijkstra)\ **Post date:** [August 21, 2026, 9:36am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/309 "2026-08-21T09:36:30Z")
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 ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/6/5/65c7c73d50326efb2178d56a44a3a07ea6c80859.png) ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/b/c/bc6a979cc9f00e9a2e42246c2f7c75099febd44d.jpeg) 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]_ ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/9/8/980e1a9c673f46739f297dbd185bf17b0b38e49f.png) ---
**Author:** ![Koen\_S](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/koen_s/32/168206_2.png) [@Koen\_S](https://community.homey.app/u/Koen_S)\ **Post date:** [August 21, 2026, 10:55am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/310 "2026-08-21T10:55:40Z")
# 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: ```auto 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 ```auto 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 `heartbeat` handler — push-only devices genuinely need that one. - Devices where `polling_interval` is 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: ```auto 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. ---
**Author:** ![Roberto\_Mario](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/roberto_mario/32/68051_2.png) [@Roberto\_Mario](https://community.homey.app/u/Roberto_Mario)\ **Post date:** [August 21, 2026, 7:08pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/311 "2026-08-21T19:08:17Z")
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. ---
**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:** [August 21, 2026, 11:42pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/312 "2026-08-21T23:42:01Z")
Hi Roberto Did you install the latest TEST version (1.0.195) and checked if it works now? [Tuya Local | Homey](https://homey.app/de-ch/app/com.tuyalocal/Tuya-Local/test/) ---
**Author:** ![Roberto\_Mario](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/roberto_mario/32/68051_2.png) [@Roberto\_Mario](https://community.homey.app/u/Roberto_Mario)\ **Post date:** [August 22, 2026, 5:47am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/313 "2026-08-22T05:47:21Z")
Yes I installed and tried the latest version, same problem as before, even in the flow I get the red triangle ---
**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:** [August 22, 2026, 8:08am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/314 "2026-08-22T08:08:19Z")
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 ---
**Author:** ![Roberto\_Mario](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/roberto_mario/32/68051_2.png) [@Roberto\_Mario](https://community.homey.app/u/Roberto_Mario)\ **Post date:** [August 22, 2026, 7:25pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/315 "2026-08-22T19:25:57Z")
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. ---
**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:** [August 22, 2026, 7:56pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/316 "2026-08-22T19:56:52Z")
Could you please send a screenshot of the working configuration? Thanks ---
**Author:** ![Roberto\_Mario](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/roberto_mario/32/68051_2.png) [@Roberto\_Mario](https://community.homey.app/u/Roberto_Mario)\ **Post date:** [August 22, 2026, 10:29pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/317 "2026-08-22T22:29:21Z")
![1000047767](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/1/1/11ef0b5c5b9b84932898c0def8afdf4400e587c7.jpeg)This works fine. I don’t know if deleting and recreating the device made a difference. ---
**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:** [August 22, 2026, 10:35pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/318 "2026-08-22T22:35:13Z")
Great - Thanks Does that mean you recreated the device by using the heater device and it worked (not the generic one)? ---
**Author:** ![Roberto\_Mario](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/roberto_mario/32/68051_2.png) [@Roberto\_Mario](https://community.homey.app/u/Roberto_Mario)\ **Post date:** [August 23, 2026, 5:44am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/319 "2026-08-23T05:44:10Z")
Yes, correct. ---
**Author:** ![Mates1134](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/mates1134/32/79472_2.png) [@Mates1134](https://community.homey.app/u/Mates1134)\ **Post date:** [August 24, 2026, 9:35am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/320 "2026-08-24T09:35:07Z")
​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! ---
**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:** [August 24, 2026, 5:41pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/321 "2026-08-24T17:41:07Z")
Hi Mates - Please provide the Cloud DP Table (und App Settings → Cloud Lookup) Thanks ---
**Author:** ![Peter\_Kawa](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/peter_kawa/32/173848_2.png) [@Peter\_Kawa](https://community.homey.app/u/Peter_Kawa)\ **Post date:** [August 24, 2026, 6:01pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/322 "2026-08-24T18:01:24Z")
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. ---
**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:** [August 24, 2026, 6:07pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/323 "2026-08-24T18:07:16Z")
There is a new option in the newest TEST versions which allows to set this per device (default is 100ms): ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/9/1/91aa0786282661d2d45f99b2ab32456edb198f8d.png) ---
**Author:** ![Roberto\_Mario](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/roberto_mario/32/68051_2.png) [@Roberto\_Mario](https://community.homey.app/u/Roberto_Mario)\ **Post date:** [August 24, 2026, 8:35pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/324 "2026-08-24T20:35:32Z")
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 ---
**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:** [August 24, 2026, 9:13pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/325 "2026-08-24T21:13:59Z")
> [@Roberto\_Mario](#): > > 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 Hi Roberto - Could you please share the full cloud dp table? ![image](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/5/f/5fd4972463ddc091d6da22c6741d2a4f85c469f5.png) [Previous page](https://community.homey.app/t/app-pro-tuya-local/154077.md?page=15) [Next page](https://community.homey.app/t/app-pro-tuya-local/154077.md?page=17)