Another connection issue thread with lots of research and will to help and test!

Yeelight LED Bulb (Color)
#41

Hi Liufei,

Can you add my MID ID as to be able to download the beta version ? Want to test the fix for get_prop … (6390626321)

I can validate if it fix the issue and report back to you. In my case is super easy to repro the issue, the only workaround I have is unplug the bulb and plug back it in, but get_prop will stop working in less than 1 minute, so it is not a good solution.

FYI : The same issue is not happening in the ceiling version. It only happen in 1S.

Thanks

#42

no problem. will do when firmware is ready

#43

Hi,

First of all, a big shout out to Tomb92, who spent time on this!

I’m a contributor of another home automation project (not HA) which uses the same Python library and I (we all) do face the same issue. I’d love to test the new firmware also.

My ID is 6229558366

Thanks!

M

#44

Hi @liufei and yeelight team, I installed your beta firmware and I can tell you that the connection problem with HA is solved. Thank you.
hooping you can release it as soon as possible.

P.S. is there any improvement for the light.ct2 (only white tunable)?

#45

@ferdy_vi, @liufei: The beta firmware is available already!??

#46

I could update the bedisde lamps to 2.0.6.0033. Is that the new / beta release? Which version did you get @ferdy_vi?
However, I don’t see an update for the bulbs / color2 or any other of my lamps

#47

You have to ask to the yeelight team to receive firmware. See above

#48

Hi, the beta version is 2.0.6_0040. There are some delay due to lazy user whitelist synchronization. You should be able to find this version in Mijia APP by now. If not, please send me a notice.

1 个赞
#49

The final update for color4 is not ready yet. The version you are seeing is 2.0.6_0031
I guess? This version already contains some enahancement on network stability and is to be released very soon.

#50

And there’s no update for ct2 yet, same like color2/3 and strip2. There have different chips equiped.

1 个赞
#51

Thx @liufei! Unfortunately still no new firmware update for the bslamp2’s :frowning:

Just to clarify: This is fix is about the issue the the lamp constantly gets unavailable and available again (at least that’s what we see in HA), so what tomb92 posted about again, right?

This is not (yet?) for fixing that the lamps go unresponsive completely and have to be turned off and on again? I have that issue with the color2 bulbs every day / every x hours…

Thanks!

#52

To be more specific:

Right? :slight_smile: Thx!

#53

Hi there guys,

i observe similar issues on the “halo” ceiling lights (those with ambilight, 49YL and 50YL).

When they fail to respond to “get_prop”, the bluetooth remotes also becomes non working. Only way to get it back is to power cycle.

Is a fix in progress for those too ? Btw, If I can be added to the beta fw my ID is 6358597450

Thanks !

#55

Yes it is. Thank you for your help

#56

Unfortunately still no update. Neither in Yeelight nor Mi Home app :frowning:

#57

Just wait for Liufei to confirm the update is out and you are added to the beta program. I have updated my yeelight 1S color4 to 2.0.6_0031 last week and it is better but still not fixed. So just wait for the beta 2.0.6_0040

#58

@TheIronShadow: That’s exactly what he said to me…

You should be able to find this version in Mijia APP by now. If not, please send me a notice.

1 个赞
#59

hi, the whitelist mechanism seems to be somehow more complex than I expected. checking with my colleagues…

2 个赞
#60

Hi. @ezcGman, @tomb92, @Aimache, @_guofeng today I found an interesting thread regarding problems with reconnection of smart devices:

WPA key update interval (Rekey Interval, also called Group Key Update Interval or WPA Group Rekey Interval) is the time in seconds between WPA / WPA2 encryption keys change. This mechanism is used to increase the level of security. After predefined time interval, the Wi-Fi access point will generate a new temporary key for all connected devices. After distributing the key, the network starts working with new security settings.
Usually, key renegotiation takes place without disconnecting and reconnecting devices and, accordingly, without loss of connection and any delay. However, there are Wi-Fi clients who cannot go through this negotiation procedure without reconnecting, which can be accompanied by a short disconnection or a delay of several seconds, and lead to failures of operations. This usually happens due to the specifics of the Wi-Fi client itself.

It was described for Keenetic routers, but in HA groups it was confirmed that same story also applicable to asus, mikrotik, and most of other routers.

As I see there are 2 solutions supporting each other: 1) increase timeframe (not 5 mins as in some of routers to once an hour or once a day) 2) On a client side - revise this section in firmware.

For Keenetic instruction is in the link. For others - look into the manuals.

Details can be found via the link
(use google translate Rus->Eng):

#61

Okay. Take your time. We are already happy that the fault is found.

1 个赞