refactor: Make entities either DIAGNOSTIC or CONFIGURATION

[cpw]

Summary

Changed the entities in this integration to be either EntityCategory.DIAGNOSTIC or EntityCategory.CONFIGURATION. This makes it a much friendlier integration with things like the mushroom dashboard generator - no longer do you get dozens of random switches and stuff for controlling your keymaster, just because you gave your lock an area, and then asked to generate a dashboard for said area.

Breaking change

It might break someone who expected to see keymaster entities in a dashboard and are using something like a smart filter, filtering out diagnostic and config entities. It does not break the generated keymaster dashboards or the keymaster dashboard strategy as far as I can tell.

Proposed change

Change all the entities of various types by assigning an EntityCategory of either DIAGNOSTIC or CONFIGURATION. No doubt people might argue with my particular choices here - I'm not super fussy, I just wanted all these useful entities to not pollute autogenerated dashboards anymore.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (which adds functionality)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: none that I can find

I used codex to help identify the exact spots to add the changes (I have spent months figuring this out as well, but heyho, it did it in 10 minutes), they are minimal in nature and the tests seem to pass. I am running this code in my local HASS instance and nothing has broken.

[tykeal]

Hi @cpw — thanks so much for opening this! Welcome to the project, this is a really nice contribution and the motivation is spot on. Dashboard auto-generators pulling in dozens of switches is a real pain point.

Two things from my side:

1. Push back on event.py → DIAGNOSTIC

Functionally nothing breaks (recorder still records, automations still trigger, logbook still receives entries), but EntityCategory.DIAGNOSTIC will demote event entities in the device page and exclude them from any auto-dashboard logic that filters diagnostics.

The reason I'd push back: HA event entities were introduced specifically as the first-class surface for "this thing happened" on devices like door locks — they're meant to be the user-visible artifact of an unlock-by-PIN. Hiding them by default arguably defeats their purpose. Power users typically want to see "Code Slot 3 unlocked the door" prominently in dashboards.

Would you be open to leaving KeymasterEvent with no category (i.e. revert just the event.py change), keeping it as a primary entity? Everything else in the PR looks well-categorized to me.

2. CI: prek failure

The Prek check failed because ruff check found and auto-fixed an import-ordering issue in tests/test_time.py (the new EntityCategory import was placed before homeassistant.core, breaking alphabetical order):

ruff check...............................................................Failed
- hook id: ruff-check
- exit code: 1
  Found 1 error (1 fixed, 0 remaining).

To fix locally and avoid this in the future, please install prek (preferred — much faster Rust-based runner, fully compatible with .pre-commit-config.yaml) or pre-commit if you'd rather stick to the original:

# Recommended: prek (faster, drop-in replacement)
pipx install prek
prek install
prek run --all-files

# Or: classic pre-commit
pipx install pre-commit
pre-commit install
pre-commit run --all-files

Then commit the auto-fix and push. The hook will catch the same issue automatically on future commits.

Again, thanks for the PR! Once those two items are addressed I'll happily approve.

[cpw]

Sure thing. I'll try and push again later today.