feat: Extend support for custom zigbee frames with zcl_command
#8867
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
chrivers
added a commit
to chrivers/zigbee-herdsman
that referenced
this pull request
Feb 22, 2025
The Philips Hue ecosystem uses cluster 0xFC01 for "entertainment mode" packets. This is a manufacturer-specific extension, that allows high-frequency updates (tested up to 90 *per second*, but typically 10-50) for up to 10 lights. Unfortunately, `manuSpecificLegrandDevices` already "owns" 0xFC01, making it impossible to send the required commands to make this work, even with the necessary patch to enable full control in `zcl_command`: Koenkk/zigbee-herdsman-converters#8867 With this change, the `.cluster` field in `zcl_command` can be specified as `manuSpecificPhilips3`, and will be correctly identified by zigbee-herdsman. These changes (this PR and the one mentioned above) is sufficient to allow Entertainment Mode control over Zigbee2MQTT! The upcoming beta version of [Bifrost](https://github.com/chrivers/bifrost) will have rudimentary support for this.
chrivers
added a commit
to chrivers/zigbee-herdsman
that referenced
this pull request
Feb 22, 2025
The Philips Hue ecosystem uses cluster 0xFC01 for "entertainment mode" packets. This is a manufacturer-specific extension, that allows high-frequency updates (tested up to 90 *per second*, but typically 10-50) for up to 10 lights. Unfortunately, `manuSpecificLegrandDevices` already "owns" 0xFC01, making it impossible to send the required commands to make this work, even with the necessary patch to enable full control in `zcl_command`: Koenkk/zigbee-herdsman-converters#8867 With this change, the `.cluster` field in `zcl_command` can be specified as `manuSpecificPhilips3`, and will be correctly identified by zigbee-herdsman. These changes (this PR and the one mentioned above) is sufficient to allow Entertainment Mode control over Zigbee2MQTT! The upcoming beta version of [Bifrost](https://github.com/chrivers/bifrost) will have rudimentary support for this.
|
The motivation for this PR is to make it possible to run Hue Entertainment Mode over z2m. See also: Koenkk/zigbee-herdsman#1322 |
|
Oh, and if the new default for whether logging is enabled is too controversial, we can of course flip it back. But it's very important for my use case that it can be disabled. |
Koenkk
reviewed
Feb 22, 2025
|
You got it - one moment :) |
…oint. The existing implementation is almost a generic "send zigbee frame" function, but falls short. Notably, it: - Does not allow specifying a Zcl.FrameType value - Does not allow suppressing normal ACK reporting - Does not allow disabling log output in z2m When working on implementing support for complicated Zigbee devices (Philips Hue, for instance), these limitations hit hard. This reasonably simple change makes the `zcl_command` significantly more powerful.
chrivers
force-pushed
the
chrivers/zcl-raw-command
branch
from
6786e15 to
ed26385
Compare
|
Ready for another look - let me know if you'd like anything else fixed :) |
|
Thanks! |
chrivers
added a commit
to chrivers/zigbee-herdsman
that referenced
this pull request
Feb 22, 2025
The Philips Hue ecosystem uses cluster 0xFC01 for "entertainment mode" packets. This is a manufacturer-specific extension, that allows high-frequency updates (tested up to 90 *per second*, but typically 10-50) for up to 10 lights. Unfortunately, `manuSpecificLegrandDevices` already "owns" 0xFC01, making it impossible to send the required commands to make this work, even with the necessary patch to enable full control in `zcl_command`: Koenkk/zigbee-herdsman-converters#8867 With this change, the `.cluster` field in `zcl_command` can be specified as `manuSpecificPhilips3`, and will be correctly identified by zigbee-herdsman. These changes (this PR and the one mentioned above) is sufficient to allow Entertainment Mode control over Zigbee2MQTT! The upcoming beta version of [Bifrost](https://github.com/chrivers/bifrost) will have rudimentary support for this.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The existing implementation is almost a generic "send zigbee frame" function, but falls short.
Notably, it:
When working on implementing support for complicated Zigbee devices (Philips Hue, for instance), these limitations hit hard.
This reasonably simple change makes the
zcl_commandsignificantly more powerful, and should be fully backwards-compatible.The one possible exception is that the logging default is reversed. I'm testing devices that need to stream at a rate of 10-60 packets/sec, so being able to disable the log is actually a critical feature, surprisingly.