I just updated the driver code but when trying to save I get this error message:
The current scope already contains a variable of the name code @ line 225, column 12.
Remove line 224, I'll fix the typo in Github when Github returns from some downtime.
great - that worked and I can control the outlet too! thanks!
I followed the instructions and was having difficulity getting the driver to sign in.
I looked into the code and discovered that settings.countryCode in line 1268 was null - I changed this to state.countryCode and done the same on line 1273 and then the driver was able to get a token.
Next issue that has me stumped is that I'm getting the error -> No permissions. This API is not subscribed. Log reproduced below.
Anyone got any ideas? This hub is on 2.3.0.113
Update - I hit "Refresh" and the driver found my 4 devices !!!!!
3 of my devices are Heaters - the driver references "Generic Component Heating Device" - Hubitat does not have such as driver - at least my hub don't have one - any ideas for an alternative driver?
My Dehumidifier was created as a Generic Component Switch - as described in an earlier contribution.
dev:15932021-11-28 23:14:09.609 warnTuya Virtual Device cloud API request failed: {"code":28841101,"msg":"No permissions. This API is not subscribed.","success":false,"t":1638141249369}
dev:15932021-11-28 23:14:09.238 debugTuya Virtual Device API POST [uri:https://openapi.tuyaeu.com, path:/v1.0/iot-03/open-hub/access-config, query:null, contentType:application/json, headers:[t:1638141249232, client_id:cqs9swyxb4pmmxx7cky1, Signature-Headers:client_id, sign:51D1BF496555201D48B507750AABDE125A8B1B35472555279F10B2120282F52C, sign_method:HMAC-SHA256, access_token:f5352e44ccdb9aee046126b72af994bb, lang:en], body:{"uid":"eu1612124555516Ii4B7","link_id":"77c1c943-a66b-4922-9d44-9abc8f416137","link_type":"mqtt","topics":"device","msg_encrypted_version":"1.0"}, timeout:20]
dev:15932021-11-28 23:14:09.232 infoTuya Virtual Device requesting Tuya MQTT configuration
dev:15932021-11-28 23:14:09.187 infoTuya Virtual Device received Tuya access token (valid for 7200s)
dev:15932021-11-28 23:14:09.183 debugTuya Virtual Device API response [result:[access_token:f5352e44ccdb9aee046126b72af994bb, expire_time:7200, platform_url:https://openapi.tuyaeu.com,
You'll find additional generic component drivers available here and I've updated the code with your fixes for countryCode too.
3 Likes
If anyone wants to play with some experimental code for LOCAL control of RGBW Tuya lights then here is your chance.
- You must already be running the cloud driver from this thread, this driver does not work standalone.
- Download the LIBRARY code here: https://raw.githubusercontent.com/bradsjm/hubitat-drivers/master/Tuya/Local/TuyaProtocolLibrary.groovy
- Download the DRIVER code here: https://raw.githubusercontent.com/bradsjm/hubitat-drivers/master/Tuya/Local/TuyaLocalRgbLight.groovy
- Find the RGBW Tuya child device you wish to make local and change the driver from the Hubitat "Generic Component RGBW" to this driver "Tuya Local RGBW Light" and click save.
- In the driver configuration you MUST enter the IP address of the light device, the driver is unable to scan for it (due to the well known limitations of Hubitat broadcast UDP protocol support)
That's it, once you enter and save the IP address the driver will start sending and receiving updates locally using the cloud as a backup method if sending directly fails. For me, round trip command and response are under 400ms which isn't exactly speedy but the protocol has a lot of overhead (encryption of packets, use of JSON etc.) and it means it will work even if you lose internet connection or Tuya cloud does a wobbly.
You can return to full cloud again by changing the driver back to "Generic Component RGBW"
REMEMBER - This is experimental code, also, it is using Hubitat raw sockets which itself is described in the documentation as "is in alpha status" so caveat emptor. I've implemented retries in the driver because the reliability of the connection to the device is questionable and I do not know if thats due to the Tuya device or the Hubitat raw socket implementation. Probably need to get a packet sniffer to find out what is really going on.
7 Likes
Looking forward to the multiple devices code addition per tuya device.
I have a ceiling fan and light controller that would greatly benefit from this. If you need help testing it, let me know and I'll assist where i can
Hello Jonathan,
I tried this code for controlling the lights locally and I'm getting some trouble. Weird thing is, in the Tuya app, it says the device has some weird IP I don't recognize. I tried to configure the light for local control using both the IP address listed in the Tuya app and the IP address listed in my Ubiquiti router and I received the same results.
You should not use the IP address in the app as its your external IP, you should use the local one in Unifi which it looks like you did as you got one successful heartbeat received. However, the connection reset messages are something I used to see a lot of from my devices.
These devices will only allow a SINGLE connection to them so if the app is open on your phone or you have some other "Local" tuya solution opening connections that will cause a failure.
I also used to see this when my Tuya devices had low signal (even though they were close to the Unifi AP). I happen to have upgraded my AP from the LR to the new 6 LR model and I've had virtually no connection resets lately but can't say if this is a co-incidence or not.
1 Like
This makes sense and yes I absolutely had the native app running. I can try to test against this later; however, given that information, this solution will not work for me until the effect calling is built (because I can't automate the effects yet and I MUST rely on the app).
I'm not trying to rush you or even tell you that the effects is a priority, it just means I won't be able to switch over to local control until I can get that. I will gladly still test this out without the effects in the meantime and report back.
There is a special option in the local driver called "sendDps" which allows sending any DPS command to the device even if it's not supported via the Tuya Cloud service e.g. effects. For example, from the logs you posted before you would use DPS number 2 and the value would be "scene1" or "scene2" etc. You can then invoke this from the rule engine as a custom command.
** Update: I've added basic effect support into the local driver, just go into the settings and tell it how many effects/scenes the device has (e.g. 4 for scene1 through scene4) and use the effect number with the seteffect command.
Once again, everything you said is true. I closed the connection to the rgbw light in tuya and it allowed for local control in HE. Additionally sending DPS:2 scene2 got me exactly the scene I need to automate. I will figure out how to get it into webcore.
Thanks
I plugged this in and it works great. This will make it easier to automate the scenes in Webcore. Thanks
Just tried out the new version with support for power strips, which I have two of. It works well and I can control each socket individually. No issues. Thanks.
I saw you are tinkering with local support for lights. Any plans to eventually extend this to other devices like power strips? I'm slowing moving everything I can away from the cloud and am willing to test the code for you.
Thanks for the work you do. Devs like you make the community great. Much appreciated.
1 Like
@IguanaBob Glad it works! I do have a local driver for outlets/switches but it won't work on power strips due to the complexity of having multiple Hubitat devices for a single Tuya device and Tuya devices only allowing a single TCP connection but its not an impossible problem to solve down the road.
@SigFan86 I've not forgotten about the ceiling fan with light, now that the power strip works I'm closer to figuring a solution for this but limited time means I can't say when.
The driver now supports the Tap-to-Run automations from the Tuya app. For example, I have two automations one that turns on a group of lights, the other to turn them all off. I use this because they all turn on and off at once instead of the popcorn effect of sending individual commands. The two automations show up as Switch devices with the name of the Tuya automation and to trigger it you turn the switch ON (I considered making it a push button device vs. a switch, open to feedback on which works better)
4 Likes
I'm waiting on ceiling fan light 
Thanks, @jonathanb this is great!
Can you please add the importUrl to the definition so we can pull down updates easier?
definition (name: 'Tuya IoT Platform (Cloud)', namespace: 'tuya', author: 'Jonathan Bradshaw’, importUrl: ‘https://raw.githubusercontent.com/bradsjm/hubitat-drivers/master/Tuya/TuyaOpenCloudAPI.groovy‘)
3 Likes
Amazing, I'll have to update to this version on the weekend - I had hacked together my own from your original driver, but I think it was conflicting having both running at once, as sometimes devices became unresponsive. (Which is why I hadn't yet cleaned up & shared my code!)
The Tap-to-Run lets you do anything the app can do, even if this driver or the Tuya API doesn't support it yet.
Eg. I need it for my tuya-based Genio Xmas tree lights: they have 8 different flashing "modes", but they weren't exposed via the API (no scenes - only on/off and brightness params available). So I set up 8 tap-to-run automations, one for each "mode" and it was working great!
I had mine as a switch that automatically turned off after a second or two (so you could trigger it again later). Only because I didn't have much time to play with it & I wasn't familiar with how push buttons work on a dashboard, especially with the "num of buttons" param.
1 Like
