-
Notifications
You must be signed in to change notification settings - Fork 3.2k
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
Exposing action_brightness_delta to allow better blueprints #8369
base: master
Are you sure you want to change the base?
Conversation
This enables the home assistant community to access the action_brightness_delta value inside blueprints and therefore have a much more pleasing dimming experience than before.
This expose should not always be present, since it is only there when the |
@Koenkk thats a great Idea! Wasn't really sure how the exposing works, but I'm digging deaper. Is there maybe a dev docs? I already have an additional feature for this and potentially more sensors in mind. But I'm very pleased that I can overwrite pretty much everything with a custom converter, makes developing/testing a breeze :) Tomorrow or in a few days I'll add it when I figured everything out and put it in the right place |
Hi @Koenkk, I've updated my PR with a new feature implementation called Additionally, I'd appreciate some guidance on implementing the exposure in Could you please provide some direction on this? Thanks! |
src/converters/fromZigbee.ts
Outdated
@@ -1424,6 +1425,22 @@ const converters1 = { | |||
payload.action_transition_time = msg.data.transtime / 100; | |||
} | |||
|
|||
if (options.simulated_color_temperature) { | |||
const deltaOpts = options.simulated_color_temperature_delta ?? 500; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume the delta is in Kelvin, I propose to use mireds here as that is what the ZCL uses.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did change it to midred
src/converters/fromZigbee.ts
Outdated
const deltaOpts = options.simulated_color_temperature_delta ?? 500; | ||
|
||
if (globalStore.getValue(msg.endpoint, 'simulated_color_temperature') === undefined) { | ||
let color_temperature = globalStore.getValue(msg.endpoint, 'simulated_color_temperature_temperature', 2000); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
let color_temperature = globalStore.getValue(msg.endpoint, 'simulated_color_temperature_temperature', 2000); | |
let colorTemperature = globalStore.getValue(msg.endpoint, 'simulated_color_temperature_temperature', 2000); |
Can you clarify it a bit more? Then I can help. |
…toring Now no hardcoded min/max values and using midred instead of kelvin
You suggested instead of exposing the additional information Also wouldn't hardcoding it be a bad pattern? A more straight forward principle might be better for future solutions, doesn't it? Maybe we could define base exposes but overwrite them at device level? That way an user has control to expose any mqtt data that it needs. What do you think about this solution? Also whats a bit ugly is that in the options descriptions often says like |
An alternative would be to dynamically add it to exposes, you cannot always add it there since not everyone is using this option. Then it can be added here: zigbee-herdsman-converters/src/index.ts Line 316 in b7877b7
(which would mean |
7a687b2
to
cd3fde0
Compare
Hi! I've now pushed my proposal of the additional options properties being spread into the exposes. What do you think? I'm a bit confused that the classes have multiple use cases (option definition and exposes) |
Also, how could I test my changes with in home assistant? Or do I have to setup zigbee2mqtt within docker myself? |
See https://github.com/zigbee2mqtt/hassio-zigbee2mqtt/blob/master/CONTRIBUTING.md#developing-against-the-home-assistant-container on how to make local changes. |
Hi! I've finally had time to implement it and test it. What do you think? |
@@ -376,6 +384,48 @@ function prepareDefinition(definition: DefinitionWithExtend): Definition { | |||
} | |||
} | |||
|
|||
//if options are defined, add them to the exposes |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This can be done much easier, see 3d98d3f#diff-47eee2b61258a9d48e4b9104d706a4aeacec2e1baba7d21f34db7d2963357d28R679 as an example
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Am I correct, that you're implying that it better should be done by the modernExtendRefactor script, to migrate all definitions to extend a simulated_light base? That sounds to be a great approach, but I'm a bit unsure if it could handle the edge cases like the D1 universal dimmer, that's an example of why this got this complicated, because it acts as a dimmer, but also as a light entity.
Is this what you're intending to push forward, or am I on the wrong track? If not I'll read into the code base and check how to integrate it
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, I meant the changes of src/lib/modernExtend.ts
This enables home assistant users to have a better dimming experience using automations like, therefore zha is not needed anymore for smooth dimming experience.
[https://github.com/TheUnlimited64/tuya_smart_knob_blueprint](url)
Only issue currently (atleast with mine) is that there seems to be a cooldown after ~2s. If I dimm long enough it stops receiving. But I'm not sure how to mitigate it.