search

tbnobody / OpenDTU

Software for ESP32 to talk to Hoymiles/TSUN/Solenso Inverters
GNU General Public License v2.0
1.81k stars 507 forks source link

[Request] Add a production curve #809

Open zebulon30 opened 1 year ago

zebulon30 commented 1 year ago

Is your feature request related to a problem? Please describe.

No response

Describe the solution you'd like

A curve of the day production would be great, with a cursor that can be set across the time that show the production at this time. Thanks

Describe alternatives you've considered

No response

Additional context

No response

CounterChip commented 1 year ago

I wouldnt like this, this could cause a lot of writes and wear on the rom, if it could be stored in the ram i would like it, but will get lost after a power cycle. Maybe iam wrong but i would like to have it reliable and maybe the ESP32 is the wrong place for the visualisation.

greg-man commented 1 year ago

I understand that storing daily production data would be kind of heavy play. But how about storing yield day data after inverter has shutdown for a period of e.g. a year? That would mean one write cycle a day and just about 2kb of memory.

CounterChip commented 1 year ago

@greg-man your idea sounds okayish to me, but this would be another request for an improvement. My personal opinion is that this isnt supposed to do such logging and the data storage belongs to some kind of database, where you can also store your other values as you like to do in small increments or just one value per day. Usually a project like this isnt stopping with just a ESP32 and involves some more devices over time, for example a power meter or something else.

zebulon30 commented 1 year ago

And what about storing the data on FireBase ?

Le 27/04/2023 à 21:49, CounterChip a écrit :

@greg-man https://github.com/greg-man your idea sounds okayish to me, but this would be another request for an improvement. My personal opinion is that this isnt supposed to do such logging and the data storage belongs to some kind of database, where you can also store your other values as you like to do in small increments or just one value per day. Usually a project like this isnt stopping with just a ESP32 and involves some more devices over time, for example a power meter or something else.

— Reply to this email directly, view it on GitHub https://github.com/tbnobody/OpenDTU/issues/809#issuecomment-1526293057, or unsubscribe https://github.com/notifications/unsubscribe-auth/AFFQR5PFTOISICVZGL46KD3XDLEU7ANCNFSM6AAAAAAXACAB4Q. You are receiving this because you authored the thread.Message ID: @.***>

greg-man commented 1 year ago

I would prefer a non cloud solution like rrd. If I remember right there is a rrdtool port to esp32.

And what about storing the data on FireBase ?

Kampfschildkroete commented 1 year ago

I don't think that is the purpose of OpenDTU. It provides the possibility to get access to the data from your inverter. The processing of the data like storing the data for specific time intervals, visualisation or anything else should be done by some kind of backend service (e.g. your house automation software).

greg-man commented 1 year ago

Well, its purpose is what you make it for...

I agree that intense data storage and analytics wont fit into a data transmission unit. But I know a lot of people who don't have much technical knowledge and for whom it is a big challenge to save the data on a regular basis. Most of them do it manually with an Excel spreadsheet. Therefore, I would find it useful to offer a rudimentary storage solution. Seeing the yield over the last 12 months would be enough for most of them; like me ;-)

Vujagig commented 1 year ago

Actually a consistent and also necessary further development. OpenDTU is supposed to be a better replacement for the original DTU, which offers this functionality with cloud support. It's precisely this statistic that people want, so they are forced to use a Shelly to get these stats. And only run a Raspi for a few graphics? (depending on the fact that it is not available). Most people just want to see what they've gotten in the different months throughout the year. The memory consumption is marginal. It also doesn't have to be saved to the exact hour in the long term. On the current day you can put it in the RAM at intervals x, the past week e.g. every hour and then weekly and long-term storage monthly, just like Home Assistant does, for example.

lifetime42 commented 8 months ago

I was look for the same feature and found this thread. I even have the skills to fetch the data by api and a short script, but I dont have a homeserver running i can set a cronjob up on. Also, I would be happy with putting the data in a spreadsheet. Automatic trailing thirteen month data of either daily, monthly or even just yearly data points (eg. ten years) would be awesome. Right now the only solution is to not forget on the 31 dec / 01 jan and have the the data of last year at hand already. Since we have the timestamps within already this should be fairly easy. No fancy chart needed imho, just the raw timeseries data is fine, we can continue on matplotlib, or excel, or jfreechart, or whatever ...

lifetime42 commented 8 months ago

This is a usecase brought up several times now with different directions:

https://github.com/tbnobody/OpenDTU/discussions/176 continous logging on sd card

https://github.com/tbnobody/OpenDTU/issues/1123 post data to external web server

https://github.com/tbnobody/OpenDTU/issues/1475 exporting raw data via csv

https://github.com/tbnobody/OpenDTU/issues/11 saving yieldtoday data (like mentioned here)

I dont claim this list complete but I think this shows there is a general interest in getting data over time out in SOME way.

stefan123t commented 3 months ago

@lifetime42 did you check the project / fork OpenDTU-Database ?

It uses the Flash-Filesystem on the ESP32 to store some of the values and displays them in a graph. We do not know for sure how long the ESP32 can sustain such writes to the flash. It may be better to attach an SD Card module and use that for storage.

@tbnobody this is IMHO a duplicate of #11.