Support for Gradient Strips, Sync Box

[d8ahazard]

Any plans on adding support for either of the two above mentioned devices?

The sync box documentation is now available the hue site:

https://developers.meethue.com/develop/hue-entertainment/hue-hdmi-sync-box-api/

And the api to individually control LEDs on gradient strips should be released....soon. ;)

[michielpost]

Will the API to individually control LEDs on the gradient strips be added to the Hue Bridge API or the SyncBox API? I guess the SyncBox API because the Sync Box is needed to control gradient strips.

Adding support for the Hue Sync Box would be a good fit for this library. But I don't have a Sync Box, so that makes testing difficult. I might add something based on the documentation.

[d8ahazard]

Obviously, I can't say for sure until it's released, but my understanding is that it will be more like an extension of the light API. So, I'd assume it would be a perfect fit for this library as well.

Let me know if you'd like any help with the integration of the sync API, I've been kind of doing the rounds lately making updates to other similar libraries. Nanoleaf, LIFX, Dreamscreen.

Oh, also, you could probably list my app GlimmrTV in your list of applications that utilize your library.

On Wed, May 26, 2021, 2:46 AM Michiel Post @.***> wrote:

Will the API to individually control LEDs on the gradient strips be added to the Hue Bridge API or the SyncBox API? I guess the SyncBox API because the Sync Box is needed to control gradient strips.

Adding support for the Hue Sync Box would be a good fit for this library. But I don't have a Sync Box, so that makes testing difficult. I might add something based on the documentation.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/Q42/Q42.HueApi/issues/252#issuecomment-848547395, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMO4NCHRKFP2AS5PP2KPYLTPSRNPANCNFSM45QWKM7Q .

[mrDenning]

Has there been any announcement that the gradient lights will be accessible via API?

[d8ahazard]

Has there been any announcement that the gradient lights will be accessible via API?

Not...yet.

But I have it on incredibly good authority that this will be happening, and soon. Basically, they're just finalizing the API, and then it will be released into the wild. Just no idea when that is...

Send me an email if you wanna chat more, I'd rather not get too into it here. :P

donate.to.digitalhigh

at

gmail...

[mrDenning]

Very good 👍

[michielpost]

If the gradient light api is added to the Hue Bridge, I will of course add support for it in this library. The Hue Sync Box api is also on my list now, but might take more time.

[d8ahazard]

If the gradient light api is added to the Hue Bridge, I will of course add support for it in this library. The Hue Sync Box api is also on my list now, but might take more time.

https://www.reddit.com/r/Hue/comments/l68tau/addressing_gradient_lightstrips_using/

Still no word on the official API, but according to this, it's a matter of setting the type to 0x01, and then addressing the sections, 1-6, although that might change.

Got a buddy with some gradient strips, going to try and do some testing with him to determine if they are detected when fetching lights/groups (they should be?) and then modifying your library to add an optional param to the initializer for StreamingLight to declare it a Gradient, and do some other things.

So, if testing pans out, there may be a PR incoming to add this. ;)

[michielpost]

Sounds great, looking forward to the PR!

[d8ahazard]

So, after looking through the code for Q42 more thoroughly, I'm pretty confident I know what needs to be done.

However, given the complexity of the EntertainmentGroup/Layer structures, I can see there are a few different ways this could be implemented. But, ultimately, I think this will need to be determined by the existing authors.

In a nutshell, I think the approach would involve making a subClass of the StreamingLight class.

In that subclass (I called it StreamingLightGradient), we add a public State[] with six states for the six zones in the Gradient strip.

Then, to send the state to the device, we modify the GetState() function like so:

` internal IEnumerable GetState() { List result = new List();

  byte deviceType = 0x01; //Type of device 0x00 = Light; 0x01 = Area
  var lightIdBytes = BitConverter.GetBytes(Id);
  // States is our state array
  foreach (var state in States) {
    result.Add(deviceType);
    result.Add(0x00);
    result.Add(Id);
    result.AddRange(state.ToByteArray());
  }

  return result;
}

`

So, that should handle the low-level API stuff. But, then there are some other caveats...

We can add a constructor to StreamingGroup that will take a Gradient Id as well as a list of light IDs, as well as check to make sure we're not sending more than 10x total values:

/// <summary> /// Constructor without light locations /// </summary> /// <param name="gradientId">ID of Gradient strip</param> /// <param name="lightIds"></param> public StreamingGroup(string gradientId, List<string> lightIds) { if (lightIds.Count > 4) { throw new ArgumentOutOfRangeException(nameof(lightIds)); } Add(new StreamingLightGradient(gradientId, new LightLocation())); this.AddRange(lightIds.Select(x => new StreamingLight(x, new LightLocation()))); }

