More IoT stuff: Tuya Local
It occurs to me just now that I didn’t note the process of configuring localtuya, so I should probably do that here in case I ever have to rebuild my setup.
First, it’s important to note the version that I’m using, which is a fork of the original
localtuya and is in turn completely different from
tuya-local which is another plugin. The reason I selected this particular fork is because it has the ability to pull the keys directly from your cloud account, which will come in handy shortly.
Installation is pretty easy - I’m using a Home Assistant container on my Kubernetes cluster, so I don’t have the fancy auto-plugin-install stuff. But just copy the
custom_components/ dir into the
config dir for homeassistant, then configure the plugin per the instructions using my cloud credentials.
Next, pulling the keys requires you to “auto-discover” the bulbs, you can’t manually say “hey, pull this device’s keys” to the plugin. Discovery requires UDP broadcasts, which means the Home-Assistant container needs to be on the same physical network as the bulbs, which is a problem for me… the bulbs are on their own VLAN, and the container is in a VXLAN on a cluster (on a bump on a log…).
So first thing, setup a Metal LB service to expose the IRC port (yes, really) that the lightbulbs use on UDP to the rest of my LAN:
ports: - port: 6667 protocol: UDP name: homeassistant-tuya targetPort: 6667
This ended up creating a load balancer on the IP 10.255.0.4. Now we just have to get packets to it! It turns out the protocol is really simple, so if I just run
socat on a device that straddles the networks (eg my router, as root but probably not required):
socat UDP4-RECVFROM:6667,broadcast,fork UDP4-SENDTO:10.255.0.4:6667
Surprisingly, it doesn’t care that the packets come from the wrong IP or anything, the protocol must include identifying information with the correct IP and the HA integration pays no attention to the actual sender IP.
I don’t leave this running permanently, I just have to remember to configure it for each new device we have to pair (and I can do that right before firewalling it off the internet). Anyway, the lightbulbs show up, I use the IoT platform’s device debugging screen to show me the order of the fields, but here they are for the Genio light bulbs:
Id: Field 20 Work mode: Field 21 (white, colour, scene, music) Brightness: Field 22 Brightness lower: 10 Brightness upper: 1000 Color Temp: Field 23 colour data: Field 24 scene data: Field 25 countdown: Field 26 (Unused on HA?)
Once this is all set up, we can use these new devices instead of the ones in the Tuya Cloud integration, and I can then firewall the websockets off and it all still works (indeed, they still work without the internet on to the house at all).
I set up my switch in much the same fashion, and I found that I was able to use the switch to control a lamp using a pair of automations, eg something like:
alias: Lamp - On description: '' trigger: - platform: device type: turned_on device_id: ae74acba41c878c3a9e0f52e170d7302 entity_id: switch.6912ha_series2_switch_1 domain: switch condition:  action: - type: turn_on device_id: 73a23bad97e7b8080891da211b59e82b entity_id: light.genio_smart_wifi_bulb_a60_rgb_cct domain: light mode: single
So the process for a new device is:
- Buy it, plug it in.
- Open the Tuya Android app on a given phone/tablet and pair the new device.
socaton the router.
- Open the settings on HA, click “Add new device” and select the new device which hopefully shows up in the dropdown. This normally takes no more than 30 seconds, tops.
- Once the device is added, the keys are automagically imported, we can just firewall the device from the internet (it stops working on the Tuya Android app but that’s OK).
… and that’s it!