[hue] {RFC} is there any need/benefit in implementing new v2 API resource types?

[andrewfg]

Philips / Signify recently added some new v2 API resource types as below. From looking at these new APIs here my personal conclusion is that there would be neither a particular purpose to, nor a particular benefit from, implementing these resource types in the binding. However I am opening this issue for discussing that.

• grouped_motion
• grouped_light_level
• service_group
• device_software_update

{ note: in addition to the newly introduced resource types listed above, there are already some other already existing resource types that are not explicitly implemented due to having neither a particular purpose, nor a particular benefit in the binding. }

[andrewfg]

@jlaur ??

[jlaur]

@andrewfg - I haven't tried it yet, but from reading https://hueblog.com/2024/06/19/philips-hue-5-19-sensors-can-finally-be-grouped/ I think the functionality around the grouped* resources types might become relevant, depending on how they actually work. I think we can consider implementing them once we find a use-case for them. 🙂

[andrewfg]

consider implementing them once we find a use-case for them

That was the purpose of opening this issue: is there a use case? But from your answer I guess that you don't see one.

the grouped* resources types might become relevant

That is my thinking. Essentially if any one motion detector in a group is triggered then the security event is triggered. Or if the average light level within a group reaches a given threshold, the light switching event is triggered. In OH the individual motion or light level sensors are anyway represented by things / channels. So the question is whether the sensor groups also need to have thing/channels? Basically the group function within the Hue bridge is replicated by the group function of items in OH (except that OH groups are more configurable). So I tend to think that OH does not need to replicate the bridge groups.