3 Types of Software Architecture for Connected Devices. A Smart Light Bulb Case
Ubiquitous computing and the latest development in the miniaturization of electronic components for the smartphone industry have made it possible to connect any device to your smartphone and a cloud to integrate it with a myriad of online services. How do consumers decide what kind of connection a device needs?
Let’s take a regular light bulb — one of the most highly commoditized products on the market. At least it used to be so until LED technology gained traction and now we are looking at forecasts of 45% growth per year through 2020 in LEDs. Markets appear to be moving toward LEDs replacing 100% of existing technology including incandescent bulbs. At the same time, the whole new segment of smart home appliances, especially the smart light bulbs, emerged with the introduction of Philips Hue in 2012.
Now we are seeing dozens of smart light bulbs on the market with new players launching a crowdfunding campaign on Kickstarter or Indiegogo every other month. Let’s pretend we need to build our own smart light bulb and think about how to connect it to the Internet and to the user.
High Level Architecture for a Connected Smart Light Bulb
There are different ways to connect a light bulb to a smartphone and/or the Internet: smartphone dependent or smartphone independent; direct connection over Bluetooth/Wi-Fi; or connection through the hub.
1. Smartphone Centric Architecture (with or without cloud)
In smartphone-centric architecture a light bulb is connected directly to a smartphone via Bluetooth. Thus the light bulb doesn’t have a direct link to the Internet and depends on the proximity of the smartphone.
In this case the connection of the light bulb to the Internet is possible only through the smartphone. Consequently any smart feature that relies on the Internet is available only in close proximity to the smartphone. It’s like triggering an IFTTT action only when the smartphone is present in a Bluetooth range (up to 100 meters), because without the smartphone there is no connection from IFTTT to the light bulb.
The definite advantage of this architecture for customers is that they don’t need an additional device or hub for the light bulb to be connected but can control it from the smartphone. Furthermore, the setup process is quite easy and straightforward for the user, but it comes at the cost of dependency on a smartphone in order to connect to the Internet.
2. Hub-centric Architecture (with or without cloud)
The Hub in hub-centric architecture is working as an intermediary for connecting a bulb to the smartphone and to the Internet, since it usually connects to the home Wi-Fi or Ethernet network. A smart lightbulb is totally independent of a smartphone and could be smart on it’s own.
With the hub-centric architecture it is easier to organize the grouping and seamless connection of the many light bulbs and other appliances in a house. Every connected device can be controlled from anywhere and at any time. Background smart triggers, from integrations to the third party services (IFTTT, stock market dynamics, etc), are easily achievable, as well as controlling lights from any smartphone belonging to the home owners.
A device cloud in this architecture is optional because many smart features could be set up without having a dedicated cloud infrastructure. But with a cloud features become more robust and reliable because there is a lot more computational power available in a cloud for complex tasks than on a hub device itself.
The drawback of hub-centric architecture lies in the need to add another device to the system that needs to be delivered to the customer’s home and installed correctly.
And this is also the architecture broadly used by Google, Apple and Amazon in approaching the smart home market today. Read more on their hubs below.
3. Cloud Centric Architecture (without hub)
In the Cloud-centric architecture without hub we have a smart device that is directly connected to the home Wi-Fi network and doesn’t need any additional hub to work. It has a simple setup process for the customer and looks similar to the Smartphone Centric Architecture but with the benefit of a direct and constant connection of the device to the Internet.
Sometimes this architecture becomes similar to the Hub centric architecture in that there is a Master-Slave relationship organized with similar smart devices. The master device is connected to the internet through the Wi-Fi network and other devices are connected to the master and to one another with the mesh network (802.15.4, 6LoWPAN, etc).
The good thing about this architecture is that there is no need to buy and install additional devices (like with the Hub) while retaining a constant and independent connection to the Internet.
Smart Home Ecosystem Wars: Android Brillo + Weave vs HomeKit vs Amazon Echo
There is a constant battle of ecosystem platforms designed to organize and connect our home appliances. Such a platform is a necessary and required step before we can invent and build more services on top of the connected smart home devices.
Google and Apple are moving towards the Hub centric architecture with OnHub and Apple TV respectively. They both also have their own infrastructure ecosystems (Brillo + Weave from Google and HomeKit from Apple) that are aiming to keep customers locked within their walled gardens. Such an approach will allow Google and Apple to have full control over your home, know everything about you and your family and provide added services to you for an additional cost. This will be a good scenario with a recurring business model for them.
Amazon is also trying to build the same ecosystem with Amazon Echo and a fleet of third party connected hardware appliance. Eventually the result will be the same locked ecosystem for the consumer in which she can use content and services and buy her household products from Amazon. Another great concept from Amazon, which is currently tested only with its Prime Members, is the Amazon Dash buttons that allow users to buy products with literally one click of a button that is attached to a wall in the kitchen or bathroom.
As we can see, there is a real race between major players to connect all the appliances in our homes. They want to connect every device to businesses, services and people to provide a real value for us. Of course, this is in exchange for the data and opportunity to subscribe you to the recurring paid services.
UPDATE: While this article was being written, Amazon released the Lightning API for the Amazon Echo, which lets customers control lights and switches by speaking a command. If you are a smart light bulb developer you can benefit from such integration, which increases interoperability and gives a customer more options when using the device.
Final Thoughts about Smart Light Bulb Development
Having said everything about connected objects let’s make a final list of thoughts that could help you design and make a decision about a great smart light bulb product and other connected objects.
- Independent connection to the Internet creates the possibility to connect the outer world with your home. Better not to lock a device into a direct connection with the smartphone, because eventually all devices should be connected the third-party services and businesses to attract customers.
- Integration with big players’ ecosystems like Google Brillo, Apple HomeKit, Amazon Echo will leverage the power of common infrastructure and unlock interoperability with other smart things.
- Open developer API from day one and build a community of makers, businesses and people around your smart device product.
Let’s make the connected world seamlessly integrated with businesses and people.
If you like this article please help to spread the word about it and Recommend it. Thanks!
Stanfy is a team of passionate software developers and engineers that works in mobile and IoT and can help you to go through the necessary steps of software engineering, from prototyping and manufacturing to the market. Let’s talk.
Originally published at stanfy.com on September 1, 2015.