Add dashboard time visibility condition

[timmo001]

Breaking change

Proposed change

Also moved some reusable logic into common areas

Type of change

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

Example configuration

visibility:
  - condition: time
    after: "08:00"
    before: "17:00"
    weekdays:
      - mon
      - tue
      - wed
      - thu
      - fri

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue or discussion: old discussion thread: [feature request - Improvement] Additional visibility condition for dashboard elements #23755
• Link to documentation pull request: Add docs for dashboard time visibility condition home-assistant.io#41605

Checklist

• The code change is tested and works locally.
• There is no commented out code in this PR.
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

[karwosts]

I guess there's no callback/event here that would cause the card to appear right at 8am, but instead it relies on the next hass update after that time to trigger the re-check?

We had a similar issue with the state for: option that it isn't really accurate if time between hass updates is long, but maybe that's ok in this case.

[timmo001]

Not 100% sure what causes the updates but it appears to be pretty on time.

There might be some efficiencies on when the conditions are refreshed in general, they currently seem to update a lot

[karwosts]

There might be some efficiencies on when the conditions are refreshed in general, they currently seem to update a lot

It's going to be refreshed on a hass update so that will be dependent on whenever you have an entity state change in your system. For some people that might be many times a second, for some without many actively changing entities it could be quite a bit longer. Like if you're only using the system for a couple lights and door sensors it might only update the next time you flip a lightswitch, which could be an indefinite amount of time.

[timmo001]

We should add a timeout to update when we hit these triggers. This should be done via a mixin alongside other conditional listeners (media query etc.) to reuse later.

Starting with moving the current listeners. Created a task for this: #27810

[karwosts]

If you're designing a new mechanism maybe keep this one in mind, someone was trying to come up with a solution for a similar problem for for:, if it could be similarly reusable for that as well.

#26094

[timmo001]

There's a lot of refactoring in this branch unrelated to the actual change, I will move these into a new branch and rebase after

---

#27858