# \[APP\]\[Pro\] Tuya Local

**URL:** <https://community.homey.app/t/app-pro-tuya-local/154077>\
**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:** 23

<div class="post-metadata">

**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 26, 2026, 3:31pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/448 "2026-09-26T15:31:25Z")

</div>

Hi Andi,

while you’re mastering the challenge with the thermostats, I’ve integrated another device into your app.

A fan with the following DPs:

DP 1 = true / false → on / off

DP 2 = 1 / 2 / 3 → propeller speed

DP 3 = normal / sleep → noise reduction

DP 8 = true / false → swing on / off

DP 11 = 0 / 1 / 2 / 3 / 4 → hours of countdown

DP 12 = 0 / 60 / 120 / 180 / 240 → minutes of count down ( automaticaly set with DP 11)

The device created so far does not yet fully reflect all of its capabilities.

Maybe you’ll find some time to work on this one as well.

---

<div class="post-metadata">

**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 26, 2026, 5:14pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/449 "2026-09-26T17:14:47Z")

</div>

Hi Jeppe,

Glad it works — thanks for confirming both directions.

The HomeKitty thing has a simple cause: Apple Home only knows off, heat, cool and auto. Your unit has five modes, including dry and fan, so this app uses its own mode setting rather than Homey’s standard one. A bridge can only pass on what it recognises, which is why your temperature works and the mode doesn’t.

I’m going to leave it as it is. Making the mode bridgeable would mean dropping dry and fan for everyone, and that’s a worse trade than the one you’ve already solved yourself — your Advanced Virtual Device does the job and lets you pick which modes Apple Home sees.

Kind regards,  
Andi

---

<div class="post-metadata">

**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 26, 2026, 5:27pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/450 "2026-09-26T17:27:59Z")

</div>

Hi Dietrich,

Good news: most of your fan was already supported — the settings just weren’t obvious. Here’s the full mapping:

Your DP Setting Value  
1 On/Off DP 1  
2 Fan Speed DP 2  
3 Mode DP 3  
8 Oscillate DP 8  
11 Countdown Timer DP 11  
12 Countdown Left DP 12  
Two things you need to change by hand.

Speed DP → 0. It defaults to 3, which is where many fans put a percentage speed and where yours puts the mode. With both pointing at DP 3 the slider wins and your mode is lost entirely — that’s almost certainly why the device felt incomplete.

Fan speed values → low=1,medium=2,high=3. Your speeds are bare numbers, so until now the picker would have shown 1, 2 and 3. That form is new in 1.0.248 — the left side is what Homey shows and what flows use, the right side is what goes to the fan. Your modes already have names, so Mode values → normal,sleep as they are.

The countdown pair works as you’d expect: DP 11 is the one you set, DP 12 is what the fan reports back on its own.

Kind regards,  
Andi

---

<div class="post-metadata">

**Author:** ![Stephen\_Petitt](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/stephen_petitt/32/121620_2.png) [@Stephen\_Petitt](https://community.homey.app/u/Stephen_Petitt)\
**Post date:** [September 27, 2026, 2:07am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/451 "2026-09-27T02:07:02Z")

</div>

Andi

I’ve had another unscheduled feed on my Petlibro Pet Feeder.

The feed occurred at 02:11, just after I re-booted my SHS althouh I had another one earlier in the day.

Dump id: 7c088347-6b1b-4029-8584-59e941cfb602

Just to remind you, I have two flows set up against the feeder; one is time-based and does a single portion feed at 06:00 every day, the second is set up to respond to a Google voice command and runs three or four times a day, again with just one portion.

Thanks

Stephen

---

<div class="post-metadata">

**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 27, 2026, 7:13am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/452 "2026-09-27T07:13:29Z")

</div>

Hi Andi,

So sorry to keep bugging you, but I just ran into another bug, while setting modes in flows.

**v1.0.248: Mode/fan value mapping: flow card dropdown sends `name=value` instead of `name`**  
With Mode values `auto=0,cool=1,dehumidify=2,fan=3,heat=4`, the “Set AC mode” and “Set AC fan speed” dropdowns only offer `Cool=1`, `Heat=4` etc. and fail with: _Invalid enum capability (ac\_mode) value: cool=1. Expected: auto,cool,dehumidify,fan,heat_. The device UI and the capability themselves work fine.

 ![SCR-20260927-imql](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/e/8/e82dbc40ab0620c0e79c895cf466ef19bcbb6cc7.png)

---

<div class="post-metadata">

