I just can’t get Scenes to work reliably

Apologies in advance for so many posts from me about this app, but I’m at my wits end, and I could use some advice. I can’t get the app to work reliably. Some specific issues I have are:

Grouped bulbs, where the group is set to use zigbee group messaging, don’t appear to do so when controlled by a scene. I have a ceiling fan fixture that has a pair of bulbs in it, which I’ve grouped. Commands to the group usually produce the desired result, if the command is sent from the Hubitat interface. Commands to the group coming from Alexa can be a bit hit and miss, because it seems that the Alexa app won’t send them if it thinks they aren’t necessary. Commands to the group from a Scene appear to iterate through the devices in the group, rather than using the group messaging.

The result is that my ceiling fan lights are never in a consistent state. I have multiple scenes (morning, daytime, relaxing, evening) that change their color temperature, or RGB throughout the day. Invariably, the bulbs will have one in the correct state, and the other in the previous state. They’re Sylvania LEDvance bulbs using the Generic RGBW driver, because the Advanced driver has another host of issues, which I’ll get into later. I have to ask Alexa to turn the scene on 2 or 3 times before everything gets in the right state.

This doesn’t apply to just those bulbs. I’ve also got Sylvania light strips (same driver) that, for other scenes (TV, cooking, gaming, movie) will change color, color temperature, and level. More often than not, I’ll get two of the three (usually on/off state and level, but not color) when the scene is activated, but not all three. Sometimes it’ll get the on/off state and color, but not the level.

This also happens to GE-branded Jasco dimmer switches. The scene will have it captured as on, 40%. The scene will turn it on, but not assign the level. Or it’ll pre-stage the level, but not turn it on. I have to run the scene activation multiple times to get the LED strips and dimmer switches to the desired scene state.

I have turned on metering for these scenes (it appears to help, but only marginally). The groups have zigbee group messaging turned on. (I’ve also tried turning it off.) The groups are configured to report the on state of any bulb as the state for the group, as I’ve previously had issues with the groups not turning off completely. I have discrete on for activation turned on for the scenes (tried it off too) and level/color pre-staging enabled where I can (and tried it with it off too). All the devices shown in the route table look healthy, with strong signal. I have activation optimization turned off for the scenes, because that just makes the unreliable results even more unreliable.

The result of all this is that I have to do things like say “Alexa, turn on relaxing illumination,” then wait for the scene to run through its metering for several seconds. Then I have to say it again, and wait again. Then I have to say it a third time. Usually that will get everything where it’s supposed to be.

I don’t have these issues controlling devices individually, but then, I’m not changing multiple state properties by voice when I do that.

I’ve posted about some of this before and some folks suggested my bulbs are killing the mesh, or I should put them on a Hue bridge. I don’t think they are, and I don’t think I will, because this entire setup used to work flawlessly on my Lightify hub. That thing seemed to use group messaging to activate scenes, because there was no popcorn effect at all, and everything immediately went to the desired state for level, power, and color.

I really, really want these scenes to work. I’ve invested a lot of time and effort in crafting them, and when they do work, it’s beautiful and exactly what I want. I don’t know if there’s something trying to economize zigbee traffic that is making my HE be stingy with commands, or something that makes grouped devices ignore the group messaging flag when run by a scene, or something that is making it impossible to do level, CT/color, and power state all at once, or some combination of all or none of the above, but the result is my scenes are broken and have to be triply run in order to get everything where it needs to be.

I’m in a 780sq. ft. apartment, and I’ve moved the zigbee channel as far away from my 2.4ghz wifi as I can. The route table shows what appears to be a healthy mesh. The scene commands just aren’t getting to the devices in a way that makes the devices behave the way I want for the scenes. The number of devices in play and the different configuration options I can set at the device, group, and scene level has made my efforts at logging and debugging fruitless. There’s just too much information, and the results are too inconsistent to be meaningful to me.

I could really use help with this. :frowning:

It really does not sound like a zigbee issue if using the groups directly work. I use scenes fairly extensively and generally don't have issues if I turn off activation optimization and I enable metering. However, I don't nest groups within scenes. What happens if you get the groups out of the equation?

Most of the devices in my scenes aren’t in groups; they misfire too, such as the LED strips and dimmer switch that get the brightness but not the color, or vise versa. The grouped bulbs in that fan fixture are just really obvious when it’s gone wrong, as they’re never supposed to be in differing states.

Hmmm ok. Scratch that idea. Does the length of the metering delay make a difference? Or would it make sense to test with a scene with few devices and then gradually increase? Not sure if that would yield more useful data. I have not heard of a limit or threshold on number of devices but it might make it easier to debug.

I’m afraid the metering length makes no difference, I’ve tried intervals from 100ms to 1000ms. I just turned on a scene now, and one of the (not grouped) LED strips went from CT 5500 to Hue 4, but missed the level command, and one of the (grouped) bulbs went from CT 5500 to CT 1700, while the other one did nothing at all. Immediately re-running the scene got them both correct.

Hmmm ok. @aaiyar has more experience with bulbs than I... I wonder if maybe he can render some assistance here.

The hub is just sending the commands faster than the bulbs can handle. Also, metering isn’t useful for Zigbee devices that can use zgm; it’s primarily for Z-wave AFAIK.
I rarely use scenes. I tried in the beginning and didn’t find them reliable unless I was setting everything to the same CT and level. I instead opted to create eight different modes throughout the day as stepping off points for CT changes. I have a mix of Hue, Sylvania (recessed lights and led strips), and Zigbee and Z-wave dimmers.

