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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
