Grafana is an analytics platform that allows you to create rich dashboards, define alerting logic when values exceed specified ranges, and visualize your data across a number of different formats. You can get a good idea of the capabilities of Grafana by just clicking through the official and community submitted dashboards on the Grafana website. The beauty of Grafana is its ability to visualize incredibly complex data sets in a way that still looks really sexy.
To deploy a custom SmartApp, you first need to login to SmartThings Graph. Be sure to login with the same account that you use to login to the SmartThings app on your phone. I originally setup my SmartThings hub using a separate account than the individual user accounts for the app. This caused issues when publishing apps, since the user that publishes the custom SmartApp via Graph is the only user that can install the SmartApp using the iOS or Android app. It sounds, confusing (and it can be), but we'll walk through it all here.
If you're super interested in all the little details, you should absolutely go and check out the InfluxDB website, but in a nutshell, InfluxDB is a time series based data platform. Unlike other database platforms that store data based on a primary key that you define, InfluxDB uses a timestamp as the primary key for data points; I'm obviously over-simplifying this to make it a little easier to understand. InfluxDB supports the auto-expiration of data—think of this as a TTL on a DNS entry if that helps you—which automatically purges the data at the end of expiration. The other big advantage to InfluxDB is that any past experience you may have with say SQL, is applicable here. The query language and syntax of InfluxDB has a lot of similarities with SQL, and you'll see that when we get to Part 4 and build our first dashboard.
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.
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.
I'm not entirely sure what version this "bug" started to present itself, but as of Cura 2.3.1 it is definitely an issue. I never store material temperatures in my GCODE. Partially because I like to change materials a lot, and mainly because even among PLA or ABS suppliers, filament varies and I often find that 5-10°C differences in my material printing temperatures are needed depending on filament brand. My general workflow is to design a part, export it as an STL, slice that STL in Cura, and then store the GCODE file inside of OctoPrint for future reprints of that part, without needing to re-slice in the future. For that reason alone, storing a material temperature in the GCODE itself makes little sense. Cura's process of selecting the model, printer, material and preset really only makes sense if you're physically printing from Cura, which I would guess is not the norm given how many people are using non-Ultimaker printers, and printing from solutions like OctoPrint.
The way Cura behaves in this regard is a little odd. If you don't add a printing temperature to your preset, Cura will add a “M109 S0” to the start of your GCODE during slicing. Effectively telling your printer to set it's temperature to zero. You've now preheated your printer to the correct temperature for your material, hit print, and nothing happens since your printer is now waiting for the temperature to be set to zero.
I've been reliably using OctoPrint on a Pine64 since I wrote the original two parts (Part 1, Part 2) of this series back in January. I was a bit behind on OctoPrint updates (running 1.3.2), and took the opportunity this weekend to upgrade to the latest stable version (1.3.4), and add in the custom action I've been meaning to create for remotely powering up my 3D printer.
I've been using a Ubiquiti Networks mPower-Mini to control power to my 3D printer since day one. In addition to providing remote on/off capabilities, these devices also allow you to track and trend power consumption and other metrics. Ubiquiti has unfortunately ended development of the mFi controller, but these devices are still manufactured for users willing to script their own interface to them. I've been working my way off of my existing mFi controller for this reason, and figured it was time to connect my mFi switch to an action inside of OctoPrint. This allows OctoPrint to issue the on/off commands directly to the outlet, without needing to login to the mFi controller, portal, or mobile app.
In case you missed the press release and social promotion last week, my company announced the release of Record Center Version 2, greatly enhancing the records management experience within SharePoint. At B&R Business Solutions, our ultimate goal is to simplify what are otherwise stressful and complicated tasks for users and record managers, making the overall records management life cycle in SharePoint much more manageable.