This happens because you need to refresh metadata. I believe I mentioned that in the support thread and in the change release notes. To update the metadata, simply open the AHB app then click on the hub button.
This forces a refresh of all the hue settings to pull in the v2 device values.
By the way, if you reboot your hub, and if all is working as it should, the app should initiate the metadata refresh upon startup.
Assuming you mean the Philips Hue button, not the Unlink Hub button, that's the one I pressed first and immediately led to null pointer exception.
back in the states. looking into these issues.
The version of code in GitHub on line 2143 is the declaration of the bri variable. Are you sure you are on the latest version of AHB code? From Hubitat Package Manager, update the AHB code, and if there are no updates listed, then please perform a "Repair" to force download and apply the latest code from GitHub.
This is what I have:
It's right on line 2150 in your picture. Didn't change the fact that the state.lights_v2 can be null in certain edge condition which I don't exactly know what it is.
I stayed at V 1.6.6 since I had to apply my own patch to port number failure. Will update when I get some free cycles.
So, what you are proposing is I change from state.lights_v2[args.id]?.color?.gamut
To
state.light_v2?[args.id]?.color?.gamut
This change would avoid an NPE, but that NPE is purely cosmetic in the edge case where your code is out of date, and the resync that was added to the newer code did not run?
That’s not what I call an edge case, it a corrupted state that self heals if you reboot the HE.
I do not provide support for private changes that are not part of the code base. That would be near impossible and very difficult to get right.
The NPE that you observed does not interfere with the hub operation, it happens because the hub’s state isn’t synced yet (which happens when you re-pair the hub, or you migrate to the newer code and don’t reboot as the change notes recommend.
would this custom Hue Bridge Integration be a solution to my problem here:
If so, can I install this while built-in Hue app is already active ?
I want to create new devices using the custom app, then swap the devices with old ones.
If you already have the built-in app, are you using the V2 protocol? The built-in app uses less processing than my app, as I do a lot more than the built-in app.
You should be able to use both, so long as the device IDs generated do not conflict. The real issue with using both is that you will double you network traffic is using the v2 app, and my app will still have to parse all the same data the built-in app has to parse.
Some things that are different: in my app, you must use the version to API as the built-in app that you pick which version you want to use. My app allows you to manage seeing devices as well as sensors, dimmers, physical lights, and groups and zones. Other things that I do that have a tattoo does not is intelligent refreshing. If you have two lights in one zone and one of those lights is in another zone and all you do is turn that one light on or off my app will not just trigger a state change on those two zones. It will also query each zone to find out the current color of the zone according to Hugh. In the version two protocol, this is not possible so I achieve it by falling back to the version one protocol for that query another thing that I do is convert colors in the hue real time event stream from Hughes XY to habitats HSV (also known as Hugh saturation and level within habitat)
I would never tell anybody not to use the built-in integration as I think that is the most streamlined solution overall but if you have a need and it sounds like you have a need then sometimes you’re using a third-party solution is the only choice and other times that’s the better choice. It never hurts to take a looks of go ahead and take a look and give it a try.
Also of interest is Coco Hue. It was developed about the same time that I developed mine. They were independently developed separate from each other so there’s two different approaches to achieve the same goal. If mine is not what you want, maybe Coco Hue is.
The snippet @bob.t posted above suggests that battery level is reported for the Lutron Auroras, is that right?
If so, what if we want to add these dimmers to Hubitat just to be able to set up alerts for the battery level (which Hue natively doesn't support), without the need to track any other state? Is there a way to do that?
I added the dimmers via the native Hue Bridge Integration and regardless of the driver I select (hueBridgeButton, Generic Zigbee Dimmer, or just Device) I don't see battery level as an attribute...
So, you would like the ability to monitor the dimmer, even if we can’t really accurately use them, so that you can report on battery level? I can do that. I will need some time, as my day job has me very busy, but this might be a good break from my daily coding job. I haven’t touched these files in a while. It might be a good exercise to see how effective AI would be at making such support.
Oh if it's a bunch of work to add, don't worry about it!
Especially because I just realized the Lutron Auroras flash red instead of white if the battery is estimated low, good enough for me.
Thanks!
Download the Hubitat app
