by Welcome back to the automation trilogy! Last time we talked about a scripty way to get around keeping DNS up to date without needing a static IP. This time we talk about a recent limitation to IF This Then That (IFTTT), an IoT service that interacts with devices with event based triggers, and how I worked around those limitations using OpenHAB. Lets get into it!
The Great IFTTT Purge
On September 10th, 2020, IFTTT launched IFTTT Pro. They promised unlimited applets, faster runs, customer support and even more integrations. What they didn’t tell us was for IFTTT free users, they were limiting us to only 3 applets. Ok they did tell us, many times in email, they were doing this… I just wanted to be cool with the whole Skynet thing. Anyway, quick background on IFTTT.
IFTTT is a webservice that acts as a middle man for other services and allows them to communicate with each other. For example, I have a IFTTT applet that blinks the lights in my living room when my Uber ride shows up.
Pretty great right? But as I mentioned, since IFTTT pro, free users only get to use 3 of these applets. The problem with that is I already use quite a few just for my printer alone. A finished print notification, turning on the lights when the print starts, status screen shots every hour for longer prints, the list goes on… So I needed to find an alternative. This brings us to OpenHAB.
OpenHAB: open source IFTTT
I stumbled upon OpenHAB googling open source alternatives for IFTTT. The biggest reason I picked them was they ran on all planforms and they had an intuitive REST API. Satisfied playing with their demo and reading their docs, I fired up a new VM on my virtual server and installed it.
After getting OpenHAB installed, the first thing you’ll want to do is jump into the PaperUI and start discovering devices!
Bindings are the meat of OpenHAB. They are the glue between the service you want to talk to and the functions of that service you want to interact with. In my case, I want to add the Phillips Hue binding since thats the service my smart bulbs run on.
The binding will then start discovering the lights and groups in my house. From there, I can tack on items and things to start controlling them from this interface.
With the right things and items added in OpenHAB we are now ready to work on the OctoPrint side of things!
Can a Python talk to an Octopus?
This is the part where things get a little messy. Our next objective is to somehow get octoprint to talk to OpenHAB when an event occurs. We all know that somehow is usually python, but in this case its BASH!
Lets first get our bash script talking to OpenHAB. The script itself if going to be very basic. Using OpenHABs REST API, we can run a POST to our printer light group to trigger whether to turn them on or off.
curl -X POST --header "Content-Type: text/plain" --header "Accept: application/json" -d "ON" "http://myopenhab:8080/rest/items/PrinterLightRoom_Switch"In this case I have two scripts, LightsON.sh and LightsOFF.sh For lights off I just change -d “ON” to -d”OFF”. That’s it!
Getting dumb GCODE to be Smart!
In Octoprint, there is a section in the settings called GCODE Scripts. Great for telling the printer to turn fans off or move the nozzle out of the way after a print. Not so great for telling the printer to run a python script after a print job.
Turns out, there is a great little plugin in the Octoprint repository called GCODE system commands. With the GCODE plugin, we can create our own GCODE commands that will be interpreted as script calls. In this case, when a print job is done or when it starts, it will run our custom OCTOXYZ commands.
And just like that, whenever we start or finish a print job, our bash script executes which sends a POST to OpenHAB which will let Phillips Hue know what lights to turn on/off. Man do I looooove open source 🙂
Shout Out to OpenHAB
I do have to give mad props to the ladies and gentlemen that worked on OpenHAB. While there are plenty of flaws with open source software, you do have to understand that the devs that work on these programs are doing so in their spare time for fun. If I built something and let it out into the wild for free, I would get discouraged if all I saw was a sea of bug reports and comments on how bad this program sucks. You’re getting it for free…. what did you expect???
Anyway, aside from my moral rant, that is how you get around the applet limitation with IFTTT! Stay tuned for automation part 3!