**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 27, 2026, 8:34am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/453 "2026-09-27T08:34:18Z")

</div>

Hi Jeppe,

Not a bother at all — that’s a precise report and the error message names the cause exactly.

The flow card dropdowns were building their list by hand: they cut the setting at the commas and used each piece as both the label and the value. Fine while a list held only plain values, wrong the moment it held a mapping — which is a feature I added two versions ago without touching these. So the card handed cool=1 to a capability that knows cool.

Your tile and the capability were right all along, which is why everything except flows worked.

Fixed in the next version, and in all ten drivers that have such a dropdown rather than only the two that accept mappings today — so the next one to get them won’t need this found again.

You’ve now found three real bugs in three versions. Please keep going.

---

<div class="post-metadata">

**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 27, 2026, 8:47am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/454 "2026-09-27T08:47:37Z")

</div>

Hi Stephen,

Found a real bug in your log: 1.5 seconds after the app connected it announced “Feeding completed”. The trigger compares the motor state against its previous value — and Homey keeps that across a restart. So if the app last stopped while it read feeding, the first honest standby afterwards looked like a completed feed. Every restart.

Please update — you’re on 1.0.237, and this is fixed in 1.0.249: [Tuya Local | Homey](https://homey.app/a/com.tuyalocal/test/)

But I can’t tell from the log whether your feeder actually dispensed anything, and that’s the part that matters. How did you know about the feed — did Homey tell you, or was there food in the bowl?

If it was Homey’s timeline, the update settles it. If there was food, I’ve fixed a bug standing next to yours rather than yours, and I’ll keep digging — your feeder’s own log recorded two entries ten seconds apart just after the app reconnected, and neither of your flows was involved.

Kind regards,  
Andi

---

<div class="post-metadata">

**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 27, 2026, 10:01am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/455 "2026-09-27T10:01:23Z")

</div>

HellonAndy,

I got the fan speed working with low/medium/high but I can’t get rid of the %-slider.

Maybe I missed something.

 ![Screenshot_20260927_114400_Homey](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/8/b/8b3fb62e2e339c6f874f73dee3bc21f2adf509bc.jpeg)

And there is also. a problem with the timer.

It is set to two hours but the DP is 0

 ![Screenshot_20260927_115601_Homey](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/a/1/a14b1aeb552409635956886d7855d25642921314.jpeg)

---

<div class="post-metadata">

**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 27, 2026, 10:28am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/456 "2026-09-27T10:28:47Z")

</div>

Hi Dietrich,

Both of those are bugs, and you did nothing wrong.

The slider. Setting Speed DP to 0 was exactly right — the slider just couldn’t go away, because it was a fixed part of the driver rather than something tied to that setting. Fixed now: with Speed DP at 0 it disappears.

The timer. The tile offers cancel, 1h … 24h; your fan wants a plain 0 to 4, where the number is hours. So selecting two hours sent “2h” to a device expecting “2”, and nothing happened — which is exactly what your screenshot shows, DP 11 sitting at “0”.

There’s a new setting for it: Timer uses plain numbers. Switch it on and 2h sends 2, while 3 coming back from the fan reads as 3h.

Both in the next version: [Tuya Local | Homey](https://homey.app/a/com.tuyalocal/test/)

Thanks — that’s two more found by looking rather than guessing.

Kind regards,  
Andi

---

<div class="post-metadata">

**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 27, 2026, 11:24am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/457 "2026-09-27T11:24:05Z")

</div>

Thank you, that’s working now.

Only the DP 12 is not correct. The debug shows 59 what is the remaining time from the timer in minutes and the device shows 24 hours what is definetly wrong.

---

<div class="post-metadata">

**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 27, 2026, 11:48am UTC](https://community.homey.app/t/app-pro-tuya-local/154077/458 "2026-09-27T11:48:19Z")

</div>

Hi Andi

Perfect thanks so much again. I think there’s another bug that has crept into vX.X.250 🙂

 ![SCR-20260927-mhms](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/4/9/49bb6eb47c5f93cb7b7e0b0a21d22049b4919d95.png)

---

<div class="post-metadata">

**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 27, 2026, 12:24pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/459 "2026-09-27T12:24:36Z")

</div>

Hi Jeppe,

That’s mine, and from the last version — thank you for the screenshot, the error message names it exactly.

Fixed in the next version. Sorry for the churn — you’ve found four now, and each one has been real.

Kind regards,  
Andi

---

<div class="post-metadata">

