> So, I want to use rrdtool to manage my weather station data. I read data > in 5 minute intervals, but my station only tells me the rain counter for > the last hour. So the number I get is a summation of my rain counter > deltas for the last 12 intervals. > > For instance, suppose in the last 5 hours I get the values the first line > below (one char for each 5-min interval), it means that, for every 5 > minutes, actual rainfall has been as in the second line. > > 011111244445678888889998767777765555553444335888889899987677 > 010000120001121000121000012000110000010100012300011010001210 > > Is there a way to specify that the values to store in the RRD would be > calculated as: > > stored[now] = input[now] - input[now - 1] + stored[now - 12]
This is not a complete answer but hopefully it helps you to tackle this problem. Short answer: no, unless something can be done with the COMPUTE DS type, which I do not know enough. RRDtool does not work with values. It works with rates. After processing its input, the resulting rate may be further processed. The original input is not kept. This said: your 'values' are actually rates: rainfall in the past hour. It probably means you will have to use the GAUGE data source type. And then your 'values' are in the database, as rates. Make sure you understand rates are <something> per second. Just multiply by 3600 if your rates are per hour. Before anything else: You will probably end up in some trial and error. It would be of a very big help both to you and to the members of this list to have actual values being given to rrdtool, the time that these happened, so that you can recreate the same conditions. This also means you will have to use real time stamps, not 'now'. To make things easier, it would be a very good idea to query your weather station not just every 5 minutes, but more precise at time stamps which are whole multiples of 300 seconds. Thus: 12:05, 12:10, 12:15 and not 12:07, 12:12, 12:17. Again this means using real time stamps, not 'now'. Read about normalization and consolidation: http://rrdtool.vandenbogaerdt.nl/process.php to understand why this helps. Your graphs should also start and end on nice numbers. That means you will have a known number of intervals in your graph. Beware: there have been, are, and probably will be off-by-one errors. Sometimes they are fixed, sometimes they pop up again. While debugging your solution always keep this in mind and modify your times accordingly. One example: start of graph is 12:00, end of graph is 13:00, number of 5-minute intervals should be 12, but actually was 13 because the interval 13:00 to 13:05 was also included. Another time with the same start and end times the last interval, 12:55 to 13:00, was not included and I ended up with only 11 intervals. https://en.wikipedia.org/wiki/Off-by-one_error#Fencepost_error You may need to change your start, or end time for the graph to compensate for this. Some ideas to investigate: * just write a program (C, bash, perl, whatever suits you) that does the processing as you described above. Feed the result to RRDtool. * use CDEFs with some PREVs and see where that leads you * what happens if you just record the data as is, and look at long term stats, e.g. one hour per pixel column, after RRDtool has averaged 12 5-minute rates into 1 1-hour rate. You can have more than one RRA in your database. Define an RRA which collects 12 5-minute intervals per bucket, consolidation function AVERAGE. Some random tips I can think of right now: * start with an empty database and fill the first 12 time slots with zero. This helps when using PREV. You can do so by specifying a start time at least one hour before your first entry. Then feed rate 0 to RRDtool. Either set heartbeat high enough to allow you to do this with a single update rate 0, or actually to 12 updates 5 minutes apart. * keep it simple. Your task is hard enough without all those extra features. Add those later when so desired. Focus now on getting the numbers right. * make your graphs big. E.g. 400 pixels, showing just 40 slots of 5 minutes worth of data (--width 400 --end <some timestamp> --start end-12000). Are the rates the same as you put in? If not, investigate. Logic error, or fencepost problem? * In your first few tries, send a rate, dump the database, make sure that the resulting rate is what you expect. Unless you find a bug (which I doubt, at this point for this part in the process) there is an error in your reasoning. * make sure to use http://oss.oetiker.ch/rrdtool/doc/index.en.html and so on. * keep discussions/questions on-list. HTH Alex _______________________________________________ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users
