Light groups not functioning well

Configuration
1

Im trying to control multiple lights with one touch of a button. Right now I have lights grouped with a light group helper in home assistant.

4 wifi lamps
3 zigbee lamps (both are groups in itself of 2/3 lights)
1 switch (changed to light with a helper)

The zigbee lamps are configured in zigbee2mqtt

I use a button on a dashboard to turn lights on/off and i use a physical button (ikea styrbar).

Im trying to create a reliable system where all lights will turn on and off when i press a button. The odd thing is however that one of the wifi lamps will never turn of when i use the physical button, but when i use the button on the dashboard it does. Is there a difference between the two methods of calling the action?

Is using groups for the lights even the best way to do this or would it be better and more reliable to send a seperate command to each lamp?

2

Is the WiFi lamp controlled locally or through the cloud? I have a couple tuya switches controlling some lights and they are sometimes having trouble connecting. Which in practice manifest with them not changing the state when asked, or with a delay. It happens rather rarely for me, but when it happens, it’s highly annoying, so it’s something you notice immediately.

In any car, I think the light groups should work fine in general for your use case. There should be also no difference when calling the light group through dashboard or through an automation doing the same thing.

3

You could also consider creating a Scene, if only as a test, to see if that makes any difference. How are you triggering the light.turn_on action in each case. I imagine the action for the physical button (zigbee button?) is via an Automation but the Dashboard is via the entity directly.

4

WiFi IoT devices mainly use 2.4GHz.
Zigbee mainly use 2.4GHz.
I would assume you saturated
the frequency spectrum for a short moment and not all commands get through then.

5

Will try with scenes and see if it makes a difference.

The physical button is zigbee indeed and i trigger it with an automation (via a blueprint actually). The dashboard a mushroom light card so i suppose its the entity directly. Would that explain the different behaviour?

6

Hmm i thought i set them to the correct channels so they wouldnt interfere that much. Maybe i could built in some delays so it wont flood it to much.

7

The cgarts you often see is not conpletely correct.
They are depicting a 802.11B channel capable of a bandwidth of 11Mbit/s.

Most use at least 802.11G capable of 54Mbit/s, which use 3 channels.
802.11N use 7 channels and I can’t remember the one that use all the channels at the same time, but it is there too.

8

I really doubt sending a command to 7 devices at the same time would cause connectivity issues. I think both WiFi and ZigBee protocols are designed with this in mind. It’s not like a simple one way radio interface, with no protection against lost signal. And I would expect the issues from connectivity to manifest in more random way.

I’ll ask again, is that WiFi lamp controlled locally or through a cloud?

9

The lamp thats not working is a wled ledstrip with a wemos d1 mini.

Im just confused as it is working when i use the dashboard but it isnt when using the automation. You would think those are using the same commands.

10

When I switch the light through the dashboard, the log says it was light turn on action, so yeah, literally the same.

Have you checked the automation trace and the logbook of the light that doesn’t turn on?

11

Many devices do not reply when data have been received, so the controller have no way of knowing the command have been received and executed, other than seeing the state of the device change.

The retry feature of commands is a common requested feature here and reading those thread will show that there is no protection for missed data packets in many cases.