I have this installed and use it to automat my dehumidifier it works pretty good with the odd missed command. I get the occasional warning from my Hubitat hub that these a lot of events this is set at 300/H. Normal I ingor it and that works a treat.
This morning ive had a look at the events and its quite chatty, 30 events in the last 45 mins and the device is turned off? Which seems quite a lot most 0f which are fan speed is low???
Just thought I would see is any one else has noted this???
Could you guide me on the chatter thing, because I think that with my 27 device on tuya it has my hubitat freeze and I need to reboot once or twice a day... if I could remove some of the chatter it might help.
thank you
Curious about this, the backend of Tuya is using a version of MQTT so the events are pushed from their servers to the driver. I wonder what is making Tuya send so many events.
You mention the odd missed command, I wonder if the Wifi connection is connecting/disconnecting and each time it re-connects it sends the current state to Tuya. I've found Tuya devices in general to have terrible Wifi reception with their internal antennas.
That said, I could always add code to ignore events that are not actually changes to state (e.g. if the device is off, ignore the additional off events) if that is what is going on.
Hi, I think you're right about the wifi connections problem.
I think my problems with tuya are 8 bulbs in my sons bedroom that are further from the routers than any other tuya device and were creating over 20000ms in couples of hours each plus the Tuya driver was giving over 15000000 ms in the logs.
So, I disable the driver and created virtual switch to link with Amazon Alexa while I'm waiting for an AP Extender and see if it helps.
Thank You
Hey there, appreciate your good work on this project. I'm having difficulty with it using some Fan controller devices. The Tuya device finds 4 devices (correct number) but only successfully creates 2 component devices, seemingly crashing while creating the first of the Fan devices:
dev:6752022-02-21 12:01:07.965 am errorgroovy.json.JsonException: expecting a ',' or a ']', but got ............................^ on line 1687 (method tuyaGetDeviceSpecificationsResponse) {"range":["cancel","1h","2h""4h","8h"]} index number 28 line number 1 the current character of '"' with an int value of 34 on array index of 3 expecting a ',' or a ']', but got The current character read is '"' with an int value of 34 the current character of '"' with an int value of 34 on array index of 3
Now at first I thought that potentially there was some dodgy json being passed by tuya (dropping the , between "2h","4h" above. And that seems to be confirmed by the debug logging i inserted into the driver. Now my problem is figuring out how to fix it.
[
category: fsd,
functions: [
[
code: fan_countdown_set,
type: Enum,
values: {
"range": [
"cancel",
"1h",
"2h""4h",
"8h"
]
}
],
[
code: fan_mode,
type: Enum,
values: {
"range": [
"nature",
"sleep"
]
}
],
[
code: temp_value,
type: Integer,
values: {
"unit": "",
"min": 0,
"max": 100,
"scale": 0,
"step": 2
}
],
[
code: bright_value,
type: Integer,
values: {
"unit": "",
"min": 0,
"max": 100,
"scale": 0,
"step": 2
}
],
[
code: switch_led,
type: Boolean,
values: {
}
],
[
code: fan_direction,
type: Enum,
values: {
"range": [
"forward",
"reverse"
]
}
],
[
code: fan_switch,
type: Boolean,
values: {
}
]
],
status: [
[
code: fan_switch,
type: Boolean,
values: {
}
],
[
code: fan_direction,
type: Enum,
values: {
"range": [
"forward",
"reverse"
]
}
],
[
code: switch_led,
type: Boolean,
values: {
}
],
[
code: bright_value,
type: Integer,
values: {
"unit": "",
"min": 0,
"max": 100,
"scale": 0,
"step": 2
}
],
[
code: temp_value,
type: Integer,
values: {
"unit": "",
"min": 0,
"max": 100,
"scale": 0,
"step": 2
}
],
[
code: fan_mode,
type: Enum,
values: {
"range": [
"sleep",
"nature"
]
}
],
[
code: fan_countdown_set,
type: Enum,
values: {
"range": [
"cancel",
"1h",
"2h",
"4h",
"8h"
]
}
]
]
]
Any thoughts? Happy to supply whatever info is needed to help the process?
Wow, good find. Looks like the official Tuya driver doesn't account for dodgy json either. Bad on Tuya for not validating their json before sending it. That said, I wonder if this workaround would fix it for you. Check line 1698 where I try and detect and fix the json problem and then re-parse it. I've a few other ideas if that doesn't work.
https://raw.githubusercontent.com/bradsjm/hubitat-drivers/development/Tuya/TuyaOpenCloudAPI.groovy
Made it through the tuya cloud setup, added the driver, and authenticated successfully. Ended up with a "generic component switch" for my device, which I assume means it isn't supported? Trying to add an Inkbird ibbq-4t. The device does successfully catch power on/off events, so the integration with the tuya cloud is at least working.
Correct, it isn't currently supported but the good news is it we can probably get it more functional. Please PM me and in the generic component switch device go to the bottom and copy the "data" section which will have JSON lines on category, statusset, functions etc. Once I have that data I can look at support for it 
Your change makes sense to me (I should've tried it myself ;)) I'll try it tonight after work.
Hey unfortunately that doesn't seem to have worked. Best I can tell (with some debug logging) is that it's not getting past the if statement. Whether response.data isn't the correct place to be looking. Or whether the search string isn't write I'm unsure. I tried a few things but couldn't get anything to work.
Nothing is generated in my log.
Nice driver. Can the driver add a siren? Zigbee Siren
Are your results the same? for temperature and humidity
OMG, you just saved my Smart house. I just brought 50 Tuya devices into Hubitat!
Could you let me know if it freeze your hub, cuz with my 27 device hub was freezing 2 or 3 times a day?
Love your work @jonathanb , I've been wanting to run my Tuya Blinds via HE for a very long time - All I need now is a Blind driver. Any chance you could please make one using the Tasmota drivers as the basis?
PS, there's a stack of info over here too:
EDIT: NVM, I found your link to generic drivers which I'll test shortly:
Yup. I had to hook a smart plug up to it so I could reboot, about every 12 hours or so. Havn't had time to mess with it and see it's overloaded or what. Anybody know if there is a item limit in hubitat?
Update: These worked great! I finally have my blinds in HE! 
I was using the app "Rebooter" and I was rebooting the hub every 12 hours, but sometimes it wasn't enough.
So I disable the tuya driver and created virtual device that I synced with Amazon Echo.
My other Plan would be to transfer everything to a C-7 and only run tuya on my C-5.
@deanveatch and @Luft, there are other integrations such as Hue and Lifx which I am sure someone out there has lots of devices and I have not heard of issues with those. There might some efficiencies to be gained in this driver code. Check the logs > Device Stats and see what it is showing in there. I only have one device but the ms, Avg is high on the integration driver compared to other "devices".
I also have started to mess with local control on my device, so far I am able to sync on/off state but it is using Node-Red. If it gains interest I was thinking about checking into the generic local control driver that someone else posted (it needs to be tweaked for each type of device).
The average ms will never be as low as unencrypted communication. I also have my own drivers for Tasmota local devices and the overhead there is so much lower. Right now I show average of 46ms for Tasmota and 648ms for Tuya!
For each received MQTT packet from Tuya, it needs to be converted from Base64, then decrypted using AES/ECB/PKCS5Padding then JSON parsed and only then can the contents be parsed to trigger events.
You would think that since commands are sent to Tuya over HTTPS they are already secure but no, Tuya wants each command to also have an HMAC-SHA256 signature calculated for it (to avoid I suppose a man-in-the-middle attack?)
I've no idea how well Hubitat hardware is designed for AES instruction optimizations but all that overhead for each packet sent and received from the Tuya cloud adds up I would assume.
Any optimizations to the code would be helpful! The send code is located in the source code at line 1890 to 1972 (tuyaRequestAsync). The parsing (parse) is located at line 655 (in my dev branch). The other area of optimization would be the createEvents method around line 1238 where the Tuya packets are converted to Hubitat events. Any experienced Groovy devs are very welcome to make suggestions for improvements.
Download the Hubitat app
