When using the "Start Level Change" "down" direction command with either a Hue group or a Hue bulb, the resulting new level is not displayed in Current States. It works fine for the "Up" direction.
What I see is that if I start off at 100% and start the down level change command, the level reported in current state stays at 100%. I can turn the light off and on again and click on the refresh button without the level updating. Even using the Refresh button on the Hue Bridge device, doesn't update the level. It isn't until either the periodic V1 poll runs or if I click the "Refresh V1" button on the Hue bridge device that it updates the level. This affects both groups and bulbs but only in the down direction.
Of note is also that using the "Stop level change" command to stop the level change before it completes also produces some interesting level reports that seem to fluctuate over 30 seconds or so before finally stabilising when using it on a group and not working at all when using on a bulb when stopping a down direction level change.
This isn't a bug in the integration, unless you're running into something completely new; rather, it's an oddity of if and how the Hue API reports this data (if you're curious: enable debug logging on the Bridge and you'll see all the raw data coming in from the device with the V2 API enabled; enable it on the device and you'll see the entries the driver determines matches with that device plus anything a poll matches with the device). The Hue API should provide the best information available, but occasionally it does weird things like this.
It will normally settle on its own within a minute or two, from what I remember with the V1 API. It's been this way for at least the last 6 years that I've been paying close attention to the Hue API but quite possibly longer (likely since introduction). I pretty much stopped paying attention to this by the time I got around to playing around more with the V2 API, but a quick test shows that it's still a bit odd for me (getting stuck at 80% reporting for a while no matter how far down I go?). You may need to wait until the polling interval passes for the new data to actually be seen by the hub -- or do a manual refresh on the Bridge device, ultimately the same outcome -- either assuming the data the Bridge itself reports is accurate by that point.
Thanks @bertabcd1234. I turned on debug logging and dove deeper into the rabbit hole 
It looks like Hue is responding to both the up and down command in a timely fashion. When going up it will return '..."dimming":{"brightness":100.0}...' and when going down it returns '..."dimming":{"brightness":0.0}...'
I wonder if the HE integration will disregard the "0.0" brightness when going down as it isn't compatible with a light that is on. But, knowing now that this is the response from the event stream, Hubitat could consider changing the implementation of the down transition to translate the "0.0" brightness in the event stream to "1.0" instead.
The Hue app immediately shows the brightness as 1% as soon as I hit the down level change command on HE.
This seems odd, too. First, 0 or 0.0 isn't a valid value for brightness according to the API docs ("value cannot be 0"). Second, just because you initiate a startLevelChange() doesn't mean you intend to go all the way to 1 (or 0?) or 100; it just means you're headed in a certain direction. What it should do is report the final level at some point (V1 did not seem to do this quickly; I haven't tested much with V2, but in a quick test it eventually did so, too). If it does that, the integration will catch up, whether via polling (with any API version) or realtime V2 API data.
Additionally, 0 is not off (nor is any particular value); there is a separate key, on, in the JSON data for the on/off state.
What the driver does is convert the data from Hue to a Hubitat level value (in the V2 API, these are basically the same; there was a wider range on Hue in V1). Then, if the value is greater than 0, it generates an event. I had to look up what the code does since I couldn't remember for sure, but this must have been related to the fact that 0 isn't a valid value on either platform and things work best when it was ignored. In my case, the API eventually reported the right data, and the drivers caught up. I'm not sure that making it report 1 instead of 0 is a good idea, since in this case neither value was really accurate, and ignoring it seems just as good (again, keep in mind that just because you issue one of these commands doesn't mean you're going to go all the way). But I'm open to ideas -- or data if anyone's Bridge is doing something different from mine.
I’m definitely with you on this one, but that’s not the way the Hue API seems to work. As soon as you hit the up direction level change command it will report a brightness level of 100 and for the down direction it will report 0. If the stop level change command is used, the API will eventually report the correct level but if the stop command is not used, there will be no further events sent from Hue. If v1 polling is not used, then the brightness level will not be correct in HE until another level change is commanded (an on and off of the light doesn’t rectify this issue, nor does a v2 refresh).
Anyway, I’ve pointed out this anomaly, which was the intention of this thread, and I’ll leave it to the good people of HE to decide on whether they want to address it or not. Cheers! 
It seems like there are two problems on the Hue side here: the fact that it reports a level of 0, which is not valid per their API spec; and the fact that it never reports the correct level on the V2 API if the stopLevelChange() command is not used. (The "if V1 polling is not used" thing is one reason that I recommend keeping this setting enabled, as it is by default and is indicated as such in the UI. )
One of these problems can be worked around in some cases, but if the V2 API never reports the correct values, I don't see a good way to work around any potential cases. It does seem like the user can work around this by using the stopLevelChange() command, which is normally intended to be used after a startLevelChange() anyway; alternatively, if you want to go to 1% or 100%, I would suggest a setLevel() to those levels instead, as there is no need for these more specialized commands in that case (in the real world, I only use these when dimming from a button/remote device, mirroring the behavior of a smart dimmer).
Is this causing problems for any of your automations, or are you just curious about the data?
"They" is "me" for this integration. The current handling seems reasonable to me based on the above unless there are problems and none of the workarounds work, but I'm open to reasonable ideas if it doesn't...
Sorry. Didn’t realise. I know you’re behind one of the community Hue integrations, didn’t know your skills had been brought in for the updated HE integration. That’s great! I like that Hubitat recognises the skills and dedication of our community and draw on that pool of skills for their official integrations! This is not the first time
No, not at this stage at least. I have yet to upgrade the hub where my Hue integration sits, but I was experimenting with the new one on a different hub. I didn’t find that everything worked very well on the old integration so I ran the new integration through its paces to see what worked and what quirks there were. This was the only quirk I found and I was otherwise very pleasantly surprised on the speed and feature set of the new integration and love it that we don’t need to rely on polling anymore (well, except for in some edge cases as it seems 
).
Since you’re the developer, let me ask you this directly then in regards to this bug (or inconsistency in Hue following their own API definitions). The event that is sent to HE after commanding a down level change seems to only include brightness as the only state and in this case the value is 0.0. So we can perhaps infer from this that the state of the switch hasn’t changed and the light is still on. Can you not use the fact that the light is on and brightness has been changed to 0.0 to just set brightness to 1? Like IF brightness==0 AND state.switch==on THEN state.level = 1
If the stop level change is used, then this will eventually change the level to the correct level, but if it isn’t used, then 1 is going to be a more correct representation of the current brightness level than the original level, right?
If this is too much of an edge case to worry about, then, as you say, there are ways to work around this as long as we know that this is the behaviour to expect.
Thanks!
I don't think so -- there's no guarantee of how far down you're going when you use a startLevelChange("down"). It could be all the way down to 1%, but it could just be down a few percent from where you are currently (e.g., well into the 90s if you're at 100%). I'm not sure either way is better; in that last case, 1% would be quite different reality. This is why I'm more inclined to just ignore invalid data, and eventually it should catch up (but, again, open to ideas if this is actually causing problems -- the main possibility in your case seems like it could be resolved by again using a matching stopLevelChange() or just setting the level to 1 or 100 directly if that's actually your goal, as these commands are geared towards specific uses).
I promise this is the last time I am going to try to sway you on this issue 
I’ll just highlight something real quick.
You are of course correct in saying that we don’t know how far the start level change command will take us. It could be a few percentage points or it could be all the way. But, if it isn’t going all the way (the change is halted by the stop command), then there will be another event sent (eventually) from Hue with the new, correct level. If the level is initially set by the integration to 1, it will then be changed to the correct value after the stop command has been used. Or, it will remain at 1 because the stop command wasn’t used. This will then also be consistent with how the Hue app reports the brightness level of the light. It is immediately set to 1% and then changed to the new value if stop is used (that can take a couple of minutes for the app to report, so even the Hue bridge doesn’t know of the correct level immediately when stop is used).
This would cause issues for those of us that mirror the level of Hue lights on the Hue bridge to non Hue lights on HE. For example: Home Assistant doesn’t filter out these bogus levels, and it makes it undesirable to mirror Hue lights imported from HA as the brightest bounces all over the place on the mirrored bulbs every time one changes the level. I know this because I tried it before Robert got the V2 api running in CoCoHue.
Yeah, that’s true. But even now, when using the stop level change command, I’ve seen delays of up to 1.5 minutes until Hue finally reports the new brightness level.
What I have observed from the v2 implementation (which to be fair is the same as is being displayed in the Hue app except for when allowing the dim level to go all the way down without using the stop command) is that the new brightness level is not available to HE immediately, as mentioned above, I’ve seen delays of up to 1.5 minutes. So in your case, with mirroring the Hue light, you’ll end up with the Hue light dimmed to its new level and the other lights staying at their original brightness level for up to 1.5 minutes until Hue finally catches up and reports the new level. That doesn’t sound great either, but the 1.5 minute delay might not be so common, maybe the delay is usually less than that. Or is that delay something that only I see in my environment?
From what I see on my system, I personally wouldn’t mirror the level of any Hue lights while using the start and stop level change commands just because how slow Hue is to detect and report the new brightness level. It would drive me insane 
For me it’s almost instant. Not sure why you’re seeing such delays.
Interesting. I’ve just been using one model of downlights to test this. I’ll try it on a bulb and LED strip as well to see if it is that model light that is slow to report back to the bridge
Nah, it's not confined to only the one model of lights. I performed the following test, with debugging enabled, to see how long it took the Hue bridge to report the new brightness level to HE. I turned on the light, set it to a brightness level of 5% or 10%. So far so good. I then commanded it to do a "start level change" in the up direction. The brightness level was then immediately reported as 100%. After a second or so I used the 'stop level change" command. The light level continued being reported as 100% until after a long delay when finally the new correct brightness level was reported. The delays I recorded were:
RGBW LED strip: 2 minutes 31 seconds
RGBW Outdoor spotlight: 53 seconds
CT Downlight: 1 minute 30 seconds
RGBW bulb: 43 seconds
Representative debug log:
Is it just me seeing these delays when using the level change commands?
Edit: And to be clear, this is not a delay that is caused by the HE implementation of the Hue integration. I'm seeing the same delays in the Hue app. Just curious to see if I'm the only one seeing these types of delays when using the start and stop level change commands.
No, I've seen them myself before (dating back to the very first version of the Hue integration on Hubitat shortly after its introduction). I don't use these values that quickly for any automation, so it's never been a big deal for my use case.
It should be noted that this particular way of running the commands is, as many are, still using the V1 API. It may be interesting to see if the equivalent method of doing this in the V2 API still produces the same result. I'm guessing so since I suspect the underlying issue is related to some Zigbee parsing on the Hue Bridge itself, but that's the only thing I can think of that might meaningfully change anything...
TL;DR: This problem stems from how the Hue bridge responds to a start level change down command. The response doesn't contain a valid brightness level.
