Look at the times each value is in the database. The energy table takes from the start of hour to the end of the hour.
The history panel just shows you raw data. There’s a very likely chance that your information is coming in slightly after the hour, which is skewing the results.
EDIT: Actually, that’s 100% happening, look at 11am for you. It’s showing the value all the way up and the drop occurs after.
BTW I found it more flexible to rely on Power metering (instead of energy one).
Power is more continuous (from HA POV) and calculation of the energy might be done on HA side, respecting the local clock.
It has downsides: it has finite resolution down to sampling frequency. So if power measurement updates HA every second, it misses changes in-between. Still, it might be better than X-seconds or Y-minutes shift.
I have been dealing with this for a few years now, by using Node-Red to modify the data in the mysql statistics table 1 min after each hour when the data is received from the meter. This has been working great for a long time now. The code is too complicated to share here, but it basically loads the last 2 values, and run a new sql query to update the record with corrected data.
When Tibber provides the one day delayed consumption and cost data, I again update the corresponding records in statistics table to be 100% synced with the data from Tibber, using Tibber integration and Mysql queries from Node-Red.
However the other day I got this idea: What if you instead just create a mysql trigger on the statistics table that shifts the timestamp before it is actually written to the database, and only for the consumption and cost entities. I have tested this in an test HA installation, and it works great, if you can live with that the table data is populated 1 hour later than normal. With this trigger the data is saved in the correct timeframe.
CREATE TRIGGER `shift_statistics_time` BEFORE INSERT ON `statistics`
FOR EACH ROW BEGIN
-- Only adjust if the metadata_id is 2 or 3 (for me energy and cost entites)
IF NEW.metadata_id IN (2, 3) THEN
-- Ensure NEW.start_ts is not NULL
IF NEW.start_ts IS NOT NULL THEN
-- Subtract 1 hour (3600 seconds) from start_ts
SET NEW.start_ts = NEW.start_ts - 3600;
END IF;
END IF;
END
And for short term:
CREATE TRIGGER `shift_statistics_short_time` BEFORE INSERT ON `statistics_short_term`
FOR EACH ROW BEGIN
-- Only adjust if the metadata_id is 2 or 3
IF NEW.metadata_id IN (2, 3) THEN
-- Ensure NEW.start_ts is not NULL
IF NEW.start_ts IS NOT NULL THEN
-- Subtract 5 minutes (300 seconds) from start_ts
SET NEW.start_ts = NEW.start_ts - 300;
END IF;
END IF;
END
Warning! This is not meant to be a guide, but ideas on a workaround approach for this problem. This may break your HA installation. Make sure you understand what you are doing before trying to repeat any of this. Always test in a test system first. I cannot help you if something goes wrong.
If anyone can come up with a py code for HA, that allows you to correct existing statistics without using direct sql queries, I could probably write a HA integration that would sync the data with delayed consumption/cost data from the Tibber API.