[Proof of Concept] Tuya/SmartLife Switches - Local Integration

I've referenced this a few times in the past---it's a roundabout way to get SmartLife switches working locally (without flashing!)

The methodology to get this working is somewhat advanced. I can't promise to support it, but I'll do my best to help.


You'll need to use your packet capture app of choice. I use iOS, so I have to tether my phone, *RVICTL*, and WireShark.

If you're on Android, you should be able to use something like Packet Capture , zAnti , or cSploit .

Capturing packets...

  1. You'll need to be on the local wifi network of the switches.
  2. In the Tuya/SmartLife/Whatever app, open the device page of the switch you want to control.
  3. Turn it off, and on. Again, make sure you do this from the individual device page
  4. At this point, you can stop capturing packets, and start looking through them.
  5. You may want to export the data for viewing on a desktop.
  6. Sort the packets by those sent to your device's IP.

The packets you want to find will usually have a length of ~300-400 bytes, and will begin and end like this:

0x45, 0x00, 0x00, 0xeb, 0x00 .... 0x00, 0x00, 0xaa, 0x55

The packets will be pretty long, but not consistent in length.

Test which packets work for on/off by using Packet Sender on a desktop. Enable persistent TCP for this step, or the tests will likely fail.

After a while of testing, you should find a packet for on, and a packet for off.

After you've captured and found your packets...

Take those packets, remove all of the brackets, braces, etc., and create a hex stream. Split the hex stream into four equal parts: ![hex string - split up|690x153](upload://bORMcNZHR2YXpv58Fgqvr9UZYJM.png)

Then, install the driver:

After Installation

  1. Create a new virtual device
  2. Assign the Tuya/SmartLife driver
  3. Add your device's IP
  4. Add your eight (four for on, four for off) hex strings to the settings:

... then, hit save!

You can now turn your Tuya/Smartlife device on and off from Hubitat. This communication is one-way only, so buckle up!


Also, flashing your devices is probably easier and more reliable than this. I initially did this as a challenge with a friend of mine to see which of us could reverse engineer the protocol of a $5 WiFi plug first.

We both realized that the switches I purchased were Tuya based, and that's where I left off. I don't really want to do more work with it for now, but I would presume that you could use the same integration method from HASS (the Tuya python library) to get the keys/certs needed to transmit commands locally.


Does this also allow you to get local changes on the device in Hubitat when they occur or is it only updated after a timeout?

It never gets updated in Hubitat :slightly_frowning_face: One-direction only. (Well, unless you use IFTTT! Then I suppose you could sync bi-directionally with some simple logic)

I don't use your code, but I have bi-directional IFTTT control by setting up 4 recipes for each switch in IFTTT; one each for on/off triggered from Hubitat; one each for on/off triggered by SmartLife. This way the device gets sync'd. So using your code this would replace the 2 IFTTT recipes for HE triggered events and can just leave the other 2 to synchronise SmartLife triggered events back to HE. Cool. But as you say, flashing with Tasmota would be a better solution.

1 Like

Depends on how comfortable you are with packet sniffing :slight_smile:

Yeah. More comfortable with that than with flashing, that's for sure :sweat_smile:

1 Like

Let me know if I can do anything to help you :slight_smile:

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.

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! :face_vomiting:

1 Like