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.

Type of change

• [ ] Dependency upgrade
• [ ] Bugfix (non-breaking change which fixes an issue)
• [x] 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/
• Link to documentation pull request:

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

• [x] The code change is tested and works locally.
• [x] 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

[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)

[rrozema]

Come on guys, what's the hold-up here? This is a much requested feature. Plus, current implementation makes for a much cleaner header bar on the energy dashboard and uses the same date picker people are already used to in the history windows. @piitaya, please can you look at your 8 months old review again?

[bramkragten]

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

[rrozema]

@rrozema Seriously... 7 hours before your comment the change was made.. Not trying to offend anyone here, I do realize and appreciate the HUGE amount of work put into HA as a whole and the quality aspects in particular. My field of expertise is elsewhere and therefor I can't contribute much myself. I'm restricted to catching up to you guys, meanwhile trying to help other users where I can. I however just wanted to emphasize that from a user standpoint this functional upgrade was perfectly ready for use 8 months ago and wanted by the users. Even if some discussion was still possible on the UI, it was useable and a big improvement over what was available. I -for one- would have loved to have that previously implemented interface available to me already. Yet that code change has been on hold for 8 months, waiting for the volunteer who took the time to implement it once, to redo his efforts. Wouldn't it have been possible to include that previous version so that we have the functionality and then discuss and make the UI perfect according to standards?

[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?

[crackerjam]

@piitaya @bramkragten

Just want to add another "hey when can this get merged" from the user base. The feature request for this has 330 votes and this looks to be done. This would be an extremely valuable feature for anyone that wants to use HA to monitor their energy usage, which is probably most users.

[bramkragten]

We have discussed this and we feel the date picker is not really user friendly. We do want to offer it to more advanced users though, so we propose to add it as an option to overflow menu of this design: https://github.com/home-assistant/frontend/pull/14337#issuecomment-1598531869 as a custom period option.

[sjtrny]

We have discussed this and we feel the date picker is not really user friendly. We do want to offer it to more advanced users though, so we propose to add it as an option to overflow menu of this design: #14337 (comment) as a custom period option.

Bram, would it be possible to share what was discussed exactly? It seems that the community (myself included) doesn't see or understand problems with Till's design. So it would be helpful if you could share the design issues/problems with us beyond saying "not really user friendly".

Generally I would expect >99% of HA users to understand what a date picker is and how to use it - especially since they are used elsewhere in the HA web interface.

The proposed design #14337 (comment) also has the following drawbacks:

• it creates greater horizontal spacing between interaction elements and I would find it annoying to have to zig zag back and forth between different selectors on the top bar
• burying the option in the overflow menu is problematic because:
  • it adds additional steps and gets in the way
  • overflow menus are generally reserved for settings rather than filters and I think most users would find this location surprising

[bramkragten]

@matthiasdebaat maybe you can explain this one better

[Madelena]

Thanks for your contributions and @matthiasdebaat is off work for the next 2 weeks, so I will fill in the details of what we discussed here.

The current design was designed based on the assumption that the users of the Energy Dashboard consist of people who drills down into their energy data at various levels of details depending on their use cases:

• Understand the impact and cost (financial and environmental) of their energy usage. Conserve energy usage for sustainability and identify waste where they are reduce energy usage. They would click through the pre-selected range shortcuts of Day / Week / Month quickly to get an overview.
• Understand the efficiency and impact of their energy generation, and also the flow of energy throughout the day. This is for those who have solar panel and battery installation. The Now view is important because keeping track of their current power generation and battery usage helps inform their energy usage at the moment.
• Determine the trends of their energy generation and consumption over time by comparing historical data as well as environmental factors. In this case, the comparison tool helps analyze their usage depending on seasons, habits, occupancy, etc. Custom range would be quite helpful here.

And here are the recommendations on the design:

• Adding a custom date range as extra option makes our solution more versatile and up to par with most data visualization apps, so this is a good contribution.
• The ability to view by day, week, month and year is standard amongst most similar apps, so we should keep them easily discoverable and accessible without adding an extra click at least on a tablet or a desktop.
• Using the date picker from history keeps the design consistent, though we should update this date picker to Material 3. Google Analytics has an example of the picker in Material 3 with date range shortcuts:
• The mobile view currently cannot fit all the required features without overflowing into multiple rows, and it needs to be redesigned at some point. I would recommend a full-screen modal date picker here.

[lfdominguez]

Interesting to see how this has not merged yet?

[Mikescotland]

Still after a year this discussion is about graphic nuances while thousands of people waiting for any kind of date picker? Come on...

[bramkragten]

I would keep the date period label with the controls, and not have that much space between them. Also I would have the prev/next buttons next to eachother

[bramkragten]

2 more things, and then I think this can get merged:

• Can we add the "today" button back on wide screens, so you can go to current date immediately
• Can we use the short form for month when a single date is picked on mobile, as it now sometimes wraps.

[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?