Is it possible to move Tuya local control devices to a separate VLAN?

[TC1]

spud I was able to successfully setup a BN-LINK Smart Plug using the Tuya PI (thank you!), my ultimate goal is to put all my IoT devices on their own VLAN for security and QoS if needed.

Does the Tuya PI rely on broadcast traffic from the device on ports 6666 and 6667? Or are you using some type of callback mechanism?

[kenm]

TC1 I have all of my IoT devices, including Tuya, on their own VLAN. I then allow access from my HS machine to that VLAN and also from that VLAN back to my HS machine, but only for established connections. In other words, new connections cannot be initiated from the IoT VLAN. There's one exception to that; I allow MQTT devices to connect to port 1883 on my MQTT broker.

[TC1]

Thanks kenm , but are you using the Tuya local control that HS plugin just implemented? From what I've researched, Tuya devices like the BN-LINK smart plugs are using UDP broadcasts for some comms, which will not transverse vlans (without a broadcast relay). I would love to be proven wrong on that

[silverton38]

If you are worried about to much traffic on your WIFI consider using the Tuya Zigbee hub and buying Tuya Zigbee compatible devices over WIFI. They are about the same price.

[kenm]

Thanks kenm , but are you using the Tuya local control that HS plugin just implemented? From what I've researched, Tuya devices like the BN-LINK smart plugs are using UDP broadcasts for some comms, which will not transverse vlans (without a broadcast relay). I would love to be proven wrong on that

Well, TBH, I thought I was, but it doesn't look like I am. Someone said that if there's an IP address next to the device in the "Manage Devices" then it's local. As a test, I blocked WAN access for my IoT VLAN, and sure enough, I couldn't control my lights anymore.

So how do you go about enabling local control? I'm happy to test it out against my setup.

Ken

[TC1]

There has to be a green check-mark next to it to indicate local control:



No worries, I've got an experiment queued up in my lab to try it out with a spare smart plug (2 for $16 was a bargain).

I'll create another VLAN, put the appropriate FW rules in place to allow open traffic across VLANs in the beginning, attempt add the plug to the IoT VLAN, see if local control can be obtained. I'm running pfSense so if it fails I'll have to figure out about adding broadcast relay helper services.

Local control for the Tuya PI is on a device-by-device case, check the PI release notes for devices supported.

[kenm]

There has to be a green check-mark next to it to indicate local control:

That's that part I missed. No checkmarks here.

After more research I've found out that my firewall (UDM Pro) can't be configured with a broadcast relay. Hopefully you'll have better luck with your pfSense.

[TC1]

I got everything working.... took a whole afternoon of experimenting to fully understand what the heck is going on. I hope to write it up or diagram it so that others can benefit.

[Black Cat]

I got everything working.... took a whole afternoon of experimenting to fully understand what the heck is going on. I hope to write it up or diagram it so that others can benefit.

looking forward to the in depth write up....

[TC1]

Ok, so here is what I found out...

Summary: Yes, local control can work across VLANs for those that want to isolate their IoT devices for security or other reasons. While control works, full status is not local and dependent on the Internet which I'll explain. Also, for local control it needs to be a Tuya device that Homeseer supports for local control (not all of them work at the moment).

What happens:

• Assuming you've already setup your VLANs, you need to temporarily have a PC (will use the Tuya web page) or smart phone (will use the Tuya Smart Life app) on the same VLAN where you intend to install your IoT device. I used my smartphone since it's easy to join the IoT wireless SSID/VLAN and then switch back to my main VLAN.
• Your IoT VLAN needs to allow Internet access for the inclusion process.
• Firewall rules:
  • Private VLAN ---> IoT VLAN = Allow
  • Private VLAN ---> Internet = Allow
  • IoT VLAN ---> Internet = Allow
  • IoT VLAN ---> Private VLAN = Block (if you want IoT isolation)
  • The tricky part: You have to be ableto pass Broadcast UDP traffic from the IoT VLAN to the VLAN where your HS4 instance is (Private VLAN in my case). Firewalls do not normally do this, you need some form of a Broadcast Relay/Proxy. In my case I got lucky in that my Unifi wireless AP and Unifi switch support passing broadcast traffic from the wireless network to the wired network.
• Using the Smart Life app you create your account. Then you add a device to your account. Once you complete that you should be able to control the device (in my case a BN-LINK smart plug) from your phone.
• Now move your phone back to your Private VLAN. If your network is setup as described above you should be able to still control the Tuya device.
• Goto the Tuya PI on HS4 and start the authorize process if you haven't done already. This allows the PI to talk to the Tuya API on your account.
• Once that is successful, have the PI read the devices on your account. What that does is pull down the device info and the security token/certificate that allows the PI to talk to the Tuya device directly. Then have the PI create a Homeseer device, if successful you'll have the device listed with its IP on your IoT VLAN and a green check mark next to it:
  
• Notice I have two devices, the one on the 10.1.10.0 network is the IoT VLAN and the other one is still on the same network as my HS4 PC, this was so I could do A/B testing on different cause and effects.

• You should now have a HS4 device created where you can issue CAPI control from:
  
