Major problems with 4.0.7.3

[lakehawk]

I don’t know if you guys have noticed this… but I was looking at the official Hue app…. And it said a mandatory update was available. Told me this a few days ago as well…. But I told it to go ahead and update…. And I noticed on that update screen that the names switches and sensors is all corrupted with this duplicate name mess. So it’s possible that’s it Philips causing a lot of this mess.

[brientim]

I don’t know if you guys have noticed this… but I was looking at the official Hue app…. And it said a mandatory update was available. Told me this a few days ago as well…. But I told it to go ahead and update…. And I noticed on that update screen that the names switches and sensors is all corrupted with this duplicate name mess. So it’s possible that’s it Philips causing a lot of this mess.

Dan, I do suspect that is part of the problem. I cleaned up my normal system and deleted everything and saw similar occur... Only add a single hub on at the moment.
I observed there was LightGroups which I haven't had for a long time.
It was not present in the Hue App and I deleted it from JowieHue using Group Info (Delete function)... lost or JowieHue errors in the logs relating to trying to update the Hubs.
I deleted the hub, and repeated and the LightGroups were no longer present; however, the same issue with Sensors, as described previously and the duplicated functions persist.

[brientim]

Hello Guys

I just did some more testing on Hue... The duplicate light as reported below are reflected in the Hub. The two lights were original IDs 13 and 14 and unassigned to any room... I renamed on the hub and then assigned to the new room and this created the duplicates IDs 18 and 19. None of this was on Homeseer or JowieHue, They of course do not show as duplicates on the Hue App but are present in the api/.../lights data .





"

[w.vuyk]

Wim,

I am reviewing my previous post and I realised even though it looks like a duplication of the name in switches, it is actually correct on the feature. i.e, the default name in Hue for a dimmer switch is .... my dimmer switch and therefore, once the Switch Feature will be my dimmer switch Switch

Tim

Tim,

I have changed the way of renaming here because of the other double names like your motion devices. In the new method the switch feature belonging to a device named "Dimmer switch" would be name like your sample "Dimmer switch Switch". But if the device was named "Dimmer Switch" the switch feature will be named Dimmer Switch also.... not perfect but I guess this will eliminate the double naming here.... One down I guess..

Hello Guys

I just did some more testing on Hue... The duplicate light as reported below are reflected in the Hub. The two lights were original IDs 13 and 14 and unassigned to any room... I renamed on the hub and then assigned to the new room and this created the duplicates IDs 18 and 19. None of this was on Homeseer or JowieHue, They of course do not show as duplicates on the Hue App but are present in the api/.../lights data .

Now this has been on the back of my mind... I noticed that in the Philips Hue app - already for a while - groups with types Lightgroup and LightSource were no longer shown in the app. But I guess what we see happening here is a major bug.

if I understand correctly, you rename a light that is not assigned to a zone or room and you then move it to a zone or a group, you get a double light entry in the API?

How did you rename the light on the hub? Using postman or the philips hue app? Would like the details on this.. There is no panic yet in the dev forum of Philips. But then, most people there do not visit the forums anymore because of the major lack of response from the Philips Hue devs......


I am not sure I will be able to work around this bug?

[brientim]

I have changed the way of renaming here because of the other double names like your motion devices. In the new method the switch feature belonging to a device named "Dimmer switch" would be name like your sample "Dimmer switch Switch". But if the device was named "Dimmer Switch" the switch feature will be named Dimmer Switch also.... not perfect but I guess this will eliminate the double naming here.... One down I guess..

That is a logical work around.

Now this has been on the back of my mind... I noticed that in the Philips Hue app - already for a while - groups with types Lightgroup and LightSource were no longer shown in the app. But I guess what we see happening here is a major bug.

Yes, a major bug and with the slow development of their V2 API, I would not imagine this us going to fixed in the near future,

if I understand correctly, you rename a light that is not assigned to a zone or room and you then move it to a zone or a group, you get a double light entry in the API?

Correct, I added the light via the Hue App, and then renamed and added to a room. I did this again and once again and you can see below this created new devices 20/21. As there is no logging in their API, you can see what/why it is occurring.
I on another Hub, see JSON below LightGroup, is orphaned in the Hue App and not visible

How did you rename the light on the hub? Using postman or the philips hue app? Would like the details on this.. There is no panic yet in the dev forum of Philips. But then, most people there do not visit the forums anymore because of the major lack of response from the Philips Hue devs......

In the Hue App > SETTINGS > Lights > Light > Edit (pencil)

I am not sure I will be able to work around this bug?

This is is not a JowieHue and heard to imagine the best to manage given the dynamic changes that can occur.
The only work around would only import where in /group {lights} and type = LightGroups... problem is that would result in delete device where Not In /group {lights} Member of Groups.

"4": {
"name": "All Backyard Lights",
"lights": [
"4",
"5",
"1",
"2",
"3",
"6",
"7",
"10",
"9",
"8"
],
"sensors": [],
"type": "LightGroup",
"state": {
"all_on": false,
"any_on": false
},
"recycle": false,
"action": {
"on": false,
"bri": 127,
"hue": 8381,
"sat": 141,
"effect": "none",
"xy": [
0.4583,
0.4099
],
"ct": 366,
"alert": "select",
"colormode": "xy"
}
},