**Author:** ![Stephen\_Petitt](https://sea1.discourse-cdn.com/flex025/user_avatar/community.homey.app/stephen_petitt/32/121620_2.png) [@Stephen\_Petitt](https://community.homey.app/u/Stephen_Petitt)\
**Post date:** [September 27, 2026, 4:23pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/460 "2026-09-27T16:23:34Z")

</div>

Hi Andi

I’ll install the update and let you know if I have any further problems,

I actually heard the feeder dispensing.

Stephen

---

<div class="post-metadata">

**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 27, 2026, 6:02pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/461 "2026-09-27T18:02:05Z")

</div>

Hi Andy,

In general it’s working now. But I think it would be better to show the remaining time in minutes insted of hours like the DP 12 does.

Your work is realy quick and much apreciated.

---

<div class="post-metadata">

**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 27, 2026, 6:39pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/462 "2026-09-27T18:39:01Z")

</div>

Hi Dietrich,

You’re right, and my first fix was only half of it. I converted minutes into hours — 59 became 1.0 h — which is correct and throws away exactly the information you want. On a timer that stops at four hours, “59 min” tells you something; “1.0 h” tells you almost nothing.

So there’s no conversion any more. The tile simply takes its unit from the same setting and shows what the fan reports: your 59 stays 59 min, and four hours reads as 240 min. Nothing to change on your side — the setting you already have is what picks the unit.

Thanks for pushing back on that rather than living with it.

Kind regards,  
Andi

---

<div class="post-metadata">

**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 28, 2026, 12:00pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/463 "2026-09-28T12:00:16Z")

</div>

It’s working perfect now. Thank you. 👍

---

<div class="post-metadata">

**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 28, 2026, 1:55pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/465 "2026-09-28T13:55:22Z")

</div>

Now I have a new one 🤔

I added a device as a Präsenzsensor what is actually a movement sensor.

Präsenzsensor (presence\_sensor)  
Last update: 28.9.2026, 15:17:45

DP Value Type  
20 false boolean  
21 “white” string  
51 “auto” string  
52 “none” string  
53 “2000lux” string  
54 “low” string  
55 5 number  
56 true boolean  
57 0 number

The DPs I could determine are:

DP 20 = true / false → on/off

DP 53 = 5l ux / 10 lux / 50 lux / 300 lux / 2000 lux → Ambient light sensor dark / evening / day

DP 54 = low / middle / high → motion distance

DP 55 = 5 / 6 / 7…/ 3600 → full light duration

DP 56 = true / false → sensor / manuell

The other DP’s might be for a sensor with integrated.light.

DEVICE Präsenzsensor  
driver presence\_sensor  
model STARLUX 05DW sensor (product hpjrxo4jplpgfjpq)  
device id bfa611…  
available yes  
protocol configured 3.3, connected 3.3 ip 192.168.11.1  
status Connected · last seen 28.09.26, 15:17:42 · poll 0s  
history 43 connections since app start · up 15h 7m total · avg 21m 6s · longest 1h 40m  
packets 171 received · 0.00/s while connected · data ever received: yes  
DP mapping  
dp\_alarm 0  
dp\_detection\_delay 0  
dp\_distance 0  
dp\_fading\_time 0  
dp\_far\_detection 0  
dp\_luminance 0  
dp\_near\_detection 0  
dp\_presence 0  
dp\_sensitivity 0  
other settings  
command\_gap\_ms 100  
fire\_and\_forget false  
lock\_protocol false  
offline\_grace\_seconds 60  
reconnect\_interval 0  
live DPs (updated 2026-09-28T13:17:45.340Z)  
DP 20 false boolean  
DP 21 “white” string  
DP 51 “auto” string  
DP 52 “none” string  
DP 53 “2000lux” string  
DP 54 “low” string  
DP 55 5 number  
DP 56 true boolean  
DP 57 0 number  
cloud spec code / dp / type / value / range  
switch\_led 20 Boolean null  
work\_mode 21 Enum null white,colour  
control\_data 28 String null  
device\_mode 51 Enum null auto,manual  
pir\_state 52 enum null pir,none  
cds 53 Enum null 2000lux,300lux,50lux,10lux,5lux,now  
pir\_sensitivity 54 Enum null low,middle,high  
pir\_delay 55 Integer null 5-3600 s  
switch\_pir 56 Boolean null  
pir\_resume\_countdown 57 value null

---

<div class="post-metadata">

**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 28, 2026, 4:10pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/466 "2026-09-28T16:10:10Z")

