-
-
Notifications
You must be signed in to change notification settings - Fork 96
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
Feature Request: Improve generic DPT handling #1453
Comments
Hi 👋!
Yes, exactly. The transcoder lookup was initially implemented for HA sensor entity value types. So it should only return compatible (numeric or string) DPTs.
Line 177 in 92b80c2
Yes, see above. DPT subclasses without main/sub number were excluded from lookup. I have made an attempts previously to support multi-value DPTs. Unfortunately I never finished those. See #1276 and #1277 |
Part 1:
It seems that some DPT parsing is implemented in remote values (e.g. DPT 251.600). This makes these DPTs unavailable for generic transcoding via transcoder_by_dpt or transcode_by_value_type.
Is there any deeper reason, that those DPTs are not part of the standard DPT handling? Is it, because they consist out of multiple values (in the RGBW case)?
If yes, followup question: is there a possibility to restructure the code to generically (via DPT main and sub number) get transcoders for those DPTs as well?
Part 2:
Some DPT implementations (like DPTDate seem to lack dpt_main_number and dpt_sub_number definitions from what I see.
Is that on purpose, am I missing something or is it just not implemented yet?
I'm happy to provide PRs to improve the handling of this, once it's clear, how it should be done.
The text was updated successfully, but these errors were encountered: