That’s what I did
Hi Andi,
I’m having a persistent connection issue with my Tuya-based swimming pool heat pump using Tuya Local v1.0.174.
The device pairs successfully and the Local Key/IP appear to be correct. However, after pairing it continuously connects and disconnects every few seconds.
The diagnostic log repeatedly shows:
Connected on protocol 3.3 (configured: 3.4)
followed almost immediately by:
Disconnected: Error from socket: read ECONNRESET
Error from socket: read ECONNRESET — likely a protocol version mismatch.
Reconnecting in 3s
This repeats continuously.
(And because of this I can’t fetch DP data (e.g. actual temperature)).
The strange part is the protocol setting: in the actual Homey device settings, Protocol Version is definitely set to 3.3, not 3.4. I have checked this after pairing. Nevertheless, Tuya Local keeps reporting configured: 3.4.
I also performed a completely fresh test:
- removed and re-paired the device;
- explicitly selected protocol 3.3;
- confirmed afterwards that the Homey device setting still says 3.3;
- Tuya Local can establish a connection, but it is reset almost immediately;
- the device sometimes reports
Connection status: ConnectedandLast data receivedgets updated; - however, no usable values appear (for example temperature remains
- °C); - the
ECONNRESET/ reconnect loop continues every few seconds.
I also tested whether the regular Homey Tuya app v1.5.6 was causing a competing connection. I completely disabled that app and left only Tuya Local running. This made no difference: the same ECONNRESET loop continued.
So at this point the most suspicious detail seems to be the discrepancy between:
Homey device setting: 3.3
Tuya Local log: configured: 3.4
Could Tuya Local perhaps be reading/caching the wrong protocol setting internally, or could there be an issue with protocol version handling in v1.0.174?
I have generated both a Tuya Local support bundle and a Homey diagnostic report.
Homey Diagnostic Report ID:
c26a6097-66ea-4b91-8389-82c8f9536862
I can provide the support bundle, DP Debug output, device details or perform additional tests if useful.
Thanks!
Hi Jan
Thanks — your log contained the answer, and it’s a real bug. Fixed in v1.0.207.
Install TEST version: Tuya Local | Homey
Nothing is cached wrongly: the protocol version is read fresh from the settings on
every attempt. The give-away is a different line — every reconnect says “attempt 1”.
Never 2, never 3. Protocol 3.3 has no session handshake, so the connection counts as
established the moment the TCP socket is accepted, which a device that actually speaks
3.4 does happily before resetting it — your ECONNRESET. The app read that as success
and cleared its failure counter, but the automatic protocol rotation only kicks in
after five consecutive failures, so it never got past one. Your heat pump retried the
same wrong version forever.
From v1.0.207 a connection only counts once the device really answers, so the rotation
gets through to a version that works.
One correction on your side: your settings say 3.4, not 3.3 — that’s what “Connected on
protocol 3.3 (configured: 3.4)” means. 3.3 is where the rotation had drifted, 3.4 is
what you have stored, and it’s very likely the right one. Leave it at 3.4.
You’re on v1.0.174, so please update rather than patching around it. If it still won’t
stay connected afterwards, send the log again.
BR
Andi
Please test the new driver in the TEST version: Tuya Local | Homey
Hi Andi,
Great, thanks.
I’ll test it and let you know.
BR Jan.
i test it, works tks!!! After some adjust to ip reservation and the upgrade you done no more instability. works perfect, tks again
Hi Andi,
I installed v1.0.207 and left the configured protocol at 3.4 as requested.
The good news is that your fix clearly works: the failure counter now increments and protocol rotation actually takes place. For example the log shows:
5 failures — trying protocol 3.3 (configured: 3.4)
and it has also tried 3.1.
Unfortunately the heat pump still remains unavailable and no live DPs have been received:
live DPs none received yet
On 3.3 the TCP connection appears to be accepted, but it is reset almost immediately without receiving data:
Connected on protocol 3.3 (configured: 3.4)
Disconnected: Error from socket: read ECONNRESET (up 8ms, no data received)
The log also contains some earlier potentially interesting errors:
Prefix does not match: ...
Attempt to access memory outside buffer bounds
So v1.0.207 definitely fixed the protocol-rotation issue, but none of the attempted protocol versions has resulted in a valid Tuya response yet.
I also submitted a fresh Homey diagnostic report while running Tuya Local v1.0.207:
Diagnostic report ID: 991fe379-0158-4c07-9616-4b4be4cc6e8c
This report was generated while the Heat Pump was still unavailable and after the protocol rotation had taken place.
Please let me know if you want me to send another diagnostic report as well.
Thanks,
Jan
Hello, I just tried this app with one light and and it worked ok.
But I’m missing a flow card to change the mode from color to white.
The light has the possibility to change that by changing the work_mode from colour to white.
Hi Dietrich,
You’re right, and thanks for the anniversary timing — good day for a bug report.
There’s a “Set light colour mode” action in the next release (Tuya Local | Homey), plus a matching
condition so a flow can ask which mode the lamp is in.
It needs the Colour Mode DP set in device settings; on your lamp that’s the work_mode
data point. If pairing found it, you’re already set.
Andi
Hi Jan
Could could you please share the Cloud DP Table (app settings → cloud lookup)?
Thank you
Andi
Hi Andi,
First of all, thanks for your great work on the Tuya Local app!
I’m currently running v1.0.208 and encountering a reproducible issue with my Tuya v3.5 devices where the driver gets permanently locked into an invalid reconnect loop on protocol 3.3 after a brief network drop or device socket freeze (EHOSTUNREACH).
The Issue
When a Tuya device explicitly configured for Protocol 3.5 briefly drops off Layer 3 or freezes (throwing EHOSTUNREACH or Handshake timed out after 15s), the app’s retry logic assumes the protocol version is wrong after 5 failed attempts. It then automatically initiates a protocol downgrade/rotation to 3.3.
Once it rotates to protocol 3.3, a fallback bug occurs:
- The device accepts the raw TCP socket connection briefly, but closes it after ~600ms due to encryption payload mismatch (
Disconnected: socket closed (up 627ms, no data received)). - The app misinterprets this brief socket opening as a successful connection on protocol 3.3 and logs:
WRN: Connected on protocol 3.3 (configured: 3.5). Update "Protocol Version" in device settings... - The driver now gets permanently stuck on protocol 3.3, looping indefinitely and never returning to the configured 3.5 setting. The only way to restore the connection is to restart the Tuya Local app in Homey.
Relevant Log Snippet (v1.0.208)
26.08.26, 22:06:30 [INF] [Licht Dusche 2] Connected
26.08.26, 22:06:30 [WRN] [Licht Dusche 2] Connected on protocol 3.3 (configured: 3.5). Update "Protocol Version" in device settings to avoid the retry delay on next reconnect.
26.08.26, 22:06:31 [WRN] [Licht Dusche 2] Disconnected: socket closed (up 627ms, no data received)
26.08.26, 22:06:31 [WRN] [Licht Dusche 2] 10 failures — trying protocol 3.4 (configured: 3.5)
26.08.26, 22:06:31 [INF] [Licht Dusche 2] Reconnecting in 307s (attempt 10)
Suggested Fix / Feature Request
- Fix: Network/unreachable errors (
EHOSTUNREACHor pure TCP connection timeouts) should not trigger a protocol version rotation, as the IP stack of the hardware is simply temporarily unavailable. - Feature Request: Add a toggle in the device advanced settings to “Lock / Disable Protocol Auto-Rotation” so devices set to 3.5 strictly stay on 3.5 without auto-downgrading.
Thanks for taking a look into this!
Hi,
Thanks — careful report. One of the three points was a real gap and is now fixed; the
other two your own log settles the other way.
Your feature request is in 1.0.210: “Lock protocol version”, a checkbox in device
settings under the protocol dropdown. With it on the app never rotates, and switching
it on also brings back a device that has already wandered off.
The thing that misled you is my fault. This line —
Connected on protocol 3.3 (configured: 3.5). Update “Protocol Version”…
— fired whenever a connection opened on a different version, including one that
collapsed 627 ms later without a byte. So the app advised 3.3 right after 3.3 failed.
It dates from when “connected” and “works” meant the same thing here; since 1.0.207
they don’t. In 1.0.210 it only appears once the device has actually answered.
With that gone, the other two look different:
Not stuck. Your log moves on three lines later: “10 failures — trying protocol 3.4”.
The counter kept counting, and after 3.4, 3.1 and 3.2 it returns to your 3.5. What it
was on 1.0.208 is slow — “Reconnecting in 307s”, over an hour for a full sweep. Fixed
in 1.0.209: a device that accepts a socket is demonstrably reachable, so the wait stays
at 15s while versions remain untried, and a sweep takes about five minutes.
EHOSTUNREACH already doesn’t rotate — it and four other unreachable codes are on a list
the rotation checks first, for exactly your reasoning. What isn’t on it is “Handshake
timed out”, and there you have a point I can’t resolve: on 3.4/3.5 a stalled key
exchange is both the classic wrong-version signature and what a network blip looks
like. Indistinguishable at that layer, so excluding it would disable the rotation for
the devices that need it most. For someone who knows their device is 3.5, the lock is
the better answer — part of why I built it.
So: update to 1.0.210 or later, and switch on “Lock protocol version” → Tuya Local | Homey
Andi
Hi Andi,
Sure, here is the complete Cloud DP Table for the Inverter Pool Heat Pump from App Settings → Cloud Lookup:
Inverter Pool Heat Pump
DP 1 Power Boolean false {}
DP 102 WInTemp value 20 -22–250 step 1 摄氏度或华氏度
DP 103 change_tem Boolean true {}
DP 104 SpeedPercentage value 0 0–150 step 1 %
DP 105 SetMode Enum warm smart, warm, cool
DP 106 SetTemp Integer 28 -22–104 step 1
DP 107 SetDnLimit value 18 -22–104 step 1
DP 108 SetUpLimit value 35 -22–104 step 1
DP 115 fault1 bitmap 0 maxlen 30
DP 116 fault2 bitmap 0 maxlen 4
DP 117 SilentMdoe Boolean false {}
DP 118 WarmOrCool bool false {}
DP 120 OutPipeTemp value 18 -22–250 step 1
DP 122 ExhaustTemp value 19 -22–250 step 1
DP 124 AmbTemp value 19 -22–250 step 1
DP 125 CompFreAct value 0 0–150 step 1
DP 126 CompressorCurrent value 0 0–100 step 1
DP 127 RadTemp value 26 -22–250 step 1
DP 128 EXVPosition value 480 0–10000 step 1
DP 129 DCFanSpeed value 0 0–10000 step 1
DP 130 Defrost bool false {}
DP 134 CompRly bool false {}
DP 135 CyclePump bool false {}
DP 136 ReserveValve bool false {}
DP 139 ChargeRly bool false {}
DP 140 ACFanSpeed enum LowSpeed LowSpeed, MidSpeed, HighSpeed
Thanks,
Jan
Hello Guys,
can anyone help me with DP points for the Feyree charger? I spent 2 days reading but without any result. My EV charger is connected to Homey, but I can not see any values or status. So I guess something is wrong with DP.
Thank you
@Oleh_Nevynnyi
Please provide the Cloud DP table (app settings → cloud lookup)
Hi Jan - Could you please delete the device and add it again after an app update?
Andi
Hi Andi,
I updated the app, deleted the Heat Pump device and paired it again from scratch.
Pairing succeeds and the device reports Connected, but unfortunately no DP data is received.
The log now repeatedly shows:
Connected
Disconnected: socket closed (up 1m 32s, no data received)
Reconnecting in 2s
Connected
So this is different from before: I no longer see the continuous ECONNRESET errors, but the connection still receives no data.
The device tile shows - °C, and the Heat Pump also does not appear in the DP Debug device dropdown.
I paired it with the Cloud DP mappings:
On/Off 1, Target Temperature 106, Current Temperature 102, Mode 105 and Power Level 104.
Please let me know if you would like a new support bundle or diagnostic report from this freshly paired device.
Thanks,
Jan
You have to go two steps further: Click On Fetch devices, select the device and copy that Cloud DP Table.
