Does anyone know of a way to update variable / sensor values stored on the hue bridge?
I have kept my motion sensors and lighting rules on the hue bridge and have used variables stored on the hue bridge to mimic mode settings. I would like to manage my mode settings in HE but also update them on the hue bridge at the same time. I currently manage these variables and rules using the All4Hue app.
Can I ask why you don't just do everything in Hubitat instead of your Hue bridge?
I did start by setting up the hue integration app and migrating my hue sensors and hue dimmer switches to HE, and was able to get motion and dimmer switch based automations to work.
I had two main sticking points:
In my lighting rules I wanted to use the state of the lights as a condition on whether to react to motion being detected. E.g. If I had adjusted the light settings in any way I didn't want the motion rule to override that with whatever it had been programmed to do.
That alone would not stop me using HE, it is able to track what the light state when managed through HE. But I wanted the flexibility to change the settings of a light through any third party app, e.g. the Philips Hue App, not wantinfg to be tied to Hubitat alone. Given the constraints of the timing for polling of the hue bridge for light status updates, I decided to keep my sensors, switches and rules on the hue bridge.
That said, I do want to use HE to control modes and other devices in my home, even including lights in any multi-device rules where it makes sense.
You are going to find that limiting since your motion sensors will not be readable in HE. So, if you want to turn on some hue lights and some other lights in the same room with motion, you will not be able to do that. I think you're going to find, unless you have 100% of your infrastructure in Hue, it makes more sense to have your control centralized in Hubitat. Just my 2 cents.
If anyone's interested I was able to write a small driver to update a CLIP sensor value on the hue bridge. Have used the driver to setup a switch in HE to flick between on and off values of one and zero. Will look at how best to integrate this with my rules, etc. Haven't put the code up on git, may do if I right some more, but happy to provide to anyone who wants it.
At this stage, I'm not even sure how one "looks inside" a Hue Bridge. Is it all done in their app, or are we talking about a MeetHue developer portal thing?
The all4hue app I used let you look at the rules and other aspects of the bridge you could not access via the Hue app on your phone or tablet.
@bertabcd1234 , is this something CoCo could potentially implement?
Reason I'm pursuing this line of inquiry is simply that the Hue Tap Dial (with CoCo and hub pairing) has eluded all attempts at smoothly ramping the Level of a Bulb I'm trying to control with it.
Best I've been able to cobble together involves Button Controller watching for the obvious Pushed (for tiny adjustments, this works flawlessly) or Held events (for larger fades up or down), with the latter being terminated by watching for Released.
I'm clinging to the belief that with judicious use of CoCo-interpreted events, I can craft just the right BC rule.... but if lurking somewhere inside the Hue hub is a counter or variable from which I could more easily deduce how far the dial has turned, it would make things so much more elegant. Plus the added WAF needed for the win (it's her bedside lamp the Dial is controlling, lol).
Unstated here is that I'm also unwilling to switch away from CoCo, because of its sheer awesomeness. This is the kind of device driver all others should aspire to be.
I don't know, though it seems it was possible via the API before so it's likely possible. Someone would have to tell me exactly what I'd need to be looking at in the API, preferably the v2 API.
Whether I will actually have time to do it or find it worth the effort in any timeframe is another story. 
Fair enough! I'm actually busily concocting a BC rule that leverages what CoCo already offers (debug helped me see a little bit behind the scenes).
But one thing I should quickly point out – since I briefly switched my Dial device over to @AndyWebs' custom driver (then realized his is meant for a Dial paired directly with HE, not Hue hub) – is that CoCo child devices may benefit from a Configure paddle on their Details page.
Reason: Switching drivers (and hitting "Configure" on the other one) caused the Button: count to drop from 6 to 5. And now that I switched back to CoCo, there's no obvious way to get that count back up to 6 (so Button Controller won't even let me create a slot for Button 6).
Does that make sense? Sorry I borked it. :-/
FOLLOW-UP:
CoCoHue devices are not intended to be used with non-CoCoHue drivers (and in general you should probably not swap out child device drivers behind the parent's back). I'm hesitant to add commands that are basically do-nothings, especially for LAN devices like this where there really isn't any "configuration" to send to the device, though I may if there end up being other uses.
But you can fix this. One way: switch to the Virtual Button driver, run "Set Number of Buttons" with the appropriate value, then switch back.
Way ahead of you there – was typing up my workarounds/solution, above, when you replied – but thanks for the confirmation. Definitely my bad, swapping drivers like that. It's actually a terrible habit left over from previous controller whose brand I shall not mention. It was common there to change drivers more often than changing socks, lol.
Shall not repeat! Was just feeling... er, experimental this morning. 
This is some old code I wrote when I was still using my lighting rules on the hue bridge and had not long purchased my C-4 (I think it was my first driver 
). It relied on knowing the sensor id from the hue bridge, which was easy enough to get via all4hue. I think at the time I only catered for two lighting levels, night and day, so could use a Boolean 1 or 0 as the sensor status, hence being able to write the driver as a HE switch.
I haven't looked at this since the v2 API, but if it's of any use my old remnants of these "sensors" do appear in the list CocoHue display when discovering devices from the bridge.
Having had a chance to look into the "CoCo Button" driver code, I better understand how it is generating button events from the eventStream data, and the new rotary (dial) input makes sense:
My theory is that, if the data stream indeed informs CoCo of when wheel movement ceases (I don't know which actionName - long_release? - or code it generates), then it should be possible to implement Released for both those buttons.
In turn, I could tinker with using Released as a more reliable means of "Stop Adjusting" or "Stop Fade" on the target bulb(s) in Button Controller or RM. Until then, as others have shown, the only viable "Raise" and "Lower" techniques involve setLevel or Adjust Level commands, which are less interactive by nature.
Thoughts?
If it does, yes; I'd just need the debug logs that show what, exactly, is coming in from the eventstream at that point. When I was writing the driver and testing with the various devices I had at home, there was nothing in the eventstream data I could find that corresponded to such a real-world event.
Download the Hubitat app
