Core: Yeelight doesn't work with hostnames, only with IP address

[zoe1337]

Home Assistant release with the issue:
0.77

Operating environment (Hass.io/Docker/Windows/etc.): Arch Linux, no Docker.
Component/platform: yeelight

Description of problem:
Not sure if this is a bug or a feature request. Yeelight devices work only if configured using their IP address, not with their hostname. Hostname resolution with mDNS works fine on the same host.
Auto-discovery finds the devices and knows their hostname, but when I configure it manually (using the hostname), it shows "unavailable". IP address works.

Problem-relevant configuration.yaml entries and (fill out even if it seems unimportant):
doesn't work:

light:
  - platform: yeelight
    devices:
        yeelink-light-ceiling1_mibt57663155.lan:
            name: Rechenzentrum
            transition: 1500

works:

light:
  - platform: yeelight
    devices:
        192.168.0.112:
            name: Rechenzentrum
            transition: 1500

[robertbeal]

Ah interestingly I've had issues with mine recently, possibly around this. I use Hassio too, on 0.77.1. I was having the problem in 0.76 (possibly 0.75 too).

Mine still work via hostname, my config looks like this:

light:
  - platform: yeelight
    devices:
      store-light:
        name: Store
        transition: 500

However, a couple of weeks back I added discovery to my configuration.yaml (I've always had it off) and without realising, I ended up with 2 "store" lights on my homeassistant, one under the hostname, and the other via the ip.

During this period I had constant problems as my lights would become "Unavailable" randomly and require a a power cycle to get them back.

I've since dropped discovery and my lights are happily working via hostname, and there's only 1 instance (as discovery isn't picking up a second).

If I get a chance I'll delve into the component, and try to recreate the issue by adding discovery back into config. For now I thought I'd give my experience of it in case it helps someone pin-point the issue (which I think is discovery related).

[robertbeal]

Looks like my statement above is a red herring. There's a distinct if/else on whether it uses discovery or config (and not both):

https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/light/yeelight.py#L146

However, I would try switching off discovery, see if that helps. I guess the ideal solution would be both work, and the component realises if a configured and discovered device are the same.

[zoe1337]

You can use

discovery:
  ignore:
    - yeelight

[robertbeal]

Learnt something new today! Although a combination of the two would still be the ideal.

[SebDominguez-zz]

Same problem here.

```yaml

• platform: yeelight
  devices:
  yeelink-light-color2_miioXXXXXX.local:
  name: Test
  model: color1

Doesn't work...
 ```yaml
  - platform: yeelight
    devices:
      192.168.0.10:
        name: Test
        model: color1

Does work.

[frenck]

This is actually a limitation of the YeeLight Python library used.

https://gitlab.com/stavros/python-yeelight/blob/master/yeelight/main.py#L233

The data passed, must be an IP address.

[SebDominguez-zz]

It would be nice to be able to setup the lightbulb by hostname instead of IP. Having to configure statics lease for each Yeelight on my DHCP server is really annoying

[robertbeal]

Nothing a socket.gethostbyname() in the homeassistant component wouldn't solve. Although it would be better if it was in the underlying library. All the above said, mine works via hostname, always has. No idea why, can't see what in the code translates it but it definitely works.

[rytilahti]

As frenck said, this needs to be handled in the backend library, please open an issue at https://gitlab.com/stavros/python-yeelight .

[SebDominguez-zz]

As frenck said, this needs to be handled in the backend library, please open an issue at https://gitlab.com/stavros/python-yeelight .

The maintainer of this project kindly told me that his lib can either use an IP or a hostname...

[skorokithakis]

Hey everyone,
Here's a session where this works:

In [1]: from yeelight import Bulb

In [2]: b = Bulb("lamp")

In [3]: b.toggle()
Out[3]: 'ok'

From the Python documentation:

A pair (host, port) is used for the AF_INET address family, where host is a string representing either a hostname in Internet domain notation like 'daring.cwi.nl' or an IPv4 address like '100.50.200.5', and port is an integer.

I don't think we're doing anything special to make this fail.

[rytilahti]

Ah, sorry for the noise then. Could you at least include a log what you see when the bulbs go to unavailable state, in best case with debug loggers enabled for both the platform (homeassistant.components.light.yeelight) and and the backend lib (yeelight)?

@robertbeal setup_platform gets called separately for automatically detected bulbs and for manually configured ones. There is an issue open related to overwriting the hass.data stored reference (#17470), which causes issues when having both manually defined and automatically discovered devices, but I'm not sure how that would cause the failure described in this issue (it is not like the object gets completely lost somewhere).

[SebDominguez-zz]

2018-12-15 23:14:28 ERROR (SyncWorker_5) [homeassistant.components.light.yeelight] Failed to connect to bulb yeelink-light-color2_miio87701750.local, Lumière Séb: A socket error occurred when sending the command.
2018-12-15 23:14:32 WARNING (MainThread) [homeassistant.components.light] Setup of platform yeelight is taking over 10 seconds.

[skorokithakis]

This is really odd though, it does look like the error is coming from the yeelight library. Can you insert a print statement before the connect line to print the address (host and port)? Other than that, are you running in docket or something that does its own networking?

[SebDominguez-zz]

I'm running hassio / hassos (whatever it's called it now): directly on a Raspberry Pi. No Docker.

Please can you be more explicite on witch file I have to alter and where precisely I need to add the print statement? I'm not a hassio dev so I'm kinda lost with such request.

[skorokithakis]

Look for yeelight/main.py and add a print(self._ip, self._port) just after self.__socket.settimeout(5).

[SebDominguez-zz]

I don't have the smallest clue on where yeelight/main.py is supposed to be on Hassio's filesystem. I tried to look for if without success.

[balloobbot]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:

[SebDominguez-zz]

Nop still doesn’t work

[robertbeal]

Have you tried ssh'ing onto your hassio/hassos instance and running the dig command for the hostname of a bulb to see if it gets an answer?

All my bulbs still work via DNS, always have. Could this be a DNS issue rather than a HA issue? (I'm running OpenWRT which manages my DNS). Have you tried dropping the .local or .lan TLD from your hostnames?

[neuman1812]

--Not sure if this should be a new issue or if this one is related, but I also have the "dual yeelight" component issue when discovery is enabled.

Example: https://i.imgur.com/xHiM8RF.png

The yeelight...macaddress are the entities added when discovery is enabled. For now I have it on ignore. I found this issue after a google search.

[rytilahti]

@neuman1812 the dual lights problem happens when you have static configuration and some bulbs are automatically detected (there is no way to differentiate between them), that is not related to this issue.

[neuman1812]

Than you yes, so I will open it as a separate ticket then.

[rytilahti]

@zewelor was working on to convert the yeelight into a component, so in the future we can convert from netdisco discovery to use the yeelight's proprietary one (and with it obtain an unique ID) which will alleviate that issue. Until then there is not much we can do.

[zewelor]

I think duplicated bulbs should work better after merging my PR, because I'm checking if there is already bulb with ip address ( https://github.com/home-assistant/home-assistant/pull/21593/files#diff-247b0c43cc33cf62e58c364503d69215R225 ). First manualy added bulbs are initialized, and then when netdisco discovers more, they are check if they exists ( via ip ). As @rytilahti says, after using yeelight unique id it should be even better.

[stale[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.