This is how it was left hanging for about a week before I bought an electrical box at a nearby Home Depot that would fit next to my original electrical box so I could begin mounting it. Steps for the finishing touches were as follows:
Cut out a bigger hole in my drywall (making sure that it was still small enough to fit under the included mounting plate)
Mount the transformer/relay next to the original electrical box. (Something to keep in mind: Double check to see if your original electrical box is bigger than its opening. If it does, you will most likely not be able to place another box right next to it without have to do some patching of the drywall after)
Paint over any small marks or discrepancies with the mounting so that it would look as good as new!
The bigger hole was still small enough for the face plate to cover (included with the Nest) and I was able to paint over the edges to make it look as good as new!
I recently decided to switch my old thermostat to a Nest and figured that it should be easy considering my current thermostat just controlled a simple electric wall heater. Unfortunately, it was only after taking my old thermostat off the wall that I realized that it was in fact a line voltage thermostat (Honeywell’s T410AA), which means that it uses high voltage (240 V) and acts as an in-line switch between the electric wall heater and the power supply. The problem with this is that systems like the Nest run off of low voltage (24 V) and can’t be used to switch a high voltage system.
To fix the issue I started researching. Surely I wasn’t the only person who wanted to switch their old school line voltage thermostat with a Nest! Unfortunately, a bunch of the solutions were on Nest’s old community site which had since been taken down. However, I was able to find out about a relay/transformer that according to the reviews should be able to bridge the gap between line voltage (240 V) and the typical low voltage setup used for modern thermostats like the Nest (24 V). The schematic for it shows the method for hooking it up to known thermostat wires.
The Aube Relay RC840T-240 does exactly that. It takes 3 wires carrying the line voltage (connected to Black, Blue, and Red) and then connects them out via 3 wires (R, C, W) carrying low voltage. This works to connect the line voltage wall heater with controls from the Nest system.
After connecting everything up, I tested the Nest to see if it worked and low and behold! It worked like expected. The only thing left after wiring and testing the setup is to mount it properly. However, the relay/transformer does not fit inside the original electrical box so I will need to devise a workaround to get it to all fit within the wall up to code.
Read the Continuation here: http://blog.anthonyngu.com/2017/01/10/finishing-touches-installing-nest-w-line-voltage/
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:
LED Screen to provide visual input (battery life, device selected, value selected, etc.)
Neopixel Ring (because who doesn’t love feedback through colors?)
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.
I got an invite to buy an Amazon Echo a while ago, but didn’t want to purchase one because it didn’t seem particularly useful. It’s only advantage to me was the SDK for speech that might be of use in the future.
After seeing the initial intro video and how scripted the commands had to be, I couldn’t justify the purchase.
If I wanted to get answers to questions I have, I would just pull out my phone and type it out rather than dealing with Speech-To-Text inadequacies when asking a long question. If I wanted to add something to a list, I would write it down on my notes or use my phone for the same reason.
I could play music using a voice command, but to be limited to my Amazon Music Library, Prime Music, or Pandora? No thanks, my audio receiver will do a better job with the audio quality in my home anyways.
On top of that, waiting for a delivery date a couple months later? No thanks.
The Turning Point
That was it, I forgot all about the product until recently. That was when I saw a couple Youtube videos showcasing hacks of the system to configure voice commands for other things! Now this is where it really gains some useful functionality.
Imagine using the mic array and speaker in the Echo to pick up your voice commands and give you audio feedback to commands you create yourself. As a developer, this would have unlimited possibilities in the home! My heart skipped a beat once I saw someone using it for these purposes despite the lack of an official SDK and I immediately started imagining the improvements I could make to my current projects in the home automation space and quickly came up with a couple scenarios that I “need” it for.
There are the typical scenarios like turning on or off appliances and lights in your home, but then there are bigger home automation scenarios where you would communicate with the Echo like you would a personal assistant.
Imagine waking up in the morning and talking to Echo and having it relay specific things you care about like the weather, news, calendar updates, family updates, etc. while also having it turn on the shower so it’s running at your preferred temperature by the time you jump in. Have it make your coffee so that when you get out of the shower, it’s ready. No need to preset things the day before, or stick to a generic schedule. It’s all voice activated.
Now imagine coming home from a day at work and asking it to turn on a specific “mood” for your home, like “summer breeze” that would open your blinds, open your windows, put on some light music, turn on just the right amount of lighting, etc. Have your home work for you!
It looks like Amazon is starting to see the value of this use case with the Echo too, because they recently announced an update that would allow their default voice commands to work with WeMo switches and Hue lights, but those are just basic scenarios.
After all my excitement about being able to create custom commands, I decided to purchase one (despite the couple months I’ll have to wait to finally receive it).
Still a Couple Faults
Works well for one room or an open-concept home, but you’ll need separate ones for each room if you want it to work everywhere. (Or maybe an extension of it in other rooms?)
From the demos online where people use it, it looks like their speech recognition system isn’t up to par with most of the other speech recognition system, yet.
I had the chance to participate this past weekend in a Hackster.io Hardware Weekend in Seattle and was blown away by the setup. Like most hackathons, they had big sponsors like Intel, Microsoft, Spark, AT&T, etc. However, unlike most of the software hackathons I have been to, they provided some hardware for people to use including Intel Edison boards with Seeed Studio Starter Kits and more. They also provided some cool and useful swag like a portable charger (which I used to power a Spark Core for my demo) and a small portable Leatherman pocket tool that is perfect for my recent maker lifestyle. The energy they provided was just spectacular and even though it was their first time hosting a hackathon, I think it went smoothly.
The food wasn’t just your normal pizza and salad hackathon meals. It also included a legitimate breakfast with bacon, eggs, bagels, cheese, etc. Lunches and dinners were comprised of delicious sandwiches (kind of like Banh Mi), mexican food, and one meal of pizza. On the side they have a whole bunch of candy, popcorn, and more snacks along with the steady supply of coffee, soda, juice, and water.
Unfortunately, like with most hackathons, the crowd of participants thinned out by day 2 with most of the remaining people being interested in learning more or deeply involved in the hacking process.
I came to the event without a clue as to what I was going to build and not really sure if I wanted to join a team, make one, or run it solo. After hearing about some of the prizes for using certain APIs (Weather Underground and WebRTC) I decided to focus my time on the Weather Underground APIs. Even after deciding what I wanted to use, I didn’t really have a clear understanding of what my final product would be and how it could change the world. I just decided to start hacking something together that I thought would be cool to own and ended up going down the path alone.
Stages of my Creation:
Started with the idea to read the forecast for the day and display it to you through an small LCD screen so that I wouldn’t need to pull up an app to view the forecast. Decided to use the Intel Edison, Cylon.js, and the Weather Underground APIs to do this.
Added functionality that would open your windows using a servo if your indoor temperature was past your comfortable zone and the outdoor temperature was colder. I also added functionality to change these settings through buttons and rotary angle sensors on the board.
Added functionality to push the data to the cloud
Realized that I could also connect to a Spark Core and communicate with it via WiFi and the Cloud from the Intel Edison, so I integrated a lighting scenario with a wireless connection.
Created a prototype case for the now deemed “Hub” in Autodesk Fusion 360.
Created a webpage using AngularJS on Azure that would showcase the data my back-end was receiving so that I could view information on the go.
Some things I’ve come to realize for my next hackathon:
Work in teams! I worked solo this weekend and although I did a lot of work to combine all the components, I definitely could have gone further with the idea and took it to the next level ending up with a professional product rather than a hacked together demo.
Set up a team before hand and know the expertise of everyone in the team and how best to leverage them. (This also might mean vet out the people who might have less to contribute if you are going hardcore)
Sometime’s it’s more about the presentation, the story, and the idea than the execution during the hackathon (although that might be due to the hardware nature of this hackathon). After all, you only have so much time both to hack and to present your creation.
Network! This is really just a great opportunity to meet other people in a related field and find out their skills and platforms of choice. Who knows? You might find a couple new tools that might be useful for your future endeavors.
Roll with it. A vision is great, but be able to adapt if things don’t work out quite like you expected. Sometimes code breaks and it can be stressful but learn from it and debug better.