[Feature Request] Hide helpers/automations

[gazpachoking]

Is your feature request related to a problem? Please describe. The keymaster helpers and automations crowd out all my manually created ones.

Describe the solution you'd like Automatically set all of the keymaster controlled automations and helpers to be hidden.

Describe alternatives you've considered Manually hide all of them?

Additional context

[Menz01]

noob question..... i noticed this as well and would like to clean it up.... if they are "hidden" they still work when needed correct?

[firstof9]

Yes they'll still work if hidden.

[Nick2253]

I don't think "Hidden" here works the way you think it does. It's for autogenerated dashboards:

Hide is really just for the UI. And specifically only for the autogenerated UI that you get when you first make a dashboard. Hidden entities won’t show up in autogenerated dashboards. But unlike disabled they do still show up everywhere else, their state is still being tracked and recorded and you can still use them in automations, scripts and anywhere else in HA like normal.

My understanding is that there currently exists no mechanism to hide entities/automations/helpers from the "Settings" UI.

[gazpachoking]

Ahh. I see you are right. I was thinking about the entity list in settings where there are filter options to not show hidden entities. It would be nice if it was the same for automations and helpers, but that change would have to go in to ha core before it would be useful.

[bobzer]

I guess many helpers could be delete by using the schedule sensor, which would be very nice https://www.home-assistant.io/integrations/schedule/

[petervk]

I would love it if these were hidden by default. I like this integration but it creates a LOT of entities that really don't need to be shown.

[bbf]

Please add the proper hidden tags to the internal helpers used by keymaster.

A family member accidentally clicked on the master toggle switch for the "Helpers" section of the auto generated lovelace and it completely destroyed my keymaster config. Imagine changing all internal booleans to false and then true. Some usercodes went to deleting state and I've spent the last hour trying to do black magic for them to work. Removing the integration doesn't fix the problem because apparently a lot entities are left behind and now I'm having to remove them by hand in hopes that when I re-install this will work.

[raman325]

All, this comes up repeatedly, and it's a known problem with the keymaster approach but it's also the only way to make something like keymaster work. I'd eventually like to make a more flexible version of keymaster but it requires changes in core. I have PRs up to make those required changes but they're going to take some time to get integrated there and then we have to basically rewrite a lot of the code here, so this is not as simple as it sounds.

Please add the proper hidden tags to the internal helpers used by keymaster.

support needs to be added to add the hidden tag via YAML and we will gladly add it in. If I am missing something and you can point me to the documentation for how to do it, let us know

I guess many helpers could be delete by using the schedule sensor, which would be very nice https://www.home-assistant.io/integrations/schedule/

not possible. It would be nice if it worked that way but I don't believe the YAML version of this helper supports the things we need.

[raman325]

also would like to plug - we welcome new contributes to help us make the necessary improvements if we are missing something

[solidslush]

I know this is a pretty old topic -- Since the new scheduling method won't work (not sure why, didn't investigate beyond @raman325 saying "nope") . I've got a work around going on a fork. Essentially renaming all the friendly names to zz-Keymaster. Involved changing all the dashboards to override the entity friendly name, but at least all the helpers and automations are sorted to the bottom of the list.

[solidslush]

For anyone else thinking of renaming stuff by forking and renaming prior to autogenerated stuff -- I did this, and I am reverting back to the original code for all the entities since I've learned of the customize: option for configuration.yaml. This way the code will stay closer to original with the only changes being to the dashboards to include shorter dashboard friendly names vs sorted friendly names.

[genebean]

For anyone else thinking of renaming stuff by forking and renaming prior to autogenerated stuff -- I did this, and I am reverting back to the original code for all the entities since I've learned of the customize: option for configuration.yaml. This way the code will stay closer to original with the only changes being to the dashboards to include shorter dashboard friendly names vs sorted friendly names.

@solidslush - can you elaborate on what you found and what you are doing now?

[solidslush]

@genebean - some of the scripts wouldn't work when adding the prefix "zz.Keymaster-". Specifically the autolocking. On a different research tangent I came across the customize option and that's probably a better method; though I haven't implemented anything yet. For instances the checkbolt stuff didn't like my modifications.

My lock batteries are dead and I haven't been bothered to unscrew the 2 stupid tiny screws holding the beauty plate on to replace them; so I'm in manual mode for the time being.

A sample:

customize:

Friendly Names for Keymaster

lock.boltchecked_entryway:
  friendly_name: zz-Keymaster boltchecked_entryway 

Since changing the Friendly Name I'll still have to have the modified Lovelace Dashboard Generation files in my fork, but hopefully that's it? I'd rather stay as close to the original repo as possible. Maybe I'll shuffle some of my priorities to flush this idea out further, especially if others find it useful.

[Nick2253]

@raman325 As I've been thinking about this more, can you expand on the reason that keymaster is using so many helpers?

As I think about other integrations, either the configuration data is saved as part of the integration configuration, or the data is saved in one (or a few) entities. And for complex configuration management from the UI, a custom card is also pretty common, which specifically interacts with those attributes stored in the entities.

Have you looked at one of those routes? Or would something like that mean a complete redo?