One would think an entire second between commands would surely be enough, though? It’s tough to wade through the logs because there’s so much going on, but it really does seem like the correct commands are just not getting sent at all.

What makes me think that is that the HE doesn’t seem to have a good idea of the state of a device at any particular time (screenshot below of a scene I just tried to make, and it captured 3 devices incorrectly: 2 RGBW strips & 1 jasco switch), and while I know the scene optimization toggle being off is supposed to send commands anyway regardless of what it thinks the state is, it really does seem that it skips things it doesn’t think need changing, whether that’s an entire device or a particular bit of its state.

I would think that metering would be ignored for devices using zgm. Zgm is a single broadcast message.

Try changing to the Generic Zigbee RGBW driver and hitting configure. Although the Advanced Zigbee RGBW driver is faster/more efficient (and why I currently use it for lights I control with Aurora rotary dimmers), the generic driver seems to more accurately reflect the state of the lights.

The only thing using Zigbee group messaging is a single group of two bulbs in a fixture (Living Room Light, in screenshot above), that exists in a scene with about a dozen other things (same screenshot). Scenes doesn’t, to my knowledge, use group messaging. One of the issues I seem to be having is that Scenes unrolls the group and tries to control its members individually, rather than honoring the use group messaging command. So the two bulbs in that fixture land on different states, because another issue is that commands are skipped when running the scene.

When I captured that screenshot, the two incorrectly captured LED strips were using the generic driver. I’ve also used the advanced driver. It doesn’t produce better outcomes, unfortunately.

Considering that I haven’t seen the issue with correct states not being reported with my 17 Sylvania recessed RGBWs, 5 Sylvania Flex XL light strips, and a handful of GE zigbee dimmers on the mesh, it makes me wonder if it’s simply a mesh issue. Devices are responsible for reporting back the correct state to the hub, so it seems that the messages are getting dropped before the hub receives them, thus it would make sense that messages from the hub to the lights might also be getting dropped before making it to them.
You may want to look at your neighbor table and see how good your connections are with the closest repeaters:

It's a 780sq. ft. apartment, and this mesh worked perfectly on the Lightify gateway, which is notoriously known for having a janky zigbee stack. All of my stuff is within 30 feet of the hub and half of it's line of sight. The lowest LQI I've got is 251 and the highest cost is 3:

Parent child parameters
EzspGetParentChildParametersResponse [childCount=0, parentEui64=0000000000000000, parentNodeId=65535]

Child Data

Neighbor Table Entry
[Tesla Coil, 097E], LQI:253, age:2, inCost:3, outCost:1
[Office Lamp, 11B3], LQI:254, age:3, inCost:1, outCost:1
[Bedroom TV, 1A70], LQI:255, age:3, inCost:1, outCost:1
[Bedroom Light West, 2295], LQI:253, age:3, inCost:3, outCost:3
[Nightstand, 40D5], LQI:254, age:4, inCost:1, outCost:1
[Patio, 4CB3], LQI:254, age:3, inCost:1, outCost:1
[Bathroom Light, 51EE], LQI:254, age:4, inCost:1, outCost:1
[Foyer, 6FB2], LQI:253, age:3, inCost:3, outCost:1
[Cabinets, 85E4], LQI:247, age:4, inCost:3, outCost:3
[Bedroom Light East, 929F], LQI:251, age:4, inCost:3, outCost:1
[Bathroom Fan, A565], LQI:254, age:3, inCost:1, outCost:1
[Desk Lamp, CB1C], LQI:255, age:3, inCost:1, outCost:1
[Oscillating Fan, CBD7], LQI:254, age:4, inCost:1, outCost:1
[Closet, DBD7], LQI:254, age:4, inCost:1, outCost:0
[Lava Lamp, ECE2], LQI:254, age:4, inCost:1, outCost:1
[Bedside Lamp, F044], LQI:255, age:1, inCost:1, outCost:0

Route Table Entry
status:Active, age:32, routeRecordState:2, concentratorType:Low Ram, [Patio, 4CB3] via [Patio, 4CB3]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Oscillating Fan, CBD7] via [Oscillating Fan, CBD7]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Bedroom TV, 1A70] via [Bedroom TV, 1A70]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Lava Lamp, ECE2] via [Oscillating Fan, CBD7]
status:Active, age:32, routeRecordState:2, concentratorType:Low Ram, [Bathroom Light, 51EE] via [Bathroom Light, 51EE]
status:Active, age:64, routeRecordState:2, concentratorType:Low Ram, [Closet, DBD7] via [Bedroom TV, 1A70]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Cabinets, 85E4] via [Patio, 4CB3]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Backsplash, CF61] via [Closet, DBD7]
status:Active, age:64, routeRecordState:0, concentratorType:None, [Island, B2DC] via [Closet, DBD7]

Although to give some credit to the notion of a busted mesh, everything that got captured wrong in my screenshot, and another device that has been plaguing me lately (Bias Light) doesn't appear in that routing table, which means they're more than one hop away.

Is there any way to traverse the mesh to figure out if they're all going through something that's decided to be a bad repeater?

That looks pretty good. Maybe @bravenel can help figure this out.

Are any of these bulbs Osram made? They will either say IQHOME (Osram) or LDVAETHER (Ledvance) on them. The prior are known to drop messages.