-
8000
-
Notifications
You must be signed in to change notification settings - Fork 13
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
Conversation
This file contains hidden or 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
a801e76
to
82cea65
Compare
…e old inlined solution
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.
…OWED http status
82cea65
to
c83ee36
Compare
Sign up for free
to jo
5563
in 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.
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.