Use none as sensor state when no alarm or timer is set

[EuleMitKeule]

This PR introduces a small change to the alarm and timer sensor entities. When no alarm or timer is set, the entity returns its state as None instead of "unavailable". This will display a localized string "Unknown" in the UI instead of marking the entity as unavailable. This still does not reflect the actual state, since it is indeed known that no alarms or timers are set, but should be a temporary improvement over having the entity marked as unavailable which usually indicates to the user that there is some kind of problem, which is not the case here.

Closes #278

[EuleMitKeule]

Something went wrong in the CI while installing dependencies I think.

[KapJI]

1. This will break existing automations.
2. Most likely this will break UI as well.

Please follow discussion in home-assistant/architecture#635

[KapJI]

I don't think we should change it right now without changes in HA Core.

[EuleMitKeule]

This will break existing automations.

True, but I would argue that the current behaviour is a bug, since an entity being unavailable indicates to the user that there is some kind of problem, which there is not. So in my opinion the change is necessary even though it will be a breaking change.

Most likely this will break UI as well.

It does not. As I stated the state will be displayed as "Unknown" without any errors. This is the intended way to handle such a case with a timestamp sensor.

I don't think we should change it right now without changes in HA Core.

The HASS dev docs state that timestamp sensors should either return a datetime object or None. I think as long as this is the intended behaviour for timestamp sensors this integration should adhere to this convention and provide a better user experience by not indicating configuration or connection problems when there aren't any.

[EuleMitKeule]

@KapJI @leikoilja I guess your take on this hasn't changed and this can be closed? I still think the current behaviour is wrong and not working the way home assistant intended.

I would appreciate a reply on my comments though.

[leikoilja]

@KapJI @leikoilja I guess your take on this hasn't changed and this can be closed? I still think the current behaviour is wrong and not working the way home assistant intended.

I would appreciate a reply on my comments though.

thanks for the ping @EuleMitKeule. I have nothing against this change and agree that sensor returning None as a default value is more user-intuitive then unavailable.
@KapJI, do you have a strong opinion on this one?

[KapJI]

I don't like "Unknown" state because it's misleading as we know the state of alarms. I agree that "Unavailable" isn't much better but I don't think we should introduce a breaking change when alternative isn't significantly better.

Proper solution could be pushing discussing in home-assistant/architecture#635 to introduce new "unset" state or something with similar meaning. If you are willing to contribute there, that will be a welcome improvement.

[EuleMitKeule]

I don't think the architecture repo is still being used really, so we should probably just open a PR against the core repo that introduces the new state.