Download energy panel data to CSV

[karwosts]

Proposed change

Inspired by history panel download, I think that could be a useful feature for energy panel as well.

This just returns the statistics, it doesn't return any derivitive calculations (consumed solar, self sufficiency, etc), but those might be a nice addition in the future.

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:
• Link to documentation pull request:

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

[balloob]

I think that you've optimized for the wrong consumer. Your CSV is great to read by a human in Excel. However, it will be a pain to consume programmatically. Since we have the UI for humans, we should keep CVS focused on program consumption.

I suggest to follow the same format as the history panel (which will also be better for re-using code to parse the data). We can add an extra column to indicate where the source is used (grid_consumption, device_consumption etc)

[karwosts]

Hmm, I did like that this dumped out in such a way that it maintained the relationship between the different entities at the same timestamp, I thought that was a nice differentiation of energy vs what history provides. If we were just going to flatten it to a single list of datapoints and lose the visual time correllation across different types, do you think there much value added by having this feature here in energy panel, if it's just providing the same thing that the history panel already provides? I thought it was nice that it provide things in a different way for different usecases.

The uses I had somewhat in mind were:

• User asking for support on forums, asking why his energy panel doesn't look like expected, and having an easy way to share datasets (or for troubleshooting bugs)
• User wanting to analyze data in spreadsheet, possibly for different experiments (evaluating different battery strategies?)
• Comparing datasets across non-adjacent time periods (e.g. Feb '23 vs Feb '24)

Hadn't really considered any use cases involving machine reading the data.

Anyway that's just my thoughts about it.

[balloob]

It's not just machine learning. Analyzing any data would involve a machine reading the data.

If you want to make a generic Excel spreadsheet or a website that reads this data to do things with it, it now needs custom logic to learn how we group things.

[bramkragten]

I think we can keep the same data but move the "headers" (grid consumption, solar production, etc) to a column, so it will be readable by a computer.

Also add a header row to indicate what data the column has.

[karwosts]

I think we can keep the same data but move the "headers" (grid consumption, solar production, etc) to a column, so it will be readable by a computer.

Also add a header row to indicate what data the column has.

I would be happy with this as well, though this still sounds a bit different than what Paulus is looking for, would have to hear if he is happy with it.

[balloob]

This one is not that bad 👍

Question: how many columns do we have when we look at a year worth of data, 365?

Question 2: if we are comparing data, should we include that data too? (and then have 730 columns?)

[balloob]

btw why is the 2nd column empty ?

[karwosts]

Question: how many columns do we have when we look at a year worth of data, 365?

No, only 12 (it's monthly aggregated in that case). Energy panel does not allow user to choose data resolution, so any time range over 35 days shows monthly-aggregated statistics.

Question 2: if we are comparing data, should we include that data too? (and then have 730 columns?)

Possibly, I didn't choose to implement that yet, I'm not sure what would be the best way to organize that data for comparison.

btw why is the 2nd column empty ?

I don't see that, do you mean 2nd row? If so it's because the timestamp consumes 2 cells (one for start and one for end), so the header required two rows.

[balloob]

Sorry, I did mean row indeed.

We cannot make up CSV formats and repurpose the 2nd row. The first row is header, the rest should be data.

I would suggest we drop the 2nd row and keep only the start timestamp in the first row.

[karwosts]

Updated from feedback (removed end times, separate type column, removed translations). Two potential open questions:

1. Do we need to include compare data? It would not be that hard to just add more data columns, but I'm not sure if it's that useful either, as user can already just download more datasets at any time offset they desire and compare offline. That allows for comparing any time period, and not just the one immediately preceeding.

2. Should the "type" for cost sensors be different than the type for the actual consumption being monitored? Or is it ok they are the same type, and can be differentiated by the unit.

[balloob]

Yeah let's differentiate the type by adding _cost to the cost one. So gas_consumption and gas_consumption_cost

[balloob]

Agree on the compare data. Let's leave it out for now.

[karwosts]

Added types:

grid_consumption_cost
grid_return_compensation
gas_consumption_cost
water_consumption_cost

[balloob]