After installing one of the recent updates of the app on Android the display of the rooms have changed. I have the impression that the dimming factor was added into the calculation of the room color, but that’s just a guess - whatever it is, it makes look brightly lit rooms look black!
It’s even worse. I turn on the light in a room with maybe 10 lights. The scene sets normal white light, some dimmed, some not. Right after that the display in the app is fine, all lights and the group have a grey color.
Hello @srudin, thanks for letting me know. This is definitely a bug as this is not how it is supposed to look. There should not be any colour changes in the new version. Apologies for the inconvenience caused, would love to get this resolved.
I am unsure what is going on. On my system all works fine, and you are the first user to report this.
In the update we migrated to a new API (= communication with the bridge), as Philips Hue no longer supports the old method we used (which could suddenly stop working). I think something is going wrong with this new API, maybe the scenes are causing the issue. Does the issue only happen with a specific scene? Or does it also happen when setting the light colour manually using the colour picker?
If you still have the official Hue App: could you please check if the same issue appears there? So at least we can rule out that this is bridge error or a corrupt scene. As Hue Essentials shows all the rainbow colours, which it reads from the bridge, I think something is going wrong on the bridge itself.
This was always the case, no changes here. However, a room should never appear as black, which means something is wrong.
Also unable to reproduce this unfortunately. Any chance you could share a screenrecording which shows the behaviour? That would be very helpful, thanks in advance.
Hi Thomas, happy to get a reaction from your side!
About the loading:
I have 5 bridges. When I opened the app in the previous versions, I saw right away my bridges and groups with their states (light on/off etc.) as it was the last time before I closed the app; then it seemed to synch and after 1-2s it updated everything - but usually only the states were visually updated (some lights now off/on) because changes to the groups (new rooms, new lights) happen rarely.
When I open the new version now I see - nothing. After 1s I can see some random bridges; and after another second the remaining bridges. This is not a serious problem but it makes things flickering and jumping around which is a bit irritating. I would like if you could load the previous situation first and update it, same as it was before.
About the colors:
The rainbow I reported in the last post also appears in the Philips Hue app. I have never seen this before, probably it came with a Hue bridge update. It is not related to a scene, the same thing happens when no light is on in a group, I then select whatever white (4000k) or color with or without dimming and wait for a minute or two and then, slowly, light after light (I tested with groups that have around 8-16 lights) they turn to some random color or black and the group gets the rainbow or the black background again. I can observe this behavior on all my 5 bridges in every group/room.
First thing to note is that I have Gledopto lights (80+ indoor and 50+ outdoor) and it seems that the indoor lights turn to a random color and the outdoor lights turn to black. However, I have these lights for about 3 years already and never observed this behavior before so it must be related to some software / firmware update.
Second thing to note is that I can observe the rainbow / random colors in the Philips Hue app as well - but not the black background. The outdoor lights looked correctly in the Philips Hue app during my testing even after 10-15min.
I have no idea what this means though… let me know what other information you need…
Thanks, I will look into this. It seems this is indeed an issue when using multiple Hue bridges.
I have some Gledopto lights here. Will try them in the following days and see if they have the same issue. If so, I hope I can implement a workaround. But if the bridge reports the wrong colours, I am afraid there is not much I can do.
Are there any findings yet?
Same thing happens to me, but not all scenes.
After some investigating this seems to be an issue with the Hue V2 API after some bridge update. Hue Essentials migrated to this API in the past (New color display is terrible - #3 by Thomas).
It seems when you set the light to a color temperature, it is briefly reported in the new API, but the value then reverts to a color value which is invalid. The color temperature value cannot be read anymore by Hue Essentials. Unfortunately this is not an easy fix as the Hue bridge reports the wrong value, so Philips Hue would need to fix this in their bridge API.
The performance issue for the initial loading of groups will be fixed in the next update of the app, version 4.0.0. I expect it to be available in the next week.
Thanks for the performance fix.
I understand the color issue depends on Philips. It’s irritating but I can live with it - let’s see if there will ever be a fix for the api.
But what about the rooms turning black? This is something I cannot see happening in the Hue app. Would it be possible to fix that? Because having rooms showing the wrong color is one thing; but having rooms showing no color when the lights are on is not just irritating, it’s misleading…
But what about the rooms turning black? This is something I cannot see happening in the Hue app. Would it be possible to fix that? Because having rooms showing the wrong color is one thing; but having rooms showing no color when the lights are on is not just irritating, it’s misleading…
The performance fix is already available on the app store. I would love to hear from you whether this has improved the startup time in your case. I have some ideas to improve this even further, but currently working on other fixes which are more important.
About the color issue, I thunk it is best to report this to Philips Hue with the details in New color display is terrible - #8 by Thomas. They can fix this in their new API.
Using the old API for this as a workaround is no viable solution unfortunately as this will decrease performance and of course the old API can be removed any time.
About the rooms turning black, I needed to add an extra option in the app to be able to debug this, as I am unfortunately not able to reproduce this myself. Please update Hue Essentials to the latest version, 4.0.3. On iOS this also contains a new UI. Could you please do the following?
API V2 optionUnfortunately I did notice there is a text selection issue in the response field (it is quite big), but some screenshots of the response (you can scroll down), should be good enough for me to spot the issue.
The black color issue does look like a third party light issue, but as you said the Hue app does report the color correctly. With the details above I should be able to see what’s going wrong with the light, and maybe even fix it.
I am on 4.0.3 Android.
Performance:
This is what I saw opening the app twice in the last minute:
First time I saw bridge 3 (and its rooms), after maybe 500ms bridge 2 (and its rooms) jumped in above 3, after another maybe 500ms bridge 1 (and its rooms) jumped in above 2. The status of the rooms (lights) refreshed some 100ms after their bridge showed up.
Second time I saw bridge 3 (and its rooms) again, then bridge 1 (and its rooms) jumped in above 3 and then bridge 2 (and its rooms) squeezed in between 1 and 3. Same behavior with the rooms (lights) status.
I cannot say how bridges 4 and 5 behaved because they were outside of the screen. I guess that bridge 3 shows up first because I connected this bridge first to the app, but maybe this is random as well.
I can live with the light status taking 1-2s to refresh after starting the app (sure, the performance could be better but it’s acceptable for 5 bridges). What I don’t like is the jumping behavior during the startup and I don’t remember experiencing this before maybe October '24. What I would like to have fixed is that the configuration that was used when the app was run the last time is immediately displayed when the app is started. After this the app can load the current data from the bridges and update the display. This will change the rooms (lights) status but with the old configuration showing up immediately there should be no “jumping” anymore in 99% of the startups (unless configuration was changed which happens very rarely).
Color issue:
I have reported it to Philips, will update here if I receive any answer. As said I can see the same behavior in the official Hue app - however, I cannot see this behavior in the “all4hue” app which I tried out recently. Seems like they have found a way to get around this problem in their app. Just an observation.
Black color issue:
Here you go:
{
"errors":[],
"data":[
{
"id":"3906300e-0cdb-408f-ac52-bd829724943b",
"id_v1":"/lights/29",
"owner":{
"rid":"b74ce688-9978-4ff1-a2ad-04db3abe8988",
"rtype":"device"
},
"metadata":{
"name":"Extended color light 29",
"archetype":"ground_spot",
"function":"mixed"
},
"product_data":{
"function":"mixed"
},
"identify":{},
"service_id":0,
"on":{
"on":true
},
"dimming":{
"brightness":19.76
},
"dimming_delta":{},
"color_temperature":{
"mirek":null,
"mirek_valid":false,
"mirek_schema":{
"mirek_minimum":158,
"mirek_maximum":495
}
},
"color_temperature_delta":{},
"color":{
"xy":{
"x":0.0,
"y":0.0
},
"gamut_type":"other"
},
"dynamics":{
"status":"none",
"status_values":[
"none"
],
"speed":0.0,
"speed_valid":false
},
"alert":{
"action_values":[
"breathe"
]
},
"signaling":{
"signal_values":[
"no_signal",
"on_off"
]
},
"mode":"normal",
"type":"light"
}
]
}
Thanks for the details.
Performance: Are you still using “groups” or do you only have “rooms” and “zones”. Hue Essentials sill shows groups using the old API, which causes a delay and could cause jumping. A solution would be to either migrate to zones, or move the groups all the way to the bottom of the list. I will look into this as this could be improved a bit, but the old API is only a temporary solution.
Color issue: the other app you mentioned is probably still using the old API and has not been updated to use the new API. As mentioned earlier, the issue is only in the new API. The old API could be removed anytime, which means apps using this API will stop working. I had to migrate to the new API in order to prevent a huge issue in the future.
Black color: thanks, I see the issue. The value of XY has an invalid 0 value, which should not be happening. I can change it show it shows white instead, not much more I can do.
Performance: I never created any groups or zones, I only use rooms. However Hue Essentials has created one element per Bridge that containes all the lights of that bridge. I cannot edit this item and in the details it says type “lightgroup”. These are the only non-rooms items I have.
Color issue: Ok I see, makes sense.
Black color: Change zero/zero to white would be nice and unproblematic I think as I have never seen a light emitting a black color 
Dummy question: What about the “color_temperature” values (mirek)? Wouldn’t that indicate that the user set a white temperature instead of a color?
Correct, but that appears broken for third party lights. In the response:
"mirek":null,
Instead of null, this should show a mirek value. This works properly for Hue lights, but for third party lights it only appears for a few seconds, then goes back to null. That’s exactly the issue that Philips Hue needs to fix.
Response from Signify:
“We’ll be forwarding your concern to the Hue Developers Group for further consideration. This community offers valuable resources and support for custom app development, and you can access it here: Hue Developers Group.”
Let’s hope they come with a solution. Unfortunately, the Hue developers group does not reply at all to me or any other developers with questions.
Black color issue should now instead show a white color as fallback with version 4.1.0 on iOS.
Very interesting discovery:
I was finally able to get the Windows app (4.1.1) working again (Windows app is not working anymore - #7 by srudin) and saw this:
Compare this with the same view in the Android app (4.0.3):
As an example check out the room “Gate”: You can see that the Windows app shows the “desired” behavior with some colored background for white lights (as it was with API V1) while the Android app shows the black background as complained above. Both screenshots were taken at the same moment and showed this situation over more than a minute.
@Thomas Thank you for the white color fallback fix (although I haven’t received it yet) but I wonder why the fallback is necessary at all if the Windows app can handle the situation properly?
Hue Essentials version 4.1.0 and higher contains a fix for black colour (now white tint as fallback). This update has been rolled out to iOS and Windows already.
As you can see, the fix is working in your Windows app. I expect the same fix for Android to be rolled out later this week in version 4.1.0 (or higher).
