It felt good to complete this project that’s been on my list for quite some time. The main goal was to scrape the values from my modem’s status page and pipe them into InfluxDB, which feeds Grafana. Not only could I look at data trends, but I could receive alerts if certain values exceeded an acceptable threshold.
Overall this is a straightforward process:
Pull in the HTML from the status page (which happens to not need any authentication, making it even easier)
Parse the tables we care about (Downstream and Upstream) using XPaths
Munge the data into something suitable for InfluxDB
Insert the data into InfluxDB
Query the InfluxDB data from Grafana
I knew I wanted to use Python for the project, so I first looked into Scrapy. After wrapping my mind around it (somewhat) I gave it a go and actually had a working solution… but it felt way over engineered and at times inflexible for what I wanted. I threw 90% of that solution away and went with a simpler script.
What I landed on was something that’s custom and lightweight, but extendable in case someone has a different status page or wants to use an alternative to InfluxDB.
Every year Clemson plays USC for their state rivalry game. I pull for Clemson and my wife pulls for USC, so we’re what you call a “House Divided”. Since this game takes place on or after Thanksgiving, it’s a great time to incorporate the LED Christmas tree and troll my spouse!
The tree works like this:
When a team scores, it plays their fight song and lights up with their primary and secondary colors.
The lights on the tree are distributed by the ratio of points. When it’s tied, they each get 50% of the lights. If Team A has 2/3 more points, they get 2/3 more lights in their color.
The ring under the star at the top of the tree is the color of winning team. If they’re tied, it’s split.
When the game is finished, the tree is the color of the team that won.
I used Golang for the software since I primarily write code in another language and want to get better at it. It makes use of various interfaces to aid in testing and abstration:
The Fetcher interface gets the latest game state from a data source
The Player interface plays audio at the given path
The Illuminator interface controls a light source (in this case the LED tree)
The source code for a local data fetcher is included in this repo only. The remote fetcher I built may or may not have used an API meant for this sort of consumption. It simply fetched from a remote data source, unmarshalled a JSON data structure, and supplied what the Fetcher interface needed.
The code runs on a Raspberry Pi and communicates with the MCU via serial. An iHome IBT63 speaker is used to play audio from the Raspberry Pi. I didn’t use the Bluetooth connection and instead used the shared power and audio connector, plugging one end into the RPi’s stereo jack and the other into the USB port.
I cross-compiled from my Mac using the rpi.sh script in the executable’s directory.
I was looking for a way to segment some IoT devices from my main network and disable their network connections on demand programmatically. The Guest Network feature on the router does a good job of segmenting the network, so I wanted a way to turn the guest network’s interface off and on based upon conditions.
Example scenario: You have cloud-based IoT cameras and want to cease all traffic when you’re home.
This puts toggling any interface on the router behind an HTTP endpoint. Since an interface is created when a guest network is enabled, we can now enable and disable that network whenever we want.
This past weekend I (finally) set up Grafana to visualize information about my machines with the usual stats like CPU usage, memory utilization, network throughput, etc. After reading up on how simple it was to add time-series data to InfluxDB, I pondered how nice it would be to also have my Apple Health data.
I wrote some Python to take the massive file that Apple lets you export (in a clunky, manual operation at the moment) and pull it into InfluxDB so that Grafana could visualize it. Check it out!
“Because my garage door doesn’t need an operating system”
I admit – I went a little overkill with the Raspberry Pi garage door opener. A machine so complex was being used to do something so simple: Perform a button press. Why did it need graphics capabilities? A multicore processor? Cron jobs? It didn’t.