Skip to content
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

Closed
skadisch opened this issue Apr 30, 2024 · 1 comment · Fixed by #1277
Closed

Feature Request: Improve generic DPT handling #1453

skadisch opened this issue Apr 30, 2024 · 1 comment · Fixed by #1277
Labels
💡 feature request Feature request

Comments

@skadisch
Copy link

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.

@farmio
Copy link
Member

farmio commented Apr 30, 2024

Hi 👋!

Is it, because they consist out of multiple values (in the RGBW case)?

Yes, exactly. The transcoder lookup was initially implemented for HA sensor entity value types. So it should only return compatible (numeric or string) DPTs.

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?

DPTNumeric was implemented at a later point - this could solve at least a part of this issue

class DPTNumeric(DPTBase):

Some DPT implementations lack dpt_main_number and dpt_sub_number definitions (...) Is that on purpose

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
The idea was to have a properly typed data structures (for internal use eg. for HA integration) that are also easily json compatible (for HA automations, frontend websockets etc.) and of course adhere KNX Specifications and are easy to use (default values etc.)
If you want to take one of these up, be my guest. Feel free to contact me on Discord or here if you want to chat about it or have any questions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
💡 feature request Feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants