Manually Add Yeelight bulbs?

Is it possible to manually add YeeLight bulbs via Hubitat's YeeLight integration, or can they only be found via UDP discovery. If they're only available via discovery, how do I raise a feature request for this?

The YeeLight LAN control protocol uses UDP multicast (from the bulb) for discovery, after that all that's needed to know is the IP address of a bulb (the bulb itself listens on TCP port 55443 for control). For those of us who use static DHCP on our routers, we can ensure a bulb always gets the same local address, so discovery is then unnecessary.

I don't like to but WiFi based IoT stuff on my normal wifi, but rather on my guest wifi SSID which is a different VLAN with AP isolation and no routing to the LAN. It's easy enough to setup a routing rule to allow the hubitat (other other LAN device) to access a device on the guest network via TCP, but the discovery process is holding me back.

Same request. I reluctantly moved my Yeelight bulbs to my main network, but I'd prefer to have them back on the IOT network.

I found a tool called udpbroadcastrelay that I'm able to run on my router (OPNsense). People have had success getting it to work with Chromecasts and some other IoT devices segregated on a different VLAN, but I've so far been unsuccessful with the YeeLights...

And this seems unnecessary... I can use yeecli on a computer that's permitted to talk to devices on the other VLAN

1 Like

Maybe the right thing to do is enable login security on the Hubitat and put it on the IoT VLAN with a router rule allowing access to the hubitat from the main LAN? Now that I think about it, I'm not sure why the Hubitat should be on the LAN instead of the IoT VLAN (at least once it's been secured).

2 Likes

This is actually a great idea! Why I didn’t think of it first…
Thanks

So putting the Hubitat on the IoT VLAN is what I did. But it's always bothered me that UDP Broadcast Relay didn't solve things for me. I finally sat down with the yeelight python package and Wireshark to explore a bit.

UDP Broadcast Relay has some configuration options:

  • listen port (1982)
  • listen address (239.255.255.250)
  • Source Address Mangling
    ** Replace source address with router's address and replace source port with listen port
    ** Replace source address with router's address, leave udp port alone

When you're on the same subnet as the bulbs, you send a discovery packet to 239.255.255.250:1982 and the bulbs respond to you on your source address and port.

With address mangling set to the router's address, the yeelights respond to the router. Neither of these options result in UDPBroadcastRelay forwarding the results.

With address mangling set to the multicast address 239.255.255.250, the bulbs don't reply at all.

With address mangling unset, the lights reply to the sender. So the only solution really is to add a firewall rule that allows the yeelights to send traffic to UDP port ANY to the LAN IP addresses that might be sending the discovery announcement.

So I think you could do:

  • udpbroadcastrelay listen on 239.255.255.250:1982 with no address mangling
  • firewall rule to allow yeelights on IoTVLAN to send UDP traffic to the hubitat (on LAN) on port 1025+

Ideal setup would use static DHCP reservations for the bulbs and either static IP or static reservations for the hubitat so that the firewall rules could be more restrictive. If we knew the hubitat always sent the discovery packet with a fixed UDP source address, the firewall rule could use that. The bulbs also send periodic announce packets (when they first connect to wifi and every hour or so, but I didn't capture any of these packets).