Yeelight Application Shows Wrong Lamp Status

Hello,

First thing first, I think this forum needs a category “Mobile Application” in order to discuss issues/suggestions related to the application.

Now I am facing the following issue with the mobile app and my Color LED Bulp. The mobile app will not show the correct lamp status after any change.

For example.

  1. My lamp is on right now.
  2. I open the app and it shows in the list that the lamp is off. I try refreshing the list, it still shows off.
  3. I enter the lamp’s control page where it shows the night sky (a.k.a it thinks the lamp is off)). I press the power button
  4. My lamp still remains on and the page now shows the lamp is on.
  5. I enter the scenes page and apply one.
  6. I return to lamp’s control page and it shows the night sky even though my lamp is still on.

I have also noticed another scenario where:

  1. My lamp is on right now.
  2. I open the app and it shows in the list that the lamp is off. I try refreshing the list, it still shows off.
  3. I press the power button for the lamp from the list page.
  4. My lamp turns off and the list page shows that the lamp is off
  5. I press again the power button from the list page
  6. My lamp turns on and the list page shows it is on
  7. I enter the lamp’s control page and it shows the night sky (a.k.a it thinks the lamp is off)

It seems the app does not refresh the lamp’s status either when opening the app neither when browsing between app pages.
I also tried the Xiaomi Home app where the above problems do not exist! There the lamp’s status is always correct. But the Xiaomi Home does not have the music mode option so I want to keep using the Yeelight app.

Anyone with the same problem?

Thanks for your suggestion, we will consider it.

For the wrong status issue, actually the application will retrieve status of all devices when you open the app. And when you send a command to the device, it will return the current status to application after the command runs successfully. However, if there is something wrong with the network, such as a long latency, the application maybe can’t receive the statue change message. That’s the reason why you encounter the issue.

Which locale do you select, Singapore or China Mainland? Do you have a sensate latency when you control the device? What platform of your phone, IOS or Android?

If there is long latency when you control the device ,please try to change your locale, reset the device, connect it the cloud and try again.

BR
Andy

Hello dingyichen,

To answer your questions:

  • I am on an android device with Android version 6.0.1

  • I have been using since the begining Singapore locale

  • I have tried many times resetting/re-configuring/re-installing. Nothing has changed.

  • As far the latency:
    Yes you could say there is a negligible latency. Not even half a second. Feels like 1/4 of a second. I tried enabling the “Lan Control” option in the settings menu and I think it was definitely faster. But even with the “Lan Control” enabled when switching pages in the app, the status of the lamp shown in the app is wrong.

  • The problem does not happen with the MiHome app. What is so different about their implementation? I have tried controlling the device with only the Yeelight app installed, only the MiHome app installed, and both of them installed. Each time the MiHome shows the status correctly.

Update:

Sorry when you said latency I thought you ment from the time a press a button in the app, until the command is completed by the lamp.

So I pressed the power button in the app to switch off my lamp. The lamp did turn off and I remained to same page app. After almost 8 seconds the status of the lamp was updated! No difference even with “Lan Control” enabled. Its always 8 to 9 seconds until the app shows the updated status.

I never waited that long on the page after pressing a button in the app, so I didn’t realize it was working but very very slow. Why is it taking so much time? The MiHome updates the status almost immediately! Is this something to do with the cloud service? But even so when “Lan Control” is enabled shouldn’t I see a significant difference?

It’s really a long latency, could you disable “Lan Control” and try to ping “ot.io.mi.com” and see the result.

Pinging from the mobile and laptop does not show any latency

Mobile ping

[/details][details=Laptop ping]

Is there any way I can see or send statistics or debug info from the Yeelight app?

400-500ms is a long latency, so maybe lots of device statue callback are missing. Our application retrieves device statue every 10 seconds, so after you press the power button, the application needs about 8 seconds to update statue.

How about the ping result of “sg.ot.io.mi.com”? This is the cloud of Singapore server.

Pretty much the same:

Mobile ping sg.ot.io.mi.com

Laptop ping sg.ot.io.mi.com

Does the MiHome use the same endpoints? If yes, then maybe the delay in the application is from something else.

What’s your ping result with mobile network?

No significant difference from the 4G network also.

4g Ping

