Thanks mate. I’ll revert back to 0.114.4.
Is this confirmed? My devices are all in the same VLAN and I just retested to upgrade HA and discover all as well as trying a Yeelight IP directly but either way it doesn’t work.
2020-11-02 08:00:01 ERROR (MainThread) [homeassistant.components.yeelight.config_flow] Failed to get capabilities from 10.10.1.104: timeout
What is confirmed?
If HA and yeelight are in the same VLAN it works.
If they are not it doesn’t.
Which HA installation are you using? If your are using HA container, then it must be in “host” mode and not bridge.
Otherwise, I am using 0.116.x and it works…
Is it confirmed as of only different VLANs don’t work. But you just answered that. Then idk what my issue is that it doesn’t work for me… The HA setup is ofc since always running host mode.
Anyone else with Unifi has/had the same issue?
Experience of a few users seems to lead to this conclusion. So “confirmed”, not really but almost 
I am not using unify.
There’s a new release out. 0.117.2. Anyone tried it yet? Does it resolve our issue with not having yeelights working if they are on a different vlan than HA?
Here’s what’s listed in the release notes:
Release 0.117.2 - November 1
- Bump pwmled to v1.6.6 (@soldag - #42607) (rpi_gpio_pwm docs)
- Fix Fibaro HC2 climate device missing temperature (@airthusiast - #42627)
- Fix geo_rss_events import statement (@exxamalte - #42629) (geo_rss_events docs)
- Bump pycfdns to 1.2.1 (@ludeeus - #42634) (cloudflare docs)
- Make sure Tasmota status sensors are disabled (@emontnemery - #42643) (tasmota docs)
- attempt to renew subscription immediately to stop endless loop if it fails after setup (@hunterjm - #42651) (onvif docs)
- Bump up ZHA dependencies (@Adminiuga - #42679) (zha docs)
- Fix canary camera entity inheritance (@ctalkington - #42691) (canary docs)
- Use pylutron_caseta 0.7.1 (@mdonoughe - #42701) (lutron_caseta docs)
Since nothing is mentioned in the release notes, I would assume it is still not working if the yeelights are in a different VLAN.
Yeah I’m thinking as much myself. I was just curious if someone actually gave it a try. 
Did give it a try. Yeelight on different vlan still not working for me on 0.117.2
Thanks for letting us know. 
It’s a shame it’s still not in the release. 
Still nothing on 0.117.04 …
Yeah. Annoying. I think, I read somewhere on Github that it is being tested in the 0.118 beta. Let’s keep fingers crossed that it makes it into this release…
New release out. Still nothing regarding this issue though.
Release 0.117.5 - November 5
- Bump hatasmota to 0.0.25.1 (@emontnemery - #42850) (tasmota docs)
- Clean up SimpliSafe binary sensor implementation (@bachya - #42841) (simplisafe docs)
- Fix missing sensor exceptions in SimpliSafe (@bachya - #42845) (simplisafe docs)
- Fix missing/incorrect SimpliSafe entities (@bachya - #42846) (simplisafe docs)
- Fix Netatmo public weather sensor bug (@cgtobi - #42858) (netatmo docs)
- Revert “Fix broken maxcube component” (@onkelbeh - #42859) (maxcube docs)
- Bump bimmer_connected to 0.7.12 (@rikroe - #42875) (bmw_connected_drive docs)
Indeed, i am having this issue with docker installation as well and i can not use host networking. Waiting for a fix of this regression.
The fix made it into 0.118.0! Finally! Has anyone been brave enough to give it a try already?
Nope… I don’t do .0
Me too. 
It works, but not with auto discovery. I had to set the light’s IP as host
1 Like
Great. Thanks for the feedback. I have set up my Yeelights in configuration.yaml with their IP addresses anyways. So I guess, I will give it a try once 0.118.1 comes out.
I can confirm that everything is working fine with Yeelights in a different VLAN (version 0.118.2).