Just trying to make the best use of the energy flow data data from a pair of GIV-AC3.0 inverters.
I am assuming that all the readings here are from the AC side of the inverters.
So if I add up all the x -> battery numbers and then the battery -> x numbers I should get a pretty good figure for round trip efficiency?
API energy flow data - is this all measured on the AC side of inverters?s
Pootle The caveats in the docs for energy flow suggests they're not terribly reliable.
https://givenergy.cloud/docs/api/v1#energy-flow-data-POSTinverter--inverter_serial_number--energy-flows
On my hybrid inverter, the API (and portal) offers 'meter data', and it shouldn't be necessary to add those up, since it already provides cumulative readings. I assume that the counter continues to accumulate even while the inverter is offline and unable to send readings to the cloud, and that the 'daily' ones are just the delta from a snapshot of the 'total' numbers at midnight, as a convenience ?
or for historical values,
https://givenergy.cloud/docs/api/v1#inverter-data-GETinverter--inverter_serial_number--data-points--date-
I've actually just switched my pvoutput.org upload script to use the meter data rather than energy flow data.
(incidentally, does anyone know if there's a trivial way in the API to get just the last data-point for a day ? You can ask for a specific page number, but if you pick an arbitrary large number, you get an empty page. You'd have to get the first page to find out the page number of the last page. When I need to, I currently just set an enormous pageSize to get all the readings, and use the last one, which is a bit wasteful.)

When I need to, I currently just set an enormous pageSize to get all the readings, and use the last one, which is a bit wasteful.)
I don't think there's a much easier way, but there's a slightly less wasteful way, at least in terms of payload, though you will require two HTTP calls.
Get the first reading for a day, and specify pageSize=1.
v1/inverter/:serial/data-points/2024-02-22?pageSize=1&page=1
Then get the last_page from the meta data element, and grab that and that alone.
v1/inverter/:serial/data-points/2024-02-22?pageSize=1&page=186
At least you reduce the response payload on both calls to a single reading.
Would be nice if Giv supported just getting the last page/reading, eg. something Pythonic like page=-1
Pootle So if I add up all the x -> battery numbers and then the battery -> x numbers I should get a pretty good figure for round trip efficiency?
Now that's interesting...
When viewing the meter data on the portal, they offer both daily and total for import, export and PV generation, but only daily for battery in and out. If I had a less trustful nature, could almost thing they didn't want to make those numbers too obvious...
But even more interesting, when I use the API to retrieve the data, it's giving identical totals...
'total': {'solar': 889.6, 'grid': {'import': 1154.6, 'export': 353.6}, 'battery': {'charge': 679.4, 'discharge': 679.4}, ...
I think I have some data downloading to do...
(I'm thinking that it could be an inverter firmware bug, if the portal is simply recording what the inverter supplies. So possibly specific to firmware revision.)
I'm starting to think less bug, more something insidious... I could understand if it was accidentally uploading the same counter value for both charge and discharge - cut/paste code errors like that are very easy. But instead it looks like the both 'total' counters are incrementing by the arithmetic mean of the charge and discharge - that's not something that gets implemented by accident.
Eg from a couple of days ago... I won't show every line, but just a few to show the pattern.
Each line is time, today's charge, today's discharge, total charge, total discharge. (I've only had the system since end of October '23, so totals haven't got very high yet.)
00:00:02Z 4.4 8.5 663.7 663.7
00:05:09Z 0 0 663.7 663.7
00:10:16Z 0.1 0 663.8 663.8
00:15:23Z 0.1 0 663.8 663.8
00:20:30Z 0.2 0 663.8 663.8
04:05:40Z 2 0 664.7 664.7
11:36:00Z 2.8 1 665.6 665.6
14:09:32Z 3.8 1 666.1 666.1
16:27:43Z 4.4 1 666.4 666.4
18:51:01Z 4.4 2 666.9 666.9
So when it's charging in the morning, both totals are increasing at half the rate. Then when it's discharging after sundown, again both counters are increasing at half the rate.
I suppose there could be a single hardware counter available, and so they chose to use it as the average of battery in and out.
Wonder Watt Asking for a high-numbered page, such as 9999, gives an empty data array, but still gives the meta data including page count. So that's very slightly less data than asking for page 1.
Odd that asking for any page less than 1 (0, -1, -10, ...) all give you the first page, but asking for any page beyond the last page gives you nothing. A bit inconsistent.