search

Olen / solar-monitor

GNU General Public License v3.0
54 stars 21 forks source link

Renogy Rover History, generation and min max support #17

Closed Anto79-ops closed 1 month ago

Anto79-ops commented 2 years ago

Hi.

The for the Renogy Rover CC, it would be great if the script can also report history, daily generation (kWh), and min and max values

thanks

Olen commented 2 years ago

That would mean that the script need to either cache the data locally and do different calculations or you need to find the correct IDs to poll to fetch the history direcly from the device if if is available.

For the first case, I don't thnink this script is the correct place. This is designed to be a simple scrpt to gather data and send them off to somewhere else in a structured manner. Personally, I store the values in an Influxdb, and can then use something like Grafana to generate all kinds of graphs, fetch historic values, calculate avg/min/max for different periods etc.

As for the second, it could make sense to fetch the history from the device on startup, and report the values if the scrpt has not been running for a while. But it would make startup a very heavy process on the data-receiver, and probably very slow as it could potentially receive hundreds of datapoints from each device. Also, you could very easily end up with lots of duplicate and redundant data in your remote database, so I am not really sure it is worth it.

Anto79-ops commented 2 years ago

@Olen you raise some good points. However, good news is that the Rover has some sort of data saving chip and sends this values out like a regular number.

Even better, a fellow here, @oedo808 has already done the leg work with a fork of your script and sniffed out the values reponsible for this, here:

https://github.com/oedo808/solar-monitor

At the moment, the values are being input into the debug files. so the datalogger/mqtt parts are not set up. This requires some more work, but its almost there if anyone has the skills and time to do the latter parts.

oedo808 commented 2 years ago

I'll try to get this knocked out. I started splitting a jumbo branch up into individual feature branches to make it easier to roll back but I'm awful with rewriting commits. I'll try to just finish the datalogger work in the jumbo branch and submit a PR rather than trying to organize the git mess I made.

oedo808 commented 2 years ago

Also, I've been running with it grabbing historical data in debug mode regularly for a while. It doesn't seem to impact much, it's just an extra set of data points, maybe double the size of the normal realtime data.

I've had some issues since, but I think they're unrelated to historical data in general and more towards filling up my tiny 8GB SD card with all of the journalctl debug logging from the solarmonitor service.

Ideally the historical data should probably be polled daily or at least 8 hours, but I think it's reasonably stable polling regularly.

Anto79-ops commented 2 years ago

thanks @oedo808 I figure if I pinged you on this, your work will get noticed at least!

Look forward to it.

Olen commented 2 years ago

Just out of curiosity - do the historical data provide you with any info that you can not get if you log data to a database? If I already get all the live updates from the devices regularily, why would I also want the historical data?

Anto79-ops commented 2 years ago

probably you can get the same if you had your own script or graph program to extract that from the data provided, but the Rover does do that for you, charge status would also be good to know (i.e. boost, mptt, float, etc).