Allow not_set value for timestamp device class

[KapJI]

Proposed change

Currently sensor with device class timestamp only supports unavailable and unknown states apart from actual timestamp.
These states are quite special and usually used for error states. unavailable for example renders as a red sign in entity manager:

Some timestamp entities like alarms or timers may be not set and unknown state also doesn't represent that state correctly.

Right now not_set state will be rendered as Invalid timestamp, this PR addresses that.

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

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue or discussion:
• Link to documentation pull request:

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

[ludeeus]

"unknown" (or rather (None)) would be the correct state when it does not have a timestamp for this device class.
If it has a "random" string it's no longer a timestamp class.

Which integrations does that?

[KapJI]

The problem with "unknown" is that state is actually known, that confuses people. Other alternatives I thought about: "none" (as a string, should be rendered as "None", a bit confusing for developers) or "off".

For example there're android next alarm sensor which uses unavailable when there's no alarm:
https://companion.home-assistant.io/docs/core/sensors/#next-alarm-sensor

I think that's semantically incorrect because data is available and causes unexpected side effects as I described with entity manager.

[ludeeus]

For that example it should not be unavailable it should be None ("unknown"), the next alarm is not known so the state is not known.

[spacegaier]

There is currently nothing in the backend that would ever set "not_set" as a state. So it's not something that the frontend should react to.

[KapJI]

You're right there's nothing right now. I guess that's because frontend doesn't support it. I want to use this in custom integration and provide people meaningful UX with nicely formatted timestamp and not set value which is not Unknown because Unknown is confusing and doesn't mean what it should mean.

[balloob]

I agree that neither unknown or unavailable are correct. Changes for a device class should happen in the architecture issue though.

[KapJI]

Opened a discussion in the architecture repo: home-assistant/architecture#635

[github-actions]

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days.
Thank you for your contributions.