Add date range picker to energy period selector

[TillFleisch]

Proposed change

Replace/Add the date range picker from history/logbook to the energy dashboard. This enables custom date ranges on the energy dashboard.
Pre-defined range selection is still possible using the date range picker. The arrows still serve the same functionality as before.

Original proposal:

Current proposal:
See comment

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:
  • https://community.home-assistant.io/t/custom-date-range-for-energy-report/
  • https://community.home-assistant.io/t/date-range-selection-in-energy-monitoring/379482
  • https://community.home-assistant.io/t/wth-custom-date-range-energy-dashboard/470178
• Link to documentation pull request: Add date range picker to energy period selector home-assistant.io#26648

The date range picker always opens to the right and can thus potentially leave the window.
This behaviour should be changed before this PR get's approved. I did not want to mess with that part, but ideally the date picker would always open towards the middle of the window.

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

[piitaya]

Hello 🙂
I like the idea but I think there is some design adjustment/questions :

• As the period text length can change, the UI jumps in desktop because the buttons are displayed after the period text.
• There is a today button inside the picker that set the period to today and another today button outside the picker that set the period start to today. It's confusing.

Also, having text buttons, text, icon buttons is not perfect. I'm sure we can improve it

[TillFleisch]

The time handle is now to the right of the text, thus it does not jitter anymore.
This change makes the date range picker issue appear more often.

[TillFleisch]

There is a today button inside the picker that set the period to today and another today button outside the picker that set the period start to today. It's confusing.

I agree, but I could not think of an elegant naming convention for this problem.
In my opinion we should remove the today button entirely as it's functionality is mostly provided by the date range picker. This solution would definitely be less confusing.

[arosboro]

Is there any remaining task for this issue which I could assist with getting it over the finish line? @TillFleisch @piitaya Happy to provide critical feedback.

[arosboro]

There is a today button inside the picker that set the period to today and another today button outside the picker that set the period start to today. It's confusing.

I agree, but I could not think of an elegant naming convention for this problem. In my opinion we should remove the today button entirely as it's functionality is mostly provided by the date range picker. This solution would definitely be less confusing.

I agree with removing the former today button if the date picker allows a today selection and it seems redundant.

[TillFleisch]

One possible name for the "today" button could be "now" or "recently". This would help separate the today button and the today date picker functionality. I don't know if this terminology will translate well into other languages.

[arosboro]

I'm thinking about it more, and your addition to the widget supports ranges. Today is only a range of hours. Maybe we should leave that to the existing functionality, and refactor the date range widget to show the following:

• This week
• This month
• This quarter
• This year

This way the user could determine how granular they want it to be, and then use comparison to get this period to last period on the chart.

The capability to choose arbitrary start and stop dates is really popular with the community. It would be the critical missing piece for users to compare usage with billing periods and dates starting on a date determined by their utility provider. For instance my billing period can be anywhere from 30-34 days and starts whenever they decide to take a reading.

[TillFleisch]

Removing the "today" option from the date-range picker is likely a bad idea because it's an option in every other instance of the date range picker and will thus confuse users.

I presume the reason as to why we have the separate today button is that the previous implementation only allowed single day/time-interval changes.
Comparing this month to 6 month back is possible by either pressing the previous/next button multiple times or using the "today" functionality.

With the new functionality the old "today" button is not necessary as the user can select the current period directly by either using schortcuts (within the date-range picker) or selecting the period manually.
Therefore I suggest we remove the old "today" button and rely on the existing date-range picker functionality which users are familiar with.

[TillFleisch]

I rebased the changes onto the current dev branch, since the date-picker dependency has been upated.
I also removed the old today button.

[sjtrny]

Is there anything blocking this? Looking forward to having this integrated.

[8ctorres]

I think this PR just got lost because it's pretty old now and the devs probably don't even look that far back when reviewing. Is there a chance that you could open another one @TillFleisch?

[TillFleisch]

@piitaya, i have rebased this branch/PR on dev to keep up with related changes.
I've also noticed that the image above in the PR description is outdated. Here is an updated version.

Which further changes are necessary to close this PR?

[bramkragten]

We have an updated design for the top bar of the energy dashboard that we would like to implement, that does not include a date range picker at the moment. We can look at adding it though, the overflow menu might be a good place for that.

@matthiasdebaat

[TillFleisch]

I really like the idea of having the energy period selector in the top bar at all times.

Here is another Idea:
In my opinion, we should use a combination of the two approaches. The date-range-picker eliminates the need for the day/week/month buttons and the related 'today' button (see discussion above).

The title of the top-bar can show the selected date(s). The kebab-menu would contain the 'Compare with previous' option.
On mobile devices, the arrow/calendar icons can be packed closer together.
(please keep in mind that I'm no design expert. This is my opinion and I'm fine with a different solution)

[TillFleisch]

This PR now implements a combined "always in the-top-bar" approach.
The header source code is heavily inspired/copied from the Dashboard.

Desktop page:

Compare data in menu:

Small screens:


The next/prev buttons are smaller on narrow screens. Maybe someone else can find a more elegant solution than reducing size.

Energy date selection card (now wrapped in ha-card)

[bramkragten]

@rrozema Seriously... 7 hours before your comment the change was made...

[TillFleisch]

I played around with this design a little more on mobile and noticed that the narrow/small time handle is quite inconvenient:

The normal-sized time handle on the other hand felt 'familiar', which is to be expected.

My solution for narrow screens reduces the size of the arrow buttons. This does not feel like a 'legal' move.
Here are some solutions:

• reduce the width requirement for the narrow time-handle

  • reduce this value this.narrow = this.offsetWidth < 450; to 350 for instance

• revert 2225c90 and deal with multi-line dates (like this constructed example)

  • 

• reduce padding/margin between the arrows and the calendar icon (this will likely result in a similar issue)

Is there a 'smallest phone size' Home Assistant is targeting design-wise?

Does anyone have other suggestions, recommendations or opinions on this?

[TillFleisch]

I think the automatically applied cast label is incorrect.
@bramkragten Can you remove it?

[tvdsluijs]

It would be great to see this go live someday. Can I help?

[TillFleisch]

We could also show Quarters as Q3 2023 instead of Oct 1 – Dec 31. I have no clue how this works with internationalization though... Is this something you are familiar with?

[bramkragten]

We could also show Quarters as Q3 2023 instead of Oct 1 – Dec 31. I have no clue how this works with internationalization though... Is this something you are familiar with?

It is not supported by the default Intl.DateTimeFormat we use now, also, I don't think it is really needed for now? 🤷‍♂️
If we do want it in the future we would need to add a translation key for it, and handle it manually.

[Madelena]

We could also show Quarters as Q3 2023 instead of Oct 1 – Dec 31. I have no clue how this works with internationalization though... Is this something you are familiar with?

Quarters are often vague, and depending on the country - or even individual corporations - Q1 can mean anything from Jan 1 - Mar 31, or Feb 1 to Apr 30, or Jun 15 to Sep 15, etc.

old

[teodorch85]

I think something is wrong with the latest version 2024.2.2
(I don't know if the problem existed in previous versions too)

with Energy Period Selector Plus it works properly

[TillFleisch]

@teodorch85, please open a separate issue for this (if there isn't already one), so that we can keep track of this issue. I too can replicate this on a (core 2024.2.2/front 20240207.1) instance. The reported values don't change, once enough days have been selected so that "months" are shown in the bar charts. Adding a day in this scenario does not change the values when it should. Note that the low-carbon circle does change.