Hi there, I'm experiencing an unusual issue using the Advanced Hue Integration on a C8 hub.
Any light or group turned on, switches off after a second - this happens when triggered via a rule or if the virtual switch is manually activated.
Is anybody else having the same problem? Any ideas for a fix please.
Switch to the cocohue integration instead. You'll be happier. It's available in Hubitat package manager. That said what do your logs say when the lights turn off after turning on?
While I'm naturally a CoCoHue fan, I don't think this should happen with any integration, and it's unlikely to be a problem with the integration itself. More likely, you have some app (including rules, etc.) using the device or a group it's a member of that it is turning it off in response to some trigger/event, possibly the bulb itself turning on. The "Events" page for the device or group, accessible from the device detail page for each, will show you. You'd be most interested in commands ("command" under the "Type" column) and specifically things like an "off" command. It will show you what app sent the command if came from Hubitat.
Keep in mind that with a Hue bridge, any other integrations you have set up could do this too: Alexa, Siri/HomeKit, etc., and Hubitat won't know about those. (But if the problem goes away when you remove or disable all devices/apps related to the Hubitat/Hue integration you're using, you'll know for sure.)
Gordon,
I had the same issues with two out of several rooms. I don't have much configured in Hue itself, but I did add a default scene to each room for Adv.HBI. . . the short of it is, I'm not sure how I got past that errant behavior.
You should ask Armand in this topic:
...bob
Thanks Bob will do - I case you have the problem again;
Also, when the above problem state manifests, even turning any light on (or all the lights) in the in the Hue app itself, the Hubitat hub turns them off within a second.
It's almost as if there is a rule that has a trigger to turn off all Hue lights as soon as it detects any one of them turning on, but I definitely do not have any rule close to that and the problem disappears after a hub restart.
I've turned on diagnostic logging as there was nothing of note in the logs before.
In my case, I both UNchecked the "Any on or All on" option in the AdvancedHueBridge device. and also removed the Room Group and Scene from AHBI. I didn't need them, between Siri and an Aurora dimmer (a simple setup). But I couldn't say what precisely did the trick.
There's also a recent update. . . so all in all, it's best to give Armand a poke.
The “Any or All on” feature does not send A change to the hue hub, all it does is to determine when to call the send ever call.
In simple terms:
If(state.allOn) {
If (all lights are on) {
hub.sendEvent([name:”switch”, value:”on”])
} else if (all light are off) {
hub.sendEvent([name:”switch”, value:”off”])
}
If(state.anyOn) {
If (any light turns on) {
hub.sendEvent([name:”switch”, value:”on”])
} else if (all light are off) {
hub.sendEvent([name:”switch”, value:”off”])
}
This is not actual code, it depicts the logic.
hub.sendEvent() does not change the physical device, it updates the HE property for the device, so that rules can fire based on property change.
I will dig into the code again to make sure, but I do not have a C8 hub, I have two C7 hubs and a C3 hub. I use the C3 for development testing and one C7 for all my network controlled / insfrated devices, and the other C7 for rules, zigbee and z-wave devices only.
I wonder if there is something corrupted because of the migration from C7 to C8?
One thought — if you have hue device in an HE scene, and you activate scenes based on rules, or fire rules based on scene state, you can end up with weird behavior like this.
For example, I have a goodnight scene to turn off all my down stair lights, turn on hall and stairway light.
This works fine and when I turn off the stairwell, and hallway, the good night scene turns off, because the scene devices are in the wrong state. As such, it’s possible to end up thinking the scene is active when in reality it’s not, and reactiving it will turn lights off again.
Again, I will double check the code. I don’t think I will find anything that calls on/off events but if Indo, I will post the fix the the app’s thread.
Informational logging will log when lights are turned on/off and when the on/off actions are called.
One think that might be happening is is the level reaches 0, then in HE the light changes to off, but it doesn’t command Hue to turn it off.
Bob has provided details above that may be a clue. He setup a scene. If you call the on() function of a group, and a default scene is define, then after turning on the light I then activate the scene. I will look at this logic. Maybe the C8 move changed the state value such that it is not working correctly when there are no hue scenes imported or set in the default scene property.
Hi Armand,
Thanks for your response - I do not use HE scenes, but I do trigger Hue Scenes via child devices as per the below parent / child screenshot in use cases demonstrated in the below rule.
I suppose is always possible that something corrupted on transfer as well.
Armand,
Let me first see if I can set this up properly:
All the Auroras are on 2 walls on one end of kitchen. I put the Phillips on the other side of the kitchen so as I leave that way I can turn off either set. I can only turn ON the K.group from that group, which is fine.
Dimming delays had me use 3 buttons to set the K.group at 3 different luminance levels, and the 4th button will turn off both the Kitchen and Coffee area lights if either are on.
Had a lot of trouble getting it to work as intended, using any switch or Siri to control either group. I didn't use any automations or scenes in the Hue bridge initially, but I figured I needed to add those parent/child scenes (groups, rooms, whatever) to sort it out. No good.
In the end, what worked was checking for both On/Off and Dimmer Level, instead of trying to command a switch or dimmer alone.
This was before your and HE's latest update. Also before your last update my Bedroom and Den had the issue Gordon is relating (2 room lights, 1 Lutron Aurora dimmer) where I removed the Parent/Child Hue room groups for resolution.
I'm not sure any of this is me not fully grokking your implementation, so I just poke around until something clicks (even though I read your explanation up-topic of its methodology). Anyways, just chiming in should this be of any help. My home is working flawlessly at the moment.
...bob
Your rule for button 4 doesn’t need the if checks. Just simple commanding both lights off is enough. The if condition check is still turning both off, on an as-needed basis. If you command them both off without the if, you avoid the race condition that occurs should the light turn on then you command if off before the he hub as received a notice that the light turned on.
I don’t see in here where the lights would turn off other than a button being pressed so this rule likely has nothing to do with the lights turning off.
For the light that randomly turns off, open the light in HE and scroll down to see what apps use it. Then also check any imported groups from HUE that the light participates in the same way. From here, I am curious what apps are in use that could affect the problem light.
I think this rule is overly complex. Trying to do too many things in one rule.
I notice:
if Patio Door is open, it will turn warning lights Red
if Street Gate is open, it will turn warning lists Purple
it will then sleep for 5 seconds then set warning lights to Relax
In this scenario, you do not cancel other delayed rule executions.
As such, walk out the Patio door, and opening the street gate in less than 5 seconds, the sequence of events will be:
warning lights purple (start 5 second delay 1)
warning lights red (start 5 second delay 2)
warning lights relax (after delay 1 expires)
warning lights relax (after delay 2 expires)
Next, if the Lounge is off, the warning light is turned off (after delay 1 expires)
Next, if the Lounge is off, the warning light is turned off (after delay 2 expires)
alternatively if the Lounge is on:
the warning light is left in on state (after delay 1 expires; may by red, purple, or relax, depending on other events re-triggering the rule)
the warning light is turned off (after delay 2 expires; because no matter what happened in delay 1, the value of AmbienceCheck is set to 0 while delay 1 is running, and after it was set to 1 before delay 2 started)
This rule complicates things, because every time one of the trigger events occurs, the rule executes but may not complete before the next rule executes. I don't know that your Boolean will work effectively as a debounce trigger to lock this rule down to only one rule event processing at a time. Instead, I think you want to pause the rule from further executions, then resume the rule upon completion, but even then I think would be dealing with a race condition. Instead, I think turning off the light, or resetting it should be canceled before called to ensure you don't have several queued up, and to guarantee only the last executed delayed actions are performed.
Well, I DID need those checks before your and HE's latest updates (to insure the Auroras, Phillips, and Siri would cooperate). Let me try to methodically go through that again and come back.
I'm not focused on the problem Gordon is having currently, since removing the parent/child group (it wasn't necessary to have them, in my case, in the first place) in my affected room(s) sorted it out for me. Not that I understood what was going on, it just fixed it. One frustration at a time [g].
Thanks.
Sounds like maybe this was just a coincidence coupled with C8 release behavioral quirks? I would encourage the removal of the if conditions, and simply calling Off: Kitchen, Cafe
My code already checks the current value to minimize Hue calls. On a busy HE hub, or Hue hub, I have seen Hue take up to 10 seconds to send the confirmation that it turned on/off a light, so pressing on/off too quickly can result in a situation where the commands are queued up, and/or dropped. hue hub can only accept 10 light update or 3 group updates per second. If you update 2 groups with just one command, then you can only update another 3 lights in that same batch, then the hue hub starts to bog down. These are Hue's guidelines, not mine.
Armand,
(all this composed while Armond replied above)
Going through the motions after just setting Button 4 to use the OFF command only for the two groups reminded me why "it didn't work right" before. Meaning it works fine now (just using OFF command).
When I would only use the OFF command previously, if either the Kitchen or Coffee group was already off, the group that was off would momentarily turn on dimmed and then turn off. I was thinking a light with 0 lux didn't necessarily mean it was also showing itself to be OFF, so I was trying to compensate (but was in the dark, so to speak).
Now though, I guess something you or the HE gerbils did recently took care of what I was experiencing. I know I still have things to learn, like how Switch OFF and TOGGLE=0 interplay, and that may have been at the root of the experience too. Oy.
Anyways, respect to Developers and Gerbils alike! 
Thanks for your comments, Armand.
This rule works flawlessly with the 30 second Private Boolean delay effectively pausing this rule, and it's mirror "Perimeter Closed" rule, from triggering via the defined Required Expression acting as a precondition, so the scenario you describe does not occur.
I've been very happy with Armand's app, but I will take a look. Nothing of value in the informational logs - i did not think of turning debug logging on while it was happening, will do so if the problem recurs
Good call - unfortunately the related events seem to have been purged already, I will take a look if happens again.
Armand,
Now that the home setup is working quite well, more thoughts come to mind to tweak it further.
As I related earlier, I originally had not used Hue scenes at all - now I'm coming up with ways I might utilize 'em. So I've added one scene to a couple of rooms at the moment, but I can't progress because. . . my OCD.
When I view the Rooms in HE, the last scene created is duplicated in the list. Fair enough, but it's not the same for scenes in other rooms. I deleted the duplicate which deletes the single scene device, deleted the Group (room) parent, and reinstalled - but the child is again duplicated (only as witnessed in the Room display in HE).
Is there a reason I should see that duplication of the Cafe-Default device in the Room list of devices, or ???
I just recalled that about 2 months ago that "Cafe" room didn't exist on the Hue hub. I had initially added a "Cafe" zone, but soon enough deleted it to create the room. Don't know if that could play into the experience here.
...bob
Download the Hubitat app
