Having previously moved my Telegraf instance to a Synology-hosted Docker environment, I’ve spent some time adding additional measures for tracking and visualization using Grafana. With that task, I recently discovered the Telegraf Exec plugin, which allows you to execute custom scripts for the purposes of collecting external data for ingress into InfluxDB (or any of the other Telegraf output options). To prove out this concept, I’m using a Bash script to connect to Fitbit and pull data from my Fitbit Blaze into InfluxDB.
In a previous post, I walked through the process of configuring Telegraf to run on a Virtual Machine hosted on my Synology DS1817+. While I quite liked the idea of running a virtual machine, with a complete OS available for configuration and installation of anything I might need, I also wanted to explore a thinner deployment of Telegraf using less resources and operating more like a service than a VM I would need to patch and maintain. Enter Docker.
As part of my Home Automation series, we configured a Grafana dashboard to display status and statistics about SmartThings devices, the local weather and more. A few months ago, I retired an 8+ year old Windows Server storage solution and replaced it with a new Synology DS1817+. I knew that I wanted to leverage Grafana to display health statistics about the Synology (disk temperatures, throughput, disk conditions, etc.)—something that I never took the time to setup for my Windows server. Thankfully, Synology’s DSM platform natively supports SNMP, and we can easily run Telegraf to monitor the SNMP data and log it in our previously created InfluxDB instance.
This project really traces its roots back to 2012, when I built a temporary irrigation solution for a small herb garden on our apartment balcony. That particular solution was designed to simply water our herbs while we were away on vacation, and was certainly limited by the fact that the 5 gallon bucket only held a 5-6 day water supply, and contained no smarts of any kind—outside of the MacGyver’d pond pump connected to a Christmas light timer. In 2016 we moved into our house—outgrowing the 5-gallon bucket solution, and starting our home automation journey. After building a new herb and vegetable planter, and planting new shrubs this year, it was time to upgrade our irrigation solution.
DarkSky offers one of the best developer APIs around. I'm not paid to say that, they're not sponsoring this post (they don't even know about it), but having worked with their API on several other projects I've always been super impressed with their data models and the specificity of the data they return. Instead of basing their data on a large area (like a zip code), DarkSky uses your specific latitude and longitude, giving you a very precise forecast. We won't be directly using the API in this particular post, but if you're curious you should definitely go check it out.
Back in the Home Automation Kickoff post, I talked about the power of the mFi Controller to record, trend, and analyze device and energy usage. One of the huge disappointments with Ubiquiti ending development of the mFi Controller was the end of development related to these capabilities. SmartThings has proven itself to be a fantastic platform for the integration and management of physical devices, but offers essentially no analytics around those devices. In this post, and the following series, we’ll look at integrating data analysis with SmartThings, and building a more data-driven home automation solution.
SmartApps are written in Groovy, and can be found within the "Add a SmartApp" menu inside of SmartThings. SmartThings provides a number of SmartApps and SmartApp categories right out of the box, so you can just pick an existing one and be up and running. In addition to that, you can self-publish your own SmartApps directly within SmartThings Graph, or publish SmartApps to GitHub for yourself or others to use. I'll talk more about the latter options when we get to creating our own SmartApp in a future post. You can think of a SmartApp almost as a Routine on steroids. SmartApps are a way to run complex logic, calculations, or even call external services as part of the automation.
Back in the Home Automation Kickoff post, I mentioned my past frustrations getting simple things like sunrise and sunset rules to work. For this example, we'll be using a simple SmartThings routine to turn on an outdoor GE Z-Wave module at sunset.
I've long planned to start a Home Automation series in an attempt to document the deployment, configuration and monitoring of various home automation components. This journey really started over a year ago when my wife and I built our house. With network drops run to anywhere that I thought we might ever want to put anything, I saw home automation as a valid excuse to apply my passion for technology outside of work and get back to some of my more "maker" roots.
I really had a few goals that I was trying to accomplish. Energy conservation and trending were at the top of that list. I've always assumed that solar panels were in our future at some point, but without knowing what our true energy usage was, or where we were wasting energy were the first two problems to solve before considering solar in order to ensure we could right-size a solar deployment and cover a large percentage of our average energy use.
Secondary to the energy monitoring was the security and comfort side of home automation. Lighting presets, more granular control over HVAC, sunrise/sunset rules, presence driven rules, etc. were all things I was excited to learn more about and develop over time.