What Makes A Smart Home Device
SMART?
Looking to develop a Smart Device for the Smart Home? Since IoT smart home devices tend to be part of larger products or ecosystems, there are several technologies you will need to consider as part of your design.
The Starting Point
A smart device is usually responsible for collecting and acting upon information as part of a larger ecosystem. Understanding the scope of what that smart device must do typically drives the
early decisions in product specification development.
Four key questions
What kind of data will be collected?
What will trigger the device?
The answers to these basic questions will ultimately help define the design limits you will work within.
How much data will the device need to work with at any given time?
What other devices will it need to communicate with?
What is the overall power budget? This is particularly important for battery-operated devices.
When you build a smart home device, you have a lot of options.
Fortunately, you also have many partners who can help you make the optimal choices for your application.
At Silicon Labs, we provide our customers with support for every major protocol and application type. Our experts can help you navigate the complexities of smart technologies to find the solutions best suited to help you build compelling smart home products. Whether you’re building a smart light bulb or door lock, we have the end-to-end technology you need, from certified hardware modules to production-ready application designs.
LEARN MORE
to ask when designing a smart device
Many technologies are required
to make a smart device smart
Click any
icon to
learn more
Connectivity
Connectivity can be achieved through wired or wireless options. The choice may be made depending on product location and what other devices are communicating with the actual product. Depending on the application, some options may
be more suitable than others.
In general, products will favor wireless connectivity over wired connectivity since wired connectivity tends to impose greater limitations on the end user. In contrast, wireless communication provides greater flexibility in device deployment, allowing users to deploy smart devices exactly where they are needed and without the need for data cables.
Options in wireless technologies are numerous and allow developers to optimize designs and better meet their core design requirements.
If connectivity needs to span longer distances and penetrate solid surfaces (such as walls) while using minimal power, then sub-GHz radio protocols hold promise. If higher bandwidth is required in closer environments, then 2.4 or 5 GHz protocols may make more sense.
In general, products will favor wireless connectivity over wired connectivity since wired connectivity tends to impose greater limitations on the end user. In contrast, wireless communication provides greater flexibility in device deployment, allowing users to deploy smart devices exactly where they are needed and without the need for data cables.
Options in wireless technologies are numerous and allow developers to optimize designs and better meet their core design requirements.
If connectivity needs to span longer distances and penetrate solid surfaces (such as walls) while using minimal power, then sub-GHz radio protocols hold promise. If higher bandwidth is required in closer environments, then 2.4 or 5 GHz protocols may make more sense.
Options in wireless technologies are numerous and allow developers to optimize designs and better meet their core design requirements.
If connectivity needs to span longer distances and penetrate solid surfaces (such as walls) while using minimal power, then sub-GHz radio protocols hold promise. If higher bandwidth is required in closer environments, then 2.4 or 5 GHz protocols
may make more sense.
Sensors and Capability
The easiest question to answer is what kind of data will the device work with?
For example, will the device control temperature, vibration,
or humidity?
This question also requires an understanding of the device’s computational and storage requirements, power consumption expectations and connectivity bandwidth.
Interoperability
Devices may need to communicate with each other and therefore need to be interoperable. Typically, an ecosystem will define how these products will interact through device profiles. Device profiles are typically defined by the technology, such as Z-Wave
or Zigbee.
Services
Devices on a common network may not need to communicate with each other, but when they do, they will use common services to share data, commands, and actions (e.g.,
a device may permit a web server to allow smartphones to access them via web browser).
Services can also be mechanisms on which business models can
be formed. For example, instead of a small sensor device analyzing data, data can be sent to the cloud. This allows the sensor to more quickly return to a low-power sleep state, thus extending effective battery life. Such cloud services can be offered at a cost to the consumer or be part of the standard product.
Protocols
Protocols define how devices
can work with and alongside
other devices. Selecting standards-based protocols typically enables longer term interoperability with other vendors. This is because they are developed through an alliance of companies dedicating thousands of man-years into their specification. Proprietary-based approaches tend to offer greater optimization for given design concerns, but they don’t offer multi-vendor, multi-product interoperability.
Software
With the growing demand for interoperability and services, software is becoming increasingly complex to design and maintain. Reference software, provided by silicon vendors, vastly accelerates time-to-market. Silicon vendors tend to participate in the development of standards and have very large deployments of silicon using the software, making it well tested in real-life applications.
This enables developers to leverage this real-world-proven software as well as maintain and keep critical code up-to-date over time with minimal investment. Specifically, developers need only define the services required for their application and select the local silicon option in terms of memory and computing power that meets these requirements.
Energy Usage
While considering protocols, services and compute power, developers need to keep an eye on energy consumption. For example, some protocols can be extremely “chatty” while others tend to be much more “sleepy”. Most protocols have implemented various mechanisms to reduce power consumption. However, inherent network rules may limit how successful a given protocol may be when compared to other protocols.
For example, Wi-Fi has certain expectations of its clients. It requires them to check in regularly or risk being disconnected from the network. Given the high energy demand required for reconnection, a constant connection may offer a lower cost to the power budget. Other protocols, such as one-way proprietary links, need not implement such requirements.
Certification
Failure to observe requirements as laid out in a standard may invalidate a product’s certification with the appropriate protocol alliance organization. This in turn can prevent a vendor from advertising compatibility (and interoperability) with other products.
While some protocols require end-product certification to be performed, all radio devices must meet emissions testing to be used in given territories. Regulatory certification for radio products is complex, given that requirements vary from country to country and the fact that these requirements frequently evolve.
To address the challenges of certification, developers have the option of creating their own radio designs using ‘pre-certified’ modules. Pre-certification typically allows developers to use a module without the need to invest in niche engineering and regulatory bureaucracy. This, in turn, accelerates time-to-market, cuts costs, and reduces long-term investment.
Computing and Storage
The protocols and services required, as well as what data will be stored or analyzed locally, will drive the selection of microcontrollers and memory requirements for smart devices.
More complex network protocols and services may drive up the need for more capable microcontrollers or increased memory (Flash/RAM) storage, especially if the device offers superior functionality or services. Network coprocessors can
often simplify development in these cases.
Security
One key change that has happened over the more recent past is the need for product and device security. As the growth of IoT and Smart Devices continues, so does the opportunity for those with malicious intent to focus their efforts on this industry. Security is only as strong as its weakest link. Server farms have invested millions of dollars on back-end security and standards-based protocols to encrypt all wireless communication.
This leaves edge devices as the new weak link, vulnerable to exploitation of their ability to access servers or to direct user disruptions. Weak security in a low-cost node can be responsible for a large-scale impact across the larger ecosystem. This impact can lead to brand damage, loss of consumer confidence, and violation of data privacy.
The cost of implementing security early in the design process is far less than attempting to apply it during a later stage, and it is definitely less than the potential costs of legal consequences.
Want to learn more on how to create smart home products that work with any hub or ecosystem?
Register for Works With by Silicon Labs, a 2-day smart
home developer training event that will help today’s
design engineers get started on designing and
integrating products that work with Amazon,
Google, Comcast and many others.