Non implemented DPT / Function work-around

[TocsinChti]

Hello again,

I have in my import a lot of element that are skipped (adress type not supported / function type not implemented). While I definitly understand for many of them, the association guess would be very challenging, there might be a half-way process to help-us speed up our entity import into HomeAssistant.

Instead of skipping all non supported DPT, would it be possible to generate at the end of the Yaml file, a grouped list all non supported items, maybe with "#" in beginning to deactivate and permit user to manually associate type/details.
This would allow user to manually go into the error list, check what has not been imported and the manually type it into its yaml file. It would be kind of to-do list of datas to be checked. Hope this makes sense ?

[laurent-martin]

Hi,
I have added the method add_comment to the genrator, so if you want, you can add comments for unsupported objects in "specific code".
Else, I have added a minimal option --comment-skipped which captures some of the skipped data into comments.
(not yet released in gem, you would need to clone the repo to test that for the moment)

[Superwallah]

I am also looking forward to have a way where ETS can be the single source of information for the import - instead of maintaining a separate script/specific code.
Would it be an option to use the "custom" function of ETS in combination with parsing the "name" (or "description" or "comment"?) for one of the defined KNX device types defined in home assistant ("binary sensor", "climate", "fan", "weather")?
Thereby, the manual mapping could be done in ETS, not in an addition script.

In a second step, the name of the group address (mapped to a "custom" function) could be parsed to the pre-defined "configuration variables", as defined on https://www.home-assistant.io/integrations/knx

The manual mapping task of the ETS project owner would still be there, but it would all be conserved in the ETS project.