That’s how Stephen fixed an issue with the Data Center location:
Damnit, I spend days to get it working, without success.
Now I have created a new smartlife account and added one spare light for testing.
Went back to the iot site logged on with my account I created weeks ago.
Deleted all projects (they where empty)
Created a new project (Central Europe Data Center)
linked my app
Now i see my device
And all of this in less then 20 minutes…
Then linked the iot in the conficuration of Tuya local
searched the local IP-address (i reserved the IP-address in my DHCP table)
Added a new device, filled in th IP-address and let the app search for the diviceID and LocalKey.
In short it works… thanks for the golden tip 
Tomorrow ill try if my main account is also connectable (i don’t think so), if not, i have a a lot of devices to migrate from one account to the new account
Hi Andi
I have two devices (currently running as “generic”, since some DPs are missing in the “driver ones”
1. Ceiling Vent with Light
-
Model: Lucande Smart LED Deckenventilator
-
Remarks: I’m using mostly the fan speed, light, brightness, mode. Not all are covered.
DP Configuration (JSON)
[
{ “dp”: 1, “cap”: “onoff”, “label”: “Ventilator”, “settable”: true },
{ “dp”: 2, “cap”: “generic_picker_1”, “label”: “Modus”, “settable”: true, “options”: “normal,sleep,nature”, “labels”: “Normal,Sleep,Nature” },
{ “dp”: 3, “cap”: “generic_number_1”, “label”: “Geschwindigkeitsstufe”, “settable”: true, “scale”: 0, “min”: 1, “max”: 6, “step”: 1 },
{ “dp”: 8, “cap”: “generic_picker_2”, “label”: “Fan direction”, “settable”: true, “options”: “forward,reverse”, “labels”: “vorwärts, rückwärts” },
{ “dp”: 15, “cap”: “generic_switch_1”, “label”: “Licht”, “settable”: true },
{ “dp”: 16, “cap”: “dim”, “label”: “Helligkeit”, “settable”: true, “scale”: 0, “min”: 0, “max”: 100, “step”: 1 },
{ “dp”: 17, “cap”: “generic_number_2”, “label”: “Farbtemperatur”, “settable”: true, “scale”: 0, “min”: 0, “max”: 100, “step”: 1 },
{ “dp”: 22, “cap”: “generic_picker_3”, “label”: “Timer”, “settable”: true, “options”: “cancel,1h,2h,4h,8h”, “labels”: “cancel,1h,2h,4h,8h” }
]
DP Table (Tuya Raw Specs):
DP 1 switch Boolean false {}
DP 2 mode Enum normal normal, sleep, nature
DP 3 fan_speed Enum 6 1, 2, 3, 4, 5, 6
DP 8 fan_direction Enum forward forward, reverse
DP 15 light Boolean false {}
DP 16 bright_value Integer 44 0–100 step 1
DP 17 temp_value Integer 0 0–100 step 1
DP 22 countdown_set Enum off cancel, 1h, 2h, 4h, 8h
2. Dehumidifier
-
Model: Klarstein Dryfy Connect 50l
-
Remarks: Until now i used a shelly plug and the “auto” mode. FINALLY thx to you i can integrate the klarstein better!
DP Configuration (JSON):
[
{“dp”: 1, “cap”: “onoff”, “label”: “Power”, “settable”: true},
{“dp”: 2, “cap”: “generic_picker_1”, “label”: “Modus”, “settable”: true, “options”: “0,1”, “labels”: “Auto, Kontinuierlich”},
{“dp”: 3, “cap”: “measure_humidity”, “label”: “Luftfeuchtigkeit IST”, “settable”: false, “scale”: 0},
{“dp”: 4, “cap”: “generic_number_1”, “label”: “Ziel-Luftfeuchtigkeit”, “settable”: true, “scale”: 0, “unit”: “%”, “min”: 30, “max”: 80, “step”: 5},
{“dp”: 6, “cap”: “generic_picker_2”, “label”: “Lüfterstufe”, “settable”: true, “options”: “0,1”, “labels”: “Hoch, Niedrig”},
{“dp”: 7, “cap”: “generic_switch_1”, “label”: “Kindersicherung”, “settable”: true},
{“dp”: 8, “cap”: “generic_switch_2”, “label”: “Schwenken”, “settable”: true},
{“dp”: 11, “cap”: “generic_sensor_2”, “label”: “Tank voll”, “settable”: false, “scale”: 0},
{“dp”: 12, “cap”: “generic_picker_3”, “label”: “Timer”, “settable”: true, “options”: “0..24”, “labels”: “Aus, 1h..24h”},
{“dp”: 13, “cap”: “generic_sensor_3”, “label”: “Restzeit Timer”, “settable”: false, “scale”: 0},
{“dp”: 101, “cap”: “generic_switch_3”, “label”: “Innere Trocknung”, “settable”: true},
{“dp”: 102, “cap”: “generic_switch_4”, “label”: “Wasserpumpe”, “settable”: true}
]
DP Table (Tuya Raw Specs):
DP 1 Power bool false
DP 2 mode enum 0
DP 3 envhumid value 48
DP 4 humidity value 55
DP 5 anion Boolean false {}
DP 6 windspeed enum 0
DP 7 lock bool false
DP 8 shake bool true
DP 11 fault bitmap 0 {“label”:[“0”,“1”,“2”,“3”,“4”,“5”]}
DP 12 countdown enum 0
DP 13 countdown_left value 0 0–1440 step 1 min
DP 101 dry bool false
DP 102 pump bool false
Is there any chance for the generic ones to “send” custom commands for the DPs? e.g. set the timer to 6h (DP12 dehumidifier)? I can’t find suitable “THEN” cards or a custom function to send the known values
thx as usual!
Rick
EDIT: added information (dp table)
Hi Rick
Could you please share the DP table for those two devices (under App settings → Cloud Lookup)?
That way others can finally as well use the devices by choosing the right driver (fan and dehumidifier).
Regarding the action card - will be implemented
Andi
As usual fast as hell
I’ve added the information in the existing post. Will test them this week
Thx again!
Hi, i have managed to connect all my devices (almost all lights) and they seem to be working perfectly.
but I have 4 lights that are unavailable and they wont recover themselves (in the normal homey tuya app connection they are still available).
one light is the same as all my other lights (a simple GU10 color), i successfully tested yesterday, but now I can’t reacht it.
The other 3 lights are 3 different kind of lights (one E14 color candle, and 2 different moodlights)
Is there something I can or have to do for “special” devices?
Hi Andi
Just tested the “THEN” card → works (tested it with the ceiling fan). Now i just need another favor 
could you add a “AND” card to check for certain dp values? e.g. if xy AND “DP 8” is true/false (or number, would leave that open like the “THEN” card).
EDIT: a “DP value changed” card for a specific device would fullfill the last needed flow card. e.g. the water alarm of my dehumidifier (DP 11 changed → “tag” true/false" → alert me).
merci und schöne aabe
Rick
Hi Rick - Please try flow cards and modifications of the Dehumidifier and Fan Driver in the next TEST version: Tuya Local | Homey
Klarstein:
dp_onoff = 1
dp_mode = 2
mode_values = 0,1
dp_current_humidity = 3
dp_target_humidity = 4
dp_anion = 5 ← falls vorhanden
dp_fan_speed = 6
fan_speed_values = 0,1
dp_child_lock = 7
dp_oscillate = 8
dp_water_full = 11
dp_countdown_timer = 12
dp_countdown_timer_numeric = true ← NEU, unbedingt aktivieren
dp_countdown_left = 13
dp_countdown_left_minutes = true ← NEU, unbedingt aktivieren
dp_self_clean = 101
dp_pump = 102
Your Fan/Light:
dp_onoff = 1
dp_mode = 2
mode_values = normal,sleep,nature ← Standard ist “normal,sleep,nature,breeze,smart”
dp_speed = 3
speed_min = 1
speed_max = 6
dp_fan_speed = 0 ← bleibt deaktiviert (kein String-Enum)
dp_direction = 8
dp_light_onoff = 15
dp_light_dim = 16
dp_light_dim_min = 0
dp_light_dim_max = 100
dp_light_color_temp = 17
dp_light_color_temp_invert = false ← testen, ggf. umschalten falls warm/kalt vertauscht wirkt
dp_countdown_timer = 22
Hi Niels
If the IP address (you can reach the devices by using test-connection) and Local Key both are correct…
…try switching Protocol Version — some light modules use a newer Tuya protocol (3.4/3.5) than the standard GU10 bulbs (3.3) and play with the settings below.
And: Check the app’s Settings → Logs tab for that device’s exact error — it’ll say things like “Connection failed” or “No heartbeat received,” which tells us whether it’s a wrong IP (connection refused/timeout) or something else.
Let me know what the relevant log lines show
Salü Andi
Thx! Proposition: Why not create a own driver vor “ceiling fans” and include the light features? in my head the direction / lights is something for ceiling fans and it would be great to get some lights on/off | lights are on |… cards as well happ to help with testing (moving my devices from generic to those drivers → gonna start with the dehumidifier now. Ceiling fan i would wait until the “lights on/off” card, since i use this one outside in my garden.
thx for your help again
Adding the cards is much easier than a separate driver
Could you please check the new cards in 1.0.134
| Karte | Typ | Wirkung |
|---|---|---|
| Licht setzen | THEN | Ein/Aus |
| Licht ist an | AND/IF | Bedingung |
| Licht-Helligkeit setzen | THEN | 0–100 % |
Hi Andi,
Just tried pairing a device under the new “Ventilator” → “Lüfter” driver to test the fan/light setup we discussed.
Selected it explicitly (see screenshot: “You’re about to connect Lüfter with Homey”), but the resulting “Device found” DP-mapping screen shows the same field template as the Humidifier driver — Humidity, Target Humidity, Water Tank, Ionizer (Anion) — instead of fan-specific fields.
Missing fields I’d need to map:
- Fan direction (forward/reverse) — DP 8 on my unit
- Light on/off — DP 15
- Light brightness (0-100) — DP 16
- Light color temperature — DP 17
Current fields (Child lock, Timer, Humidity, Target Humidity, Water tank, Temperature, Ionizer) don’t cover any of these, so there’s no way to map them during pairing right now.
My device’s full DP layout for reference:
| DP | Value | Function |
|---|---|---|
| 1 | onoff | Fan power |
| 2 | normal/sleep/nature | Mode |
| 3 | 1-6 | Fan speed |
| 8 | forward/reverse | Direction |
| 15 | true/false | Light on/off |
| 16 | 0-100 | Brightness |
| 17 | 0-100 | Color temperature |
| 22 | cancel/1h/2h/4h/8h | Timer |
Looks like the “Lüfter” driver might have inherited the Humidifier template by mistake? Holding off on pairing for now to avoid losing light/direction control on my existing generic setup. Happy to test further once there’s a fix.
Thanks for all the work on this!
Could you please try it again with the newest version?
the 2 moodlights needed to be set on 3.1 protocol, now they seem to be and stay connected.
The E14 light doesn’t respond to any protocol, the strange thing is that the log says that it is connected.
But i also notice that the other tuya app also has problems keeping it steady, so maybe the light itself is broken. the light isn’t importand, ill replace it. not gonna put hours into it for 6 euros
thanks for the support
Salü Andi
Wow - works! just moved the fan from generic to the “Lüfter” Driver and the device is working.
Regarding the dehumidifier - the “Lüfter Schwenkung” is now in the “Lüfter” Driver and not in the “dehumidifier” driver I have a card in the ceiling fan now, but not in the dehumidifier.
My bad fixed now in 1.0.139
Hi,
I’ve been using Tuya Local for a while and really like it, but I recently picked up a portable EV charger (Vevor, Type 2, 16A/3.68kW single phase, Tuya modelId e1mtzkaw, product LS-AS/EU-H8) and had to shoehorn it into the Generic driver. It mostly works after a lot of trial and error, but I think this category of device (Tuya EV chargers, sold under a bunch of rebrands: Vevor, Nine, Tera, Emini, Aimiler, Ecopoint, Dowell…) is common enough now that it might be worth a dedicated driver, similar to what you did for Heat Pump. Home Assistant’s tuya-local integration already has several of these mapped (nine_ev_charger.yaml, tera_w01_evcharger.yaml, etc.) so there’s a decent reference if you want to look at how they structured it. Also worth noting, Tuya has a dedicated category code for this device class, qccdz (shows up in the app’s own device info panel) — might be a good hook to auto-suggest a dedicated driver during pairing instead of relying on people stumbling into the Generic one.
Here’s the full DP model I pulled from the Tuya Cloud API for mine, might save you some digging:
| DP | Name | R/W | Type | Details |
|---|---|---|---|---|
| 1 | forward_energy_total | ro | value | scale 2, unit kWh — lifetime total (see note below) |
| 3 | work_state | ro | enum | charger_free, charger_insert, charger_free_fault, charger_wait, charger_charging, charger_pause, charger_end, charger_fault |
| 4 | charge_cur_set | rw | value | scale 0, unit A — capped ~6-16A physically, raw cloud range is much wider |
| 6 | phase_a | ro | raw | 8 bytes big-endian: 2B voltage (x0.1V), 3B current (x0.001A), 3B power (x0.001kW) |
| 10 | fault | ro | bitmap | 16 bits: ov_cr, ov2_cr_fault, ov_vol, undervoltage_alarm, contactor_adhesion, contactor_fault, earth_fault, meter_hardware_alarm, scram_fault, cp_fault, meter_commu_fault, card_reader_fault, cir_short_fault, adhesion_fault, self_test_alarm, leakagecurr_alarm |
| 13 | connection_state | ro | enum | controlpi_12v, controlpi_12v_pwm, controlpi_9v, controlpi_9v_pwm, controlpi_6v, controlpi_6v_pwm, controlpi_error |
| 14 | work_mode | rw | enum | charge_now, charge_pct, charge_energy, charge_schedule, charge_delay |
| 18 | switch | rw | bool | — |
| 19 | local_timer | rw | raw | 2 bytes: start hour / end hour |
| 23 | system_version | ro | string | — |
| 24 | temp_current | ro | value | scale 0, unit °C |
| 25 | charge_energy_once | ro | value | scale 2, unit kWh — current/last session energy |
| 27 | online_state | rw | enum | offline, online |
| 28 | timer_on | rw | value | unit h — delay before power-on |
| 33 | mode_set | rw | raw | 8 bytes, capability flags |
Some higher power variants (32A/7kW, product SS_EU_Mode2_7kW for example) also expose dp5/dp9 (single phase / total power as plain integers) and dp6/7/8 as three separate phase readings, still in that raw byte format. Mine only has the single dp6.
A few things I ran into with the Generic driver that a dedicated driver would fix:
- The current-limit DP (dp4 above) is a plain integer, not a Tuya enum, so it can only go on generic_number/Custom Slider. I tried remapping it to a Custom Picker for a clearer stepped display (only 11 possible values, 6 to 16A), but looking at
device.js,_dpToCap()checkstypeof rawValue === 'number'first and returns before ever touchingoptions/labels/readMap— so readMap is basically dead code for numeric DPs. Worked fine going picker→DP (writeMap), just not the other way. A one-line fix (checking readMap before the number branch, usingrm[String(rawValue)]) would make numeric enums usable, might be worth it for other device types too, not just EV chargers. - dp10 is a proper 16-bit bitmap with specific fault codes, but the only capability available is a plain boolean alarm. Would be nice to at least expose the raw bitmap value somewhere so people can match it against the fault table without digging into raw DP debug output.
- dp1 (lifetime total) never updated locally for me even through a full charge cycle, even though the session counter (dp25) tracked correctly and matched the Tuya app exactly. I checked the HA integration’s config for a similar model and they don’t map dp1 at all either, so I think it’s a known dead end for these chargers over LAN. Might be worth doing the same trick you already do for smart plugs (computing energy locally instead of trusting the local counter), just triggered off dp25 whenever work_state hits charger_end, since there’s no live power DP to integrate from on this model.
- one more thing if you ever expose dp14 (work_mode) as a picker: the enum range Tuya reports for it doesn’t seem to reflect what’s actually usable. Mine reports 4 selectable values (charge_now, charge_pct, charge_energy, charge_schedule), but dp33 (mode_set, a raw bitmask specifically documented to say which modes are implemented) decodes to
01 00 00 00 01 00 00 00for my unit — only byte1 (charge_now) and byte5 (charge_delay, which isn’t even in the enum range) are set. So percent/quantity/schedule are listed as valid options but don’t seem to do anything on this hardware, and the one that’s actually implemented besides immediate mode isn’t in the enum at all. I’d trust dp33 over the static enum range if you ever build a mode picker for these.
Happy to test anything against my actual unit if that helps, I’ve got a working Device ID and Local Key for it already and can grab raw DP dumps on demand (not pasting the local key here obviously, can send by DM if useful).
check → works now thx!
Hi Elliot
Could you please provide the DP Table? you’ll find it under App settings (should be exact the same data as your DP model)
Thank you