[raman325]

can you expand on the reason that keymaster is using so many helpers?

The TLDR is that that's the way it was originally implemented.

Have you looked at one of those routes? Or would something like that mean a complete redo?

Some of this has only recently become possible, and even then, doing this in keymaster would require a complete rewrite.

So instead of breaking keymaster for existing users, I have been working on a new integration that eliminates the automations and input helpers approach in favor of moving everything to code. The integration is not quite ready for primetime yet as I still have to test all of the functionality, but if you want to take a look, it's here: https://github.com/raman325/lock_code_manager

[Omnipius]

As a work around for now, would it be possible to have keymaster add Unique IDs to all of the objects it creates? That would at least enable bulk categorization and hiding via the new filtering options in HA. A quick glance at the code suggests adding a UUID generator wouldn't be huge lift.

[genebean]

As a work around for now, would it be possible to have keymaster add Unique IDs to all of the objects it creates? That would at least enable bulk categorization and hiding via the new filtering options in HA. A quick glance at the code suggests adding a UUID generator wouldn't be huge lift.

This would be really nice to have.

[Omnipius]

So, it turns out bulk hiding of helpers from the entities tab already works as is.

1. Settings>Devices & Services>Entities
2. Search for your lock name as it shows up in Keymaster
3. Expand the Filters Panel.
4. Expand Integrations
5. Search within Integrations for "Input"
6. Select all of input helper integrations
7. Enter selection mode (button left of the main search box)
8. Click the checkbox in the header to select all
9. Expand the 3-dot menu in the top right
10. Click hide selected

You can also create a Keymaster category or label so you can group or filter these out in other list menus.

However, this doesn't work for template sensors that aren't assigned a unique_id in the generated yaml template, namely: "Desired PIN State", "PIN synchronized with lock", and "PIN Status". Without that, the UI can't mark them hidden. We can fix this in 8 lines of code.

The first six are to add unique_id: "UUID" to each sensor and binary_sensor in keymaster.yaml and keymaster_child.yaml.

The two lines of python code added to helpers.py:

1. In the header: import uuid
2. In 'output_to_file_from_template' just before outfile.write(line): line = line.replace("UUID",str(uuid.4()))

The perhaps slight annoyance here would be that the UUID will change every time the template is regenerated, breaking the reference to the UI database and settings, both making it visible again and potentially leaving garbage in the HA database.

A more stable approach would be to generate a file with a list of UUIDs. The above str(uuid.4()) call would be replaced with a function to pull from that list sequentially, incrementing with each call (using a global or a class variable). If it's the end of the list, then you call str(uuid.4()), append that to the end of the file for use next time, and return the new UUID. This will mean the same entities get the same UUID each time the yaml is regenerated, maintaining the link to their UI properties.

[genebean]

@Omnipius - any chance you understand the needs enough to make a pull request to upstream the uuid bits so we can all get it by default?

[Omnipius]

@genebean - I believe I do. I've got the python and HA chops for it (small potatoes compared to my day job). However, it would be my first time contributing to an open source project or modifying a custom integration in HA.

Is there a guide on how to create a branch and put keymaster in my HA instance on that branch to test?

[genebean]

Awesome @Omnipius! I am not sure about a guide, but keymaster is stored in custom_components/keymaster so you could rename that folder and then upload your copy there and restart HA. The "Terminal & SSH" addon has git in it so you could clone and pull via that fairly painlessly. You could also use the Samba addon to transfer files from your computer to HA. Hope that helps!

[Omnipius]

I have a fix tested and working on my instance. I'll get it set up as a PR tomorrow.

I actually ended up abandoning the UUID approach. Though using a UUID as uniqueid in HA is best practices, everything in keymaster assumes that entity ID is unique. Since HA will actually append an "#" to an entity ID with a different unique_ID than the one it already has, the UUID approach leads to a lot of edge cases that break keymaster (even with the UUID list file).

Instead, I opted to lean in and enforce keymaster's assumption that entity ID is unique and just made unique_id the same as entity ID. This also has the benefit of being 6 lines of YAML (8 if you fix boltchecked_LOCKNAME while you're at it) with no changes to python.

With the change, you just have to reconfigure your keymaster integration, let it rebuild the package files, go into the entities list, search for your lock name, select all, and hide them. That is, assuming your lock name in keymaster is unique in your HA instance. If it's not, you'll have to come up with some other filtering to only get keymaster entities. A long term fix there would be to change the YAML templates to prefix all keymaster entities with "keymaster_", but that could be breaking for some installs and a lot of work.

[genebean]

That's awesome! Thanks for digging into this!

[Omnipius]

Merged and included in release 0.0.94. I believe this is as much as can be reasonably done against this issue for now. If HA ever enables programmatic control over default UI visibility, this could be revisited. However, this is unlikely.

There is Frenck's Spook custom integration that does add a service to control hide/unhide on entities. However, I imagine that the maintainers here would prefer not to include another large and wide ranging custom integration as a dependency.

I would recommend documenting in the wiki how to use the new filtering options and/or Spook to hide keymaster entities and then closing this issue as resolved.