Add elevation_at_time sensor

[BrodyBuster]

I currently use a template macro to calculate the elevation at a specific time … ie at 22:30 tonight the elevation will be -42.5 deg … so that I can equate time to elevation, and use that elevation data in a blueprint. It seems redundant to me to use a template macro, when the sun2 integration already could make that data available via an input time to the elevation calculation, then return the output elevation as a sensor value.

Something like sensor.elevation_at_time_2230

Is this something you could incorporate? Thank you for considering the request.

[BrodyBuster]

To add to the request, the input time would be in the format given by a time helper : 22:30:00 And not include date.

What this would give, is the elevation at a specific time, and it would adjust throughout the year. Meaning, at 22:30:00 in the winter time (for my location) it would return approx -43. As each day passes this value would increase until the equinox, then start decreasing and in the summer time it would return something like -20.

Your elevation calculations include the calendar day of the year, so each time the input number (time) and the calendar day number (day) change, this sensor would update.

[pnbruckner]

Yes, this would probably be relatively easy to add. Would a constant value be ok, or would it need to read a datetime sensor? The latter is a bit harder, but still doable.

[BrodyBuster]

Thanks for your prompt reply ... here is what I envisioned, and how I am currently doing this with the template macro. The macro input is the current time or some time I am interested in getting the elevation for. Depending on how I call the macro I can either get the current elevation, or the elevation at a specific time.

Get current elevation:
{# Get the elevation at time now() from the elevation macro #}
{% from 'elevation.jinja' import elevation %}
{{ elevation (now()) }}

or

{# Get the elevation at time specified by input.datetime from the elevation macro #}
{% from 'elevation.jinja' import elevation %}
{{ elevation (states('input_datetime.warm_glow_end_dimming')) }}

The input.datetime helper only contains time, not date, so it's value is hh:mm:ss

The macro does some time string manipulation since now() also includes the date and the date is not needed for the elevation calculations (uses calendar day of the year). The final time passed to the elevation calculations will then be decimal hours ie 22.5 for 22:30:00

{## get day of the year ##}
{% set day = now().strftime('%j') | int %}

{## convert convert time, if needed to hh:mm ##}
{% set time = input_time | string %}
{% set today_date = (now() | string)[:11] %}

{% if today_date in time %}
{% set current_time = time[11:19] %}
{% else %}
{% set current_time = time %}
{% endif %}

{## convert time to decimal time ##}
{% set time = today_date + current_time %}
{% set time_hr = ((as_timestamp(time) | timestamp_custom('%H:%M'))[:2]) | int %}
{% set time_min = ((as_timestamp(time) | timestamp_custom('%H:%M'))[-2:]) | int %}
{% if time_min != 0 %}
{% set time_min = time_min / 60 %}
{% endif %}
{% set decimal_time = time_hr + time_min %}

.... elevation calculation ....

{{ elevation }}

I would have to assume your python script is doing something similar. All that being said, ideally it would be great if the new sensor takes the input as either a given time (22:30:00 or 22:30) in the sensor declaration or as a states('input.helper'), so that it can be adjusted from lovelace or other automations, etc.

Something like this maybe:
sensor:

• platform: sun2
  monitored_conditions:
  -elevation_at_time: 22:30
  name: Elevation at 22:30

or

sensor:

• platform: sun2
  monitored_conditions:
  -elevation_at_time: "{{ states('input_datetime.warm_glow_end_dimming') }}"
  name: Elevation at 22:30

I apologize if I over explained this, and I appreciate your time looking into the request.

[pnbruckner]

The integration would not be evaluating a template. Rather, it would either take a time string, or the entity ID of an input_datetime helper. If the latter, then it would read its state directly, and then listen for changes to it so it can update the time from it. Either way, it would then calculate the elevation at that time for today. It would also update each day at midnight when a new day starts.

[BrodyBuster]

The integration would not be evaluating a template. Rather, it would either take a time string, or the entity ID of an input_datetime helper. If the latter, then it would read its state directly, and then listen for changes to it so it can update the time from it. Either way, it would then calculate the elevation at that time for today. It would also update each day at midnight when a new day starts.

Sounds like that would work. If I understood all that completely, then the difference is only the template evaluation of the helper vs reading it directly. Perfect!

[pnbruckner]

@BrodyBuster I have a preliminary implementation that so far supports time strings. The config would look like this:

sensor:
  - platform: sun2
    monitored_conditions:
      - elevation_at_time: '12:00'

I need to add support for an input_datetime entity ID, and I'm also going to add an optional name setting.

If you'd like to give it a try and know how to use a branch (see the PR), let me know how it works for you. If you don't know how to do that, then I could make a beta release.

[BrodyBuster]

@BrodyBuster I have a preliminary implementation that so far supports time strings. The config would look like this:

sensor:
  - platform: sun2
    monitored_conditions:
      - elevation_at_time: '12:00'

I need to add support for an input_datetime entity ID, and I'm also going to add an optional name setting.

If you'd like to give it a try and know how to use a branch (see the PR), let me know how it works for you. If you don't know how to do that, then I could make a beta release.

Works perfectly. I updated my integration with the PR, added the sensor and updated the time to 22:30 . Restarted. Sensor value is -44.529....... my calculated value was -44.38. Appreciate you turning this around so quickly. The input helper would definitely by an added bonus, since I do tend to adjust this value.

[pnbruckner]

I updated the branch to add the name option. E.g.:

sensor:
  - platform: sun2
    monitored_conditions:
      - elevation_at_time: '12:00'
        name: Elv @ noon

[pnbruckner]

@BrodyBuster I also added support for input_datetime entities. E.g.:

sensor:
  - platform: sun2
    monitored_conditions:
      - elevation_at_time: '12:00'
        name: Elv @ noon
      - elevation_at_time: input_datetime.test
        name: Elv @ test var

I still need to update the docs before I create a beta release. If you give it a try as is, let me know how it works for you.

[BrodyBuster]

Awesome. I will check this out ASAP. Currently out of town, but I will get to it in the next couple days. Thank you for adding this enhancement.

[pnbruckner]

Beta version 2.5.0b0 released.

[pnbruckner]

Beta version 2.5.0b1 released with improved input_datetime error handling.

Regarding using an input_datetime entity, I’m thinking of using the date if it has one. There could be a use case where the elevation at a certain time on a certain date is wanted, regardless of what the current date it. But I think it should always have a time. Thoughts?

[BrodyBuster]

I think it’s good to have the option, it would certainly allow for more use cases. As long as the input can be both an input time without a date or an input time with a date.

I only use time, because the input helper is set once, and applicable for every day that follows, not just one day.

Hope that made sense.

[pnbruckner]

Yep. Or, if you never change the input_datetime, you could always just configure the sun2 sensor with a fixed time string. Either way would work.

[pnbruckner]

Released 2.5.0b2 that uses an input_datetime entity's date if present.

[pnbruckner]

Released 2.5.0b3 that adds suggested display precision where appropriate.