Is The Philips Hue Entertainment Zigbee Extension Implemented In Z2M?

[danieledwardgeorgehitchcock]

I have been following this project for a while now, and have also contributed from time-to-time for new devices.

I am curious to know whether the custom behaviour / zigbee extenstion that Philips introduced for their Entertainment functionality has been implemented / can be replicated - I have looked through the issue history and cannot find anything definitive.

Here is a link to a Philips blog post which describes this custom behaviour (not sure that this can be viewed without a login).

The important part is:

1. The command packages together the target state of up to 10 light channels in a custom Zigbee message.
   This message is sent as a unicast over the mesh network to an automatically chosen proxy node in the target entertainment room.
2. This proxy node sends out a non-repeating low level MAC layer broadcast which all nearby lights will hear.
3. The nearby lights unbundle the message and act on their states.
4. Since the command is unicasting together with MAC broadcasts, we can stream commands 25 times per second to any light in the home whilst still creating spatial effects across multiple lights, all without causing network congestion.

Additionally, the mechanism has no retries, which benefits an entertainment setting where synchronization is critical: for example, a delayed frame from an explosion in an action movie is worse than skipping the frame entirely.

[Koenkk]

This is not supported and I don't know if this can be supported in the future. I guess it depends if the coordinator firmwares allows us to send such low level messages. You can start by sniffing the traffic of this: https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html

[sofakng]

I'm also extremely interested in this. I've just purchased a Zigbee stick (zzh!) to experiment with, but I use Hue Entertainment mode a lot so I'm not quite ready to convert over. I wish Hue would provide implementation details so this could be implemented elsewhere...

[adrianipopescu]

sorry to necro this thread, but has there been any progress from device manufacturers / firmware devs / support in general on this topic?

[chrivers]

In case anyone else also stumbles on this thread:

Not exactly for entertainment mode, but I've just finished reversing the vendor-specific zigbee format used for gradient light strips:

https://github.com/chrivers/bifrost/blob/master/doc/hue-zigbee-format.md

From a cursory glance at entertainment mode traffic, I think a similar sort of encoding might be in play.

Anyway, I just wanted to offer people the reference material I wrote, in case it's useful.

[danieledwardgeorgehitchcock]

This is amazing work!

Is your intent to merge what you have learned back in with this project, or are you looking for others to take on that mantle?

Your documentation (as far as I can see), applies to Color and Color gradient fixtures - have you investigated the payloads for White Ambiance fixtures? - are they the same, and unsupported attributes get dis-regarded by the fixtures?

I'd also be interested to see some further investigation on how this does indeed apply to Entertainment.. Are Entertainment groups the same as normal Zigbee groups? I suspect not... How are Fixture ID's allocated?

[chrivers]

Thank you :)

So I don't have any Hue lamps of the white-gradient type, but the document I've linked is the entire payload for the state attr of the manuSpecificPhilips2 cluster (0xFC03).

This cluster seems to be supported by most, if not all, Philips Hue lights.

Also, the state includes the color temperature in Mirek (as well as other more common properties, like the on/off field). Considering this, I would definitely expect this to work across pretty much all hue devices, but unfortunately, I cannot test it myself.

As for your question of development - I must admit, I've never done any serious work in typescript. I don't even know how to get a proper dev environment set up 😅

I would love to help with ideas, explanations, brainstorming, etc, but I think it's much better for everybody if someone else (better versed in the arcane js arts) can implement the improvements in z2m.

I've opened an issue with Zigbee-Herdsman-Converters, describing the top 9(!) problems with the current implementation:

Koenkk/zigbee-herdsman-converters#8697

I've tried to make it detailed and as clear as possible what I think needs to be done, but that one issue did end up being more gargantuan than I intended 😅

Regarding Entertainment groups, I've done a bit of initial research on it. They are not normal zigbee groups.

There are other manufacturer-specific clusters and commands, that seem completely unidentified so far. Roughly, the process works like this:

1. When sync is started, the bridge calls out (broadcast, if I remember correctly) for the entertainment group to be set up. It mentions the participating devices by some kind of ID. I'm not exactly sure what this ID is. It seems to be an u16 per light (so, a gradient light strip can have up to 7 data points in the group). This start message seems to be repeated 5-7 times, probably to maximize the likelihood that all participants receive it.

2. While sync is running, a vendor-specific message is sent as a ZLL Commissioning(!!) frame.

Unless I've misunderstood something, that seems a little crazy.. 😆

Best hypothesis so far: I think the idea is that Commissioning frames can be broadcast, without being retransmitted. So this allows the "director" node (either the bridge, or a proxy device) to send continuous updates, without overwhelming the mesh with retransmissions.

Because the sync messages carry a sequence number, it's easy to tell the order of messages, and they are never retransmitted. If a device misses one update, it'll just get the state in the next one.

3. When sync is stopped, similar protocols as the start step are used to shut down the stream. This seems to be a fairly simple "stop" message, repeated 5-7 times.

[chrivers]

For anyone interested in the current research, consider joining me on discord:

https://discord.gg/YvBKjHBJpA

It's for my Bifrost project. Bifrost is a Hue Bridge Emulator, using Zigbee2MQTT as a back-end.

[danieledwardgeorgehitchcock]

I will definitely check out your project as I took have been getting growingly frustrated with diyHue, it's limitations and performance and would love to contribute in both projects where I can..!