Thanks, Alex! The last but about the double update did it for me. I split my Python script into two objects which each did their own rrdupdate and set half the values to U. By combining the data into a single update, my values are now working just fine. I thought that the U would be the same as no-update but apparently not.
On Mon, Jan 22, 2018 at 11:18 PM, Alex van den Bogaerdt < a...@vandenbogaerdt.nl> wrote: > > I was hoping someone could help me understand how values are computed in > > RRD. > > I got a temp database (create below). I got a loop that adds an update > > ever > > ~2 minutes. > > 120 seconds. > > And your interval (database step) is 200 seconds. > > > rrdtool info says the DS got known values for the last two > > columns (ext_temperature, ext_humidity). > > and also reports part of the interval is unknown. > > Guessing here, I did not do all the exercises: my guess is that you always > have part of an interval set to unknown data. > > Suggestion to debug, and maybe also to make permanent changes to your > database setup: > > 1: set your database to step==1 > 2: the RRAs you already have, collect data 200x the current step size > (e.g. you now have RRA:AVERAGE:0.5:1:2016 this becomes > RRA:AVERAGE:0.5:200:2016 ) > 3: an extra RRA expects data every 1 step. It won't get it that often, but > that does not matter. Just make sure heartbeat is set high enough. > 4: also keep MIN and MAX if so desired > > This new, extra RRA aids in debugging. Just make it long enough to look > back an hour or so (3600 seconds). Longer if you wish to keep and use the > data. Disk space is cheap. > > Your previous setup: one complete interval was 200 seconds and you needed > at least 2 updates for it to fill. The new proposed setup completes more > than one interval of 1 second each time you update. > > If you see weird rates in the first interval of such ranges (rates being > pulled to zero), then your version of RRDtool suffers from the > sub-second-precision bug. Ignore, or make sure you update with integer > timestamps instead of "N" for now. > > > Last but not least: if you receive your data as one batch of numbers, > then never mind but if you receive your numbers separate from each other, > then do not combine them in one RRD database. > > E.g. update x:1:2:3:4:5:6:U:U followed by update x+1:U:U:U:U:U:U:1:2 > messes things up. It will NOT result in only updating the first 6 DSes and > then only the last 2. > > HTH > Alex > > >
_______________________________________________ rrd-users mailing list rrd-users@lists.oetiker.ch https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users