Niklas,
Here's a good way to prepare your timestamps before doing the actual average in an Expression Analysis:

Thanks!
Found out the reason I got strang values is because om leap year. I tried bacfill on the previous month instead and it worked out just fine.
Using the function yearday and it goes wild in February. Any ideas why that is and solutions?

The yellow ones are between 00:00-06:00.
This is what happens:

Works perfect when January turns to February.
2024-01-31 00:00 - 2024-02-01 06:00
This is the latest one:

Works everytime except 2024-03-01 00:00-01:00.
What I´m trying to get is something like this:

Average * Hours
From 06:00 the first day of the month to 06:00 the first day of the next month.
As you can see on the picture it works like a clock except 29/3 00-01.
Tried yours like this on a different point:

But it goes to zero at midnight.
I just tried the Yearday('*') function, and it works fine in my system. Did a recalc daily since 1-Jan, and no unexpected results. Perhaps you can add a screenshot of your calculation, it'll make the issue easier to spot.
That's a lot of logic, and it tells me your task isn't as simple as "calculate the average from 06:00 the first day of each month to 06:00 the first day of next". Because if it is, you can do this in one operation, as I demonstrated in the first reply. If not, please specify more in detail how you need the logic to work.
Your screenshot doesn't show the scheduling, but the logic of comparing timestamps in "TotOut" indicates you may be scheduling this to run every six hours during the day? Or every hour perhaps?
So exactly at 06:00 first day of the month you reset to 0, then you have the middle line which is run between 00:00 and 06:00, and the last line if the calculation runs after 06:00?
Readability of the logic isn't that good, and especially being used to BOM() for beginning of month, I find the whole Yearday('1') syntax a bit confusing. Please explain the two TimeM and Time6h a bit more. Are they fractions of a month, and you multiply the averages by this fraction? Wouldn't it be better to just add the correct end time directly in the TagAvg functions?
I tried your formula and I don't get any spikes or inconsistencies around that. I'm using the example tag 'cdt158' and it appears to work for me. The only thing I could see is that the factor you're multiplying the TagAvg with, will become zero for the first day of every month, so when I ran a test with 6h calculation period, all the first four values were 0. But if you run this daily, this should work fine.
If the factor is supposed to be the hours since the start of the calculation, you could get that more accurately by subtracting the two timestamps. Then you're left with a variable with the 'timespan' data type, which you could convert into seconds, then into hours. In this screenshot the two are the same, but it'll work more accurately for the entire month.
