I read various articles and it's just so confusing. The hardware options. What to download. How to wire it up. How to execute the flash. I just know its going to be a whole world of trouble and I'll end up burning hours and hours and end up getting frustrated, swearing a lot, and then throwing it out the window much to my wife's annoyance lol. So right now I just use IFTTT on the various WiFi devices I have and tolerate the lag. May try your code here but its kinda only half a solution because the reverse sync is really still needed.
1 Like
I was thinking you could still use IFTTT for that part
Yes, would have to. Which means it's still reliant on the Cloud. Boo! 
2 Likes
I know this is a very old thread, should this still work? I did a packet capture on my firewall to the IP of my Tuya switch, and all the traffic is TLS 1.2, so it is encrypted.
Thanks,
Rick
Iād try to send them ahead of time with packet sender, or some similar app. Should work, though!
I don't follow. Do I need to capture with an app on the phone that will grab the data before encryption?
How does tethering the phone fit into this. I'm iOS on my phone, but Windows 10 pc.
Right now I'm doing the exact same thing as @Angus_M in post#4.
Thanks
Youāll need to use a packet capture app on a Mac or PC. Iāll see if thereās a method for capturing it in WindowsāIāve always used Mac in my iOS development environment
Linux has wireshark.. I happen to have a couple linux boxes running
I finally managed to make some progress on Tuya devices for Hubitat. This is still work in progress, but with this device handler I am able to send encrypted messages directly to my tuya Wifi siren turning it on without any external tools, it is just the Hubitat hub that calculates the message.
What you need to to pair the tuya device with one of the standard tuya apps, and get hold of the IP, device ID, device key (I used the register at iot.tuya.com and the Linux tools to extract the device key), and control endpoint. Once you have this information you just add it to the device preferences in Hubitat.
I used a package sniffer with the original tuya app to find out which endpoint to use, the Wifi siren I have has endpoint 104. But for other switches I think I have seen endpoints around 0-4.
I am posting this half finished work for others to get started with tuya devices on Hubitat. My next step is to decode the incoming message for the device.
[EDIT] Moving my repos to github as the import function doesn't seem to work for gitlab:
3 Likes
I searched and couldn't find it elsewhere.
I know that HA now supports local Tuya integration. Any way to do that with Hubitat?
gave up on this when i realized i need a separate pi just to update the firmware so it would work locally in hubitat.
I think that you can now have local control without flashing a new firmware, I'm just not sure whether it can be done with HE. See here for HA: DON'T use the Tuya Integration - get your devices off the cloud with Local Tuya - YouTube
I run my Tuya switches locally on HA - no need to update firmware. however I don't believe it would be possible on Hubitat as there is still no UDP support available.. 
It's a surprising omission for a company touting a local solution.
1 Like
Thereās been UDP for a few years. Iāve got three or four drivers that use it.
Really - you can listen for a UDP datagram - keeping the socket open permanently - and receive broadcast UDP ? I knew you could send a UDP datagram and process an immediate return but nothing beyond that.
@gopher.ny Is there persistent UDP support? Canāt remember if you can leave it open without checking my drivers.
You can return a HubAction with options containing type: 'LAN_TYPE_UDPCLIENT', and the hub will send a UDP packet. A response, if any, will appear as a callback to parse method.
There is no listening on the port without sending something first at the moment, though.
What's the use scenario?
@kevin would have to tell you the use-case. Iāve always just polled UDP devices for state changes, which has been working great for a few years now.
It is for any use case where a device pushes out a UDP packet - typically broadcast for status events. Quite a lot of devices actually do this. Because they are unsolicited and sporadic HE canāt receive them.
Tuya switches do this I believe when switched so tracking status requires it.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
