Thanks for your help Ryan
Maybe someone else will have a different answer but there was a reason that hub connect was developed.
If anyone else has an idea other than “using hub connect like I am supposed to” I would love to hear from you. If connect is my only option I may buy a couple of new hubs and play around with hub connect again to see if I can keep a stable connection between hubs. Would love to get what I have working though if at all possible.
To be clear, does this happen if you manually manipulate the device on the hub it's "linked" to, or is lack of color control only a problem when using an Echo device with voice control as in the original post?
It looks like Hub Link/Link to Hub should support this if there is indeed is a "Hub Link" device exposed with that capability. Support may be interested in hearing more about this. Staff have recommended HubConnect before, so if you're able to set that up, you'll likely get better results (and have more versatility to do more in the long run), but I wouldn't be abrasive enough to say that's what you're "supposed to do"...
He cannot control the light from the master hub only on the hub that the bulb is paired to.
Hub Link and Link to Hub were developed for a specific purpose... assisting with the migration of devices from SmartThings to Hubitat. It focuses on simple devices in which one or two attributes are all that is needed to manage a migration. Take a Garage Door Opener. Hub Link will allow the Tilt sensor aspect of the device but does NOT allow the garage door to be opened and closed. Only the sensor portion can cross from one hub to another.
HubConnect was specifically developed to go beyond and allow the bidirectional transfer of Attributes and Commands hub to hub. Yes, it's a more fully featured product and yes, that makes it a step or two more nuanced to install. HubConnect also allows for many more than just two hubs, which is another element of that must be configured.
As far as I remember, HubLink was developed when Hubitat's color model was very very simple. It wouldn't surprise me to hear that color attributes and commands don't transfer. There's also "Other Hub" that fits between HubLink and HubConnect that might have more abilities.
I was able to control color on the linked hub that the device was paired to but not the on the master hub no. I will try it again with a different color bulb tomorrow.
I believe I was able to duplicate this...
I installed HubLink on one Hub and Link to Hub on the hub with a ZWave RGBW bulb. I know it's not the Hue, but then I don't own anything from them. This is as close as I can get. 
I added the RGBW in Link to Hub and the virtual device was created on the hub running HubLink.
I can turn the bulb on and off from the HubLink hub, but I cannot do a "setColor". Logs show the command occurs and is received by the Link to Hub hub:
dev:582 2019-07-27 10:36:47.278 pm debug setColor([saturation:100)...
dev:1576 2019-07-27 10:36:47.241 pm debug parse color,[saturation:100, hue:35, level:100]
2nd attempt:
dev:582 2019-07-27 10:40:09.516 pm debug setColor([saturation:89)...
dev:1576 2019-07-27 10:40:09.482 pm debug parse color,[saturation:89, hue:35, level:89]
However, using the setHue command, does work.
dev:582 2019-07-27 10:41:17.111 pm info Hank RGBW LED Bulb colorName is Medium Spring Green
dev:582 2019-07-27 10:41:17.104 pm info Hank RGBW LED Bulb RGB is [0, 255, 163]
dev:582 2019-07-27 10:41:17.101 pm info Hank RGBW LED Bulb color is #00ffa3
dev:582 2019-07-27 10:41:17.098 pm info Hank RGBW LED Bulb saturation is 100
dev:582 2019-07-27 10:41:17.095 pm info Hank RGBW LED Bulb hue is 44
dev:582 2019-07-27 10:41:17.089 pm debug setHue(44)...
dev:1576 2019-07-27 10:41:17.050 pm info vr_Hank RGBW LED Bulb colorMode is RGB
dev:1576 2019-07-27 10:41:17.046 pm info vr_Hank RGBW LED Bulb colorName is Black
dev:1576 2019-07-27 10:41:16.985 pm info vr_Hank RGBW LED Bulb hue was set to 44%
dev:1576 2019-07-27 10:41:16.721 pm debug parse hue,44
On the other hand, HubConnect works just fine, no surprise there....
dev:752 2019-07-27 10:43:34.411 pm info UpperBath Sink Dimmer is at 22% [digital]
dev:752 2019-07-27 10:43:34.410 pm info UpperBath Sink Dimmer is on [digital]
dev:582 2019-07-27 10:43:31.315 pm info Hank RGBW LED Bulb colorName is Dark Violet
dev:582 2019-07-27 10:43:31.309 pm info Hank RGBW LED Bulb RGB is [189, 0, 255]
dev:582 2019-07-27 10:43:31.307 pm info Hank RGBW LED Bulb color is #bd00ff
dev:582 2019-07-27 10:43:31.299 pm info Hank RGBW LED Bulb saturation is 100
dev:582 2019-07-27 10:43:31.296 pm info Hank RGBW LED Bulb hue is 79
dev:582 2019-07-27 10:43:31.293 pm debug setColor([saturation:100, level:100, hue:79])...
app:837 2019-07-27 10:43:31.278 pm info Received command from server: ["Hank RGBW LED Bulb": setColor]So, long story short, you need to use Hub Connect in order to get color attributes to pass from one hub to the other. Thank you for confirming.
Thanks so much for verifying, this was a big help.
So I installed HubConnect again on my existing hubs along side the hub link but I am having issues where the devices on the remote hub are not updating status on the master hub. For example if I turn a switch on or off for a hubconnect device on the master hub it works but the status never changes. This is a problem because all my rules run on the master hub but don't work if they don't know the status of the device. If I do a sync command on the master hub it does pull the status properly though. This is different than the hub link they update status immediately. Am I missing a setting? The remote hubs show as online.
On your server, which method of connectivity are you using?
For two hubs on the same LAN, set as per this screen cap for the last two fields
If you changed those values, grab the Connection Key and paste it into your Remote again.
I am using Hubitat lan and event socket.
I can't duplicate this.
I ran a test and have logs... that I'll try to explain:
First, these are logs from the remote (ZeeRadioUpper) and the Server (coordinator) merged and then sorted by time... this reverses the normal 'most-recent-on-top' order:
ZeeRadioUpper dev:838 2019-07-29 09:15:39.192 pm info Office WallSwitch was turned off [digital]
ZeeRadioUpper dev:838 2019-07-29 09:15:40.011 pm info Office WallSwitch was turned on [digital]
coordinator app:3 2019-07-29 09:15:41.067 pm info Received event from ZeeRadioUpper/Office WallSwitch: [switch, off null]
coordinator app:3 2019-07-29 09:15:41.871 pm info Received event from ZeeRadioUpper/Office WallSwitch: [switch, on null]
ZeeRadioUpper app:837 2019-07-29 09:15:57.117 pm info Received command from server: ["Office WallSwitch": off]
ZeeRadioUpper dev:838 2019-07-29 09:15:57.483 pm info Office WallSwitch was turned off [digital]
ZeeRadioUpper app:837 2019-07-29 09:15:58.150 pm info Received command from server: ["Office WallSwitch": on]
ZeeRadioUpper dev:838 2019-07-29 09:15:58.520 pm info Office WallSwitch was turned on [digital]
coordinator app:3 2019-07-29 09:15:59.356 pm info Received event from ZeeRadioUpper/Office WallSwitch: [switch, off null]
coordinator app:3 2019-07-29 09:16:00.438 pm info Received event from ZeeRadioUpper/Office WallSwitch: [switch, on null]
The top two logs are me turning the switch off then on again from the remote.. the Hub that has the 'real' device. It's followed by the pair of logs on the coordinator, showing the change arrived... was correctly "mirrored."
The next 4 are off then on from 'coordinator' and the first indication is on ZeeRadioUpper where it logs that the server sent a change.. an off... followed by the real device going off, which gets mirrored back to coordinator.
The coordinator does NOT change the state of the virtual device initially, it changes in response to a change on the real device. In other words, the top set of 4 and the bottom both reflect that a change occurred on the real device and THAT is what gets mirrored.
I'm sorry that I can't duplicate this for you. The device is the Lamp here in my office, which I certainly noticed turned off and on, on-demand.
I am getting this error in my logs. Unable to create the Hub monitoring device: com.hubitat.app.exception.UnknownDeviceTypeException: Device type 'HubConnect Remote Hub' in namespace 'shackrat' not found.
So think my problem stems from the way I am setting up my second remote hub. I can setup the first hub and if I test a device presented to my master hub it works fine updating status. But then when I add the connection to my second hub it seems to break the status updates on the first hub. Do you have the exact sequence of steps to setup both remote hubs correctly?
you haven't installed ALL the pieces.
That driver goes on the Server:
The last paragraph of that screencap.
The installation instructions say to install 3 things on the server and one thing on the Remote...
2 apps, one Driver on the Server.
1 App on the Remote.
That will allow for the establishment of hub-to-hub traffic.
Then.. depending on where the real devices are.. put corresponding stub (Universal) drivers on the OPPOSITE hub.
If you're reflecting real devices from a remote to the server, then all the Universal drivers go on the Server. IF the real devices are on the Server hub, then all the Universal drivers go on the Remote hub.
Yep I was missing the Hubconnect Remote Hub driver. I have installed that on the server hub. Still not getting status updates. Maybe if I remove the apps on the remote and server hubs and start over?
Once the Apps and Driver pieces are in place, you just need to redo the Key portion. On the server, get the Key and then on the Remote paste it in and Done all the way out.
That will tell the server there's a new Remote and it will.. this time.. find the driver it needed to automatically create the remote as a device
