Yeelight / Motion Lighting help needed

Let me make a few assumptions here....you have bulbs that are part of more than 1 group. Also, you control the bulbs individually sometimes. What you need to do is enable this option:

Use group device to indicate if any members are on needs to be enabled. Otherwise the group will just display it's last state, not the state of the included members.

Hey @Ryan780,
from above yeebulb 4, 5 and 6 are part of one group only, "hallway lights".
The bulbs are never called on individually from an app or rule, only ever controlled by the switch - that way if i change the bulbs in the group, I wont loose any automations.

As these are yeelights I didnt thing the zigbee group messaging was going to be of much benefit - but I can try the optimization option. Yep I have group device enabled.

Have you verified if you can replicate the problem by just manually manipulating the group device(s)--from your device page for that group, not the app (which you really can't do this from anyway)--and seeing if the bulbs respond as expected? You might also want to try it both with and without "optimziation" enabled (which, if enabled, won't try to send on/off commands to bulbs it thinks are in the right state already--often good since it creates less traffic, but Wi-Fi probably has the bandwidth to handle it and it could be problematic if the bulb state doesn't update for some reason). Zigbee group messaging, of course, won't do anything here. I agree that "Use group device to indicate if any members are on" is probably the best choice here; the next version of Groups is supposed to have some changes here that might help you a bit, but I can't remember exactly what (I think options to set the group to off when all are off or on when all are on?).

If you're able to replicate the problem here, I'm not sure there's an easy fix and I'm no 100% sure what the cause could be--likely not rate-limiting or loss since your LAN should, again, have the bandwith to do this and if it's TCP it shouldn't "loose" anything, and I assume Yeelights all connect with individual IP addresses and not through a bridge/gateway of some sort (e.g., the Hue Bridge has a rate limit but even then, I think, will continue with its cache as time allows).

...but at least that could help narrow it down. :slight_smile:

Even with that as you can see above, all 3 bulbs were still on even with the group dimmer switch off :frowning:

With verifying it with your example, do you mean to turn on a bulb individually and see if they all turn on / the switch turns on ?

Yeah - all the yeelights have static IP addresses / no hub between them.

*turning one bulb on, turns the switch on, and turning that one bulb off turns the switch off

So,
I thought maybe 2 of the 3 groups that were having issues were made to go off with lux conditions, but the third is no lux conditional so that rules that out.

All 3 groups are yeelight, so i updated the yeelight firmware on the hallway lights only, but they still have had the issue after that.

The issue is never under the same condition, or the same group. I just walk into garage/kitchen/hallway and find that group on - pull up the dashboard and find the switch off but the bulbs on.

The only thing I could think of was maybe trying the hallway lights back on the RM motion rule VS the ML rule and see if that eliminates the issue - I do have 2 rules for the hallway lights. One for day mode when lux is below 35 and one in night mode if the sensor is tripped turn on the lights for 10min at 10% brightness.
I have never had the lights stay on at night for the hallway - only had the issue of one of the bulbs not dropping to 10% at night with motion.

My other thought was to change out the kitchen yee for a hue and see if that solved the problem.
Or do I set up mirror and make doubly sure that when the switch is off the bulbs are off... The last one really seems like double handling as I have other yeelights with ML rules that dont have this issue of staying on when the switch is off.

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.

1 Like

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.)

1 Like

cheers bud, will tool around and see what i can find out.

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.

Thats what im saying! lol.

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.

This is a group of a yeelight and a hue bulb.
Switch is off, hue is off, yeelights still on.
This group / one had not been acting up before.

2019-10-24%20(5)

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.

Hey @Ryan780

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:

  1. A yeelight
  2. That are controlled by ML automations.

Not that I'm aware of.

All devices will show up if in-use by an app.
image

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.

so to contradict that, here is Yeebulb 6, it is on my Lighting Dashboard as a dimmer and it is NOT listed on the "in use by" device page.

so have I done something wrong ??

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.