Running actions parallel without one device being affected by the other

[livid vale]

Hello, I have a bunch of ZigBee IKEA lights connected to a Sonoff E. I also have a bunch of Ikea ZigBee light dimmers, which I'd like to use to control all the active lights at once.

Issue arises when I want to control the lights when one of the lights is turned off with a dumb switch (in that case I'd like HA to just ignore the failed attempt for that specific entity and continue execution on the rest of the devices)

I used the "parallel" block but when a device is unreachable and not yet tagged as "unavailable", the light dimmer doesn't do anything, until all previous requests time out.

Below is a graphical block example

[prisma vale]

A better method is to use a template to generate a list of active lights. If they're all in a light group then you can do

{{expand(group) | select('is_state', 'on') }}

[livid vale]

That would generally work, but the state update is not instant. Thus a disconnected light shows up as "on" for about an hour.

[prisma vale]

ah gotcha

Have you tried changing the automation mode to "restart" - that would cancel any hanging commands from HA if your dimmer switch re-triggers the automation while it's still trying to set a disconnected light

[livid vale]

That might be it. I edited my automations and will try them when I'm home. Thank you :3

[small thicket]

Don’t let the light get disconnected. You are causing problems within the mesh that will affect end devices. Smart bulbs are meant to always be on (as they are router devices). When you disconnect a router device, the mesh has to take time to rebuild the routes and such and can cause end devices to drop.

[livid vale]

What happens when an end device drops? Just reconnect?

Currently the only end devices I have are the light dimmers

[small thicket]

Depends on the end device, but generally you would have to manually re-pair the device that drops.

Keyword being "currently" lol

[livid vale]

Wouldn't that be an issue when power outages happen?

[small thicket]

Not as much, no.

[livid vale]

I don't think devices dropping just because you lost power are handling the situation correctly

[small thicket]

There's a difference between the entire mesh going down versus a single device. On an entire mesh rebuild, you may have older end devices that won't come back properly (or they will because the router they were using came back as well). But, a single device losing power will trigger end devices to try to find a new route. Some will, some won't. It depends on the Zigbee version the devices are using and what the manufacturer has decided to follow in terms of spec.

[livid vale]

I see. Either way, the place it needs to cover is very small and the walls are made of paper. The coordinator being placed in the middle of the place makes it reach with excellent coverage in every corner. Considering I power off all the routers and only the coordinator stays online, can end devices connect to the coordinator and use that as a router?

[small thicket]

No

[livid vale]

Or can I perhaps disable the meshing so it all connects through the coordinator?

[small thicket]

HIGHLY recommended against.

NO

That's not how Zigbee works.

Zigbee is a mesh protocol. While the coordinator CAN route, it's not spec'd to do that. It's meant to coordinate to routing devices and end devices through the routing devices.

Don't conflate WiFi networking with Zigbee. They are different beasts.

[livid vale]

Did that and doesn't seem to have an effect unfortunately. :/

It completes one "action", then becomes unresponsive for about 6 seconds (some sort of a timeout) and if given another action in that time frame, it executes it, and then another 6 second cool down to use the dimmer.

Oh... The blueprint uses mode single, which I presume can't be overriden

Perhaps I could split it into 2 automations - light actions and button presses. So the blueprint used to handle button presses doesn't directly talk to the lights but instead triggers another automation

This way I could set the light turning automations to use the reset mode

Hmm. Can't do that because that requires a trigger :/

[livid vale]

So after plitting up the logic in 2... I noticed that when i click the button to turn on/off the light, it kinda "schedules" the action due to some of the devices being unreachable. How do i get rid of that?

And as expected, when I turn ON all lights (so no timeouts occur), there is no delay.

Since the automation "fails" to execute, it probably gives a timeout to the devices it is calling and thus any automations that want to modify the state of devices with pending state changes get queued instead. That would explain the behavior. Now the question is, can i cancel the "turn off lights" automation when my "turn on lights" automation is triggered?

[nimble oar]

a time in the future indicates clocks out of sync between frontend/backend. it does not mean it is "scheduled"

if you see something in the future it already happened, but your frontend clock is lagging

[livid vale]

oh yeah. synced my clock and now it just says now

Either way, when i spam click turn on/off either using a physical button or the turn on/off automation, it seems to be queuing the requests and they execute in 15 second intervals. Not sure how that is happening when i did set the mode to restart