I’ve managed to get an Elko Smart Termostat (WiFi) connected, but its reporting the temperature using 2 digits for the fraction. Is there any chance you can add 100 as a temperature divisor? The current option is limited to 1 or 10.
Hi Danny
Yes — I’d recommend it. The app connects to the device, so it needs the address to stay where it is. If your router hands the device a different IP later, the app keeps knocking at the old one and the device goes unavailable; the log then shows EHOSTUNREACH for that address.
The cleanest way is a DHCP reservation in your router rather than a static address on the device itself — Tuya devices generally don’t let you set one anyway. On a Fritz!Box it’s the “always assign the same IPv4 address to this device” checkbox in the device’s detail view; other routers call it a static lease or address reservation.
If it does happen, nothing is lost: look up the new address in your router and correct IP address in the device’s advanced settings. The local key stays valid — that only changes if you reset or re-pair the device in the Tuya app.
Glad the lights are working
Andi
Please try the newest TEST version and let me know if it works: Tuya Local | Homey
Thank you
Good evening, when I try to add a thermostat, after setting the IP, device ID, and local key and connecting. I see all the correct data (current temperature, set temperature, status), but when I try to save I get the error
invalid_setting_type
This is the DP cloud
Name: studio
ID:
Local Key:
Product: XH-CTW
Category: wk
UUID:
studio
DP 1 Power bool true
DP 2 TempSet value 100
DP 3 TempCurrent value 265
DP 4 Mode enum Manual
DP 6 ChildLock bool false
DP 12 Fault bitmap 0
DP 101 C_F bool false
DP 102 Heating_state bool false
DP 103 Ext_temperature value 890
DP 104 Days_Holiday value 1
DP 105 Settemp_Holiday value 15
DP 106 Hightemp_Protect bool true
DP 107 LowTemp_Protect bool true
DP 108 ext_temp_display bool false
DP 109 room_temp_compensate value -10
DP 110 room_temp_zone value 5
DP 113 low_temp_limit value 5
DP 114 set_temp_max value 35
DP 115 set_temp_min value 5
DP 117 power_state enum keep
DP 118 Prog_Type enum 2days
DP 119 Prog_Workday1 raw BgARhwARCwQT
DP 120 Prog_Workday2 raw EgATFgARFwAR
DP 121 Prog_Restday1 raw BgAPBwATCx4T
DP 122 Prog_Restday2 raw DR4TEQATFAAP
DP — switch Boolean true {}
DP — temp_set Integer 100 5–1220 step 1 ℃
DP — child_lock Boolean false {}
DP — temp_current Integer 265 0–1580 step 1 ℃
Hi Roberto
Please try the latest TEST version and let me know if it works now: Tuya Local | Homey
Thank you
Working perfectly. Thank you!
I had some problems connecting to the thermostats. Out of six, I managed to connect four without any problems; the other two took a bit of trial and error.
Everything works now.
I even managed to find the dual switch, which, for some strange reason, advertises a MAC address, but uses a different one online.
Overall, it’s a bit of a challenge, but I hope this is the end of the thousand attempts with apps that use cloud computing.
I noticed a small issue with the app. My router and access points reset overnight. I assigned all DHCP reservations to ensure the same ones, but the app doesn’t automatically reconnect to the devices when the network comes back up. In the morning, I restart the app and everything works again.
Weather station WIFIWEST500WT
I am trying to get this weatherstation working in my homey Pro. I have come a long way but i can’t get the datapoint mapping right.
This are the available datapoints
DP
Function / Name
Debug Value
Type
Scale (scale)
101
Indoor Temperature
251
number
0.1
102
Indoor Humidity
520
number
0.1
103
Outdoor Temperature
190
number
0.1
104
Outdoor Humidity
810
number
0.1
109
Atmospheric Pressure
10130
number
0.1
110
UV Index / Sun Power
0
number
1 (none)
111
Wind Speed
0
number
0.1
112
Wind Direction
“SW”
string
N/A (String)
113
Rainfall
0
number
0.1
114
Wind Gust / Extra
0
number
1 / 0.1
126
Comfort Status
“comfortable”
string
N/A (String)
This is the current data in the Tuya local app.
Most values look ok
The issue is that in homey the DP’s 112 and 126 are not showing a value. .
What would be the correct JSON setting to show these values in the correct way? That is een textstring.
For DP 112
:
For DP 126:
Hi Roberto
when the network returns, the app opens a connection to each device again. For devices on protocol 3.4 or 3.5 there is a key exchange right after the connection opens, and if the device doesn’t answer it — common while it is still starting up after a power cut — the app waited for a reply that never came. No timeout, no retry, and nothing written to the log. A device on 3.3 can end up in the same place: after several failed attempts the app tries the other protocol versions, and if the network comes back while it happens to be on 3.4 or 3.5, it gets stuck the same way. Restarting resets it to the configured version, which is why your mornings worked.
There was a second half to it: the stalled connection was left open, and these devices accept exactly one connection at a time — so it kept the device unreachable even for later attempts.
Both are fixed in 1.0.177. The connection attempt now has its own time limit, and a handshake that goes unanswered is closed and retried like any other failure. Timeouts also get a proper explanation in the log now instead of a bare error line.
I also added a flow action, Reconnect devices, which reconnects everything at once instead of needing one flow per device. You don’t need it for this bug any more, but it is handy on a schedule or a button after the network has misbehaved. The default, “offline devices only”, leaves working devices alone, so it is safe to run repeatedly.
Please check new TEST version if it works for you: Tuya Local | Homey
Andi
Hi Guus
Could you please provide the Cloud Lookup Table?
Thank you
Andi
