Unable to Control Multiple Devices Consistently

[zimmra]

Individual control of lamps works great after your recent update.

However when I try to control my group of lamps (total 6) not all of the lamps receive commands. It seems 1-3 of the lamps react when controlled as a group

I'd be happy to provide whatever info you'd like, although nothing appears 'wrong' in the debug logs.

[yangqian]

I have four GE lights (no RGB). I could control them at the same time using a group without any problem. I have a few comments and suggestions:

1. Keep in mind that the Bluetooth use the same frequency as 2.4G wifi (wireless b/g) and USB 3.0. You might have a problem if you use a Bluetooth dongle on USB 3.0 port or close to a 2.4G router.
2. Sort the lights such that the one closest to the home assistant are on top. In this case home assistant will try the one with best connection first.
3. Provide as much detailed as you can. Are you sending commands to change the brightness, color temperature or color hue? What are the corresponding results? Which one reacted and how? Do they turn on simultaneously? Are they the one closest to the home assistant hub?
4. Did you set up your group in home assistant?
5. Could you reduce the number in a group and test? Are you still having problems using 4 lights?
6. Are you using circadian_lighting?

[zimmra]

1. Keep in mind that the Bluetooth use the same frequency as 2.4G wifi (wireless b/g) and USB 3.0. You might have a problem if you use a Bluetooth dongle on USB 3.0 port or close to a 2.4G router.

Initially I was using a bluetooth dongle, which was passed through ESXi to an Ubuntu VM which I thought was the culprit (something in the chain there). I did a fresh install of Ubuntu ARM64 on an RPi4 using the internal bluetooth and the result is the same. The only common denominator between these two instances is Ubuntu, so perhaps I will try a different distro to see if results are any better. Individual control of the lamps works fantastically (seemingly more snappy than from the actual C by GE app), so I am inclined to think it is not a bluetooth range/interference problem

2. Sort the lights such that the one closest to the home assistant are on top. In this case home assistant will try the one with best connection first.

Location of the RPi doesn't seem to change behavior

3. Provide as much detailed as you can. Are you sending commands to change the brightness, color temperature or color hue? What are the corresponding results? Which one reacted and how? Do they turn on simultaneously? Are they the one closest to the home assistant hub?

_Every command as a group exhibits this behavior: On, Off, CCT (temp), Brightness, RGB (Color Wheel) Results are always the same, 1-3 lamps respond to the command sent and the other 3-5 do nothing. The 'reacting lamps' varies, it is never the same lamp responding necessarily - it is seemingly random. I have issued group on group off commands a large number of times now to see if I could detect a pattern and I cannot find anything continuity. The group of lamps is 6 lamps in a row above my mirror. (vanity_1, vanity_2, vanity_3, etc) with #1 being closest to my server closet (vanity_1 and the bluetooth source are <5ft away from each other, vanity6 (the furthest) is maybe 12ft away)

4. Did you set up your group in home assistant?

Yes both light group functions, as well as the on/off switch at the top of the 'Light' entity exhibit the same sporadic control

5. Could you reduce the number in a group and test? Are you still having problems using 4 lights?

_I did some testing in the developer tools sections by just issuing commands to vanity_1 and vanity2, and the problem persisted, very rarely would it actually control them together. I can try to completely eliminate some in the config and report back to see if that improved at all

6. Are you using circadian_lighting?

Not in this instance, but that is my desired end result.

[yangqian]

When you group the light using home assistant. Home assistant will send command almost at the same time (Due to the lock mechanism in the code, they emit one right after the other). You could try to add a few more light groups with various number of GE lights to test how many it can handle.

One possibility is that somehow the bluetooth mesh could only handle 4 to 5 sequential commands at the same time. For me, 4 lights can be toggled at the same time.

A potential workaround of this problem is to add a few milliseconds of delay right after each sent package. I.e., after the command of

    def send_packet(self, id, command, params):
        # the lock mechanism is to prevent the simutaneous packets if
        # you control two devices at the same time though a group.
        self.lock.acquire()
        try:
          self.link.send_packet(id, command, params)

in light.py

[zimmra]

    def send_packet(self, id, command, params):
        # the lock mechanism is to prevent the simutaneous packets if
        # you control two devices at the same time though a group.
        self.lock.acquire()
        try:
          self.link.send_packet(id, command, params)
          time.sleep(0.002)

I tried that with values .05, .01, .005, .003, .002, .001 and it introduced "wonkiness" - Commands show up really late (several seconds) or don't show up at all. Doesn't seem to change the bulbs not being controlled together consistently.

[zimmra]

I factory reset my lamps, removed 3 of them from power, and created a new location (generating a new username and password from the getconfig.py script) I also spun up Home Assistant OS to eliminate Ubuntu from the equation.

I added just 3 lights to the location in C by GE, and imported the new config to Home Assistant.

Even with just 3 lamps group control is sporadic/random. There is no perceivable difference than my 6 lamp setup, the lamps have a very low chance of reacting to group commands. With this new instance, same as the last one, individual control is spot on and responsive.

[ShadhyGit]

Hello, I'm experiencing the same issue and was wondering if any solution was found, thanks.

[yangqian]

I encountered the same problem using a Bluetooth chip BCM4339/4335. I was able to reliably and almost simultaneously control two bulbs by using a 0.05 seconds delay.

[zimmra]

I encountered the same problem using a Bluetooth chip BCM4339/4335. I was able to reliably and almost simultaneously control two bulbs by using a 0.05 seconds delay.

I hope to have time to test/deploy this over the weekend, will let you know.

Might I ask what bluetooth chipeset you were using previously with no issues?

[yangqian]

I encountered the same problem using a Bluetooth chip BCM4339/4335. I was able to reliably and almost simultaneously control two bulbs by using a 0.05 seconds delay.

I hope to have time to test/deploy this over the weekend, will let you know.

Might I ask what bluetooth chipeset you were using previously with no issues?

The original bluetooth chip that gives no problem is MODALIAS=sdio:c00v02D0dA9BF which should translates to BCM43455

[zimmra]

The original bluetooth chip that gives no problem is

MODALIAS=sdio:c00v02D0dA9BF

which should translates to BCM43455

Weird. I was using a RPi4 which uses a CYW43455 which I was under the impression is equivalent/identical

I also tried a USB adapter with a CSR8510 A10 and results were the same

[zimmra]

I recently revisited this custom component.

I have tried it both with and without your sleep addition in https://github.com/yangqian/hass-gelight/commit/6546cfb39951d48d0918bed0b33180ec3daf35e2

It works well with your addition, but it also seems to work well now without it. I am using https://github.com/mjg59/bluepy/tree/local_version to fulfill the bluepy dependency. mjg59 used to work at Google but now has his own personal fork of the project. I believe https://github.com/mjg59/bluepy/commit/f9a575d7d177b07b3720f27cf43e8b095752758e potentially addresses the same issue, as the intermittent control issue I was previously having is not apparent at all.