My personal opinion, we are a DNS solution and the dashboard is for monitoring and controlling the DNS functions. There are other solutions (including yours) that are more geared towards monitoring the status of the device or other metrics that are very nice, but don’t help us with being a better DNS server. It gets us on a slippery slope of feature creep and adds to the support load that we are already struggling with. I like the graph and the solution, but I don’t see it as being something that I would add to the base code.

We’ve discussed options of making the web interface modular so that user created addons could be added to the admin page, but in the end, it’s an admin page and not a monitoring platform. We’ve had requests for things like drive space usage, and other metrics that we’ve declined to implement, maybe if we grow and have more staff (or any full time staff) that could support the features we can look at mainline code inclusion, but as it is we’re just a group of volunteers and the project is growing to the point where we can’t provide timely support to every request that comes in.

So we have to look at every Feature Request or code submission and ask “How does this make us a better DNS ad blocker?” and use that as the test to what we implement in mainline code. We also have to be careful as to what may be seen by users as officially sanctioned features, and I’m concerned that the feature of using this as a tool to send messages to ISPs about speeds will end up as tweets and emails saying that “Pi-hole is detecting that I’m not getting what I paid for.” Even if it’s clearly noted that this is a 3rd party add on, we will have users that will expect the core team to handle their issues and we just don’t have the people to do that.

So that’s why I personally am saying no to mainline as it stands now. We will review the ability for user created addon’s when we work the admin interface rewrite but that has to be done very carefully so that the possibility for malicious code (and I’m not inferring in any way that this is malicious, the code is in public view,) can’t happen, and that anything that is displayed on the page with Pi-hole branding is not going to cause problems with either the Pi-hole or anything that the Pi-hole touches.

Also would need to let users know that the design of the Raspberry Pi makes speedtests inaccurate above a certain speed. I run on a device with a true 1Gbps interface, but with the standard Raspberry Pi you have so much contention with the single USB bus that I personally wouldn’t trust any results from anything faster than 50-60Mbps. I’ve used (and used to be the Arch packager) for RPI-Monitor, and even that had some issues with speedtests.

I really do like what you have created and hopefully we can somehow work things so that it can be included in the future, but we just don’t have the staff and the time to do it correctly right now. But we are starting on the rebuild of the interface so it’s a good time to look at modularity and setting up a framework that would allow for user addons.

Thanks, always wanted a intervalled speedtest on my C.H.I.P., and this works great,
on Pi-hole Version vDev (FTLDNS, v3.3-75-g82d5afe) Web Interface Version v3.3 FTL Version vDev (FTLDNS, vDev-003371f).