There’s always a more elegant way. However, if it’s working right for you, then lock it in. Whether it’s 5 lines or 2 lines it’s going to use about the same amount of CPU.
What like is you are breaking it out into its own template. I find that to be a best practice as it’s easy to observe and makes the resulting automations much simpler to make correct. You can then chain this into making a different decision if its sunny vs cloudy, etc.
I’d change the default from “unknown” to some time, so that even if the sun integration fails, something reasonable happens.
I should then alternatively ask how can I set today + a fixed time to provide a datetime stamp. The reason I want this is I’m having issues with the downstream automations when all I have is time.
The following provides me a time of 5:30, but how to get today + 5:30 so that the resulting output is ‘2023-02-09T05:30:00+10:00’
{% set sunrise_range_start = today_at('5:30').time() %}
If I understood your template correctly, it’s limiting the value to fall within a range. There’s a simple technique for doing that and it’s explained here:
If you’re unconvinced that the technique works, copy-paste the following version into the Template Editor and change the hours value to add/subtract time from sunrise to see how the template behaves.
{% set rise = (state_attr('sun.sun', 'next_rising') | as_datetime | as_local - timedelta(hours=2)).time() %}
{% set start = today_at('5:30').time() %}
{% set end = today_at('7:30').time() %}
{{ ([start, rise, end] | sort)[1].strftime("%H:%M:%S") }}