8000 Chrivers/z2m refactoring by chrivers · Pull Request #115 · chrivers/bifrost · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Chrivers/z2m refactoring #115

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 14 commits into from
May 2, 2025
Merged

Chrivers/z2m refactoring #115

merged 14 commits into from
May 2, 2025

Conversation

chrivers
Copy link
Owner
@chrivers chrivers commented Apr 21, 2025

This change cleans up a bunch of internal code related to the z2m backend, and
makes two important user-facing improvement:

Status updates

Previously, as part of supporting hue effects (candle, fireplace, etc), we would
encode all light update requests to hue lights as the hue-specific
HueZigbeeUpdate data format.

This is the data format a Hue Bridge (mostly) uses to control lights, and is a
quick and effective way to update all light settings at once, even the
vendor-specific extensions.

However, Zigbee2MQTT does not know how to report state updates when this update
method is used. It just sees a "raw" message, and passes it along.

So until we land better support in Zigbee2MQTT for dealing with these kinds of
state updates, split light updates into two parts: one for regular light
properties (on/off, brightness, etc), and one optional part for hue-specific
effects.

The hue-specific update is then only sent if needed and supported.

This makes z2m able to report changes to common properties again, but has the
slight downside of sending two messages, if hue-specific extensions are used.

Hopefully over time this can be simplified, but for now this is an improvement
over the previous situation.

Z-Stack entertainment mode fix

Previously, "z-stack" based adaptors did not work with entertainment mode,
because of the way the highly specialized Zigbee frames are constructed.

This update changes how entertainment mode frames are constructed, allowing
adapters in the Z-Stack family to join the fun.

@chrivers chrivers force-pushed the chrivers/z2m-refactoring branch 2 times, most recently from a801e76 to 82cea65 Compare April 24, 2025 22:31
chrivers added 14 commits April 29, 2025 23:40
Setting the source endpoint in this way causes problems with non-ember z2m
adapters, most notably ZStack devices.

This property was a leftover from the reverse engineering, and it turns out
setting it is not required, so let's get rid of it.
…igbeeUpdate from a LightUpdate. Used only for effects
Previously, as part of supporting hue effects (candle, fireplace, etc), we would
encode all light update requests to hue lights as the hue-specific
`HueZigbeeUpdate` data format.

This is the data format a Hue Bridge (mostly) uses to control lights, and is a
quick and effective way to update all light settings at once, even the
vendor-specific extensions.

However, Zigbee2MQTT does not know how to report state updates when this update
method is used. It just sees a "raw" message, and passes it along.

So until we land better support in Zigbee2MQTT for dealing with these kinds of
state updates, split light updates into two parts: one for regular light
properties (on/off, brightness, etc), and one optional part for hue-specific
effects.

The hue-specific update is then only sent if needed and supported.

This makes z2m able to report changes to common properties again, but has the
slight downside of sending two messages, if hue-specific extensions are used.

Hopefully over time this can be simplified, but for now this is an improvement
over the previous situation.
@chrivers chrivers force-pushed the chrivers/z2m-refactoring branch from 82cea65 to c83ee36 Compare May 2, 2025 11:14
@chrivers chrivers merged commit f3e76d1 into master May 2, 2025
1 check passed
@chrivers chrivers deleted the chrivers/z2m-refactoring branch May 2, 2025 11:20
Sign up for free to jo 5563 in this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant
0