I did a quick test and it seems to work. Thank you.
Hi Andi,
I have been building something similar for my own house since March, a small local Tuya app on the Python runtime. Three drivers, nothing more. Then time ran out, I stopped working on it, and to be honest I only properly noticed your app afterwards. Yours does the same thing on a much bigger scale, and it does it well.
So I am not going to submit mine or take it any further. Instead I have put the code online as it is, in case anything in there turns out to be useful to you: https://github.com/michelhelsdingen/tuya-local. MIT, no strings attached, and no need to credit me anywhere.
If I were you I would look at the registry first. I spent a while on devices going unavailable until the app was restarted, and it came down to three separate things. An update that mutated a copy of the record instead of the record itself. A cloud import that overwrote a working local key with an older one. And a save that kept the full data point spec, which made it too large for Homey settings, so the registry came back empty after a restart. That last one is the one that matches the restart reports in here. The README explains all three and there are tests for each of them.
There is also a smoke detector driver in there, which I did not see in your list.
Maybe none of it is useful to you, and that is completely fine. Either way, nice work on the app, and on the way you support people in this thread.
Michel
Hi Michel — thank you, and that is a generous way to handle it.
I checked your three registry faults against my own code. The second one lands. My “check local keys” writes a cloud key over the stored one whenever they differ, without asking whether the stored one is currently working — and I widened that check’s reach only yesterday, onto exactly the accounts whose cloud data is most likely stale. You caught a fault I made worse a day ago. It is getting a guard: a device that is connected and receiving data keeps its key.
The third has the same shape with less blast radius here — my DP snapshot is diagnostic, not a device registry, so losing it cannot take a device offline. Still an unbounded write inside a silent catch, which is not defensible. Fixing that too.
The first does not apply: different runtime, and the read-modify-write is atomic on Node’s single thread.
Your smoke detector is a real gap in my list — I will look at your data point mapping when I get to that driver. And you get a line in the changelog 
Thank you
Regards
Andi
Update: new TEST version is ready including the modifications and the new smoke detector driver: Tuya Local | Homey
Can you add Loeffen LFIM6000 ice maker?
It supports switch as boolean and mode as string “big” “small”
Hi John - Could you please configure the device by using the generic driver?
Yes, i haven’t been able to try the app yet. But i wasn’t sure if the generic device was what i was looking for. I won’t be home for a while, but i’ll try when i can. Thanks!
Hello Andi and thank you for a great software. I have 2 air quality sensor units and a weather station that I would like to get up and running, bought on Aliexpress. I am including links here. Can you post these so they work?air quality sensor weather station
luft kvalitet
DP 1 air_quality_index enum level_1 level_1, level_2, level_3
DP 2 temp_current value 28 -400–2000 step 1 ℃
DP 3 humidity_value value 68 0–1000 step 1 %
DP 4 co2_value value 440 0–10000 step 1 ppm
DP 5 ch2o_value value 3 0–9999 step 1 mg/m³
DP 7 pm25_value value 12 0–999 step 1 ug/m³
DP 8 pm1 value 14 0–999 step 1 ug/m³
DP 9 pm10 value 17 0–999 step 1 ug/m³
DP 22 battery_percentage value 100 0–100 step 1 %
DP 23 charge_state bool true {}
DP 28 alarm_volume Enum middle low, middle, high, mute
DP 101 tvoc_value value 7
DP 102 co_value value 0
DP 103 bl_level enum level2
DP 104 co2_alarm_value value 700
DP 105 sleep_timer value 40
DP 106 buzz bool false
DP 107 pm03 value 13
DP 108 secondcal value 114
DP 109 clock1 value 0
DP 110 clock2 value 0
DP 111 clock3 value 240
DP 112 temp_unit_convert enum c
DP 113 co_alarm_value value 30
DP 114 pm25_alarm_value value 100
DP 115 hcho_alarm_value value 61
DP 116 clock1_en bool false
DP 117 clock2_en bool false
DP 118 clock3_en bool false
Smart IR
DP 101 temp_current value 238
DP 102 humidity_value value 63
DP 201 ir_send string {“control”:“study_exit”}
DP 202 ir_study_code raw 3wNAA1MHTAPJA0wDygNMA8kDLAPJA9cGUwdLA6kD1gZSB9YGMwdFd6kDawMzB0sDyQNqA6oDLAPnAy0DyAPVBlMHSwOpA9UGUwfVBjMHQ3epA0sDUwdLA8gDTAPIA0wDyAMtA8gD1QZTB0sDyAO3BlIH1QYzB1J3qgNMA1MHTAPJAy0DyANMA8kDTAPJA9YGNAdMA8kD1wY0B9YGVAc5d6oDTANTB0wDyQMtA8kDTAPJA0wDyQPWBjQHTAPJA9YGNAfXBlMHNXepA0sDUgdMA8gDTAPIAywDyQNLA8kD1QZSBywDyQPVBlIH1QY0Bz93qQNMA1IHSwPIA0wDyANLA8kDSwOpA9YGUgdLA8kDtgZSB9UGUgc1d6oDTANUB0wDyQNMA6kDTAPJA0wDyQPXBjQHawOqA9YGNQfWBlMHMHU=
DP — va_temperature Integer 238 -200–800 step 1 ℃
DP — va_humidity Integer 63 0–100 step 1 %
værstasjon
DP 1 temp_current value -200
DP 101 intemp value 258
DP 102 inhum value 550
DP 103 ch1temp value 123
DP 104 ch1hum value 920
DP 105 ch2temp value -500
DP 106 ch2hum value 0
DP 107 ch3temp value -500
DP 108 ch3hum value 0
DP 126 com enum comfortable
DP 127 alarm raw AX8AAAAAAn8AAAAAA38AAAAA
DP 128 alert raw ZQMDASIAyGcAAwDIAABpAAMCvP4MawADArz+DA==
DP 129 unit raw AQACAA==
DP 130 battery raw AAIBBAL/A/8=
DP 131 basic raw fwMHAACABGVnaWuBCA==
DP 132 alertup bitmap 0
DP 133 datadisplay raw ZQBmAGcAaABpA2oDawNsAw==
DP — va_temperature Integer -200 -200–600 step 1 ℃
Hi Kai - are all three devices battery powered?
It would be great if you could check as next step if you are able to add the devices as generic device (if you get some values out of them).
reason: some battery driven devices do not work with the local connection
as soon as you’ve checked that, we can go ahead and build specific drivers for them.
Andi
EDIT: for værstasjon you could test with the Weather Station driver
No, all devices are USB powered. Are they already in Tuya local?
Hi Kai
all three devices are covered in the next test version: Tuya Local | Homey
Air quality monitor — new driver. Every reading gets a tile: CO₂, PM2.5 / PM1 / PM10 / PM0.3, TVOC, CO, formaldehyde, temperature, humidity and battery, plus alarm volume, backlight and buzzer as controls. The CO₂, CO and PM2.5 alarms compare against the limits you set on the monitor itself (700 / 30 / 100), so they stay yours.
One thing I can’t work out from the data: Tuya doesn’t publish which unit these send formaldehyde and TVOC in, so I pass the value through unchanged rather than guess at a conversion. What does the monitor’s own display show for formaldehyde while the app shows 3? That tells me the factor. While you’re there, a quick check that temperature and humidity match the display too.
Smart IR — new driver. It learns a code from any remote and replays it from a flow, and it reads the built-in temperature and humidity sensor.
Weather station — channels 2 and 3 report −500 and 0, which is what these stations send for a channel with no sensor paired to it, so those tiles stay empty. That is correct rather than a fault. For the outdoor sensor’s battery level, set up Cloud Lookup before adding the device — it finds that data point by name. Without it, enter
130 under DP Sensor Batteries by hand.
If you experience issues with the drivers, create a support bundle and send it to me:
Andi
What do you mean with “trial version”?
trial version of these 3 devices. you said there was a better update coming later?
The TEST version will be released first. If no issues are identified, it will then be promoted to the production release.
Hi Andi,
I am using a Tuya EV charger (category qccdz) with Tuya Local v1.0.232 on Homey Pro.
Basic control of the charger works, but voltage, current, power and session energy are not populated correctly in Homey.
The charger does not expose the phase measurements as the usual 7/8-byte packed phase DPs. Instead, all three phases and additional measurements are sent together as JSON in DP 102.
Example while actively charging:
DP 102:
{“L1”:[2320,55,12],“L2”:[2320,58,13],“L3”:[2320,56,13],“t”:370,“p”:39,“d”:54150,“e”:113}
From comparison with the charger’s actual measurements, this appears to mean approximately:
L1: 232.0 V / 5.5 A / ~1.2 kW
L2: 232.0 V / 5.8 A / ~1.3 kW
L3: 232.0 V / 5.6 A / ~1.3 kW
p: ~3.9 kW total power
t: ~37.0 °C
Example DP 102 while idle:
{“L1”:[2350,0,0],“L2”:[2350,0,0],“L3”:[2350,0,0],“t”:300,“p”:0,“d”:15920,“e”:46}
Other relevant DPs:
DP 109 = WORKING while charging
DP 150 = 6 (configured charging-current limit)
DP 152 = 16
DP 153 = “charge: t=5324s (88min) e=11.263kWh”
The vehicle independently reports approximately 4.1 kW charging power at the same time, which is consistent with the ~3.9 kW value contained in DP 102.
If DP 102 is assigned to one of the existing packed phase or scalar measurement DP settings, Homey produces obviously invalid readings because DP 102 is not the standard packed binary phase format.
Would it be possible to add support for this JSON-based DP 102 format to the EV Charger driver and map its values to Homey’s voltage/current/power capabilities?
I can provide the complete DP Debug output and a Tuya Local support bundle if needed.
Thank you!
Hi Sebastian
There is a new TEST version available now - please install and let me know how it goes: Tuya Local | Homey
The important part: set DP Phase JSON = 102 and leave Phase A / B / C at 0 — otherwise the packed reader goes on trying to take the JSON apart as if it were the binary format.
afterwards - please provide the complete DP Debug output and a Tuya Local support bundle to doublecheck the driver.
Thank you
Andi
