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.
I had a couple Pine64 boards sitting in a drawer, and decided it was finally time to replace that old Raspberry Pi running OctoPrint (err, OctoPi) for my 3D printer. The Raspberry Pi has served admirably, but it was definitely time for an upgrade, and a chance to improve a lot of my overall printing workflow.
While many people see the intranet as a pretty (hopefully) homepage, in reality the modern enterprise intranet is a complex animal of many moving parts. Structuring of the information within the intranet, how that information is presented to the user, how the user interacts with it, how the organization manages it, and the physical branding that sits on top of all of it are all critical conversations to have if an intranet is going to be effective. In this session we’ll explore the building blocks of a successful intranet and discuss common intranet pitfalls to avoid on your next intranet roll-out.