But, there's still stuff for the EntertainmentLight bit that needs to be addressed. Similarly to the StreamingLight, we'd need an EntertainmentLightGradient (or EntertainmentGradient, EntertainmentStrip?) class that implements most of the EntertainmentLight methods, but does slightly different things so we can store the 6x different states.

Oh, also, we probably need a boolean for StreamingLight/StreamingLightGradient so we can determine whether or not it's a strip.

And that's where I need a bit of direction. Given the concepts I've mentioned above, what do you guys think is the best approach for adding the necessary handlers elsewhere so that we can still more or less treat a Gradient as a regular light, but still address it individually as well?

[vchlum]

Hi @d8ahazard, I have bad news regarding the gradient light strip support in general. After the latest bridge update, the trick with deviceType = 0x01 does not work anymore. We probably need to wait for API version 2 to be published by Philips Hue. I implemented the solution with deviceType = 0x01 in my project and it stopped working after the bridge update. I searched the Internet for the solution and I wasn't able to find it. That is why I started to watch this thread. In hope for the solution:-D

[d8ahazard]

Ah. I see. Well then, yeah, I guess we wait. I'll poke at the code for the latest android app...

On Fri, Jul 30, 2021 at 11:58 AM Václav Chlumský @.***> wrote:

Hi @d8ahazard https://github.com/d8ahazard, I have bad news regarding the gradient light strip support in general. After the latest bridge update, the trick with deviceType = 0x01 does not work anymore. We probably need to wait for API version 2 to be published by Philips Hue. I implemented the solution with deviceType = 0x01 in my project and it stopped working after the bridge update. I searched the Internet for the solution and I wasn't able to find it. That is why I started to watch this thread. In hope for the solution:-D

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Q42/Q42.HueApi/issues/252#issuecomment-890026861, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAMO4NEDBXFNJVGMHQFLKOTT2LKZVANCNFSM45QWKM7Q .

[d8ahazard]

Okay! So, I don't have "official" documentation, but I did get a reply in the Hue dev forums with instructions on how to address Gradient Strips.

Will probably work on a PR in the next few days and see if I can get this...but I don't actually own any gradient strips, so testing might be...difficult.

https://developers.meethue.com/forum/t/gradient-lightstrip-and-the-new-entertainment-api/6499/4

[d8ahazard]

Hi @d8ahazard, I have bad news regarding the gradient light strip support in general. After the latest bridge update, the trick with deviceType = 0x01 does not work anymore. We probably need to wait for API version 2 to be published by Philips Hue. I implemented the solution with deviceType = 0x01 in my project and it stopped working after the bridge update. I searched the Internet for the solution and I wasn't able to find it. That is why I started to watch this thread. In hope for the solution:-D

Wait - aren't you the person who commented in the hue forums? :P Looks like the user names are similar. ;)

[vchlum]

Yes, it is me:-) I was eager to provide this feature for my project and for myself. So I collected information from the internet and a lot of my own effort.

I hope the gradient light strip feature description would not change until the official API description release, but no warranty of course:-) I own the gradient light strip, so I could help with testing if you need it.

First thing is to implement the event subscriber, no need for a gradient light strip for that.

[d8ahazard]

@michielpost

Looks like the V2 API is now official, with quite a few changes...including support for Gradients.

With this, we would also like to provide an update and reminder on deprecated services:

The V1 OAUTH2 (/oauth2) endpoint has been deprecated since July 2020 and will be disabled on short term – please double check that you are using the V2 OAUTH2 (/v2/oauth2) endpoint
HTTP has been replaced by HTTPS since November 2018. The V2 API does not support HTTP, but also for the V1 API it will be blocked when all bridges have received Signify signed certificates.
As per today, we deprecate UPnP as a local bridge discovery method, scheduled to be disabled in Q2 2022. Please use the recommended discovery methods mDNS and discovery.meethue.com which are supported since January 2018.
The Philips Hue SDK will not be updated to support the V2 API as it has been deprecated since July 2019, however the Hue Entertainment Development Kit (EDK) remains available and is fully compatible with the new API. The interface of the EDK itself is unchanged, so if you were using the EDK you can support the V2 Entertainment API simply by intaking the latest EDK version – no code changes required on your end.
The V1 Entertainment API is not able to control the individual segments of the new Gradient lights, which can be a confusing user experience. Therefore we request developers to prioritize upgrading entertainment features to the V2 entertainment API. As a general reminder, the REST API – whether V1 or V2 – must not be used for use cases with continuous fast light updates, as compared to the dedicated streaming API it provides a much slower update rate, cannot be stopped from other apps, and floods the new event stream with unnecessary messages.

