Python程序调试时只有灯泡调试模式打开的前几分钟能够发现设备

Yeelight LED Bulb (Color)
#1

您好，我在使用python例程调试时发现，只有灯泡极客模式打开的前几分钟能够发现设备。过一会儿再通过输入 r 刷新设备列表便无法发现设备。 此时只有再关闭极客模式重新打开的时候才能发现设备，并且几分钟之后又无法发现设备。 不知是什么原因？

#2

您好，我使用谷歌翻譯，所以我希望大家相互理解。

從看Python代碼，當你按下R，它運行’send_search_broadcast’ - 不處理響應。試試這個更改為“bulbs_detection_loop”：

#3 
elif argv[0] == "r" or argv[0] == "refresh":
      detected_bulbs.clear()
      bulb_idx2ip.clear()
      send_search_broadcast()

change to:

elif argv[0] == "r" or argv[0] == "refresh":
      detected_bulbs.clear()
      bulb_idx2ip.clear()
      bulbs_detection_loop()
#4

Thanks for your help! But actually bulbs_detection_loop() was continuing running in another thread, which was trying to receive response from the bulb every 100 ms, so after sending the search broadcast, it should get the response and update the bulb list very quickly.
I tried using wireshark to monitor the udp package across the lan, the bulb responsed to my computer’s search request in a few minutes normally after powered on. But after a while, the bulb stopped responding to any search request.
By the way, I didn’t captured the Periodical Advertise Broadcast Packet from the bulb in wireshark.

p.s. I am using a open-wrt router, I am not sure whether there are some tricks in it.

#5

Hi, which version of firmware is the bulb running? We made some update recently which could avoid such issue.

#6

color bulb firmware version: 1.3.1_42 . displayed as the newest version in yeelight app

#7

Did you capture the packets on the router or on your computer? The multicast message sometimes was dropped by some router for unknown reason (I saw once on Netgear), but per our experience, it works as expected most of the times.
Since your are using an open-wrt router, you may logon to it and grab some kernel log or syslog and did some analysis, or you can post your log here and we will look into it.

#8

Ah missed that, didn’t fully read the code!

Have you been able to try a different router?

#9

Thanks for your help, problem solved!

Looks like the problem lies in the multicast_snooping setting of my router. following is the description at the end of this article OpenWrt document about udp multicast

With IGMP snooping, multicast forwarding is disabled for bridges. One pure bridge solution is to disable multicast_snooping.

I followed the instructions, added the following in /etc/rc.local,

echo "0" > /sys/devices/virtual/net/br-lan/bridge/multicast_snooping

After reboot, the bulb can respond broadcast normally now even after long times, the advertisement broadcast interval of the bulb was monitored to be 1 hour.

However, I still feel very confused since another device using SSDP(WD MyCloud) in my lan works pretty well through all the time. I didn’t find any useful information in the kernel or system log about udp packet drop.

Issue resummary

Problem Description

  • Color bulb can response to broadcast search request only within a few minutes after:
    • power off and power on the bulb. (hardware power switch, always works)
    • close and reopen the ‘geek mode’. (not always works)
    • reboot the router. (always works)

Color bulb Info

  • bought at 2016.09.28 @ mi.com
  • firmware version: 1.3.1_42

Router Info(I am using a third-party compiled firmware)

  • Device Type: NETGEAR WNDR4300 V1
  • Firmware Version: OpenWrt Chaos Calmer 15.05.01-gy408-G18fix9 gargoyle / LuCI for-15.05 branch (git-16.081.39589-0207cb7)
  • Kernel Version: 3.18.23

System Log (I reproduced this problem during the log time)

Mon Oct  3 10:30:00 2016 kern.info kernel: [ 2984.490000] sh (24161): drop_caches: 3
Mon Oct  3 10:30:59 2016 daemon.info hostapd: wlan0: STA 64:76:ba:aa:14:20 WPA: group key handshake completed (RSN)
Mon Oct  3 10:30:59 2016 daemon.info hostapd: wlan0: STA b4:0b:44:0d:49:69 WPA: group key handshake completed (RSN)
Mon Oct  3 10:30:59 2016 daemon.info hostapd: wlan0: STA f0:db:f8:21:25:6d WPA: group key handshake completed (RSN)
Mon Oct  3 10:31:01 2016 kern.info kernel: [ 3044.670000] sh (25008): drop_caches: 3
Mon Oct  3 10:32:01 2016 kern.info kernel: [ 3104.730000] sh (25516): drop_caches: 3
Mon Oct  3 10:33:00 2016 kern.info kernel: [ 3164.130000] sh (25859): drop_caches: 3
Mon Oct  3 10:34:00 2016 kern.info kernel: [ 3224.010000] sh (26531): drop_caches: 3
Mon Oct  3 10:35:00 2016 kern.info kernel: [ 3284.170000] sh (27038): drop_caches: 3
Mon Oct  3 10:36:00 2016 kern.info kernel: [ 3344.260000] sh (27545): drop_caches: 3
Mon Oct  3 10:37:00 2016 kern.info kernel: [ 3404.360000] sh (28052): drop_caches: 3
Mon Oct  3 10:38:01 2016 kern.info kernel: [ 3464.510000] sh (28727): drop_caches: 3
Mon Oct  3 10:39:01 2016 kern.info kernel: [ 3524.990000] sh (29738): drop_caches: 3
Mon Oct  3 10:40:00 2016 kern.info kernel: [ 3584.050000] sh (31086): drop_caches: 3
Sending Commands with Perl, IO::Socket
Bulb stops to respond to SSDP requests after some minutes
#10

I did some google about the IGMP snooping and multicast and found this article from Juniper is helpful. It explains the technique in detail.
https://www.juniper.net/techpubs/en_US/junos12.1/topics/concept/igmp-snooping-multicast-forwarding.html

In this article, following words may explain why your NAS works well while the bulb doesn’t. I guess your NAS will send IGMP query or PIM hellos from time to time to prevent the cache being cleaned up, but the bulb may don’t have the mechanism (in the bulb, we use lwip as our tcp/ip stack, which is simpler than normal linux network stack. I will check the code and update it later).

Interfaces that IGMP snooping learns about are subject to aging. For example, if a multicast-router interface does not receive IGMP queries or PIM hellos within a certain interval, IGMP snooping removes that interface from its multicast cache table.

1 个赞