Hey folks,
I've been exploring this all morning and there are various community solutions (thanks to all) taking different approaches: Tuya direct, via SmartThings, via Google Home, etc. However, I don't know about you but I have enough subscriptions in my life and would prefer not to pay Google for another one to control a few lights/fans. To my question: is there a way to integrate these switches/fans for free with Hubitat?
Thanks!
Here are a couple of threads to review depending on what your desire is and what devices you have:
and
Hopefully this will provide insight into the supported capabilities. There are many drivers and supported devices thanks to the great community developers.
Thanks.
Yup, found both of those. Should've mentioned, my Tuya devices are all WiFi--set them up a few years back before I learned better.
The IoT driver seems to be the way to go.
Yes, I used that for my wifi curtains. Works great,
Excellent.
It's working for my standard WiFi switches that control exterior floodlighting but it's not working well for my combo fan:light switches. Fan ON/OFF works but not speed control. Light ON/OFF doesn't work at all.
If I could find a combo Z-Wave fan:light switch I'd take that route but, alas, nothing so far.
Can you add them to Smart Things without a hub? I see both the Smart Life and the Tuya Home apps in the list of devices you can add in the ST app (I do not have a hub).
If that works you might be able to do that and then bring them over from ST with Replica. I use it for my fridge and its a great app. [RELEASE] HubiThings Replica
Its sort of a hack using two cloud systems but would probably work well most of the time.
I thought of the same thing and actually started going down the Google home route. I've got a ton of vDevs in place right now but that's a pain to maintain.
If I could just find a Z-Wave combo switch that supports both dimming and fan speed, I'd just replace the Tuya stuff but even the Zooz switch doesn't handle fan speed. Sigh. A strange gap in the market. 
That's not the same as what I mentioned at all. With Google Home / Alexa you cannot pull devices back into HE unless you do virtual devices and routines to keep it in sync. With the Smart Things route the app I mentioned interfaces directly with the Smart Things cloud API to communicate device updates bi-directionally in real time.
Also, Alexa can integrate directly to Tuya, so if you are having issues with Alexa I would just integrate directly with the Tuya cloud via the Alexa skills. This wont get the device into HE, but you can control it from Alexa that way.
I integrated Tuya and Google home with Tuya's native integrations and planned to fully integrate the devices via the community integration I posted above. Feels like a similar approach to me. Still, I don't like having 1-cloud dependency, let alone 2 so I bailed out. Perhaps the Smart Things route over the Google equiv. would expose things properly but, again, throwing another cloud into the mix doesn't sit well with me.
I assume you mean Alexa can integrate directly with Tuya (as opposed to Tuya can integrate with Tuya)--yes, I've had that for 3 years or so and it's mostly functional but, as you implied, that doesn't expose devices to Hubitat... compound that with how inferior Alexa routines are compared to Hubitat RM and I'm making no progress.
I'm transitioning everything I can from Alexa primary control to Hubitat--that's the goal. New Z-Wave/Matter (heck, I'd settle for Zigbee at this point) switch H/W is the ultimate but, as I said, that doesn't exist yet.
Its not, because the Google Home integration (system or community) can only push HE devices to Google and keep those device status in sync. They cannot bring devices that are added in Google back to HE. Same as how the Alexa integration works. Hope that makes sense, tried to explain it the best I could.
Just went to check and you're correct--my bad. I've tried various integration approaches over the past week and could've sworn it was the Google one that mis-represented the device class to Alexa but clearly not.
Anyhoo--your explanations were good--my memory apparently not so much.
The Tuya IoT community integration is my 2nd-best option but it's not working well enough so I'll see if I can come to terms with a 2-step cloud-backed solution (
) but I'm not gonna hold my breath. I may take the Zooz switch and deal with no fan speed control within Hubitat (or from the wall switch which is worse I think).
Thanks for the support!
Instead of multiple back and forth posts on the Tuya thread, could try to get it working for you here. I am familiar with the driver code, I have made my own modifications to it in the past.
Looks like from your errors on the other thread it is having issues getting the correct code to send for the first state (I think on/off). Should be a pretty easy patch on the driver.
Can you provide the JSON string from the "functions" in the data at the bottom of the virtual device which is throwing those errors? Raw text copy/paste would be good, I can toss it into a JSON formatter so its more readable.
Other info for reference:
Certainly... thanks for picking this up.
Here's most everything given how tiny it is:
... and the Live log from a failed 'light' 'ON' event:
... and a successful 'fan' 'ON' event:
While I don't buy the reasoning, since every other device is working, figured I'd add this anyway:
The error the driver is creating is correct (except it should say on, not off). There is not a way to turn the device on/off in the functions list, just brightness. Not sure what that last screenshot is from, the Tuya side maybe? Error is probably due to sending a null value.
Possibly some of the data is missing and attached to the fan on accident, since you said it had split them up. Can you get the "functions" from the fan as well?
Also, go to the main integrations device and turn on debug logging then press refresh. Look in your logs for the data back from this device, should look something like this (be careful not to post any tokens / api keys). This is from a RGB LED strip so there is probably more data that your device will have.
This may also show what code needs to be sent to turn it on/off.
That's a snippet from Hubitat's device events tab; if you click on any part of the event, that dialog box pops. I thought the descriptionText might be of interest since it appears to indicate the structure being sent is malformed.
Sure, here you go:
I turned debug logging on for the parent device when I first created it--seemed likely it was gonna be useful; same for each child device I've been tinkering with. My log entries don't really resemble yours but different device types perhaps or may be your pic is edited/snipped. I've obfuscated just the access_token since everything else is typical header content, general metadata, device-ID-specific or an otherwise contextless signature.
Thanks again for the assist!
Ok... so I found the issue in the code but I do not think it is easily fixable. It is only copying over the functions for the dimming part and not the on/off of the light. BUT, we can fix it manually (I think).
You will want this app, [RELEASE] Custom Device Note App
It is made to add custom notes to the "data" of a device but you can also edit/replace existing data.
On the LIGHT device, edit the "functions" data with that app and replace it with this:
{"light":{"type":"Boolean"},"bright_value":{"max":1000,"min":10,"scale":0,"step":1,"type":"Integer"}}
Thats it, should in theory work correctly now if I am understanding this right.
Looks like possibly, when the light is on, it is going to think the fan is also on. If that happens I see how we can fix that also by removing the "light" data from the functions on the fan device.
// EDIT:
It's working now. I removed/refreshed all Tuya IoT API enumerated devices and tried again. So far, they're all working now.
The fan remains independent of the light control so that's also a win.
Thanks so much--can't tell you how much I appreciate the effort!
A potential hurdle: as of this morning, control over the lights has gone. It appears something re-asserted the original Functions value... presumably, the parent and|or child IoT device. I'll keep an eye on it. FYI
// EDIT: confirmed. It happened within 10 mins of my overriding the value with the fix. Bummer--thought you'd nailed it with that approach.
Any other thoughts?
I did not think the integration code (parent device) overrode those values once the child device was established. I will have to take another look at it later.
Yeah, I was a bit surprised, too. Even renaming the child devices gets 'undone' eventually.
Appreciate the help!
Download the Hubitat app
