Xiaomi Yeelight Strip not supported in HA 50.1

Configuration
41

Well, here is the new turn. After I restart the HA, the yeelight cannot be found again like before. It listed as unavailable in the frontend and of course could not be controlled. That’s so strange because I didn’t change anything.

42

I will check what happens to mine after a reset.

44

Mine are working after a reset. So let’s take this step by step. Do you have friendly names for the strips because I wonder how they show up on your states but are unavailable. What name do they have in your states? Which version of HA are you running and are you using HASS, Hassbian or…? Can you change your ultra-minimalistic config and add the ‘platform: yeelight’ just to make sure we’re doing the same thing.

By the way I also have “Unknown miio device found” warning in my log but they work anyway.

45

Well, speak to environment, I am using the latest 0.51.2 HA, installed by All-in-One method. I did give strip a friendly_name. My mi app is set to Mainland of China.

I did a series of experiment last night.

  1. Light is in Singpore Server. I add the platform: yeelight configuration, the result is an error saying that I didn’t fill ip. Then I add ip, and the light show up in frontend with friendly_name but status is unavailable. So conclusion is that you just cannot add any platform configuration.

  2. I change the server to Mainland of China. Besides the Unknown miio device found, the light disappear at the front end. Add the platform configuration, failed. Add detailed configuration include ip, failed. So China Server doesn’t work for me.

  3. I sense that it uses udp, so I doubt maybe it is relevant to my router’s proxy. But after I turn off proxy, everything stayed the same. So it is irrelevant.

  4. I also notice that the light have to be on when start HA, or HA would not discover it. I think this procedure is to push light to send signal to server.

Here’s my conclusion: Region Singpore with no configuration work for me.

As for Unknown miio error, I guess it is result of discovery? Or relevant to Xiaomi Gateway Components? That makes system regard it as mi device by default and search for mi platform.

Anyway, the light strip is working well now. Thanks for your help~~

46

Strange, how long did you wait after a reset of HA because I have noticed it can take quite some time before they are discovered (same for the other yeelights I have). I have never switched them on and they are still discovered automatically by HA. I think we get the unknown error because the component only recognizes white or rgb not strip. Atleast that is how it looks to me after a quick look at the code.

47

Perhaps 5 - 10 minutes? If I don’t turn the light on manually, then it would not be discovered forever. But once I turn it on, it is added to frontend immediately without any delay.

So actually we can add a type of strip into code to avoid error?

48

As far as I can see it’s either white, color or unknown. HA discovers it as a color light from requesting the properties (I assume). I found this comment in the python-yeelight library:

When trying to access before properties are known, the bulb type is unknown.

This might be the reason it shows up in the log as unknown. But truly speaking I have no idea :grin:

49

I checked the python-yeelight documents as well. Yeah, you are right. And the maker didn’t open issue board, so we cannot create one. Sigh…

50

I think you can on:

51

I just changed my configuration with fixed ip-addresses for my yeelight blubs and strips. Everything works fine but the HA log still gets spammed with a ‘unknown miio device found’ warning. @cxlwill did you report an issue on this?

52

Ia the warning from the discovery component? Can you post it here? I’ve fixed it a while ago for the yeelight strip, and I think it was out in 0.51.

53

Really? this is the warning I get in HA 0.51.2;

> 2017-08-19 16:17:23 WARNING (Thread-8) [root] Unknown miio device found: ServiceInfo(type='_miio._udp.local.', name='yeelink-light-strip1_miio56724911._miio._udp.local.', address=b'\xc0\xa8\x05i', port=54321, weight=0, priority=0, server='yeelink-light-strip1_miio56724911.local.', properties={b'mac': b'34ce0087b050', b'epoch': b'1'})
> 2017-08-19 16:17:23 WARNING (Thread-8) [root] Unknown miio device found: ServiceInfo(type='_miio._udp.local.', name='yeelink-light-strip1_miio56728590._miio._udp.local.', address=b'\xc0\xa8\x05j', port=54321, weight=0, priority=0, server='yeelink-light-strip1_miio56728590.local.', properties={b'mac': b'34ce0087beaf', b'epoch': b'1'})
54

I’m getting the same thing with the following error:

2017-08-19 19:50:12 ERROR (SyncWorker_7) [homeassistant.components.light.yeelight] Failed to connect to bulb 10.0.0.23, yeelight_UNKNOWN_34ce0087d2e0: A socket error occurred when sending the command.

To me, that means there is an error with the port config.

I’m also getting that milo warning as well.

It just shows like this:

27
271004×392 16.6 KB

YLDD01YL strip.

This is my config:

light:
  - platform: hue
    host: 10.0.0.3
    allow_unreachable: true
  - platform: yeelight
    devices:
      10.0.0.23:
        name: Bedroom-Strip
        transition: 1000
        use_music_mode: true

Mainland China server for the app, which is the closest to me by 2k+ miles, so I hope that isn’t the problem just for latency sake.

55

Sorry, it wasn’t released in 0.51 after all. Anyway, if you configure the device using its IP, instead of auto-discovery, you can safely ignore the warning.

The commit is here: https://github.com/home-assistant/netdisco/commit/03c773b99c13a28886b4074f2028bbc63e8c56b8

1 Like
56

Thank you for the information @abmantis I manually changed it and the warning messages are gone.

@nicholasgriffintn have you enabled the developer mode?

57

Thank you @abmantis, mine works without warning as well by following your code changes manually.
@nicholasgriffintn First, make sure you turn developer mode on. If you have done it, then you can try delete all yeelight configuration to make HA discover and add it automatically.

58

I had developer mode turned on, I did a bit of messing around with the config and it did eventually work, which is great.

The guide for it should definitely be updated with the troubleshooting information that we have found out, I looked at it before purchasing and it seemed easy, it definitely wasn’t lol.

The note about turning developer mode on should also be moved up the article imo.

That all said, it’s working fine now, however, it’s not very responsive, I presume that’s simply due to the price of the strips, which I’m fine with.

59

Congratulation first for successful work~ I think if correction of netdisco comes next HA update, then there is no warning to be concerned about. Maybe they could add some information about automatic discovery of strips and support for both two models of strips.

60

They are usually responsive, but if you do many consecutive requests, they will lock. Usually it is not an issue since you don’t do like 1 request per second. If you need them to handle more requests, enable music mode in the config.