So for the last week I have noticed some "oddities" with my motion lighting, but didnt think too much on it. But the last 2 days many weird things have been happening.
So I have all my ML turning on switches, that control either one bulb or a group of bulbs.
I have a ML rule that if fired turn on the switch (3 bulbs) and set the dimmers to 10%
the last few days one bulb (not the same one everytime) stays at 100%, but if you walk past the sensor again after the lights turn off all 3 seem to go to 10%
I have a ML rule in my garage that turns on a switch for a single bulb, after 5 minutes turn it off.
noticed last night the garage light was still on, pull up my lighting dashboard and the switch is off - but the bulbs still on. Toggle the switch and the bulb then turned off
I have another ML rule in the kitchen, if the lux in below 35 - turn on the switch which turns on one bulb for 10 minutes.
again, full sun when the kids are up and one of thems opened the blinds but before I leave for work the bulbs still on. Pull up the lighting dashboard - switch is off - bulb is on
1 is a group of 3 white yeelights and 2 + 3 are RGBW yeelights. If the bulbs werent responding, they wouldnt of turned on and if they werent responding I wouldnt of been able to toggle the switch and get them to turn off.
Not sure what to try to get them back to normal - but everythings been working great for awhile there.
So that I could switch out (change) bulbs and not wreck automations I have set the automations to turn on virtual switches instead of the bulbs directly, if that makes sense.
So my issue is the motion lighting is turning off the virtual switches, but the bulbs arn't turning off. If i toggle the VS on then off, then bulb will then turn off.
So currently, the yeelight in the kitchen is on because the lux is below 35 and there is moment. But this morning the switch was off and the light was still on.
Because of the automations associated with them. I tied them to the VS - that way I can change the bulb anytime I want to any type and I dont have to go back and fix the automations associated with that/those bulbs.
hallway lights has 5 automations tied to the switch,
I could change the 3 bulbs in 10 minutes and redo the group and not loose anything.
Im not sure its a "huge layer" some switches control one bulb and some control four.
I dont think its ML, because I have other MS that are tied to hue bulbs and they dont seem to be having the issue. It just seems to be my yeelights currently.
Bulbs -> switches I think the VS are controlling groups from groups and scenes.
This seems like the important part to know. The problem is undoubtedly not Motion Lighting--as both of you acknowledge--if it's turning off the virtual switches, so it's probably something with your virtual-to-"real" switch automation. The above doesn't really make it clear how you're doing that (Groups and Scenes doesn't have any built-in way that I can think of).
Have you considered using the Mirror/Mirror Me app, which was introduced a few firmware versions ago, to "sync" your virtual switches to the real ones? This app was made for another purpose (devices like the RGB Genie remotes and Lutron Aurora that implement level and whatnot capabilities normally associated with real dimmers/bulbs), but it should work. You could probably also just use Groups and Scenes itself and create a "group," even if it contains only one bulb, and then use that group anywhere instead of your virtual devices. You can switch out the "real" devices within that group as needed. Now that I write it out, that sounds like a much better idea...
I know that all my lights are in groups from the Groups and Scenes app, just cant remember how I tied the switch to the group - but thats how they are setup as I was trying to decide from the start to stick with my yeelights or change over to more hue/ikea bulbs.
ML is turning the switch off - but only some of my yeelights that are set to turn on with MS arn't turning off with the switch - thats the issue yeah.
If only I had remote access to my hub lol.
I'll check tonight when I get home.
*but from that list
laundry light is a yeelight with MS - no issue
front bathroom lights is a yeelight and hue in a group with MS - no issue
bathroom light, yeelight with MS - no issue
Currently I have seen Garage light, One kitchen light not turn off and an issue with hallway lights have random issues.
I'm sorry, I still don't understand. If you are using the groups app, there is a virtual device created that has the switch capability. In face, all bulbs also have the switch capability. So, you can control that directly rather than through a "man-in-the-middle" virtual device. Without knowing all of your setup of these devices there really is no assistance anyone can give. We would need much greater detail in how you are accomplishing this.
Sorry - my initial post is incorrect. There are no addition VS inbetween.
I created all my bulbs into groups based on location,
groups vary from 1 bulb to 4 per group.
I then (above - Group Bulb Dimmer) have a switch for that group and thats what you see on the dashboard.
Individual bulbs on the dashboard, and the Group Bulb Dimmers as the switches you see on the dashboard.
So here are the hallway lights, still on even though the system has turned the Group Bulb Dimmer switch off
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).
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.
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.)
