[Feature Request] Make keymaster functionality more modular

[raman325]

I was wondering if we could have an option in the configuration to disable autolock functionality such that the templates generated do not include them. Reason being, I already run my own autolock automations and they also incorporate checks of if my door is still open before enabling the re-lock. So I'd like the ability to keep using my own autolock with the Keymaster integration but without added bloat of additional unused entities created from the integration.

Originally posted by @emteedubs in https://github.com/FutureTense/keymaster/issues/141#issuecomment-876840853

This could include

• autolocking functionality
• scheduling
• perhaps any sort of conditional control at all, e.g. if a user simply wants to use keymaster to set user codes?

[firstof9]

Could break out the templates into additional files that get included/excluded on generation.

[FutureTense]

To do this, we would need some sort of templating system where the html/yaml stuff is included via variables etc. I don’t want to reinvent the wheel. Maybe there is something out there that can accomplish this?

[raman325]

that's exactly what jinja does ironically enough. Using jinja to generate jinja (e.g. template sensors) is 🤯

[rct]

KeyMaster has a lot of very nice functionality. Some modularity would help. I tried it for the first time and was overwhelmed by the number of entities that were created for just one of my locks. Of the 400+ entities that had my lock name in them, there were 389 input_* helpers with 10 code slots.

    196 boolean
    160 datetime
     10 number
     23 text

The bulk of those (at least 140 of the datetimes and a fair chuck of the booleans) seem to be related to scheduling which I don't need. I have two locks, so I'd wind up with hundreds of entities related to scheduling that I don't use. I realize reducing the number of code slots would help as it seems there are 41 entities per code slot.

automation.synchronize_codeslot_lockname_10
automation.turn_on_access_limit_lockname_10
input_boolean.accesslimit_lockname_10
input_boolean.daterange_lockname_10
input_boolean.enabled_lockname_10
input_boolean.fri_lockname_10
input_boolean.fri_inc_lockname_10
input_boolean.mon_lockname_10
input_boolean.mon_inc_lockname_10
input_boolean.notify_lockname_10
input_boolean.reset_codeslot_lockname_10
input_boolean.sat_lockname_10
input_boolean.sat_inc_lockname_10
input_boolean.sun_lockname_10
input_boolean.sun_inc_lockname_10
input_boolean.thu_lockname_10
input_boolean.thu_inc_lockname_10
input_boolean.tue_lockname_10
input_boolean.tue_inc_lockname_10
input_boolean.wed_lockname_10
input_boolean.wed_inc_lockname_10
input_datetime.end_date_lockname_10
input_datetime.fri_end_date_lockname_10
input_datetime.fri_start_date_lockname_10
input_datetime.mon_end_date_lockname_10
input_datetime.mon_start_date_lockname_10
input_datetime.sat_end_date_lockname_10
input_datetime.sat_start_date_lockname_10
input_datetime.start_date_lockname_10
input_datetime.sun_end_date_lockname_10
input_datetime.sun_start_date_lockname_10
input_datetime.thu_end_date_lockname_10
input_datetime.thu_start_date_lockname_10
input_datetime.tue_end_date_lockname_10
input_datetime.tue_start_date_lockname_10
input_datetime.wed_end_date_lockname_10
input_datetime.wed_start_date_lockname_10
input_number.accesscount_lockname_10
input_text.lockname_name_10
input_text.lockname_pin_10
sensor.lockname_code_slot_10

I came here to submit an enhancement request that all of the KeyMaster generated entities should be able to be identified as belonging to KeyMaster. Only 4 of the 389 input_* entities have keymaster in the id. Of the 41 entities for a code slot none of them have keymaster in the id.

I've moved the generated YAML out of the config directory, but most of the entities are still around. They show as unavailable and restored: true. Fortunately I tried KeyMaster on my test system. I haven't searched yet to find out if there is an easy way to delete all of those entities. Since it's a test system, it might be easier to start fresh.

I've saved all the generated YAML so that I can hopefully pull out some of the pieces I need. It looks like there is a lot that I can learn from reading through the generated files. I think KeyMaster has a lot of impressive functionality. You've certainly put a ton of work into it. I hope this doesn't sound too critical.

[firstof9]

I haven't searched yet to find out if there is an easy way to delete all of those entities.

When removing the integration it should clean up the input helpers that get generated.

[rct]

I haven't searched yet to find out if there is an easy way to delete all of those entities.

When removing the integration it should clean up the input helpers that get generated.

Maybe I'm doing something wrong? YAML has been removed. Integration disabled, then deleted. They all show as unavailable and restored.

If you have an autogenerated lovelace dashboard, they still show up there as well:

[firstof9]

I think the act of disabling it may cause the issue with it not removing the created helpers.

[rct]

I think the act of disabling it may cause the issue with it not removing the created helpers.

Possibly. Though the integrations card only showed 11 entities associated with the integration. It doesn't show the input_* helpers as belonging to the integration.

[firstof9]

That's because we add them internally. They are not in a template.