Strange values in graphics of Enphase device

[freekdk]

Like last year I had again a spike in the data for the Enphase device.

I took the data for the day production of the spike day and corrected that value in the table Meter_Calendar; the item Value.
Obviously also the value of the item Counter needed correction, which means that almost all values of that item in Meter_Calendar for that DeviceRowId needs to be corrected. I choose to start at the lowest date for that item, so the values in item Counter remain the same for the dates after the sate with the spike.

After that I looked at the graphs for that device and found a spike in the data for June 2023. Also the graph when choosing the year value shows an unrealistic value for 2023. Values for the other years are comparable with what the Enphase website shows.

As far as I know values for a month in the graph are calculated using the values of the Counter item in Meter_Calendar - I assume at the date of the last day of the previous month and the last date of that month. So with an sqlite3 command I extracted the Counter values for 2023-05-31 and 2023-06-30, which are respectively 17728861 and 18128236. So the difference is 399375. The graph shows a value for that month as 3.034,43.

Looking a little bit further at the value for the year 2023 on 2022-12-31 is 16784125 and the value of Counter at 2023-12-31 is 19119743.So I would expect the value for that year to be 2.335,62. However the graph shows: 4.970,64. The discrepancy in both these values is ~2635050.

I looked at values in table UserVariables and did not found a correlation. The lines with EnphaseOffset_Production_xx are:

Code: Select all

3|EnphaseOffset_Production_12|2|20506.355000|2025-08-12 15:44:11
7|EnphaseOffset_Production_14|2|0|2025-07-16 00:10:27

I have 4 lines with EnphaseToken_xxxxx. The last two have date/time 2025-07-16 00:10:27, which coincides with the data withe last spike.

Anybody knows how to explain the discrepancy for the month June 2023 and how to get them right?

[redhouse]

Have a look at this topic: viewtopic.php?t=42611

I have been struggling with this as well and have managed to get the daily/monthly totals corrected in the database. In the year view of 2024, august 2024 in my case, I still see the spike (and one in september as well due to a second enphase update a month later...). I have tried to correct this as well on a test system, but after corrections, the spike came back a month later. In the end I decided to live with it .

[freekdk]

I have been struggling with this as well and have managed to get the daily/monthly totals corrected in the database. In the year view of 2024, august 2024 in my case, I still see the spike (and one in september as well due to a second enphase update a month later...). I have tried to correct this as well on a test system, but after corrections, the spike came back a month later. In the end I decided to live with it

Did you make the data in table Meter_Calendar and Meter consistent? But if you do not make the value in table DeviceStatus consistent with the newest value in table Meter you will get again a spike the next day. This last change must be done while domoticz is stopped. Apparently the values stored in table DeviceStatus are kept in the live version of domoticz, is updated in the table when they change and is only read from this table when domoticz starts.

[freekdk]

I found the problem.

One of the counter values of a date in June 2023 was not the sum of the counter value of the previous day and the value of that day. With an sqlite3 update I corrected that value. Other values around that day were OK. Maybe the sqlite3 update for that day, when I corrected all the values in Meter_Calendar did not succeed without detection.

So apparently all values in table Counter of a month are used to calculate the production in a month.