[Feature] Progress Bar - Add time_end key and display if present

[yyolk]

Adds the ability to include a time_end parameter to the page_data passed into a progress_bar(...) page.

I use progress_bar for displaying timers, I thought since there's so much space underneath the progress bar it would be nice to include a time_end which is really up to the caller to decide if it's an estimate or the exact time the progress bar will reach 100%

After feedback, the time_end parameter requires the user to render the expected time, which is also like the PV/Solar page. What is passed in is just a string.

---

Here's an example page_data for the service call that includes some context unrelated to these changes, mainly timer_name and progress are fetched from a call to another script before this service call.

page_type: progress_bar
header: "{{ timer_name }} Timer"
progress: "{{ progress.percent_complete }}"
footer: "{{ progress.remaining_text }}"
time_end: "{{ as_timestamp(state_attr(timer_entity, 'finishes_at'))|timestamp_custom('%H:%M') }}"
# this could also work
# time_end: "{{ as_local(as_datetime(state_attr(timer_entity, 'finishes_at'))).strftime('%H:%M') }}"
footer_offset: 15

[!NOTE] As an aside the script in use above does keep the timer page active by forcing a loop to stay open until the timer is cancelled or completed. That is to say it makes me interested in where #49 is going.

I opted for a "light grey" rgb(151, 151, 151) as the default time_end_color, but I don't really have a strong opinion. My thinking was it should look different than the time above and this was a quick way to achieve that, it is also customizable like the time_color is.

And here's how it looks (please excuse the bad photo, the light grey doesn't look this muted and I think is more legible):

As another example situation where I use the progress_bar page in my normal rotation of pages, set on the integration configuration is like during the work day which also are fed from a timer, but is a template helper (sensor) I've created off the work_day timer and could make use of the time_end parameter.

The sensor state as the value for time_end is a timestamp device class.

- page_type: progress_bar
  enabled: "{{ states.schedule.work_week.state }}"
  progress: "{{ states('sensor.work_day_8h_percent_complete') }}"
  footer: >-
    {% set finishes_at = state_attr('timer.work_day_8h', 'finishes_at') %} {{
    '00:00:00' if finishes_at == None else (as_datetime(finishes_at) -
    now()).total_seconds() | timestamp_custom('%H:%M:%S', false) }}
  footer_offset: "15"
  header: Work Day
  time_end: "{{ as_timestamp(states.sensor.work_ends.state)|timestamp_custom('%H:%M') }}"
  # this will also work:
  # time_end: "{{ as_local(as_datetime(states.sensor.work_ends.state)).strftime('%H:%M') }}"

Please let me know if I should change anything if this could be an acceptable feature.

This was my first time testing a custom integration on my only home assistant install - so please let me know if I missed anything!

[gickowtf]

i would be very happy if you would concentrate on the essentials when making changes and not replace ' with ". this way i have to check the entire code for changes because more lines have been changed accordingly. otherwise i will gladly adopt your idea :D

[yyolk]

i would be very happy if you would concentrate on the essentials when making changes and not replace ' with ". this way i have to check the entire code for changes because more lines have been changed accordingly. otherwise i will gladly adopt your idea :D

Sure, I've narrowed the formatting to one commit, but if its helpful I'll drop it entirely

[Mrredstone5230]

i would be very happy if you would concentrate on the essentials when making changes and not replace ' with ". this way i have to check the entire code for changes because more lines have been changed accordingly. otherwise i will gladly adopt your idea :D

Sure, I've narrowed the formatting to one commit, but if its helpful I'll drop it entirely

No no no, I think it's fiiiiine. I think it was needed anyways.

[yyolk]

i would be very happy if you would concentrate on the essentials when making changes and not replace ' with ". this way i have to check the entire code for changes because more lines have been changed accordingly. otherwise i will gladly adopt your idea :D

Sure, I've narrowed the formatting to one commit, but if its helpful I'll drop it entirely

No no no, I think it's fiiiiine. I think it was needed anyways.

haha ok, I already force-pushed an update - looks like theres more for me to change 😄

so if it's okay I'll run formatting on the file at the end of an approving review

[gickowtf]

no problem it's not urgent... give me a sign when you are ready. i test every time anyway and then write the readme directly... i don't think i do anything else anymore -.-

[yyolk]

no problem it's not urgent... give me a sign when you are ready. i test every time anyway and then write the readme directly... i don't think i do anything else anymore -.-

well if it's helpful, I started the README changes in b594d5dc3dfffd733293f4fc85a07e9dd96d6c48!