Smart Home 101
If CES 2015 proved anything, it's that the smart home market is a confused mess. Before you dive into the details of any solution, its important to have a high-level overview of the various components involved. Since Media Tuners supplies brands with a cloud platform, Web service licensing, mobile app development, firmware development, product planning, and project management, we have a fairly complete perspective on what's required in a home automation solution. The diagram below gives a good starting point. smart devices: the things in the Internet of Things, including light bulbs, switches, plugs, thermostats, smoke alarms, sensors, sprinkler controllers, and other devices. To be a smart device, it has to have some local processing power and some kind of connectivity to the outside world
mobile app: running on a smartphone, this is the primary control mechanism in modern systems. Ideally, the app will speak to devices directly, but in many systems, it must speak to a hub can speak the same radio language as the devices
hub: always-on device that translates commands to devices with proprietary radio formats and/or offers connectivity to the devices from outside the home
router: WiFi & Ethernet connectivity in the home and broadband access to the Internet.
cloud platform: a cluster of servers running on the Web directing traffic between home devices and the outside, including access to 3rd party Web services, backup, provisioning, automated & contextual actions, user account management, voice control, and other services
3rd party Web services: a wide range of data services which can be used for triggering events, sharing information, user context, radio and video content, weather, recommendations, and other services
The essentials of any solution are the smart devices and some sort of control mechanism. Recently, the control device of choice has become a mobile app running on iOS or Android smartphones. This (good) choice has specific consequences for the architecture of a smart home solution. Smartphones can only communicate via WiFi, Bluetooth, Bluetooth LE, or 4G. They don't natively speak Zigbee, Z-wave, or any of the other alternative radio protocols. So, for solutions that use Zigbee, Z-wave, or the like on the devices, a hub is required to allow the phone to talk to the devices. On the other hand, if the devices speak WiFi or Bluetooth LE, the phone can communicate with them directly and no hub is required.
A hub-less system has the obvious advantages of reduced system complexity and reduced cost. If the devices adopt WiFi natively, the system ends up being very flexible, but the cost benefit is eliminated due to the relatively high per-device cost of integrating WiFi when compared to the other radio technologies. That leaves Bluetooth LE (BTLE), which has a low per device cost and is native in the phone. Up until recently, BTLE was not as attractive due to its lack of mesh capability to extend the network, a problem that has been solved by CSRmesh with other vendors likely to follow suit soon.
A hub is also required if the system wishes to allow users to access the system from the outside world or allow Web services to interact with the system in realtime. In both of these cases, the system requires a cloud platform that the hub can connect to. This cloud platform can offer services as simple as firmware updates or as complex as off-board voice control and predictive modeling to automate home behaviors. As the cloud platform gets more complex, it typically will leverage 3rd party Web services to provide a more complete user experience.
Each component has hardware, software, and interface or protocols associated with it. So, for example, to create a smart light bulb that can be controlled both inside and outside the home and by automated Internet events, you need a hardware platform for the bulb, firmware to run on the bulb, a command protocol to run over the radio network to the bulb, mobile app software to run on the user's phone, a hardware platform for the hub, host application software to run on the hub, a RESTful or TCP socket interface to control the hub, a cloud platform hosting provider like Amazon, cloud platform software or software as a service, a RESTful or Websocket API to control the cloud platform, and licenses to various 3rd party Web services to flesh out the user experience.
It is important to note that while these components are all required, their form factors can vary significantly. For example, in the smart lighting example, a hub could just be a "super bulb" that speaks both WiFi and BTLE. Alternatively, the hub functionality could be blended into the home router or could be implemented as an app running on an old smartphone or tablet that is "always-on" at the house. There are many ways to implement these components, but they will all be present in the system in one form or another.