The logic would be something like this…
Decide which virtual pins are going to be use to hold your weekly, monthly and yearly running totals.
We’ll call these…
V10 = weekly
V11 = monthly
V12 = yearly
You’ll presumably already have global float variables that you’ll use to hold these running totals, we’ll assume that they are called weekly, monthly and yearly.
When your device reboots, you’ll want to get the last values from the Blynk server, so you’ll have a BLYNK_CONNECTED callback that has Blynk_syncVirtual commands for V10, V 11 & V12
These will cause the corresponding BLYNK_WRITE(vPin) callbacks to fire. One of those callbacks would look like this:
weekly = param.asFloat;
You’ll have similar ones for V11 and V12, and you now have the latest running totals from the Blynk server.
I’d abandon this idea, and instead use the RTC widget. Have variables to hold lastDayNumber, lastMonthNumber and LastYear. These can also be stored against virtual pins, and synchronised with the server at startup as described above.
Then have a timer that runs (maybe once every minute) that checks if the day number returned by the RTC widget is different to your lastDayNumber variable. If it is then you’ll check if the week number has also changed, and if the year number has changed as well.
Assuming that the week and year are the same then it’s just a case of calling a function which adds your current daily total to the weekly total, writes their result back to the virtual pin, resets the daily total and updates the lastDayNumber variable.
If the week has incremented then the weekly total will be added to the yearly total (assuming that you only want to increment this weekly); and of the year has changed then the annual total will be zeroed.
The corresponding virtual pins, running totals and lastMonthNumber/yearNumber variables will needs to be handled too.