Request for guidance on restore: true, cumulative values and a recent reset

Hello!

When I originally flashed my Vue3 units to ESPHome and started monitoring about 32 different circuits in two panels, I created entries that were accumulating total energy usage on most or all of them. Example:

  - { sensor: cir16, platform: integration, accuracy_decimals: 2, name: "HVAC AUX Heat Total Energy", time_unit: h, restore: true, state_class: total_increasing, device_class: energy }

I had found this by way of an example config I was using to get my bearings at the time and restore: true seemed logical so that the values would be retained across reboots. I did note some concern over wearing out the flash, but I intended to revisit this sooner than later.

Of course, I forgot.

Today, 2026.4.0 sort of bricked the first Vue3 I updated (I wasn’t alone - see other threads) and I had to reflash my unit over the UART for the first time since the original installation. I restored my last good 2026.3.3 firmware for now until I better understand the problem.

I quickly noticed that all of my accumulating values like the one above have reset to zero. I assume the firmware flashing erased the local storage of those values.

So my questions:

I assume it’s better to configure things such that these accumulating values are stored on the HA side and not on the device? Would eliminate the flash concerns, too, I gather.

Is there a sane way I can port over the historical data to a new config - knowing I’ll lose the gap here in the interim? Right now, my graphs for those values predictably show longterm increases and, after the four hour gap where my Vue3 was down, they all crash to zero.

OR am I fundamentally misunderstanding how this is handled?

Above all, I’d just appreciate advice on the best means for collecting longterm data like this to see trends and totals, but with less risk of loss in a case like this.

Thanks!

Store it in a global variable, rather than in the sensor. You can restore the value each boot using sensor.integration.set_value:, write it back to the global with on_value: and you can set the initial_value: in the global to get your historical values loaded.

I’m not sure what type your global variable will be though…

EDIT: Globals survived an upgrade via USB to 2026.4 as well.

Thanks! This is along the lines of what I thought - I just need to dig into how to implement it.

Regarding globals surviving in 2026.4 - can you elaborate on that? In my case, there is no USB on the device - it’s OTA or a rather painful serial scenario and OTA took it in the teeth with the 2026.4.0 for these units. The update applied by OTA, then it didn’t come back and I was forced to serial. I realize now that the process I used to apply the firmware probably erased the device first rather than upgrading it… so I did this to myself inadvertently. But it starts with me storing it there to begin with being the wrong approach, honestly.

I guess the other thing I need to determine is if these long term ever-growing values are worth keeping? I’m getting daily values I can see in the Energy panel, so it has me wondering if I’m ever actually using the lifetime values in any meaningful way. Probably rather have them than not, though.

USB update is just update via onboard UART - so same as what you said erased the values. I already had the code to test this on my test bed for some reason - maybe I used it in a project…

1 Like