HI @srebhan , thank your for your reply and your questions. All very valid question, I will try some answers.
My first question here would be why you don’t compute the rate in the query or using a database task rather than computing it in Telegraf?
The simple answer is, that I’m not able to do it 
Actually I tried for another use case already to compute the time difference between the last and last but one value and didn’t succeed.
It may (besides my limited knowledge) has to do with the fact, that I try to use InfluxQL as query language.
Since I’m using InfluxDB V2 SQL is not available.
Since Flux is kind of depreciated in the coming V3 I don’t want to invest in learning it.
Though I’m not completely consistent with it, since I’m using already a task, where, afaik, Flux is currently the only option. My friend ChatGPT helped me out.
That’s kind of the 2nd part of the answer. The Flux task I’m using has two issues: I don’t fully understand it (and don’t want to invest to change that fact) and it has technical issues in one function (if you are interested in the details: Tasks runs quite long and uses a lot of memory - #6 by scott).
But maybe that is still a good approach. Do you have an advice how to achieve my goal with a query or a task? Using the query I see the issue that the rain counter overflows at 255.
The easier answer is: I was not aware of it.
Now, that you have pointed it out, I have to dig in it to understand it. The overflow situation comes to my mind also here.
Actually I found that example and was under the impression that I followed it, with the exception that I did not store the complete measurement but only the value of interest.
But this example, by using the state dictionary, leads to the problems I described in my initial post (state dictionary reset when telegraf is restarted).
