What is SmarterHome?

SmarterHome is a Secured, Cloud-based smart home solution to control "Things" from anywhere. The solution is based on a Pub/Sub architecture results everything is a "Thing" - even your control hub! Each "Thing" can communicate with other "Things" over topic based message broker to control your light, temperature and more...

screenshot
screenshot
screenshot
screenshot
screenshot

"Things" talk to each other using MQTT protocol. The MQTT broker is actually a CloudMQTT server which handles commands & queries from any member of the network. Extending your network with more "things" no matter their location was never easier.

The MQTT broker is "Cloud Hosted" therefore accessible even outside your LAN, to anyone you desire! No need to expose ports on your personal router in order to control your AC from a mobile app.

Required resource's to run a "Thing" are low - aimed to run on most of the Cortex-M MCUs. Currently, the things are implemented on TI CC1350 LaunchPad connected to TI CC3100 Boosterpack supplying the WiFi Connectivity and requires ~40kB RAM and ~60kB ROM.

One of the coolest things we can add are voice controllers like Google Home or Amazon Echo. Adding them to the network of "Things" will enable voice control over the other things, like "Turn on the lights in the kitchen". You can even query the temperature in your bedroom and be replied with a metallic voice :)

The code of the embedded nodes & The dialogflow server (hosted by Heroku) can be found in our Github repository. You can find our project on Github

The Team

See who are behind SmarterHome

Xiaoying Riley

Adi Kadoche

Electrical Engineering MSc Student
Tom Najdek

Shachak Zicher

Electrical Engineering MSc Student

Insider to SamrterHome

Components
SmarterHome is built on several components
image

CC1350 Launchpad

The node SW runs on a CC1350 - Cortex-M3 MCU with BLE & Proprietary capabilities. It has on board LEDs - one of them is used as a connection indicator (the green) and another one as a 'light bulb' (the red). In addition, there is built in AON temp sensor used to query the temperature in your room!
image

CC3100 Boosterpack

The CC3100 Allows the node to connect to the internet using Wi-Fi and full TCP stack implemented on it. It is connected to the CC1350 with SPI + I/Os allowing the CC3100 to inform new data or events to the hosting MCU. Only required parts of the SDK (sockets, wlan and dns resolving) are enabled in order to lower the resources footprint.
image

Cloud MQTT

Cloud MQTT is a crucial part of our architecture - it enables a topic based conversation between "things", allowing them to communicate with each other based on the required functionality and scaling of consumers. For example, lighting the light in the kitchen can light as many nodes as you want, as long as they are configured in 'kitchen' location.
image

Google Home Mini

In Order to make everything much cooler, we added Voice Control to our "Things" network using Google Home Mini. As long as it's linked to your account, Voice Control is enabled for every Google Home (or any google assistant you have - even the one in our cell phone!).
image

Dialogflow

In order to have a conversation with your things and define the dialog flow and schemas of the messages, We used Dialogflow - A tool to define and structure common language dialogs. That's how we can teach Google assistant new locations, commands and more!
image

Heroku

In order to connect the voice control to our network as a "Thing" (and not as a control hub) we hosted RESTful API on Heroku platform. That's how your voice command transform from a regular json to the network's MQTT message. In other words, it is used as an adapter between Dialogflow and the Cloud MQTT.
Architecture
The basic architecture is quite simple - everything in the network is a thing, connected to the internet. Whenever a "Thing" wants to communicate with another "Thing" he simply sends a message to the message broker with the corresponding topic - resulting any subscriber which subscribes on this topic will receive the message from the publisher. In the following example, we can see two endpoints connected to the internet (even from different APs) through the Wi-Fi connection, enabled by the CC3100 board. Both of the endpoints are placed in the kitchen, therefore they subscribe messages related to the kitchen and more specifically, lights in the kitchen (as the endpoints demonstrate smart light switches). Whenever a message related to the topic "lights in the kitchen" arrives, all the consumers receive this message and handle it. In this case - they turn on the lights.
This architecture allows us to create a dynamic and remote network of "Things": you can build an app on your mobile phone in order to control lights - just publish the MQTT message to the write topic and every consumer that consumes this topic will act accordingly.
There are huge benefits of course - "Things" are accessible from everywhere as long as it's connected to the internet. Moreover, the "Things" hold a tcp connection to the MQTT server with keep-alive - therefore there is no need to expose (forward) any port from WAN to LAN (in order to "pass the NAT") and maintaining your LAN security.

Full Demonstration

Command
For our full demonstration we used the following setup:
As you can see, each time a speaker asks for a command, the google home analyzes the command's structure and (using dialogflow) creates a JSON with the location (kitchen), the device (lights) and the command (on). The JSON is sent to out web service running on Heroku dyno (through webhook supplied by dialogflow agent). The JSON is then translated into MQTT message (containing json with the command & parameters if there are any). The MQTT broker sends the message to the subscribing clients. In this case - nothing will happen to the lights in the living room (of course). As you can see, we easily adapted the Google Home Mini to be a "Thing" in our network, using a simple web service hosted on Heroku (same as for our CloudMQTT server).
Query
This time we wanted to demonstrate querying feature. The setup is slightly different:
This time, you can see a full round trip - querying results the same flow until the device receives the MQTT message. The Heroku know holds the response to dialogflow until a response is received from the endpoint. When the endpoint responds with MQTT message including the sentence to read to the user with a matching correlation id of the request, the web server matches the correlation to the HTTP session and responds to dialogflow, supplying the reply sentence to the Home mini and then it's speakers sound the response to the user. There is room to extend & enhance this flow - supporting multiple consumers query, crafting the sentence of the response in dialogflow instead of the endpoint and more...