No--if you never manipulate the individual bulbs directly, I don't see much use in trying that. What I meant is to manually try what you've said your automation is ultimately doing: manipulate the group device (turn it on and off a few times yourself) and see if you can replicate the problem you see when you use this group device in an automation. If I understand your problem correctly, it's that your individual devices do not always respond when your motion lighting automation manipulates the group device. Because the the on/off state of the group device always appears correct, the problem is likely not your automation (it must be working if those are right, and the problem must lie with something--whether something you can control or not--in your group). My suggestion is just one way to take the motion lighting automation out of the picture and test this hypothesis. Correct me if any of my understanding is wrong about your actual problem (but the takeaway is that Motion Lighting seems irrelevant).
This isn't really relevant now; I was talking about what staff have mentioned may be coming in a future version of Groups and Scenes.
When testing this (or testing a real automation, ideally one at a time), I'd highly recommend you check your "In Use By" for all devices (both the group and the individual devices) to make sure no other app/automation might be touching them. You can temporarily disable apps if needed (see: [TUTORIAL] How to disable Apps and Devices (platform v2.0.3 or newer)). You definitely need to make sure no other automation is interfering with this one and changing devices in ways you did not expect that might lead to this problem; disabling any other one that touches the device (and maybe all of them when you perform the "manual" test I described above) is a good way to do that.
Switching out a Hue bulb (assuming it's a Hue Bridge bulb or that you have no other kind, i.e., non-bulbs, of Zigbee devices on your network) would be one way to see if it's something with a Yeelight just not receiving a command or if it's something with the automation(s). Now that I mention that, turning on logging (default info/description logging might be enough--probably don't need debug, but it can't hurt) for your individual bulbs might be a good idea too so you can see what they think they're doing.
Most of the time my automations go on and off no issue.
Currently I am finding bulbs still on after the switch has be turned off by ML.
If I find the bulb/bulbs still on I toggle the Group Dimmer Switch on and off and everytime the bulbs will turn off.
I will try the optimization, but these automations, some have been live for months with no issue. And other yeelights in my system are not having this issue - they are also in groups with ML rules attached to them.
But would that not still be controlling the switch, which in turn would be controlling the lights. IE if another automation turns the switch off, the lights turn off too - not stay on.
Will turn on logging for the naughty bulbs when I get home for sure.
I know it's tempting to think ML is the source of the problem, but if it correctly turns off the group switch (I assume it was previously on; checking logs will help you verify), it is unlikely to be the problem, and the fact that other automations seem to happen to work would just be luck. You turning the group off yourself--or any other app turning the group off--should be the same as ML doing so...unless, for example, the group is already off before ML gets to it (say, if you have another automation on the group or any bulb--why I suggest disabling anything else when you're testing).
Basically, I'd play around a bit more but focus on the group devices and see if/where you can get the problems to appear, i.e., try to narrow it down. (And if you want to test an automation, RM might indeed be better than ML here--one of the rare times I'd say this--so you can be extra-sure none of the "don't turn off if X" options aren't checked in ML. Either should work but this would at least help with testing something there.)
Then how is it possible that the lights are on but the group switch is off? It isn't. If you only ever control the group device, all 4 of the devices would match. Something has to be changing the lights individually.
To prove my point @Ryan780 - today I showed you a pic of the Group Dimmer Switch as off (hallway lights), but the 3 yeebulbs that make up the hallway as on.
Here are the 3 bulbs devices pages showing nothing else is controlling them BUT the group.
Okay...what you have cannot be accurate. If the bulb is on a dashboard, that should also be showing up on the In Use By screen. But you just showed that it doesn't. So, how can you show that it's on a dashboard when it isn't in use by the dashboard app?
Also, stop going to the dashboard as the end-all-be-all of information. Go to the edit device page. Then you can see if the edit device page matches the dashboard and can determine if the problem is the device or the dashboard. Both of which might be the case. But what you are saying doesn't line up with the data that you are showing.
Wait... your individual bulbs show up "in use by" dashboard if they are on the dashboard ?
I dont know what to tell you man, I added the Group Dimmer Switch for "Hallway Lights" group to the dashboard, and then I have the individual bulbs as bulbs on the dashboard (so I can see the group and the parts that make up that group).
I dont need to go to the dashboard, I can see that one of the 2 lights are on in the bathroom with my eyes, THEN I got to the dashboard and can see the switch is off (group) but the light is still on (bulb).
The in-use-by screenshot was to show you the only thing controlling the individual bulbs is the group "hallway lights" (yeebulb 4,5 and 6) - as you suggested another automation might be controlling the individual bulbs - but thats not how I setup My automations.
I think whats more interesting is the "front bathroom lights" group where the hue light has received the command to turn off With the Group Dimmer Switch, but the yeelight has not / didnt turn off.
Was there an issue with the previous update with ML @bravenel / @mike.maxwell that could still be affecting my yeelights ?
I am currently having no issues with groups being turned on/off with modes (with groups that have yeelights), I am having issues with yeelights being turned on and off with Motion Lighting.
I have gone back and turned on "enable on/off optimization" for all groups that contain:
Dashboards are no different. So, if your lights are not showing up as "in-use-by" a dashboard but you think they are on a dashboard, I would double check what device you think you have listed. You might have extra virtual devices you forgot you created.
And you saved that dashboard and clicked update on the edit device page? I've never seen a device in a dashboard not report that it is. But hey...stranger things have happened.
That is the reason I suggested you go to the edit device page to check. This might be the whole problem. The dashboard might be corrupted. If it is not listing the dashboard on the edit device page, the dashboard is likely not subscribed to events from the device and therefore won't update correctly.
That device, has been on that dashboard, for say... 6 months+
its not a new dashboard, not a new device.
The issue with the yeelights has been happening i'd say for the last week and ive made No changes to my system at all or new devices in my house (phone/microwave/fridge) nothing new.
I hear you, but i need you to read this one bit:
I see a light on, that should be off.
I check the dashboard, the dashboard tells me what I am seeing is correct (bulb on) but the dashboard is also showing me the Group Dimmer Switch is off. So the bulb (yeelight) should be off.
The Dashboard can't be corrupt, its showing me what im seeing, there is no error. The error is when the ML rule sends the command "sometimes" to turn off a yeelight, the yeelight Doesnt turn off.
If I toggle the Group Dimmer Switch from the dashboard, I can get the yeelight to turn off without fail.
And from what I witnessed last night (below post link), a group where it has 1 yeelight and 1 hue light, the hue got the message, and the yeelight didnt.
And I have no idea where to go from here, thus the thread.
Off is off is off. Whether that be from a dimmer, a group command or a ML command. There is nothing special about the way one would issue the off than another. it's the device driver that would be controlling the message to the device. Not ML or Groups or even a dashboard.
Since this a community driver, I would recommend you contact the developer that built it. This is likely an issue with the way the driver is issuing the command or updating hubitat on the status. For example, if the driver is issuing the "off" event before the bulb is actually turned off, the command may not be actually issued to the light. A deeper dive into the driver would be necessary.
Also, I cannot think of any reason why the dashboard the device is assigned to is not showing up on the "in-use-by". That is EXTREMELY odd. Did the IP address of the bulb change at any point? I would go back in an make sure the bulb is still selected in the dashboard app and that there arent mysteriously two of them.
No...what i mean is that it doesn't make sense that the device doesn't show up as in use by the dashboard. Have you tried putting the bulb into the ML without the group device?
Since this is also tied in with the Yeelights app...that might be part of it but I can't imagine why. Again, mike is the only one who'd be able to answer that question. No one else has access to the code.
I can try that, last night I added the "optimisation" to all of the yeelight groups that have ML rules.
I will give that a day or two (or until frustration bubbles over) - then I will try moving it from groups to bulbs.
its also not isolated to a single yeelight bulb. I am having this issue now with over 80% of my yeelights on different nights. Random rooms that have had motion minutes ago with bulbs still on but with Group Dimmer Switches off.
