Think I have found a bug. I have 2 HE hub's. My primary hub runs all Zwave and Zigbee devices and my second hub run's all my cloud connection devices including 2 Hue bridges.
I use link to hub to connect several of the Hue bulbs to the main hub where most of my rules run.
I have created a rule on the main bub to set the color of some hue bulbs based on the mode (morning, afternoon, night). I can not get the hue bulbs to work with the color per mode action.
I have verified that I can go into the device settings on the linked bulb and set the color and level and the bulbs work fine.
I then created a simple rule on both hubs with the same action of "color per mode". The rule works on the secondary hub with the hue hubs attached but does not work on the primary hub with the linked hue bulb. Have verified that the Hue bulbs show up as Linked RGBW light.
FYI, the Hue Bridge connection goes over your LAN, not the cloud.
I think I've seen problems with RGB(W) bulbs and Hub Link/Link to Hub before. I did a search and found someone who had what sounds like a similar problem and someone else who was able to replicate it: Control Hue RGB lights through a linked hub - #25 by csteele
If you're able to set up HubConnect instead of Hub Link/Link to Hub, you'll likely have much better luck. It's third-party code, but staff have recommended it to users in the past, so it should be pretty solid (just a bit more difficult to set up). Hub Link/Link to Hub haven't seen many changes--actually none that I can think of--since Hub Link was introduced (the original was just Link to Hub for connecting to SmartThings, and the latter was added per customer requests). I'm guessing their interest has waned since the advent of HubConnect, though this does seem like a bug they could fix.
That being said, you could also just integrate your Hue Bridge to both hubs if that's all you need the lights for. Hub Link/Link to Hub, HubConnect, and the Hue Bridge Integration are all (unless you use ST for the first or second or specify otherwise for the second) LAN integrations, so I'm not sure I see much advantage to segregation there.
Thanks for the quick reply. Your correct the Hue bridge connection is LAN based. I had the Hue bridges on both hubs but my primary hub was up to almost 250 devices and I noticed significant slow rule execution when I was turning on 100's of devices at the same time. So I moved the 100ish hue bulbs and light-strips over the the secondary hub and I see much faster rule execution on rules controlling large amounts of devices.
I looked at HubConnect but was skeptical with all the issues people are having with hub slow downs about using 3d party code. Maybe I will give that a try and see!
Caution is always warranted with third-party code, so that's not a bad plan! I do think there are enough people on HubConnect that someone would have noticed it was causing mass problems by now (not sure I've heard of any at all but there have been a few bug fixes and enhancements). As I mentioned, staff have even recommended it as an alternative to Hub Link/Link to Hub. It's pretty solid in my experience--and might actually give you better performance than Link to Hub since it can use event sockets instead of HTTP, which with a lot of devices will likely be less work on both hubs.
If you have hundreds of Hue bulbs, many of which you never change except as part of a group, you can sync the Hue Group to Hubitat instead of the individual bulbs. It might reduce the amount of work the hub has to do. For example, if you have recessed lights in your kitchen which you never control individually, it might be useful in that kind of situation. Just a thought.
That is exactly what I do. I only bring the Hue Group in when I have groups of lights that only work together. For now, my easiest work around is to just split my rules up to run the Hue bulb portion of the rules on the secondary hub where they are connected.
Once I have the rules separated then I will try HubConnect and work back to ideally having single rules.
