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.
  • Start socat on 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!

Horsham, VIC, Australia

Author:

fwaggle

Published:


Modified:


Filed under:


Location:

Horsham, VIC, Australia

Navigation: Older Entry Newer Entry