Yes, I did sudo the command.
I didn’t delete them first. I’m going out now, so I’ll do it tomorrow and get back to you.
Thanks for the help.
Phill
Hi,
sudo chmod 777 /var/www/html/collectd/
sudo rm -f /var/www/html/collectd/*.png
I did this and all graphs showed missing images. Left it 10 minutes, because I was not sure whether collectd needed a restart.
Restarted collectd and the missing yearly max distance now displays OK.
Bandwidth does not display for any tab.
I rechecked configs by search and confirmed:
collectd.conf eth0 in plugin.
make-collectd-graphs has 5 instances of eth0
index.html has 6 instances of eth0
jprochazka please note this is not a problem for me at this time. Would be nice to have, and get to the bottom of, but not urgent.
Thanks for your help, and thanks for creating the scripting. I’m sure it will help people like me who aren’t that good at the installation.
kind regards
Phill
For completeness.
Due to thinking my SD card had corrupted, today, I installed Jessie on a new SD card.
Installation via the script https://github.com/jprochazka/adsb-feeder worked without problem. Bandwidth graphs do not work on eth0.
Phill
If your Pi is connected via LAN connection you have to change a few things. I couple pages back talks about this. I had the same issue. Because I don’t use WiFi on my Pi.
Hi SJ,
Thanks, yes, I’d made the changes from wlan0 to eth0.
Phill
Cool. Glad it’s working.
Ah, nope, it’s not working, however it’s not a problem. It’s just a report for jprochazka.
If I do need a bandwidth report I’ll try a wifi dongle.
Phill
Thanks! Working on the ability to specify a wired connection next.
Just out of curiosity if you run the command “ifconfig” what interface is your IP address bound to. is it in fact eth0?
Yes, static address on eth0
eth0 Link encap:Ethernet HWaddr b8:27:eb:bf:24:d6
inet addr:192.168.2.15 Bcast:192.168.2.255 Mask:255.255.255.0
inet6 addr: fe80::48cd:dcd9:8fb0:70ea/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:160944 errors:0 dropped:129 overruns:0 frame:0
TX packets:294606 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:16741608 (15.9 MiB) TX bytes:123003802 (117.3 MiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:1590856 errors:0 dropped:0 overruns:0 frame:0
TX packets:1590856 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:466002860 (444.4 MiB) TX bytes:466002860 (444.4 MiB)
Hope this is of use to you. Also apologies if there is something here I should know.
Phill
It would be nice if you can incorporate the “WiFi auto-reconnect script” from flightaware.com/adsb/piaware/bu … ional#wifi into your script.
I used your script today and had two small hiccups:
- All I wanted to do was to add the graphs (everything else is already up and running). I wish there was an option to skip dump1090 install. In the event, I let the script re-install dump1090-mutability.
- The script did not create /var/www/html/collectd directory. I manually created /html/collectd directory structure and ran sudo ./install.sh. It worked this time and populated /var/www/html/collectd but now I don’t know exactly what action did the trick: manually creating the directory structure or using sudo for the installation.
Thanks for your work on this!
I would agree with #1. Other then that awesome work on the graphs. jprochazka keep up the good work.
Hi there.
Just an update for you.
I had a power cut and chewed up an SD card. As reported in another thread, I formatted the SD card and used Win32DiskImager to write a previously saved image of the Jessie installation, (from that same card), that I had made by using your script. I’m not for one minute saying the problem was caused by the script, but the image did not run. Now “normally” I have to start piaware
sudo /etc/init.d/piaware start
but was unable to access the pi via ssh, although IPscan24 reported two instances of pi on two different addresses.
I took that same card, formatted it, installed Jessie, faffed about with the TV to get it to open via CLI, took it back upstairs and was able to SSH to it fine. I was not able to run the script successfully as it was not able to get a copy of Debhelper. In this case it continued trying to install components that it couldn’t unpack until it reached the end.
When you update can you add a break point so the script can be exited early so as to go back and try again at a later time? Meanwhile I’ll see why I cannot make a decent copy.
Thanks
BTW I installed a wifi adapter that works fine BUT… the bandwidth graph still doesn’t work. I’ll have a dig around but looks like something in my set up.
Phill
I have ran into this myself and I am working on adding checks that will halt an installation if for some reason a prerequisite package is not available or has an issue installing. I am wanting to make it where it will try to install the needed package a couple times before reporting an error and exiting the script completely so a person can manually take a look at why there is an issue installing a package such as internet connectivity or some other issue. github.com/jprochazka/adsb-feeder/issues/14
I am also going to be looking into making it so a person can choose only to install the web features only including the performance graphs as requested in the very near future once a few more issues are cleared from the tracker.
EDIT:
I committed changes to the “web” branch adding breakpoints whenever a package fails to install. The “web” branch has this and many other changes which I am going to be merging very soon. I only need to test them using an SDR receiver which I do not have handy where I am at right now so hopefully this evening I can get the changes merged. Once this is done I will be working on making it so someone would have the choice on installing only certain things such as the performance graphs.
In the mean time you can “try” the following steps to install only the graphs.
I merged the mentioned “web” branch today so this set of commands may or may not work.
The older commands previously posted here will not.
sudo apt-get install git
git clone https://github.com/jprochazka/adsb-feeder.git
cd adsb-feeder
chmod +x bash/portal/install.sh
sudo bash/portal/install.sh
No guarantees this works due to the fact I did not test that it works but this should install only the graphs/portal for now. The new “web” branch adds navigation to the top of the map as well as the performance graphs and an empty for now homepage. These instructions should be temporary being I plan to add the ability to select certain things to be installed on their own in the very near future.
Thanks JP,
Sorry I haven’t had time to try this yet.
Question on collectd graphs range graph.
My stats “Positions Reported by Distance from Receiver” claims ~20 @ 240 to 300 miles on a daily basis. The collectd graph ADS_B max range for the week shows peak range 196nm (~ 230 miles). For the last couple of days the positions report shows one > 300 miles, yet this never shows on the collectd.
Any thoughts.
Phill
It’s due to the way round robin databases work. When collectd stores the data, it doesn’t keep every piece of information indefinitely. For dump1090, it keeps data at several different resolutions. It keeps data at one minute resolution for about 20 hours. After that, it is reduced to around 7 minutes per sample, then a few hours etc.
When the database is full, it wraps round and overwrites old information. This means the rrd files are of fixed size and don’t get very large over time. The tradeoff is reduced resolution over long time periods. If you get a rare spike at very long range, but only for a short period (20 positions could only represent 10 seconds of flight for one aircraft), you may find that it doesn’t appear on your graph.
The other thing is that the rrds store the minimum, maximum and average value for that period of time and the graph only show one of those figures. If you look in the script that generates the graph, you will see lines like this:
"DEF:messages=$2/dump1090_messages-local_accepted.rrd:value:AVERAGE" \
That will get the data corresponding to the average for each time period stored, ie the average over the previous 60 seconds at the highest resolution. If you change the AVERAGE to MAX or MIN, then you will alter the graph to show the maximum or minimum data stored for that period respectively. For short period graphs, these may be fairly close in value but for longer periods there could be a substantial difference as there could be several hours between each data point.
Dump1090 updates the json data used by collectd once per second, but as far as I’m aware the python script that collectd calls isn’t getting the data that frequently. That means that a short lived contact might be missed for something like range.
Here’s a couple of graphs that illustrate:
This is 24 hours. You can see that the maximum and minimum are very close to the average value, so over a day the average will correspond quite closely with the message rate you would have seen had you looked at the map page at any particular time.
http://i.imgur.com/rfwgIMZ.png
This one shows a week. You can see that the longer samples have more variation between maximum and minimum, but are still quite close to the average.
http://i.imgur.com/A67Xs17.png
This one shows a year. The very long time between samples means that they almost always straddle busy and quiet periods, so the deviation from the average is much higher.
http://i.imgur.com/kEWzJUv.png
A quick question - I build the jessie image using jpochazka script (plus some other stuff), imaged a new SD, put the newly imaged card in one of the “production” PI and renamed the host to match previous name. Everything seems working OK except one thing - all ADSB related collectd graphs are empty (the images are generating but with no data). Where I should look to fix the problem?
First try running the following command and see if you get any errors.
<PATH TO THE FILE>/make-collectd-graphs.sh 24h
Also check the folder /var/lib/collectd/rrd/localhost make sure that there is a folder in there named dump1090-localhost.
If this folder is not present make sure that the hostname in collectd.conf is hard coded to localhost and that the <Instance …> tag between the tags for the collectd dump1090 plugin is still localhost.
I did not ran the make graphs script separately, but I saw in syslog that it is being executed by cron with no issues. I also checked the /var/lib/collectd/rrd/localhost and the dump1090-localhost is there, but the rrds within the folder have not being updated since the I took the image. I will check collectd.conf tags next (thanks for the idea!).
If the rrd files are not being updated…
Check the collectd.conf file first make sure the dump1090 plugin configuration still looks something like so:
<Plugin python>
ModulePath "/home/pi/adsb-feeder/build/portal/graphs"
LogTraces true
Import "dump1090"
<Module dump1090>
<Instance localhost>
URL "http://localhost/dump1090"
</Instance>
</Module>
</Plugin>
Also you might want to make sure that “localhost” resolves to 127.0.0.1 using nslookup or ping. If your installation has a GUI installed also try opening a web browser locally on the device and open localhost/dump1090 and make sure at the dump1090 map shows up for you. If localhost does not resolve add the following line to the top of the file /etc/hosts if it does not exist.
127.0.0.1 localhost
Kind of curious if when you changed the host name it may have hosed up the resolution of the name localhost. The dump1090-tools plugin uses http to get data from dump1090 and if it cannot resolve the name local host then it isn’t going to get data. You can also try changing 127.0.0.1/dump1090 in your collectd.conf.
Just taking guesses here kind of hard to troubleshoot something with only general information. 
FYI:
cron output is sent to /dev/null to cut back on writes to an SD card so as to not risk wearing one out too quickly if one is used so nothing will be logged.
(writing to an SD card every 5 minutes, many times more often, is not something I like to force on people.)
Running the above command will not foul up any stats and will help to trouble shoot the issue immensely.