[michielpost]

Wow, lots of changes. Will take some while before all that is in this library.

[michielpost]

I just released the first version of the new HueApi NuGet package: https://www.nuget.org/packages/HueApi/ This package targets the new clip v2 API. This is a first start to support new features, it does not support the entertainment v2 api yet.

[d8ahazard]

I just released the first version of the new HueApi NuGet package: https://www.nuget.org/packages/HueApi/ This package targets the new clip v2 API. This is a first start to support new features, it does not support the entertainment v2 api yet.

Awesome! How do I implement Entertainment stuff in the new API? Still use the old lib?

[michielpost]

The new HueApi package implements all API's in clip v2, described here: https://developers.meethue.com/develop/hue-api-v2/api-reference/

There's also a protocol update for the Entertainment API, described here: https://developers.meethue.com/develop/hue-api-v2/migration-guide-to-the-new-hue-api/#Entertainment

It's a minor update to be able to address the gradient light strip. That's not implemented yet. It will stay in the Q42.HueApi.Entertainment package.

[michielpost]

I just released a package for the V2 Entertainment API. It only uses the v2 API and allows streaming to channels and lights with multiple channels.

You need to use the new packages that target the v2 api:

• https://www.nuget.org/packages/HueApi.Entertainment/
• https://www.nuget.org/packages/HueApi/

Most of the code stayed the same. Example usage can be found in the HueApi.Entertainment.ConsoleSample app: https://github.com/michielpost/Q42.HueApi/blob/master/src/HueApi.Entertainment.ConsoleSample/StreamingSetup.cs#L26-L38

I was able to stream to my own lights, but I don't have any gradient lightstrips. So if anybody has those and can try it out, please let me know if that works.

[d8ahazard]

I just released a package for the V2 Entertainment API. It only uses the v2 API and allows streaming to channels and lights with multiple channels.

You need to use the new packages that target the v2 api:

• https://www.nuget.org/packages/HueApi.Entertainment/
• https://www.nuget.org/packages/HueApi/

Most of the code stayed the same. Example usage can be found in the HueApi.Entertainment.ConsoleSample app: https://github.com/michielpost/Q42.HueApi/blob/master/src/HueApi.Entertainment.ConsoleSample/StreamingSetup.cs#L26-L38

I was able to stream to my own lights, but I don't have any gradient lightstrips. So if anybody has those and can try it out, please let me know if that works.

Thanks! Gonna work on implementing, then I can have some ppl test gradient strips.

Do you have an example of linking using the new API?

[michielpost]

Do you have an example of linking using the new API?

The new API does not have support for linking with the bridge yet. So you need to use the old packages for that.

[d8ahazard]

What about api//groups in the new CLIP API?

Is that exposed somewhere in the library?

[michielpost]

What about api//groups in the new CLIP API?

Is that exposed somewhere in the library?

Yes, there's the Grouped Light API Example usage can be seen here: https://github.com/michielpost/Q42.HueApi/blob/master/src/HueApi.Tests/GroupedLightTest.cs

Hue API reference: https://developers.meethue.com/develop/hue-api-v2/api-reference/#resource_grouped_light

Currently the grouped light API is pretty limited, it only supports turning it on/off and set the alert action. I expect Philips Hue to expand the API, so we can set colors, dimming etc. I already made support for that in the HueApi V2, but we need to wait for Hue to actually implement this API further.

[d8ahazard]

Let me explain what it is I'm actually doing, then maybe you can recommend a way to do it with the "new" API.

1. Look up all the possible entertainment groups, plus each light (channel) in that group. This is why I was using the groups endpoint.

2. Look up all the possible lights so I can get their friendly names and model numbers, plus capabilities...which can probably now be got just by looking at the new groups (entertainmentconfiguration) endpoint. Specifically, looking for ones that can be streamed to.

Store all this data locally, present it to the user so they first select an ent group, then map each light/device to a region of the TV screen, like so:

Similarly, during streaming, I'm using this "mapping" data to determine which lights to control, and which colors to send to them based on the screen data. Currently, I'm not seeing quite how I'd do this with the new API...

[michielpost]

With GetEntertainmentConfigurations you can get all entertainment groups. Each group contains a Channels list with all the possible channels to stream to.

With GetEntertainmentServices you get all the devices that support streaming. You can link those IDs to the IDs from the Channels list. Each entertainment service also has an Owner property with a Resource Id.

You can get the name of the lights if you link the Owner RID with the same Owner RIDs you get back from GetLights.

[d8ahazard]

Beautiful, thank you again. I think that's the info I needed to make this work again. ;)