• When you turn the smart plug on from either HS4 or at the plug, it will then respond with a UDP Broadcast indicating the current On/Off status and the energy monitoring stats. Since it's a broadcast, all devices listening on the UDP port (the Tuya PI and your Smartphone app) will get the updates. These devices will send their stats similar to how Zigbee devices work, in that, they don't report on a cyclic basis that you set, but instead whenever the environment changes (this why I prefer Zigbee sensors over Z-wave ones).
• Now block Internet access from your IoT VLAN, you'll notice that you can still control the Tuya device and get status updates, proving that control is in fact local. Also, while observing my firewall logs, the Tuya device never attempted to access the Internet since I would have seen the blocked attempt.

Now the bad part:

• So I unplugged the smart plug from the wall socket and guess what happened? Nothing. Meaning that I was issuing On/Off commands from the HS4 web page, The HS4 device switch status was changing, but in fact nothing was happening. Eventually the "State" child device turned red and indicated Offline.
• I plugged the smart plug back into the wall and guess what happened? Nothing. The State did not change back to Online on the HS4 device, nor did the Smart Life app know it was back Online. Local control did work again and also status updates via the UDP broadcasts.
• What I did see though was the Tuya device continuously trying to phone home to the Tuya cloud. Apparently when these devices power on they are programmed to contact the Tuya cloud to update their State. When I Allowed Internet access from the IoT VLAN again, then HS4 finally knew it was back Online once the Tuya PI polled the Tuya cloud.
• So basically, while control is indeed local, without Internet access then HS4 has no idea whether the device has been powered down and back up. Below is the network traffic flow of what I believe is going on:
  

Suggestions for the Tuya PI:

spud would it be possible to incorporate a loop/feedback mechanism in that when a CAPI command is sent, don't assume the Tuya device received it unless it gets a UDP broadcast back? And once a UDP response is received then change the State status from Offline to Online rather than relying on the Tuya cloud? I apologize if I misrepresented anything, these are simply my observations after running various scenarios.

Thanks for listening.

[spud]

The Tuya plugin rely on UDP broadcast traffic on ports 6666 and 6667 only for discovering the devices at startup or when the "Read devices" button is clicked. Once devices are discovered, then UDP is never used anymore, all local control and status updates are done using a TCP connection on port 6668.

The Online/Offline status represents the status of the connection with the Tuya cloud, so if the device cannot access the internet it will show as Offline (even if the plugin can connect locally). So, for devices for which local control is supported we probably need to add a new "Local control Status" feature which would show if the plugin is connected locally to the device or not.

[TC1]

The Tuya plugin rely on UDP broadcast traffic on ports 6666 and 6667 only for discovering the devices at startup or when the "Read devices" button is clicked. Once devices are discovered, then UDP is never used anymore, all local control and status updates are done using a TCP connection on port 6668.

Thanks for that clarification. So basically once the "controller" (either the Tuya PI or the smartphone app) sends a command to the target Tuya device, it keeps that TCP connection open which allows the device to send back status changes? I'm assuming that's the case because I can get status updates on both HS4 and my smartphone simultaneously, which I assumed was because the Tuya device was broadcasting and I've also blocked the device from initiating TCP connections back to the VLAN where HS4 is.

The Online/Offline status represents the status of the connection with the Tuya cloud, so if the device cannot access the internet it will show as Offline (even if the plugin can connect locally). So, for devices for which local control is supported we probably need to add a new "Local control Status" feature which would show if the plugin is connected locally to the device or not.

That sounds awesome, is there anything you need for me to do to help with this feature request?
Thanks again for your support on this.

[spud]

Thanks for that clarification. So basically once the "controller" (either the Tuya PI or the smartphone app) sends a command to the target Tuya device, it keeps that TCP connection open which allows the device to send back status changes? I'm assuming that's the case because I can get status updates on both HS4 and my smartphone simultaneously, which I assumed was because the Tuya device was broadcasting and I've also blocked the device from initiating TCP connections back to the VLAN where HS4 is.

Yes the TCP connection stays open.
In some instances I have seen the plugin unable to open a TCP connection with a device if the Tuya app was opened, so some devices may allow only one TCP connection.

[TC1]

The Tuya plugin rely on UDP broadcast traffic on ports 6666 and 6667 only for discovering the devices at startup or when the "Read devices" button is clicked. Once devices are discovered, then UDP is never used anymore, all local control and status updates are done using a TCP connection on port 6668.

The Online/Offline status represents the status of the connection with the Tuya cloud, so if the device cannot access the internet it will show as Offline (even if the plugin can connect locally). So, for devices for which local control is supported we probably need to add a new "Local control Status" feature which would show if the plugin is connected locally to the device or not.

spud I noticed that a new Tuya PI beta was posted and was wondering if local status was still on your radar

Thanks!

[spud]

spud I noticed that a new Tuya PI beta was posted and was wondering if local status was still on your radar

Thanks!

I have just released another beta (version 4.0.32) which adds a new "Local Connection" device feature. You will have to install that version and then go to the "Tuya > Manage Devices" page then select the devices and click the "Create HomeSeer Devices" button for the new feature to be created.