I am also trying to develop a C# client for the lamp. I was unable to even find the lamp. But then i bumped the timeout of the udp socket to 20s and I finally received the search response from the lamp. I have tried resetting the lamp, still no difference.

You can “telnet device’s ip 55443” and typing some commands to do some tests. Through this method, you can verify if the lamp is working properly.

Yes I tried that last night when I couldn’t discover the lamp at all. I used telnet to connect directly and the lamp would answer me with the default error payload that the command is not right. So the lamp seems to be working.

Could it be something to do with my router? I installed wireshark to watch the packets from the WiFi adapter but I don’t understand if there is something out of the ordinary. What I still don’t understand is that if it was a problem with my network configuration, then MiHome app should have the same delays. But it doesn’t. Is MiHome using other ways to communicate with the lamp?

They are using the same protocol, but with a different server. All the traffic are encrypted, so tcpdump/wireshark is not very helpful. Please let us know your Xiaomi account, we will check the log in server side.

Ok, I ll send it to you with private msg.

I can confirm absolutely the same behaviour on my side. Yeelight Ceiling Lamp and Yeelight Smart Bulb are both update their statuses like not in real time at all. It takes 8-10 sec to update statuses in the Yeelight app.

I’m from Europe, use Singapore server. I tried LAN control on and off, has no any difference. My internet connection is fast and reliable, so can’t tell what’s​ the reason.

Please let me know if I can help to address the issue.

[quote=“sviperz, post:15, topic:869, full:false”]
I can confirm absolutely the same behaviour on my side. Yeelight Ceiling Lamp and Yeelight Smart Bulb are both update their statuses like not in real time at all. It takes 8-10 sec to update statuses in the Yeelight app.

I’m from Europe, use Singapore server. I tried LAN control on and off, has no any difference. My internet connection is fast and reliable, so can’t tell what’s​ the reason.

Please let me know if I can help to address the issue.[/quote]

Have you also tried controlling them with MiHome app? Any differences?


I don’t know if I had a breakthrough, but the status latency has finally dropped to acceptable levels of 1 or 2 seconds. I went to my router’s page and checked any setting for QoS or anything related. Most of them were disabled but I did found one option that seems to have the router snoop on multicast packets to prioritize them

IGMP snooping is the process of listening to Internet Group Management Protocol (IGMP) network traffic. The feature allows a network switch to listen in on the IGMP conversation between hosts and routers. By listening to these conversations the switch maintains a map of which links need which IP multicast streams. Multicasts may be filtered from the links which do not need them and thus controls which ports receive specific multicast traffic.

Does that mean it snoops for multicast packets sent to 1900 port? Does it snoop for multicast packets in general (thus capturing traffic to 1982 port as well)? Nevertheless it seems like an unnecessary option for my home network, so I disabled it.
Was it luck? Was it something else? I have no idea, but the response time of the app’s status is now fast, at around 1-2 seconds. Maybe my smart TV was causing a lot of traffic? I don’t know. Could this be totally unrelated? Maybe, I turned IGM Snooping on and didn’t see any 8+ sec latency. So I can’t be certain it did any difference.

Even when sending a discover multicast packet which would previously gave me no devices (because I had short timeout on the socket binding), now I get a response from the lamp in about two seconds.

Anyway this feels like a total fluke and most probably this problem will come to haunt me again in the future. I hope you guys can find something in the logs because otherwise the app is unusable with so much latency.

I will try it. What account server did you try with MiHome app? Anyway, I don’t like MiHome app as it is not as polished as Yeelight app. I have to say that statuses updating not every time takes so long, sometimes it updates quickly. I will provide more info later regarding ping timing from ot.io.mi.com and sg.ot.io.mi.com.

I agree that it’s some kind of glitch which depends on some concatenation of circumstances. Hope it will be addressed in future updates.

I have been using since the beginning Singapore server in both apps. I have not any trouble with MiHome and everything works fast without any latency. But MiHome lacks scheduling, music mode and developer mode, so I want to use Yeelight app.

I´m also experiencing this problem. One example is when using the widget in android where the status is only updated after you click the refresh icon.

Did you somehow add the lamp in MiHome app or it was there already? I’ve tried all servers available, but the lamps don’t appear in the list of devices anyway.