</div>

Hi Andi,

I noticed another issue today, this time with the Wallbox consumption shown in Homey Energy.

The live values from the charger look correct and match the original Tuya app almost exactly.

At around 18:05 the Tuya app showed:

- Charging active
- 223 V
- 15.2 A
- 3.4 kW
- Session energy: 2.2 kWh
- Session duration: 00:39:07

Homey showed at the same time:

- evcharger\_charging: true
- plugged\_in\_charging
- approx. 225 V
- 15.2 A
- 3.4 kW
- charge\_session\_energy: 2.2 kWh

So the live data and session energy look perfect.

However, Homey’s Energy dashboard shows the Wallbox as having consumed **7.2 kWh today** , even though the current charging session has only delivered **2.2 kWh**.

The cumulative meter\_power.charged value was around **156.108 kWh** at the time of the screenshot and shortly afterwards was already **156.292 kWh**.

Could Homey Energy be deriving the daily consumption from meter\_power.charged, and could something about how that counter is updated be causing the 7.2 kWh daily figure?

The interesting comparison is:

- Tuya session energy: **2.2 kWh**
- Homey charge\_session\_energy: **2.2 kWh**
- Homey Energy dashboard Wallbox consumption today: **7.2 kWh**

I have screenshots showing all three values taken at essentially the same time.

Kind regards,  
Sebastian

 ![IMG_1625](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/f/c/fc35f6df248f39933a71464089de25d832adff97.jpeg)

 ![IMG_1626](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/6/5/65b5c78244393058d43299e220ab790149b386a3.jpeg)

 ![IMG_1624](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/4/d/4d79507c01cf8641202bcf78283cbe14c852883a.jpeg)

 ![IMG_1623](https://us1.discourse-cdn.com/flex025/uploads/athom/original/3X/e/0/e002dc5c35b3a7132d7fbfc00df21e182608e33c.jpeg)

---

<div class="post-metadata">

**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 28, 2026, 6:58pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/467 "2026-09-28T18:58:31Z")

</div>

Hi Dietrich,

The bug is real and fixed: DP 52 is your motion state, reporting pir / none, and the driver only recognised the word presence. It compared false every time — the tile would have sat on “no motion” while the data point changed underneath it, with nothing in the log, because nothing was failing.

Set Presence DP to 52 and motion works. One correction to your own list: DP 54 is sensitivity (low / middle / high), not distance.

What the driver can’t do yet, honestly. It was built around an mmWave sensor and only reads four things: motion, fault, distance, illuminance. Your dusk threshold (53), sensitivity (54), delay (55) and PIR enable (56) are all settable on the device, but there is nothing in this driver to set them from — and the sensitivity and delay settings you see in the device settings expect numbers, where yours are words. So they won’t help you.

If you’d find those four useful as real controls in Homey, say so and I’ll look at adding them. It’s a proper piece of work rather than a one-line fix, so I’d rather know it’s wanted.

Kind regards,  
Andi

---

<div class="post-metadata">

**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 28, 2026, 7:04pm UTC](https://community.homey.app/t/app-pro-tuya-local/154077/468 "2026-09-28T19:04:25Z")

</div>

Hi Sebastian,

I’ve been through this one and I don’t think it’s a bug — but here’s the reasoning rather than just the conclusion, so you can check it.

Three things can feed meter\_power.charged, and they’re mutually exclusive by configuration: power integration (when the energy source is Power or Estimate), session-counter increments (Session), and completed charge records (Session, and only when the live counter isn’t also in use). Exactly one runs.

Your own numbers argue against double-counting. The counter went 156.108 → 156.292, a rise of 0.184 kWh. At the 3.4 kW you were drawing, that’s about three minutes of charging. If something were counting twice, it would climb at 6.8 kW and cover the same ground in half the time.

7.2 − 2.2 = 5.0 kWh. So the question is simply: did you charge earlier today? Homey Energy builds its daily figure from the difference in that counter since midnight, so it includes every session of the day, not just the one running. Your charger’s own history screen — the one showing 110 sessions — will list today’s entries; if they add up to about 5 kWh before this one, everything agrees and there’s nothing to fix.

If they don’t add up, tell me and I’ll take it apart properly. I’d also want to know your Total energy source setting, since that decides which of the three paths is running.

Kind regards,  
Andi

[Previous page](https://community.homey.app/t/app-pro-tuya-local/154077.md?page=22)

[Next page](https://community.homey.app/t/app-pro-tuya-local/154077.md?page=24)
