I’ve noticed an issue recently where someone in the house will tell Alexa to turn lights on, and instead of just turning the lights on in that room (as it’s configured in Alexa, with groups including each rooms specific echo device), it seems to be turning every light connected in the house.
I’ve looked at the Alexa privacy history and there is no instance of “turn all lights on”… it doesn’t seem to happen all the time, that I can tell, which makes it even harder to troubleshoot.
Any ideas of what I can look at to try to figure this out?
Sometimes when you say turn on "the lights" Alexa hears "all lights"
My workaround as suggested by someone else here was to make a Room/Group in Alexa named "All Lights" with nothing in it, so that nothing happens when it hears that.
I think another way is to make a blank routine with "All Lights" as the trigger.
Is this still a case if the text in the privacy records does not indicate that it heard “all lights”? Here’s a log of the commands that it heard this morning:
For example, Living Room has 1 echo dot in the group in Alexa, and one hue group light shared from Hubitat to Alexa. Normally you don’t specify any lights in particular, just “turn lights on/off”, and it only affects that room
I think you are right, it would show "all" there if thats what it heard.
Do you have hunches enabled? There is a history for that too.
Is it always Hue lights? There have been at least one other case where trying to use something in Hue from HE was triggering all the Hue lights to come on. Something with the updated Integration app. Which Hue integration do you use?
Have you checked the event log on any of the lights that came on, which should not have? You should be able to see in there if Alexa called the On command or something else. Provide a screenshot please.
I’m just using the standard Hue Bridge Integration on my C4 hub (currently on Hubitat 2.4.0.151).
Unfortunately I don’t see any Events for any of the hue groups that were triggered this morning (last Events for rec room were from 8pm on 2/3), and the hub logs only show them turning on and off, without any mention of the source.
Do you have the Hue devices shared to Alexa via Hubitat or do you have Hue paired directly to Alexa itself?
If Alexa commanded the devices through HE then you could see a "command-on" on whatever devices (or group activators) Alexa told to turn on. If it goes straight to Hue from Alexa then I don't think there is much more info you can gather.
@bertabcd1234 could this be the same issue someone else had with the migration to the updated Hue app?
I checked to confirm, but everything in my Alexa account is shared from Hubitat. I also made sure that I don't even have a Hue skill in Alexa, so everything should be coming through this path.
I did notice in the Hue Bridge Integration, there is a toggle for "Prefer V2 Hue API", which is still disabled on my hub. I have never enabled that, if that helps with anything
The problem I think they had is that the DNI of some group was not set correctly. @talz13, can you go to the Hue integration app and then *Advanced Options > Advanced Debug Options... and select Fetch Groups Info, wait a few seconds, then select Log Groups Cache and post the output from Logs that this will generate?
If you don't want to post the whole thing here -- it will likely be quite large -- look for (or use the search/filter textbox to find) entries that might have something like "id_v1:/group/0" in the text.
Also, I'd be curious to see the DNIs of all your Hue groups on the hub, which Log Child Device Info on this same page will also generate (or you can filter your device list for the first part of all these DNIs and see if any stand out).
Thanks for the information! A lot less verbosity on the V1 output (as you have), so that's not unexpected in this case.
I don't love these devices:
These DNIs should probably all be in the format like "Hue/13/Group/9", i.e., without the "hueGroup:" thing in the middle towards the end. I'll see what might be causing that to get set wrong and also see if I can find a way to identify this and fix it in the future.
If you know how to edit DNIs manually (not too difficult: device detail page/flyout, Device Info, "edit" next to Device Network ID, and confirm the prompt that otherwise discourages you from doing this), I suspect that is all that is wrong, and doing this should fix at least one thing that definitely looks like a problem -- but hopefully all of them.
Along those lines, can you confirm that turning on of off any of these devices actually does your whole house (or maybe nothing at all, which is really what I'd guess, but I don't really know what this would do...)? If so, that could certainly explain your problem -- even from Hubitat, which it doesn't sound like above, but I'm wondering if that's because you only happened to try devices that were not affected (it would have been only rooms/zones, not individual lights). And it would also fix Alexa, which is really just a symptom of a deeper problem. If not, there must be more going on, but this really stands out to me.
You have to do fairly soon after...but you can say ", what did you just hear" and it will tell you. I use that all the time because the microphones barely work anymore .
Going back to the above, I think I figured out what's going on here: very early versions of the built-in Hue Bridge integration apparently created groups with a DNI that was just in "hueGroup:groupID" format, not "hueGroup:appID/groupID" format, undoubtedly changed because you'd risk DNI conflicts the former way if you added more than one Bridge to your hub. This was fixed pretty early on (late 2018, only months after the integration itself came out) -- and it's why I didn't see it in my testing (I stopped using the built-in integration in favor of my own long ago and only set it up again recently to test conversion).
Long story short, this messed up the change to DNIs that was made as part of the 2.4.0 upgrade since the originals were not in the expected format.
This change, to be made in 2.4.1, will only help new upgrades, not existing installs, but I'll think about putting something there that can be run manually in this hopefully rare case (and maybe see why it's having unexpected behavior instead of just failing... EDIT: apparently that's just what the Hue V1 API does if you pass something unexpected as the group ID).
.
