Or maybe you looked at date like 1/4/2019 and decided it’s 1st of April. 
BTW I am experimenting with netdata plugin based on your scripts:
1 Like
I’m a big fan of Netdata - I’ll check this out, thank you. Right now I’m doing a mix of collectd & curls to put data into graphite/grafana.
EDIT: looks great! (here is a graph of your plugin lined up with my curl input)
1 Like
These graphs are really good and I must thank @wiedehopf for all the work he’s put in to them.
I wonder if anyone has done what I hope to do and if so, can give me some pointers. I’ve fitted a “one wire temperature” probe inside my feeder and it’s all working, I can read the temperature using the command more /sys/bus/w1/devices/28-0319977943e7/w1_slave on my Pi.
This gives me a response:
56 01 55 05 7f a5 81 66 06 : crc=06 YES
56 01 55 05 7f a5 81 66 06 t=21375
Where t=21375 is the temperature, ie 21.375°C and 28-0319977943e7 is the serial number of the temperature probe.
I’d like to integrate this into my graphs so I can keep a track of the temperature inside the box as well as the Pi CPU temperature.
I’ve found quite a few guides on setting up graphs using this sensor but I’m struggling to integrate it into the graphs page.
I appreciate it’s a long shot and an unusual thing to ask but has anyone else done this already?
Could you show this output:
ls -l /sys/bus/w1/devices/28-0319977943e7/*
Let’s try this command and see if it extracts the temperature:
grep -oP -e 't=\K[0-9]*' /sys/bus/w1/devices/28-0319977943e7/w1_slave
1 Like
git clone -b extra_temp https://github.com/wiedehopf/graphs1090.git
cd graphs1090
sudo bash install.sh test
This should work.
First tried to collect the temp sensor using the table plugin via configuration in /etc/collectd/collectd.conf but the file format is annoying.
Does it have a sysfs file with just the value in it?
Anyway you can see the code difference with git show if you are curious about the code.
I didn’t bother to change the html stuff, your graph is just named like the UAT messages graph and displayed in its place 
2 Likes
That just returns me to the prompt, no output at all.
It does! Perfect Thank you.
I will take a comparative look at the code - But it’ll be later after Eurovision!
No need if you don’t care, just if you’re curious
Maybe i’ll make it proper with configuration and all.
This way it’ll be in the main branch.
Right now it’s just a one off hack with your sensor serial number hard-coded.
Having the temperature in a file of its own without all the other stuff would make it a little easier. But i guess that’s not available with that driver.
1 Like
I think it’d be a really useful addition but it’s pretty niche and I don’t know if anyone else would actually use it although if the option is there, it might give some people the impetus to install one of these temperature sensors.
We all like to fiddle and experiment in this forum and it’s more data that’s available. Technically there’s not much I can do to adjust the temperature in the box that’s mounted 33ft up in the air but I find it interesting to see what’s happening up there. The times it’ll be most intriguing is in the height of the summer and the depths of the winter. It’s all very well seeing the Pi CPU temperature but to know what the ambient is as well is pretty cool.
1 Like
Mmh, any idea how the max number in the table ADS-B Aircraft Seen / Tracked is calculated?
It is eg 155 in the last 24 hours, but only 148 in the last 30 days, 117 in the last year, and 93 in the last 3 years (The feeder is only collecting data for less then a year).
Shouldn’t it be something like max(values of time interval selected), so that the current values are always included?
"DEF:all=$(check $2/dump1090_aircraft-recent.rrd):total:AVERAGE" \
"DEF:pos=$(check $2/dump1090_aircraft-recent.rrd):positions:AVERAGE" \
"DEF:mlat=$(check $2/dump1090_mlat-recent.rrd):value:AVERAGE" \
"DEF:tisb=$(check $2/dump1090_tisb-recent.rrd):value:AVERAGE" \
"CDEF:noloc=all,pos,-" \
"VDEF:avgac=all,AVERAGE" \
"VDEF:maxac=all,MAXIMUM" \
"AREA:all#00FF00:Aircraft Seen / Tracked, " \
"GPRINT:avgac:Average\:%3.0lf " \
"GPRINT:maxac:Maximum\:%3.0lf\c" \
"LINE1:pos#0000FF:w/ Position" \
"LINE1:noloc#FF0000:w/o Position" \
"LINE1:mlat#000000:MLAT" \
"LINE1:tisb#00c0FF:TIS-B" \
Yeah this should be an easy fix.
Basically you need to use the MAX part of the database instead of the AVERAGE part.
"DEF:all=$(check $2/dump1090_aircraft-recent.rrd):total:AVERAGE" \
When the 1 minute granular data is made less granular to save space when saving 3 years worth of data, a propagation function must be used.
So you make 3 databases basically: MIN, MAX, AVERAGE.
But if you want a true maximum you need to use the MAXIMUM as a basis.
That means defining a new data source and using the maximum function on that.
I’ll implement it another day
Use the install.sh to update and check if it’s better now.
For everyone else:
The UAT graphs are now hidden by default and will be automatically shown once skyview978 is running for some time.
3 Likes
That was quick. Looks ok now, last 6 it is 148, last 24 157, last 48 157, last 7 165, for the rest as well. Great 
Thank you, much tidier now
Should have suspected that the neat freaks were going to revolt
There is also a possibility of getting back the disk graphs in case your kernel is too current for you collectd.
At least on the RPi you can just install a new collectd version rather easily:
wget -O /tmp/collectd.deb http://raspbian.raspberrypi.org/raspbian/pool/main/c/collectd/collectd-core_5.8.1-1.3_armhf.deb
sudo dpkg -i /tmp/collectd.deb
How can i resize the rrd database’s without lossing data…?
As you can see data is truncated after 1 year of collecting data…
Left week ago , right this evening
I started years ago with the “adsb receiver-project”
adsb receiver project only saves one year, that is reflected in the rrd files.
I’ll see if i can whip something up.
There is a somewhat easy solution just increase the RRA size for the last 3 RRAs.
It’s a command like this:
rrdtool tune dump1090_messages-local_accepted.rrd RRA#0:=13000 RRA#1:=13000 RRA#2:=13000
Can you give me the output of
rrdtool info /var/lib/collectd/rrd/localhost/dump1090-localhost/dump1090_messages-local_accepted_0.rrd | grep row
I’ll look into completely converting to the new data format i’m using, the granularity in some graphs is better and it looks nicer.
rrdtool info /var/lib/collectd/rrd/localhost/dump1090-localhost/dump1090_messages-local_accepted_0.rrd | grep row
rra[0].rows = 1200
rra[0].cur_row = 968
rra[0].pdp_per_row = 1
rra[1].rows = 1200
rra[1].cur_row = 719
rra[1].pdp_per_row = 1
rra[2].rows = 1200
rra[2].cur_row = 262
rra[2].pdp_per_row = 1
rra[3].rows = 1440
rra[3].cur_row = 905
rra[3].pdp_per_row = 1
rra[4].rows = 1440
rra[4].cur_row = 658
rra[4].pdp_per_row = 1
rra[5].rows = 1440
rra[5].cur_row = 886
rra[5].pdp_per_row = 1
rra[6].rows = 1260
rra[6].cur_row = 243
rra[6].pdp_per_row = 8
rra[7].rows = 1260
rra[7].cur_row = 1247
rra[7].pdp_per_row = 8
rra[8].rows = 1260
rra[8].cur_row = 1206
rra[8].pdp_per_row = 8
rra[9].rows = 1207
rra[9].cur_row = 311
rra[9].pdp_per_row = 37
rra[10].rows = 1207
rra[10].cur_row = 559
rra[10].pdp_per_row = 37
rra[11].rows = 1207
rra[11].cur_row = 598
rra[11].pdp_per_row = 37
rra[12].rows = 1201
rra[12].cur_row = 131
rra[12].pdp_per_row = 439
rra[13].rows = 1201
rra[13].cur_row = 469
rra[13].pdp_per_row = 439
rra[14].rows = 1201
rra[14].cur_row = 800
rra[14].pdp_per_row = 439
Oh before we start playing let’s just do a backup:
sudo cp -r /var/lib/collectd/rrd/localhost /var/lib/collectd/rrd/$(date -I)
1 Like
Ok, this should do the trick:
for file in $(find /var/lib/collectd/rrd/localhost | grep '\.rrd'); do sudo rrdtool tune $file RRA#12:=3640 RRA#13:=3640 RRA#14:=3640 ;done
That’s not the “new” structure i’m using but it should be good enough.
If you want the “new” structure i’ll check how this could be done most easily.
1 Like
Thnx , lets collected some data for a week and see…