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.

[luke-lewandowski]

I have same issue here. Based in Sydney, Australia.

Any thoughts or workarounds yet?

[EGiZBYwq]

I had the same problem.

Read this: https://developers.home-assistant.io/docs/core/entity/sensor/#entities-representing-a-total-amount and check ( => developer-tools - state), if state_class of your sensor is total or total_increasing

In my case it was total.

Defining a template sensor for use in my energy dashboard seems to solve the problem:

template:
  - sensor:
      name: "Solarenergiezaehler-gefiltert"
      state: "{{ states('sensor.gosungrow_virtual_xxxxxxx_xx_x_x_pv_daily_energy') }}"
      unit_of_measurement: "kWh"
      device_class: "energy"
      state_class: >>> "total_increasing" <<<

[bamcauliffe]

In the Addin Documentation, right at the bottom it has;

Electricity grid sensor.gosungrow_virtual_XXXXXXXXXXXXXX_grid_to_load_energy sensor.gosungrow_virtual_XXXXXXXXXXXXXX_pv_to_grid_energy

Solar Panels sensor.gosungrow_virtual_XXXXXXXXXXXXXX_pv_energy

Home Battery Storage sensor.gosungrow_virtual_XXXXXXXXXXXXXX_battery_discharge_energy sensor.gosungrow_virtual_XXXXXXXXXXXXXX_battery_charge_energy

I have not been able to find these entities, so I am currently using

Electricity grid sensor.gosungrow_virtual_1202522_7_1_1_p8063 sensor.gosungrow_virtual_1202522_7_1_1_p8062

Solar Panels sensor.gosungrow_virtual_devices_xxxxxxxxx_today_energy

The trouble is these entities are "measurement" state-class rather than "total_increasing".

I have tried customizing the entities in the confiruation.yaml file. However the values for these entities resets to 0 each day at midnight, so the correct configuring of these entities would be a). state_class: totoal_increasing b). last_reset: (midnight this morning) I am not sure how to get this right nor how to align the time with the inverter. I am hopping that getting those entities mentioned in the documentation will more easily address the issue. I am not sure if these entities are not in version 3.07 that I have installed or I need to re-add this system to HA to get those entities loaded correctly.

[EGiZBYwq]

@bamcauliffe

I'm using these sensors for my energy dashboard:

• sensor.gosungrow_virtual_xxxxxxx_xx_x_x_pv_daily_energy
• sensor.gosungrow_virtual_xxxxxxx_xx_x_x_battery_charge_energy
• sensor.gosungrow_virtual_xxxxxxx_xx_x_x_battery_discharge_energy
• sensor.gosungrow_virtual_xxxxxxx_xx_x_x_pv_to_grid_energy
• sensor.gosungrow_virtual_xxxxxxx_xx_x_x_grid_to_load_energy

To each of those there are some other sensors which deliver identical data, just with different names. However, in my case at least, ALL sensors (of this energy kind) have state_class total.

So if you are fine with the data of your sensors (beside the "reset"-feature), then just keep it.

To avoid the daily reset of the data, try putting these lines into your yaml:

template:
  - sensor:
      name: "whatever-1"
      state: "{{ states('sensor.gosungrow_virtual_1202522_7_1_1_p8063') }}"
      unit_of_measurement: "kWh"
      device_class: "energy"
      state_class: "total_increasing"
  - sensor:
      name: "whatever-2"
      state: "{{ states('sensor.gosungrow_virtual_1202522_7_1_1_p8062') }}"
      unit_of_measurement: "kWh"
      device_class: "energy"
      state_class: "total_increasing"

and similar for any other Sungrow sensor you are experiencing this kind of reset.

[bamcauliffe]

Hello EGiZBYwq,

Which version of GoSungrow are you using 3.0.7?

I tried those settings but they did not work. The values for those entities do increase in total but at midnight they reset to 0. The Energy integration should be able to use this entity if it has the "Last_reset" is showing midnight this morning.

I have been thinking that if I am missing those entities, perhaps I should uninstall the GoSungrow add in and start a fresh.

[EGiZBYwq]

@bamcauliffe

Yes, my GoSungrow version is 3.0.7.

On the configuration page of the energy dashboard: did you change the names to the new template sensor names (in my example above it would be => whatever-1 instead of gosungrow_virtual_1202522_7_1_1_p8063, => whatever-2 instead of gosungrow_virtual_1202522_7_1_1_p8062 , ...) ?

[bamcauliffe]

Hello EGiZBYwq,

Thank you.

I did have the "state_class" as "total" only. I see that the "state_class" of "total_increasing" should address this. I have made the change and will see what happens overnight.