Quite possibly.
There still hasn’t been any build guide published for the current emonSD so I cannot comment on the current position, but definately prior to the latest image, the values held in redis are not persisted accross reboots (it is/was a low-write “optimisation”) so the first data in is/was always unused for increasing the total, it created the “reset point” only.
For example if you had a battery operated emonTH pulse counter and your emonpi was off line for whatever reason, whilst your emonpi is off line the pulsecount on the emonTH continues to grow, when your emonpi comes online the first value received is assumed to be the new “zero point” (as redis is flushed on the reboot there is no “last value”) then the second value received will lead to a calculation based on the 1st value, now held in redis.
So the emonPi’s “low-write” emoncms is not able to “catch up” with missed energy/pulse values after a reboot, it is as if the world stopped for the duration of the downtime. This is not the case for regular emoncms as the last redis value is regularly persisted to disc by redis and read back into memory at start up, so the 1st value recieved after boot up, is compared to the last value received before going offline, in the case of the battery emonTH pulsecounter, no pulses would be lost.
There is a awy around this (is it is still an issue in the latest image) by using the rather catchlyl named “Total pulse count to pulse increment” process instead. (see Wh accumulator - strange behavior - #5 by pb66) don’t be put off processes that don’t have generic names, the only difference between a pulse and a Wh is possibly scaling in many instances (but more often not even that)