Large spike at 12am in Home Assistant Energy graphs

[baylf2000]

I'm using the GoSungrow add-on for Home Assistant. I have the energy dashboard configured as per the instructions on the add-one page. Each day I see a very large spike in use at 12am, which seems to account for most or all of the previous day's usage, as per the attached image (taken around 1pm).

If someone could suggest what I might be doing wrong it would be much appreciated.

[Growianer]

I'm using the GoSungrow add-on for Home Assistant. I have the energy dashboard configured as per the instructions on the add-one page. Each day I see a very large spike in use at 12am, which seems to account for most or all of the previous day's usage, as per the attached image (taken around 1pm).

If someone could suggest what I might be doing wrong it would be much appreciated.

The same here...

[dbuggz]

Similar problem here:

[absynth42]

I have the same issue. I'm not sure why this happens, but it's a little annoying as it also messes up the self-reliance statistics. Could it be some kind of clock skew between the Sungrow inverter and Home Assistant?

The stats inside isolarcloud are correct, so the issue must be on GoSungrow's end.

[Paraphraser]

I think you are probably right about this being a time-difference issue.

I don't have this problem myself but I'm pretty sure that's explained by the way I use GoSungrow, which is documented at Paraphraser/gosungrow-fetch and, in particular, this line of the example script:

${FETCH_DATE}0000 ${FETCH_DATE}2359 5 \

It's a long time since I set this up so my memory is hazy but I think I probably started out assuming that the time range would be a half-open range (ie "from ≤ time < thru") and calculated both the FETCH_DATE (usually "yesterday") plus one day after the fetch date (usually "today") so that the original expanded line would have been something like this:

202410230000 202410240000 5 \

I would have noticed that (a) there were 289 data rows in the response and (b) the last line was mostly zeroes. I would have reasoned that there are 24*60/5=288 five-minute periods in a day so I would have inferred that either GoSungrow or iSolarCloud must be interpreting the command as a request for a closed range (ie "from ≤ time ≤ thru"), the practical result being that I was being given the first five-minute bucket of the following day in each response.

The usage for the relevant command is:

GoSungrow show point data  [YYYYmmdd[HHMMSS] | .] [YYYYmmdd[HHMMSS] | .] [interval | .] <points ...> [flags]

I can't remember whether I ever tried including seconds in the range, as in:

${FETCH_DATE}000000 ${FETCH_DATE}235959 5 \

I've just tested including seconds and it seems to work so either I never tried it, or I tried it and noticed the occasional bit of weird data, put it down to clock differences, then reasoned that it didn't really matter whether I lost any data in the 23:59:00 through 23:59:59 range anyway.

The upshot of all this is that I never see any backwards movements (green line):

Whether this helps with the GoSungrow HA add-on I can't say but it might give someone who wants to examine how the queries are formed in the code a place to start.