Creating the Smart Home Universal Remote

It’s been a while since I last made a smart home device, not because my home is fully automated or because there wasn’t a need for another device, but because I still live in a rented unit and didn’t want to to spend the time making and setting up custom devices that would need to be torn down in the future.

Well the other day I realized that I could build another home automation device without a long-term stationary placement requirement! Not too long ago I built voice integration into my smart home system using the Amazon Echo (check out the articles here). While this worked well for moments without ambient noise, it failed to work well during parties, while watching movies, or while listening to music on my sound system. Obviously I needed another way to interact with these smart home devices and the current method of pulling out a phone or tablet, unlocking it, then switching between apps just didn’t appeal to me. What I really wanted was a universal remote that could also talk to my smart home devices.

So I started designing and planning out the features that I would want in my smart home controller and it had to be wireless charged (because replacing batteries or being tethered to a wall is archaic). Here’s the requirements I came up with:

Essentially, the goal is to get it all placed inside of an enclosure like this:

universal-button

Here’s a video of the very early prototype’s functionality:

As well as a more in depth Hackster post:

https://www.hackster.io/anthony-ngu/universal-smart-home-remote-wirelessly-powered-896f3c

Unboxing the Bluz Dev Kit – Kickstarter

logo_nobg
In April of 2015 I found a Kickstarter called Bluz which offered a cloud-connected Bluetooth LE development kit that could be run off a coin cell battery for months or even years on end. The Bluz is very similar to a product called the Particle Photon released earlier last year and the Photon has quickly become one of my favorite development platforms for developing Maker projects. I figured that a Bluetooth LE dev kit would be a great addition to my maker tools.
DSC_5101.00_00_11_32344.Still001
After a bit of wait, it arrived on my doorstep and I figured that I would record an unboxing video and a simple test with the Bluz.
Since I pledged $49, I received what they call the Wearables Kit which included one Bluz dev kit, a Coin Cell Battery Shield and an Accelerometer shield.
sparkfun_imu
The accelerometer shield that I received was not a custom Bluz created one, but actually a Sparkfun branded shield that I had already purchased on my own (an extra never hurt).
battery_shield
The coin cell battery shield is unique to the Bluz and allows it to be powered off a single coin cell battery. Included in this shield is an on/off switch that is surprisingly missing from the number of other battery shields that I’ve bought and tested.
bluz
The Bluz itself looks very similar to the Particle Photon and actually has the same footprint so that it can take advantage of the same shields as the Photon. It even piggybacks off the Particle’s online development tools and the same deployment pattern (aside from the need to be hooked to a gateway that I’ll talk more about later). One big difference in the immediate presentation of the Bluz is that it does not have a micro USB port for powering it. This is partly due to the fact that it can supposedly last longer periods of time on very little battery and its primary purpose is to not be continually connected to an outlet. The’ recommended method of powering it is to use the coin cell shield, or the VIN, or 3.3V pin
For my unboxing, I didn’t have a method of powering it through the Vin or 3.3V pin directly or a coin cell battery lying around, so I decided to use a Particle Shield Shield in order to breakout a DC Power connection (which ends up powering it through the Vin pin anyways).
The major thing to know about the Bluz is that it needs to be connected to a gateway or the Bluz iOS or Android apps in order to communicate to the cloud. While there are plans to open source the iOS and Android connection code, they haven’t been released yet and this is a pretty big limitation for anyone like myself that wants to use a direct communication line between Bluetooth devices and the Bluz. However, Bluz sells a gateway shield that can be attached to a Particle that allows up to 8 Bluz to connect to it and communicate to the cloud.
gw_shield
Also, I have yet to test out the claim that it can last months or years on a single coin cell battery, but will be using it future projects and will be testing this out. There is one difference in the code that supposedly helps the Bluz achieve this feat. The code inside the loop function contains a System.sleep call in the default sketch.

I expect the Bluz to be a worthwhile investment and can’t wait to see what kinds of projects I can build with this low powered Bluetooth LE dev platform. I love that they leveraged the Particle ecosystem and online development IDE as well.

Youtube Video Efforts & LED Mask

Lately I’ve focused more of my efforts on Youtube videos for the side projects that I build. While I enjoy the process of writing blog entries, I also found that I enjoy the visual draw and documentation capabilities that Youtube allows me for the generation process of my side projects. Through the provided analytics I’ve been able to see that the videos I make generate higher engagement, but the value of written posts in providing engagement for text and programming related questions and solutions is undeniable.

The latest video I’ve posted to my Youtube channel is about the making of an LED mask. I have thought about the project in the past and this October I decided to build one using a Particle Photon as the controller. Due to the spacing of the Neopixel LEDs on the strip (60 LEDs per meter) I decided to interlace the strips with an offset.

For those that don’t know, Particle was previously called Spark and I had used their first product, the Core, in the past before the Photon was released. The Photon is evolution of the Core. While much of the platform has stayed the same (both the good and the “could improv), it remains one of my favorite hardware development boards due to its size and capabilities. I’m looking forward to the upcoming release of the Electron that I backed on Kickstarter.

If you want the code for the LED mask, you can find it here.

Open Smart Hub

Ever since February 22 when I entered the Hackster Hardware Weekend in Seattle, I’ve had a growing passion for the open source side of home automation. What started as a simple idea to automate the closing and opening of windows became something bigger than I ever imagined.

The Hackster.io Hardware Weekend was how the Open Smart Hub was born. I started with a hacked together hub that could run on the Intel Edison and automate a servo to act as the window opening mechanism based on WeatherUnderground API information or light/motion from a Spark.io Core (now named Particle.io). Once the event finished I realized that my implementation couldn’t scale and was horribly confusing to recreate.

I began to research the implementations that were available to the public. What were the open source options? What were the professional products? How did they succeed or fail to solve the problem? My conclusion was that the home automation space was cluttered with all the different companies, organizations, products, and applications. What we as consumers and I as a programmer needed was a simple platform to expand, integrate, and customize my personalized home automation experience. IFTTT is a great alternative but it is impossible to add your own devices, actions, functions, etc. There is no communal collaboration! If you added a device and someone else wanted to use the same sort of device, they would have to recreate it themselves.

That is when I began to reimplement the Open Smart Hub with a modular design. I chose Node.js as my platform because of it’s low barrier to entry for programmers, abundant tutorials, and abundant library of open source modules. The core of the new implementation is the configuration file that declares the available device types (think WeMo switches, Hue light bulbs, Nest, Weather Underground data, etc.) as well as a user’s stored scenarios and devices. I chose an implementation where you could fully own and have the ability to control everything. After all it’s your home!

The implementation is split into two parts, a local hub run on a Raspberry Pi 2 within your home network which handles all the interaction between your devices and an online hub that gives you an accessible UI from anywhere.

Here’s a demo of a basic scenario implementation:

If you would like to check out the details or learn more check out the Hackster.io project: http://www.hackster.io/anthony-ngu/open-source-home-hub