add power production charts

[maxfreu]

Moin!

WARNING: This has been coded by Claude Sonnet 3.7. I just told it that I want nice charts, because I don't have a smart home. This is what I got:

Seems to work quite nicely. I think it screwed up some js configuration files on the go, but I have no clue about web programming.

I think this would make more sense together with an SD card, but so far it works for me. I wonder how long it takes until the memory is full. Certainly this needs more testing; volunteers welcome :)

[schlimmchen]

Hm... Interesting.

• Yeah, there is definitly cleanup and manual curation to perform on this changeset.
• I think this feature needs an opt-in, i.e., as switch to enable it.
• The feature is of very limited use without persistence. Persistence can be achieved through the littleFS, i.e., the flash. Writing hourly and before a restart makes sense, I guess.
• The smallest resolution is questionable. Also the amount of past data has to have a defined limit, so we know exactly how large the serialized data (probably JSON) will get and how much heap it takes up at most when processing it. A respective cleanup task is needed. Like: keep 12 monthly datasets, keep 28 daily datasets, and one week worth of hourly datasets -- something like that.

I guess in the downstream project OpenDTU-OnBattery, this quickly blows up in our face when trying to also track solar charge controller data and battery data.

[AndreasBoehm]

There is a fork that includes charts: https://github.com/RaBa64/OpenDTU-Database

[maxfreu]

There is a fork that includes charts: https://github.com/RaBa64/OpenDTU-Database

Oh nice, I didn't know that. With the fork in place it's highly questionable whether it makes sense to include these changes here. Probably not, as the fork also already implements persistent storage. Feel free to close.

[stefan123t]

@maxfreu I had a short peek at your PR. I am positively impressed by the readability of the code.

The API endpoint does only start with /charts this may need to be adapted to /api/history/data or something matching the other API endpoints structure.

This is using four separate classes for 20Min, Hourly, Daily, Monthly Aggregates.
It may make sense to ask Claude to implement the code using a template class, that way we can have one common implementation instead of four.
Also I would prefer 5/15Min, Hourly, Daily and Monthly Aggregates.
That way you could even have a very detailed graph of the last Hour.

I think if we could keep the data in memory in those four ring buffers (!) for a day and only persist the higher two (Daily, Monthly) once a day.
Then it should actually fit on the LittleFS without wearing the Flash EEPROM out or requiring additional SD Card support, IMHO.

I also noticed in your joint implementation with Claude, that it uses the OpenSource chart.js instead of vue-google-charts in RaBa64's implementation.
I recall that there was some concern regarding the use of somewhat proprietary Google (?) Charts in the past.
Though I do not recall if I mix this up with another charting implementation in AhoyDTU or whether these concerns are still necessary / valid.

[stefan123t]

See also PRs #935 and #2125

[maxfreu]

Hi! Thanks for taking a look! Unfortunately I currently have issues connecting to my inverter and don't have the time to advance things here. Your suggestions sound reasonable. Does it make sense to wait for the two PRs you mentioned to be merged?