[w.vuyk]

Rechecking the post you did I think I can come around the Philips API bug (it has a name now ) The hard part is not getting confused. But I will leave it for now, because it should not be the reason other devices double on their details. I will send you an updated version (also to Dan) than has some points resolved and more logging on the creation of devices, so maybe I then find out why this happens with mono... I have tried searching for lowercase/upper case possibilities for this, but could not yet find any yet.

Wim

[lakehawk]

Tim, I went back and checked.. the other day you had sent me screen shot of your Hue app showing your bridge was at software level ....3030 ... that was when I checked my Hue hub and it said an update was available and I took it ( I have automatic updates turned off on their hub ) .. and then I sent you back a screenshot showing my hub was now at level ....6040 But after that "update" I started seeing that a new update was available.. but when I clicked on update I would get a white screen from their app popup.. and not controls...

Now yesterday again I saw "mandatory update" and when I took that update it did update the bridge... and not my bridge is reporting its at software level ...3030 So I am thinking Philips knew they rolled out a defective bridge update and have forced a rollback...

They spend an inordinate amount of time creating popups for their app promoting their "sales" on their bulbs and such.... I wish they would spend as much time updating the core functions and fix their bugs. Definitely Wim is having to chase their defects that are affecting us all.

[brientim]

Rechecking the post you did I think I can come around the Philips API bug (it has a name now ) The hard part is not getting confused. But I will leave it for now, because it should not be the reason other devices double on their details. I will send you an updated version (also to Dan) than has some points resolved and more logging on the creation of devices, so maybe I then find out why this happens with mono... I have tried searching for lowercase/upper case possibilities for this, but could not yet find any yet.

Wim

I have passed the defect on the Philips but not through their Development forum as that may never get picked up. I messaged them via Facebook and I have found that to be the most reliable method to get it to them.

[brientim]

Tim, I went back and checked.. the other day you had sent me screen shot of your Hue app showing your bridge was at software level ....3030 ... that was when I checked my Hue hub and it said an update was available and I took it ( I have automatic updates turned off on their hub ) .. and then I sent you back a screenshot showing my hub was now at level ....6040 But after that "update" I started seeing that a new update was available.. but when I clicked on update I would get a white screen from their app popup.. and not controls...

Now yesterday again I saw "mandatory update" and when I took that update it did update the bridge... and not my bridge is reporting its at software level ...3030 So I am thinking Philips knew they rolled out a defective bridge update and have forced a rollback...

They spend an inordinate amount of time creating popups for their app promoting their "sales" on their bulbs and such.... I wish they would spend as much time updating the core functions and fix their bugs. Definitely Wim is having to chase their defects that are affecting us all.

Dan, I have checked and all three hubs are on the latest version, but unusual to see two firmware releases in a week... Indicating that there was probably a major issue with1951146040
Does not help that the release notes are not useful.



June 13, 2022
Software version: 1952043030

• Improved performance and reliability of the system

June 6, 2022
Software version: 1951146040

• Improved performance and reliability of the system

[lakehawk]

June 13, 2022
Software version: 1952043030

• Improved performance and reliability of the system

June 6, 2022
Software version: 1951146040

• Improved performance and reliability of the system

Don't you wish for once they would improve the usability ...

[brientim]

Dan. Overall I think that they have done a reasonable job on the Hue App but it isn't a seamless workflow and hence 3rd party integration with HS and ZHP are they most important.
The core issue and everyones complaint is the limitation of the hub and thus the firmware is critical... But recent releases and tied to V2 API slow development, this is letting it all down and generating unnecessary work for the likes of Wim and you. I think the major defect stems from Mar as indicated in their Developers forurm.


dennisgeurts
Mar 21
Hue_Developer_Suppor:

You are right, unfortunately zone creation ended up partially in the specification already but is not yet implemented

Hello, does the latest bridge update “Improved performance and reliability of the system”
introducess any new features improvements , like zone creation ?

Reply

Hue_Developer_Suppor
Mar 23
Yes correct, this has been implemented in the latest firmware release 1950111030. You can now create and modify rooms and zones via CLIPv2.
The release notes are indeed only mentioning end-user facing changes, so any API improvements will also just be mentioned under the generic “Improved performance and reliability of the system”.

[w.vuyk]

Yes, the devs are always responding in an avoiding way. It all started with the devs being very good and detailing in documentation when Hue started. Then there were at least two years of silence an non documented changes. Now, they started communicating again, but only when really needed. APIV2 documentation was started, but is now again very outdated, Changes are taking place, without updating the documentation. It is hard to guess what they are up to nowadays.

[brientim]

Hello Wim,

Thank you for your work and I see that .74 has been submitted.

As indicated, I have report the major defects to Philips Hue Dev Team. I assume the defects are a result of the recent changes and having to maintain reverse compatibility with older app releases that are not supported by more recent releases.