# \[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:** 22
**Author:** ![Sebastian\_Klas](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/sebastian_klas/32/171935_2.png) [@Sebastian\_Klas](https://community.homey.app/u/Sebastian_Klas)\ **Post date:** [September 23, 2026, 4:53pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/427 "2026-09-23T16:53:51Z")
One more thing I’ve just tested: DP140 works correctly for start/stop commands from Homey, but the Homey switch does not follow when the charger is started or stopped externally from the Tuya app. So DP140 appears to work for sending the command, but it doesn’t currently provide/sync the switch state back to Homey. Since DP109 reliably reports the actual charger state, could the Homey switch state perhaps be synchronized from DP109? For example: - WORKING → On - PAUSE → Off - IDLEINS → probably On/available, since the charger is enabled and the vehicle is plugged in but not requesting power. That way the Homey switch would also update correctly when start/stop is performed from the Tuya app. ---
**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:** [September 23, 2026, 8:47pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/428 "2026-09-23T20:47:48Z")
Hi Dietrich, That screen is the pairing dialog, and it’s showing exactly what it should — the Bridge’s own two data points. The sub-device list isn’t there; it lives in DP Debug, which only exists once a device has been added. Also: you didn’t need to pair it again. If you now have two Bridge entries pointing at 192.168.5.10, please delete one. These devices accept exactly one local connection, and two entries for the same address fight each other for it — that alone can stop anything from arriving. Where to look: app settings → DP Debug → pick Bridge in the dropdown → scroll past its own data points. If a sub-device has reported, there’s a section headed Sub-devices behind this gateway. It probably won’t be there immediately. The gateway only forwards a sub-device’s values when that sub-device actually sends something, and a radiator thermostat is quiet by nature — it may report once every half hour. So give it a nudge: turn the dial on one thermostat, or change its target temperature in the Tuya app, then switch on Auto-refresh in DP Debug and watch for a minute. If something appears — an id with DP 2 and DP 3 under it — that’s the answer and we’re most of the way there. If nothing appears after a few deliberate changes, that’s also an answer: your Bridge keeps its sub-devices to itself and relays them only to the cloud. Either way we’ll know, which we couldn’t before. Kind regards, Andi ---
**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:** [September 23, 2026, 8:59pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/429 "2026-09-23T20:59:11Z")
Hi Sebastian, That settles it, and your own older data confirms it without being asked. d=12350 against DP153’s t=1225s is a ten-second gap — your polling interval — so d is the running session’s duration in tenths of a second, exactly as you read it. The nice part: two readings you sent days ago prove the same thing independently. They’re 240 seconds and 0.7 kWh apart, which works out to 10.5 kW — the power both of them reported at the time. Energy over time meeting the power checks both units at once. So the block is uniform after all, which I should have seen much earlier: every field counts in tenths of its unit. 2320 → 232.0 V, 55 → 5.5 A, 370 → 37.0 °C, 39 → 3.9 kW, 113 → 11.3 kWh, 12350 → 1235.0 s. d goes to the log rather than a tile, since there’s nothing to show a charging duration on, but the log now says what it is instead of calling it a mystery. The switch: yes, and it’s built. Slightly differently from your proposal, though — no new setting. The switch follows the reported state only while the switch data point has never said anything of its own. The app already remembers every data point a device has ever sent, so the moment DP 140 reports a value, this stops and that value governs again. It fixes your charger without changing behaviour for the hundreds where the switch point works normally. Your mapping is what I used: WORKING → on, PAUSE → off, IDLEINS → on. Unplugged leaves the switch alone, since it says nothing about whether the charger is enabled. Good to hear DP 140 works. The short delay before power reappears is expected — the measurement block only arrives when the charger sends it, so the first one after a start is whenever it feels like it. Kind regards, Andi ---
**Author:** ![Dietrich\_Kassner](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/dietrich_kassner/32/176924_2.png) [@Dietrich\_Kassner](https://community.homey.app/u/Dietrich_Kassner)\ **Post date:** [September 24, 2026, 9:27am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/430 "2026-09-24T09:27:00Z")
Hello Andi, after playing a liitle bit with the Thermostats I get the following as DP debug: Bridge ![Screenshot_20260924_111101_Homey](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/5/c/5cfeccc0624f47475a5daf261f2a88f6da7b2d27.jpeg) Sub devices Bluetooth Thermostat ![Screenshot_20260924_111111_Homey](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/f/e/fe060e65103a6a130fa19f853b9719530fac31f9.jpeg) Zigbee Thermostat ![Screenshot_20260924_111117_Homey](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/5/e/5ef2a135a4d72f71333c4835f1b2ed0192d7a438.jpeg) ---
**Author:** ![Jeppe\_Ladefoged](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/jeppe_ladefoged/32/113852_2.png) [@Jeppe\_Ladefoged](https://community.homey.app/u/Jeppe_Ladefoged)\ **Post date:** [September 24, 2026, 12:48pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/431 "2026-09-24T12:48:25Z")
Thanks so much for a great app! I recently added my Air Condition to the app but numeric mode/fan speed enums are not read or written (v1.0.237) My AC runs on protocol 3.5 and has a stable connection with Homey and Tuya IOS app. It doesn’t answer status requests but receives all data. “Temperature” changes and “Power” toggle works via Homey. DP 4 “mode”: Auto=“0”, Cool=“1”, Dry=“2”, Fan=“3”, Heat=“4”. DP Debug shows DP 4 change when I switch modes in the Tuya app, but the Homey mode picker doesn’t follow. Changing the mode in Homey sends nothing to the AC, and there’s no log entry at all. Entering 1,4,0,2,3 in Mode under device settings gives “cannot restrict options… current value ‘auto’ is not in that list”. Could the AC driver support a value mapping for mode (e.g. cool=1,heat=4,auto=0,dry=2,fan=3)? The same probably applies to fan speed (DP 5 is also a numeric enum). Support bundle and cloud lookup output attached. ```json Air Conditioner DP 1 switch Boolean false {} DP 2 temp_set Integer 2300 1600–3100 step 50 ℃ DP 3 temp_current value 2470 -10000–10000 step 50 ℃ DP 4 mode enum 0 DP 5 fan_speed_enum enum 0 DP 7 auto bool true DP 8 eco bool false DP 9 drying bool false DP 12 heat Boolean false {} DP 13 light Boolean true {} DP 16 beep Boolean true {} DP 24 temp_set_f Integer 73 61–88 step 1 ℉ DP 26 health Boolean false {} DP 27 cleaning Boolean false {} DP 31 gear_vertical enum 8 DP 34 gear_horizontal enum 8 DP 39 fresh_air_valve bool false {} DP 40 supply_fan_speed enum 0 DP 101 temperature_type bool false DP 102 eight_add_hot bool false DP 103 heat_status bool false DP 104 high_temperature_wind bool false DP 105 cool_feel_wind bool false DP 106 new_wind_auto_switch bool false DP 107 weektimer1 string DP 108 freshair_status bool false DP 109 weektimer2 string DP 110 filter_block_status bool false DP 111 ai_eco_switch bool false DP 112 access_card_insert bool false DP 113 upper_tem_limit value 3100 DP 114 lower_tem_limit value 1600 DP 115 wind_speed_percentage value 0 DP 116 ure value 1400 DP 117 external_unit_fanspeed value 720 DP 118 outdoor_fan_tarspeed value 0 DP 119 compressor_frequency value 42 DP 120 outdoor_comptar_freqrun value 42 DP 121 outdoor_comptar_freqset value 0 DP 122 outdoor_eevtar_opendegree value 0 DP 123 soft_wind enum 0 DP 124 ai_eco_status enum 0 DP 125 regular_reporting enum 1 DP 126 sleep_enum enum 0 DP 127 electricity value 0 DP 128 electricity_starttime value 1790253854 DP 129 electricity_endtime value 1790253974 DP 130 clearele_starttime value 0 DP 131 clearele_endtime value 0 DP 132 generator_mode enum 0 DP 133 capabilities raw FAMHCAkLDA0VFxwfISIjJCcoKSox DP 134 error_code raw AA== DP 135 light_sense bool false DP 136 specialtimer string DP 137 vertical_wind enum 0 DP 138 horizontal_wind enum 0 DP 139 wakeup_word enum 0 DP 140 wakeup_status enum 0 DP 141 volume value 10 DP 142 voice_switch bool false DP 143 voice_status enum 0 DP 144 examine_mode bool false DP 145 stores_mode bool false DP 146 sound_location enum 0 DP 147 smart_windmode enum 0 DP 148 mic_distance value 0 DP 149 filter_blocknotify bool false DP 150 max_volume value 1 DP 151 auto_gen_mode enum 0 DP 152 power_source enum 0 DP 153 ble_module_status enum 0 DP 154 ble_module_mac string DP 155 newwind_super bool false DP 156 light_senser_status bool false DP 157 anti_directblow bool false DP 158 widearea_wind bool false DP 159 encircle_wind bool false DP 160 zone_wind bool false DP 161 left_ht_direction enum 0 DP 162 right_ht_direction enum 0 DP 163 wind3d_switch bool false DP 164 wind3d_type enum 0 DP 165 solar_power value 0 DP 166 grid_power value 0 DP 167 solar_electricity value 0 DP 168 solar_state enum 0 DP 169 openadr_eventlist string DP 170 openadr_switch bool false DP 171 openadr_status bool false DP 172 openadr_request enum 0 DP 173 fireplace_sw bool false DP 174 lowheat_sw bool false DP 175 lowheat_tempc value 800 DP 176 lowheat_tempf value 46 DP 194 voice_welcome_play_switch bool false DP 195 virtual_ai_time value 0 DP 196 virtual_ai_save value 0 DP 197 voice_language string DP 198 virtual_period value 120 DP 199 virtual_electricity value 0 DP — mode_auto Boolean true {} DP — mode_eco Boolean false {} DP — mode_dry Boolean false {} ``` **Tuya Local 1.0.237 — support bundle (1 device)** > **Support bundle** > > ```auto > Tuya Local v1.0.237 — support bundle > Generated: 2026-09-24T12:40:21.260Z > App started: 2026-09-24T06:16:49.896Z (running 6h 23m) > Homey: 13.5.0 > Cloud lookup: configured (eu) — account listing not attempted since the app started > ======================================================================== > > DEVICE Air Conditioner > driver air_conditioner > model T-plus-Audio (product nn2ooaacswz6uyi0) > device id bf7712… > available yes > protocol configured 3.5, connected 3.5 ip 192.168.0.181 > status Connected · last seen 9/24/26, 2:40:18 PM · poll 30s > history 2 connections since app start · up 6h 23m total · avg 3h 11m · longest 6h 20m > packets 1195 received · 0.05/s while connected · data ever received: yes > DP mapping > dp_anion 0 > dp_child_lock 7 > dp_countdown_left 0 > dp_countdown_timer 0 > dp_current_temp 3 > dp_eco 8 > dp_fan_speed 5 > dp_fault 20 > dp_mode 4 > dp_onoff 1 > dp_sleep 9 > dp_swing 8 > dp_swing_h 0 > dp_target_temp 2 > other settings > alarm_grace_seconds 30 > command_gap_ms 100 > fan_speed_values "2,auto,low,medium,high,turbo" > fire_and_forget true > lock_protocol true > mode_values "cool,heat,auto,dry,fan" > offline_grace_seconds 60 > reconnect_interval 0 > swing_values "off,on" > temp_divisor 100 > temp_max 31 > temp_min 16 > temp_step 1 > live DPs (updated 2026-09-24T12:40:17.251Z) > DP 1 false boolean > DP 2 2300 number > DP 3 2470 number > DP 4 "0" string > DP 5 "0" string > DP 7 true boolean > DP 8 false boolean > DP 9 false boolean > DP 13 true boolean > DP 16 true boolean > DP 24 73 number > DP 26 false boolean > DP 27 false boolean > DP 31 "8" string > DP 34 "8" string > DP 101 false boolean > DP 102 false boolean > DP 103 false boolean > DP 104 false boolean > DP 105 false boolean > DP 111 false boolean > DP 113 3100 number > DP 114 1600 number > DP 116 1400 number > DP 117 720 number > DP 118 0 number > DP 119 42 number > DP 120 42 number > DP 121 0 number > DP 122 0 number > DP 123 "0" string > DP 124 "0" string > DP 125 "1" string > DP 126 "0" string > DP 127 0 number > DP 128 1790253494 number > DP 129 1790253614 number > DP 132 "0" string > DP 137 "0" string > DP 138 "0" string > cloud spec code / dp / type / value / range > switch 1 Boolean null > temp_set 2 Integer null 1600-3100 ℃ > temp_current 3 value null -10000-10000 ℃ > mode 4 enum null > fan_speed_enum 5 enum null > auto 7 bool null > eco 8 bool null > drying 9 bool null > heat 12 Boolean null > light 13 Boolean null > beep 16 Boolean null > temp_set_f 24 Integer null 61-88 ℉ > health 26 Boolean null > cleaning 27 Boolean null > gear_vertical 31 enum null > gear_horizontal 34 enum null > fresh_air_valve 39 bool null > supply_fan_speed 40 enum null > temperature_type 101 bool null > eight_add_hot 102 bool null > heat_status 103 bool null > high_temperature_wind 104 bool null > cool_feel_wind 105 bool null > new_wind_auto_switch 106 bool null > weektimer1 107 string null > freshair_status 108 bool null > weektimer2 109 string null > filter_block_status 110 bool null > ai_eco_switch 111 bool null > access_card_insert 112 bool null > upper_tem_limit 113 value null > lower_tem_limit 114 value null > wind_speed_percentage 115 value null > ure 116 value null > external_unit_fanspeed 117 value null > outdoor_fan_tarspeed 118 value null > compressor_frequency 119 value null > outdoor_comptar_freqrun 120 value null > outdoor_comptar_freqset 121 value null > outdoor_eevtar_opendegree 122 value null > soft_wind 123 enum null > ai_eco_status 124 enum null > regular_reporting 125 enum null > sleep_enum 126 enum null > electricity 127 value null > electricity_starttime 128 value null > electricity_endtime 129 value null > clearele_starttime 130 value null > clearele_endtime 131 value null > generator_mode 132 enum null > capabilities 133 raw null > error_code 134 raw null > light_sense 135 bool null > specialtimer 136 string null > vertical_wind 137 enum null > horizontal_wind 138 enum null > wakeup_word 139 enum null > wakeup_status 140 enum null > volume 141 value null > voice_switch 142 bool null > voice_status 143 enum null > examine_mode 144 bool null > stores_mode 145 bool null > sound_location 146 enum null > smart_windmode 147 enum null > mic_distance 148 value null > filter_blocknotify 149 bool null > max_volume 150 value null > auto_gen_mode 151 enum null > power_source 152 enum null > ble_module_status 153 enum null > ble_module_mac 154 string null > newwind_super 155 bool null > light_senser_status 156 bool null > anti_directblow 157 bool null > widearea_wind 158 bool null > encircle_wind 159 bool null > zone_wind 160 bool null > left_ht_direction 161 enum null > right_ht_direction 162 enum null > wind3d_switch 163 bool null > wind3d_type 164 enum null > solar_power 165 value null > grid_power 166 value null > solar_electricity 167 value null > solar_state 168 enum null > openadr_eventlist 169 string null > openadr_switch 170 bool null > openadr_status 171 bool null > openadr_request 172 enum null > fireplace_sw 173 bool null > lowheat_sw 174 bool null > lowheat_tempc 175 value null > lowheat_tempf 176 value null > voice_welcome_play_switch 194 bool null > virtual_ai_time 195 value null > virtual_ai_save 196 value null > voice_language 197 string null > virtual_period 198 value null > virtual_electricity 199 value null > mode_auto undefined Boolean null > mode_eco undefined Boolean null > mode_dry undefined Boolean null > ------------------------------------------------------------------------ > > LOG — warnings, errors and connection events, newest first > 35 of 35 distinct messages from 123 of 500 entries. Repeats are folded into one line. The device sections above carry the DP mapping and the live values — please include them when quoting this report. > 2026-09-24T12:37:13.134Z [WARN] [Air Conditioner] Disconnected: socket closed (up 6h 20m, 1182 packets) > 2026-09-24T12:37:11.133Z [WARN] [Air Conditioner] Ignoring malformed packet from device: The value of "offset" is out of range. It must be >= 0 and <= 6. Received 8 > 2026-09-23T20:20:48.734Z [WARN] [Air Conditioner] 5 failures — trying protocol 3.3 (configured: 3.4) > 2026-09-23T20:17:35.426Z [WARN] [Air Conditioner] Disconnected: socket closed (up 1s, no data received) > 2026-09-23T20:17:56.118Z [WARN] [Air Conditioner] Status request failed: Timeout waiting for status response from device id: bf7712e--------- ×5 — 20:17:29, 20:17:34, 20:17:41, 20:17:44, 20:17:56 > 2026-09-23T20:17:00.058Z [WARN] [Air Conditioner] Connected and answering keep-alives, but 2 status requests in a row went unanswered and no data has ever arrived on this connection. That combination points at the Local Key or the Device ID, not at the protocol: a keep-alive needs neither, a status request needs both, so a device that answers the first and drops the second is receiving something it cannot decrypt. Re-copy both from the Tuya IoT platform — the Local Key changes every time the device is re-added in the Smart Life app. With cloud credentials saved, Settings → Fix It → Check local keys makes that comparison for every device in one press. > 2026-09-23T20:16:43.558Z [WARN] [Air Conditioner] Disconnected: Error from socket: read ECONNRESET (up 748ms, no data received) > 2026-09-23T20:16:43.557Z [ERROR] [Air Conditioner] Error from socket: read ECONNRESET — the device closed the connection without us having sent it anything, so the protocol version cannot be the cause on 3.3: nothing is written on connect below 3.4. A device that drops an idle connection this fast usually has its single local connection slot taken — these accept exactly one. Check the Tuya or Smart Life app, another integration, and whether a second device in this app points at the same address. > 2026-09-23T20:21:53.830Z [WARN] [Air Conditioner] Disconnected: socket closed (up 2s, no data received) ×11 since 2026-09-23T20:16:39.370Z > 2026-09-23T20:19:52.338Z [WARN] [Air Conditioner] Connection failed: Handshake timed out after 15s — the device accepted the connection but never completed the key exchange, which usually means it does not speak the protocol version being tried. The app rotates through the others on its own; if it settles on one that works, the log says so and that version belongs in the device settings. ×7 since 2026-09-23T20:16:03.128Z > 2026-09-23T19:49:25.984Z [WARN] [Air Conditioner] ac_mode: cannot restrict options to [1, 4, 0, 2, 3] — current value "auto" is not in that list. Update the device to a supported value first, or include "auto" in the setting. > 2026-09-23T19:45:43.617Z [WARN] [Air Conditioner] ac_mode: cannot restrict options to [1, 4, 0, 2, 3] — current value "cool" is not in that list. Update the device to a supported value first, or include "cool" in the setting. > 2026-09-23T13:32:48.825Z [WARN] [Air Conditioner] Disconnected: socket closed (up 50s, 7 packets) > 2026-09-23T13:31:55.453Z [WARN] [Air Conditioner] Disconnected: socket closed (up 2m 42s, 18 packets) > 2026-09-24T12:37:15.710Z [INFO] [Air Conditioner] Connected ×27 since 2026-09-23T13:29:12.986Z > 2026-09-23T12:39:03.036Z [ERROR] [Cloud] Device list failed: No devices found (assoc: No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ; S2/uid=bay17901: No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ; S3/smartlife: No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ; S3/tuyaSmart: No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ; schema: No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ; v2: No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ; s6: No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ; s7: uri path invalid) ×3 — 12:13:16, 12:15:07, 12:39:03 > 2026-09-23T12:39:03.036Z [ERROR] [Cloud] All strategies failed — assoc: No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ; S2/uid=bay17901: No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ; S3/smartlife: No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ; S3/tuyaSmart: No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ; schema: No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ; v2: No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ; s6: No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ; s7: uri path invalid ×3 — 12:13:16, 12:15:07, 12:39:03 > 2026-09-23T12:39:03.005Z [WARN] [Cloud] S6: p1 failed — code=28841107 msg=No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ×3 — 12:13:16, 12:15:07, 12:39:03 > 2026-09-23T12:39:02.957Z [WARN] [Cloud] S5: p1 failed — code=28841107 msg=No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ×3 — 12:13:16, 12:15:07, 12:39:02 > 2026-09-23T12:39:02.911Z [WARN] [Cloud] S4: /v1.0/devices failed — code=28841107 msg=No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ×3 — 12:13:16, 12:15:07, 12:39:02 > 2026-09-23T12:39:02.864Z [WARN] [Cloud] S3 legacy: /users/bay17901/devices failed — code=28841107 msg=No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ×3 — 12:13:16, 12:15:07, 12:39:02 > 2026-09-23T12:39:02.738Z [WARN] [Cloud] S3/tuyaSmart: failed — code=28841107 msg=No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ×3 — 12:13:16, 12:15:07, 12:39:02 > 2026-09-23T12:39:02.681Z [WARN] [Cloud] S3/smartlife: failed — code=28841107 msg=No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ×3 — 12:13:16, 12:15:07, 12:39:02 > 2026-09-23T12:39:02.368Z [WARN] [Cloud] S2/uid=bay17901: failed — code=28841107 msg=No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ×3 — 12:13:16, 12:15:06, 12:39:02 > 2026-09-23T12:39:02.316Z [WARN] [Cloud] S1: iot-01/associated-users failed — code=28841107 msg=No permission. The data center is suspended.Please go to the cloud development platform to enable the data center. ×3 — 12:13:16, 12:15:06, 12:39:02 > 2026-09-23T12:51:23.978Z [ERROR] [Cloud] Device list failed: No devices found (S2/uid=bay17901: permission deny; S3/smartlife: permission deny; S3/tuyaSmart: permission deny; schema: permission deny; s6: device_ids param is illegal, please check it; s7: uri path invalid) ×3 — 11:33:00, 11:37:06, 12:51:23 > 2026-09-23T12:51:23.978Z [ERROR] [Cloud] All strategies failed — S2/uid=bay17901: permission deny; S3/smartlife: permission deny; S3/tuyaSmart: permission deny; schema: permission deny; s6: device_ids param is illegal, please check it; s7: uri path invalid ×3 — 11:33:00, 11:37:06, 12:51:23 > 2026-09-23T12:51:23.978Z [WARN] [Cloud] S7: p1 failed — code=1108 msg=uri path invalid ×6 — 11:33:00, 11:37:06, 12:13:16, 12:15:07, 12:39:03, 12:51:23 > 2026-09-23T12:51:23.944Z [WARN] [Cloud] S6: p1 failed — code=1109 msg=device_ids param is illegal, please check it ×3 — 11:33:00, 11:37:06, 12:51:23 > 2026-09-23T12:51:23.587Z [WARN] [Cloud] S4: /v1.0/devices failed — code=1106 msg=permission deny ×3 — 11:33:00, 11:37:06, 12:51:23 > 2026-09-23T12:51:23.518Z [WARN] [Cloud] S3 legacy: /users/bay17901/devices failed — code=1106 msg=permission deny ×3 — 11:33:00, 11:37:06, 12:51:23 > 2026-09-23T12:51:22.470Z [WARN] [Cloud] S3/tuyaSmart: failed — code=1106 msg=permission deny ×3 — 11:32:59, 11:37:05, 12:51:22 > 2026-09-23T12:51:22.343Z [WARN] [Cloud] S3/smartlife: failed — code=1106 msg=permission deny ×3 — 11:32:59, 11:37:05, 12:51:22 > 2026-09-23T12:51:22.088Z [WARN] [Cloud] S2/uid=bay17901: failed — code=1106 msg=permission deny ×3 — 11:32:59, 11:37:05, 12:51:22 > 2026-09-23T11:32:30.263Z [ERROR] [Cloud] Token failed: sign invalid ×2 — 11:31:28, 11:32:30 > > ``` ---
**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:** [September 24, 2026, 4:06pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/432 "2026-09-24T16:06:03Z")
Hi Dietrich, First, update to 1.0.241 ([Tuya Local | Homey](https://homey.app/a/com.tuyalocal/test/)). Until then the Bridge’s own list still shows the thermostats’ data points mixed into its own, which makes the picture confusing to read. Then one experiment, and it’s the only thing I need from you right now. Take one thermostat at a time, change its target temperature by two or three degrees, wait a moment, then open DP Debug → Bridge with Auto-refresh on and look at that sub-device’s section. Tell me which number moved and to what. - On the Zigbee one I expect DP 2 to follow (it reads 60 now, so 6.0 °C — set it to 8 and it should read 80). - On the Bluetooth one my guess is DP 16 (it reads 220, which would be 22.0 °C). That one really is a guess from a single reading, which is exactly the kind of thing that has misled me twice recently — so it’s worth two minutes to check rather than assume. That gives me both layouts, and it also confirms which identifier belongs to which thermostat. What happens after that is on my side, and it’s the harder half. Reading them is solved. Sending a command to a sub-device is a different matter: the library I use can address one, but its request looks different from the implementation that’s known to work elsewhere, and I have no such gateway here to test against. So that part will take a while and I won’t promise a date. Nothing else needed in the meantime — the map is the useful thing right now. Kind regards, Andi ---
**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:** [September 24, 2026, 4:17pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/433 "2026-09-24T16:17:46Z")
Hi Jeppe, You diagnosed it exactly right, and your error message names the cause better than I could have. That one list had to be two things at once — the choices Homey shows and the values sent to the device. On a unit that names its modes you never notice. On yours, which numbers them, the two can’t be the same list. In 1.0.242 it can carry both, written the way you proposed: [Tuya Local | Homey](https://homey.app/a/com.tuyalocal/test/) auto=0,cool=1,dry=2,fan=3,heat=4 Left is what Homey shows and what flows see, right is what goes to the AC and what it sends back. Same for Fan speed — yours looks like DP 5 with the same numbering, so something like auto=0,low=1,medium=2,high=3 once you’ve checked which number is which. A list without equals signs behaves exactly as before, so nothing else changes. Three other things in your bundle that you didn’t ask about but are worth fixing, because pairing guessed wrong: Child lock DP is 7. On your unit DP 7 is auto, not a child lock. Set it to 0. Swing DP is 8 — and so is Eco. Both point at DP 8, which is eco. Your real swing is gear\_vertical on DP 31 (currently “8”), with gear\_horizontal on DP 34 if you want the second axis. Those are numbered enums too, so the same name=value form applies. Fault DP is 20, which doesn’t exist on your device. Harmless, but set it to 0. Your actual error\_code is DP 134, raw-encoded, which the driver can’t read yet. Unrelated: your Cloud Lookup is failing with “The data center is suspended” — that’s your Tuya IoT trial having expired, not the app. Extending it is free but takes a day or two: Cloud → Cloud Services → IoT Core → View Details → Extend Trial Period. If the mode picker follows your unit after the update, I’d be glad to hear it — and if the fan speed numbering turns out different from my guess, tell me what DP 5 actually shows. Kind regards, Andi ---
**Author:** ![Sebastian\_Klas](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/sebastian_klas/32/171935_2.png) [@Sebastian\_Klas](https://community.homey.app/u/Sebastian_Klas)\ **Post date:** [September 24, 2026, 4:41pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/434 "2026-09-24T16:41:17Z")
Hi Andi, I’ve installed the new version and tested the switch-state fallback. I stopped the charger externally. Homey correctly reports the charger state as plugged\_in\_paused / PAUSE, with 0 W and 0 A, but the Homey on/off switch still remains ON. So DP109 → PAUSE is definitely reaching Homey correctly, but it doesn’t seem to update the switch state to OFF yet. Current Homey state after stopping: evcharger\_charging: true evcharger\_charging\_state: plugged\_in\_paused measure\_power: 0 W measure\_current: 0 A The charger itself is stopped correctly; only the Homey switch remains active. ---
**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:** [September 24, 2026, 8:14pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/435 "2026-09-24T20:14:56Z")
Hi Sebastian, You found a bug in the fix, and a clean one — thank you for testing it properly rather than assuming it worked. The fallback was meant to stand down once the switch data point starts reporting itself. But I checked whether that number had ever arrived in a packet — and a device echoing back the command Homey just sent is a packet. So the first time you pressed the switch in Homey, you switched the fallback off permanently. Exactly the case it was built for. That’s why everything else looked right: DP 109 reaching Homey, the state going to plugged\_in\_paused, 0 W and 0 A. All of that was working. Only the one check in the middle was asking the wrong question. It now stands down when the switch point reports a value of its own, which the app can already tell apart — an echo of our own command is filtered out before that point in the code, so anything that gets through is a genuine report. My test had the same blind spot, which is why it went out broken: it started from a device that had never been switched from Homey. It now starts from yours — the number already seen — and requires the fallback to work anyway. In 1.0.243. Please try the same test again: stop the charger externally, and the switch should follow within a second or two. If it doesn’t, tell me and I’ll stop guessing and ask for a support bundle instead. Kind regards, Andi ---
**Author:** ![Dietrich\_Kassner](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/dietrich_kassner/32/176924_2.png) [@Dietrich\_Kassner](https://community.homey.app/u/Dietrich_Kassner)\ **Post date:** [September 24, 2026, 8:18pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/436 "2026-09-24T20:18:31Z")
Hello Andi, Zigbee: DP2 = 225 → temperatur set to 22.5°C DP3 = 230 → actual temperatur is 23°C DP4 = manual / auto / freeze → modus DP20 = true / false → automatic test valve DP7 = true / false → child lock DP18 = true / false → window open recognition DP17 = open / close → window state Bluetooth: I don’t get any values for the second device anymore. ---
**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:** [September 24, 2026, 8:34pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/437 "2026-09-24T20:34:32Z")
Hi Dietrich, The Zigbee map is confirmed exactly as you read it — DP 2 target and DP 3 measured, both in tenths, DP 4 the mode, 7 child lock, 17 and 18 the window, 20 the valve test. One thing your device told us that its own Tuya specification does not: the mode has a third value, freeze. The specification lists only auto and manual. That’s the kind of thing only an actual device can settle. The Bluetooth one didn’t stop — I lost it. The sub-device list was only held in memory, so updating the app emptied it, and it refills only as each sub-device speaks up again. A radiator thermostat can stay quiet for half an hour. Worse, I had told you that an empty section means the gateway keeps its sub-devices to itself. That’s only true if nothing else can empty the list — and something could: me. Sorry for sending you down that path. Fixed in 1.0.244. The list is kept across restarts now, and each entry shows a date rather than just a clock time once its last report isn’t from today, so a sleeping device no longer reads like a waking one. After the update your Bluetooth thermostat should simply be back, with nothing to do on your side. If it’s still missing an hour or two after that, then it really has gone quiet — and that’s a separate question worth looking at, since it was reporting fine before. Kind regards, Andi ---
**Author:** ![Dietrich\_Kassner](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/dietrich_kassner/32/176924_2.png) [@Dietrich\_Kassner](https://community.homey.app/u/Dietrich_Kassner)\ **Post date:** [September 24, 2026, 9:38pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/438 "2026-09-24T21:38:49Z")
Hi Andi, I updated the app. But since then the DP debug shows a change of the zigbee temperatur setting emidiatly but not the actual temperatur. Ok, a bit later the actual temperatur is there. It shows no values for the Bluetooth device. Ok, it took a long time until it shows values for the Bluetooth device. But now I have some: DP2 = auto / manual / holidayready → modus DP16 = 230 → temperatur set to 23°C DP24 = 225 → actual temperatur is 22.5°C DP101 = 300 / 0 → fast heating on / off ---
**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:** [September 24, 2026, 10:18pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/439 "2026-09-24T22:18:00Z")
Fixed properly in the next version: what has once been seen stays, and a later report only updates its own entry. ---
**Author:** ![Sebastian\_Klas](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/sebastian_klas/32/171935_2.png) [@Sebastian\_Klas](https://community.homey.app/u/Sebastian_Klas)\ **Post date:** [September 25, 2026, 6:08am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/440 "2026-09-25T06:08:43Z")
Hi Andi, I tested it again with v1.0.244, and unfortunately the switch still does not follow the actual charger state. The car finished charging while it was still plugged in. At that point Homey showed: - evcharger\_charging: true - evcharger\_charging\_state: plugged\_in - Power: 0 W - Current: 0 A - Session energy: 8.5 kWh So the charging switch remained ON even though charging had already finished. This morning the car was physically unplugged from the wallbox. I checked Homey again immediately afterwards and got: - evcharger\_charging: true - evcharger\_charging\_state: plugged\_out - Power: 0 W - Current: 0 A - Voltage: 234 V So Homey correctly detects that the vehicle is now unplugged (plugged\_out), but the charging switch still remains ON (evcharger\_charging: true). This seems to be a very clear case: the charger state itself is reaching Homey correctly, but the switch capability is not being updated to false. I can send you a support bundle from this state if that helps. Kind regards, Sebastian ---
**Author:** ![Jeppe\_Ladefoged](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/jeppe_ladefoged/32/113852_2.png) [@Jeppe\_Ladefoged](https://community.homey.app/u/Jeppe_Ladefoged)\ **Post date:** [September 25, 2026, 9:19am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/441 "2026-09-25T09:19:22Z")
Hi @Andi Thanks so much for the suggestions. I’ve installed 1.0.245 and made the corrections you suggested (thanks) I have Homey working in Sync with Tuya and vice versa. I’m still seeing the DP-numbers for “Mode” and “Fan speed” not the text strings. Am setting it up wrong? **Device settings** ![SCR-20260925-kjqp](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/4/0/40be382b7cf07959a8167c2161421351631e82c6.png) **Device modes/fan speed** ![SCR-20260925-kdhi](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/3/b/3b699d311785bb5ee4d9d230913f2f895738db24.jpeg) ![SCR-20260925-kdjd](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/8/3/8385de7671c6a5268b1eb5957332f6f6f0ea7847.jpeg) Also I did some messing about in DP debug and noted the following if that helps you. Happy to do some more testing if you need any help. Names noted in parenthesis are the actual titel/label in the Tuya IOS app: **Modes (DP4)** auto=0 cool=1 dry=2 fan=3 heat=4 **Fan speed (DP5)** auto=0 (auto) note: dp=7 changes to true when auto is selected. False in any other fan speed setting mute=1 (mute) low=2 (low wind) medium=3 (mid low wind) normal=4 (mid wind) strong=5 (mid high wind) high=6 (high wind) turbo=7 (strong wind) **Misc** dp=13 (Light) note: turns on/off the number display on the indoor A/C unit. False = off dp=16 (Beep) note: turns on/off the beep when changing settings on the indoor A/C unit. False = off dp=111 (Eco mode) note: false = off **Sleep (DP126)** standard=1 (Standard) elderly=2 (The aged) child=3 (Child) ---
**Author:** ![Sebastian\_Klas](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/sebastian_klas/32/171935_2.png) [@Sebastian\_Klas](https://community.homey.app/u/Sebastian_Klas)\ **Post date:** [September 25, 2026, 5:02pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/442 "2026-09-25T17:02:39Z")
Hi Andi, I noticed another issue with the energy values and compared Homey directly with the original Tuya charger app. The current live/session value actually seems to be correct: Tuya app currently shows: - Duration: 02:37:03 - Charged: 8.7 kWh - Current: 0.0 A - Power: 0.0 kW - Status: Ready to charge Homey also shows: - charge\_session\_energy: 8.7 kWh So Homey appears to be receiving the current 8.7 kWh session value correctly. However, there are two things that don’t match: 1. The Tuya charging history shows the completed charge from 24 September as: - 17:34–20:04 - 2h30m - 8.0 kWh But the charger’s live screen still shows 02:37:03 and 8.7 kWh. So it looks like the charger exposes a live/session counter separately from the final charge-history record. 1. More importantly, Homey’s meter\_power.charged currently shows 148.901 kWh. The original Tuya charging history shows: - 110 charging sessions - 1391.1 kWh total So 148.901 kWh clearly does not appear to represent the charger’s actual lifetime/total charged energy. Could meter\_power.charged currently be mapped to the wrong DP or have the wrong scaling? I have screenshots from the original Tuya app showing both the 1391.1 kWh total history and the 8.7 kWh live/session value if you need them. Kind regards, Sebastian ![IMG_1570](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/8/c/8ca94723634ce1b8b247ee0f71b8575bc2d5d887.jpeg) ![IMG_1569](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/c/3/c34e1facb95e44534485f02d303dfa63c51b070c.jpeg) ---
**Author:** ![Jeppe\_Ladefoged](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/jeppe_ladefoged/32/113852_2.png) [@Jeppe\_Ladefoged](https://community.homey.app/u/Jeppe_Ladefoged)\ **Post date:** [September 25, 2026, 5:34pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/444 "2026-09-25T17:34:20Z")
Was testing a bit further and found this: **v1.0.245: value mapping only works outgoing** With `auto=0,cool=1,dry=2,fan=3,heat=4`, setting the mode from Homey works, but incoming changes (Tuya app, IR remote) are dropped. DP Debug shows DP 4 updating, but the capability doesn’t. With plain values `0,1,2,3,4`, both directions work. Suspect the reverse lookup compares the device’s string `"4"` against a numeric `4`. Same for fan speed (DP 5). ---
**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:** [September 25, 2026, 8:51pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/445 "2026-09-25T20:51:40Z")
Hi Sebastian, The switch: not a malfunction, but my design — and you’ve shown it’s the wrong one. “Plugged in, idle” counted as on because the charger does stand ready, and unplugged left the switch alone because that says nothing about whether the charger is enabled. Both defensible on paper, both wrong on your device. The premise was unsound anyway: on a charger whose switch data point only takes commands, there is no source at all for “is it enabled”. I had the switch showing something the app cannot know. Whether it’s charging, it can know — so that’s what it shows now. WORKING on; PAUSE, IDLEINS, IDLE and SLEEP all off. Both of your cases come out right. meter\_power.charged is not mis-mapped. It is the app’s own counter, accumulated since you paired the device — 148.9 kWh is simply how much it has watched go through. Your charger’s real lifetime figure of 1391.1 kWh over 110 sessions exists only in Tuya’s cloud; there is no local data point carrying it. We established that back when the support bundle first came in, and nothing since has turned one up. So the two numbers are not supposed to agree, and no scaling change will make them. If that’s not the number you want on the tile, the honest options are to leave it as “since Homey started counting” or to ignore it. I’d rather not fabricate a total by seeding it from a screenshot. Your point about the live counter is a useful confirmation, by the way: 8.7 kWh and 02:37:03 on the live screen against 8.0 kWh and 2h30m in the history for the same charge. Those really are two different things in the firmware, which is exactly why the app reads them from two separate settings. ---
**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:** [September 25, 2026, 8:51pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/446 "2026-09-25T20:51:54Z")
Hi Jeppe, Both of your symptoms have one cause, and it’s mine. You had the device’s own values in the setting before, so the mode capability was sitting on a raw “4”. When you switched to auto=0,…,heat=4, “4” is no longer in the list — the list now holds names — so the guard that stops a list from excluding the current value refused the change, and the old picker stayed. Everything else follows from that. The picker kept showing numbers because its options were never replaced. And incoming changes were dropped because the driver was now correctly translating “4” to “heat” and writing it into a picker that had never heard of heat. Your string-versus-number theory was a reasonable guess but lands next to it — the comparison was fine; the list of allowed values wasn’t. A current value that turns out to be a device value is now carried across to its name, with a line in the log saying so, and both directions work from the moment you save. Your data point table is genuinely valuable — thank you. The fan speed names in particular (auto=0,mute=1,low=2,medium=3,normal=4,strong=5,high=6,turbo=7) are exactly what someone with the same unit will need, and I’d rather have your labels than invent my own. Two notes on the others: Eco: set Eco DP to 111. That one works today. Sleep: the driver expects a boolean there, and yours is a three-value enum (standard / elderly / child). Setting Sleep DP to 126 would leave it permanently on. Better left at 0 until I give it proper values. Light (13) and Beep (16) have no settings in this driver yet. Worth adding — they’re simple booleans, and I’ll note them. If you’re still up for testing: after the update, confirm that changing the mode on the IR remote moves the Homey tile. That’s the direction that was broken. ---
**Author:** ![Jeppe\_Ladefoged](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/jeppe_ladefoged/32/113852_2.png) [@Jeppe\_Ladefoged](https://community.homey.app/u/Jeppe_Ladefoged)\ **Post date:** [September 26, 2026, 11:12am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/447 "2026-09-26T11:12:02Z")
Hi Andi, Perfect! Thanks so much for the fix and suggestions once again! I can confirm that bi-directional mode/fan speed is working as expected in v1.0.246. Homey input and remote input stays in sync and names for mode/fan setting are shown. Let me know if there is anything else you need. Just a note: (and I completely understand if this is out of the scope of your app!) When bridging the Air Condition with Homekitty to Apple Home. Mode is “stuck” at Auto and only temp change seems to work. If you want I’m happy to do some testing on that side. Here’s a short screen capture: [ScreenRecording\_09-26-2026 13-03-17\_1](https://www.icloud.com/iclouddrive/086sAStIKyIN_zPHUdINx-mmw) For now I have set up the AC as an Advanced Virtual Device to bridge to Apple Home which is working fine. I would be nice however to just bridge your Tuya Local device. Any way thanks again for you suggestion and work, let me know if you need anything. [Previous page](https://community.homey.app/t/app-pro-tuya-local/154077.md?page=21) [Next page](https://community.homey.app/t/app-pro-tuya-local/154077.md?page=23)