Smart Home Interoperability: The Key Hurdles

In Part 1 of this article, we scanned some of the existing approaches to connected home interoperability and explained why, despite progress, achieving coordinated smart home capabilities is still difficult for most consumers.

The Case for Device Application Programming Interfaces (APIs)

Before we identify and explain some of the key hurdles contributing to this state of affairs, it should be pointed out that devices in the connected home vary greatly in the degree of control offered, as well as the richness of data they provide. Some device categories, such as sensors (e.g., motion, contact, water leak etc.), report basic status or emit a periodic heartbeat to signal they're online. Since they don’t offer elaborate functionality, communication level compatibility with a third-party smart home hub that aggregates a device (or sensor) state is sufficient in most cases.

Other devices do require control capabilities and therefore expose functionality through an app of sorts, whether a dedicated one or one furnished by the hub vendor (some of which were discussed previously). On the other extreme are products such as connected cameras and smart thermostats that depend on cloud-based services to offer functionally rich apps for control and analytics. The important distinction regarding devices that offer a mobile app, speech or other automation hooks for control is that they hinge on some form of API.

What’s interesting about APIs, whether these are used to facilitate basic automation through the increasingly popular speech interfaces (Amazon’s Alexa and Google Assistant), is the degree of openness and documentation offered by device companies varies greatly. Roughly speaking, the industry seems to be split into several camps: companies that are completely secretive regarding the availability of APIs (even if they offer IFTTT or Stringify compatibility and seemingly use it as their "get out of jail free" interoperability card), those that restrict API use to an exclusive set of strategic partners and the expanding number of companies that take a more liberal (and should we say customer-focused) approach to interoperability.

In our assessment through a cursory scan of the industry, and through numerous discussions culminating at CES 2019, the latter approach is becoming more pervasive, and the cohort of companies designing products (and supporting services) for openness and integration is growing. Whether a device brand publicly advertises APIs for individuals and companies to build apps and support new Applications, or whether it offers full-fledged developer programs, the trend is clear, and quite frankly, it's a very positive development.

The diagram below provides a snapshot of currently popular device brands in North America and our cursory assessment of their interoperability
stance.

Image Credit: Plasmatic Technologies

Product and Business Strategy

Whether devices require a hardware hub (or “bridge”) for local access or internet-enabled connectivity, directly connect to the home WiFi, leverage another network (e.g., cellular, LoRa, etc.) or through a combination of such, users need an app to interface with the products and to operate them. In certain cases, for example basic sensors and connected light bulbs do not require a dedicated app, and pairing them via Zigbee or Z-Wave with hardware hubs is enough. In most cases, however, the vendor does provide an app that carries their brand, is optimized for operating the device and showcases differentiating features and service capabilities.

The development of full-featured, intuitive and visually appealing apps for both major smartphone platforms—iOS and Android—is not a trivial undertaking. Quite obviously, this investment and the ongoing cost and effort to maintain apps is not only critical to reinforce product value but also an important support platform for the brand and for promotion of additional products and services. As such, many companies take a rather protective stance of the customer experience and are cautious of third-party app integrations that may undermine app stickiness, eliminate the appeal of their app or reduce monetization opportunities that could otherwise fund operations, customer service and more.

Some vendors, even if integrations with major external interface such as Amazon Alexa, Google Assistant or IFTTT are available, refrain from exposing the APIs on which they were built. By taking this stance, these companies retain full control of the customer relationship, which is particularly important when the ongoing use of devices or certain features are delivered through a service for a subscription fee.

Unfortunately, not all consumers are enamored with products that impose recurring service fees, and some users can understandably be quite vocal if a vendor starts to charge for features (including integrations) that are expected as a key element of the product or worse, were previously provided at no charge. Furthermore, preventing integrations with other products or services may not be a sustainable approach since knowledgeable and motivated users eventually find creative ways to bypass those limitations and are often eager to share their achievements online, be it with various Facebook user groups, Reddit or Sourceforge, for example.

Security and Privacy

Brands are understandably protective of their hard-earned reputation and customer relationships. As such, the approach many vendors take to avoid security and privacy risks is to restrict remote device access to their app or constrain the interfaces to a very limited set of tightly controlled ones. There is no shortage of manufacturers that only offer interoperability through one (or at best two) of the popular voice interfaces and maybe even publish an IFTTT channel or Stringify flow.

On the other hand, the business potential from broad interoperability, specifically if such is delivered through cloud APIs can easily outweigh the cost of implementing proper mechanisms to provide, secure and manage access. To that end, manufacturers of both devices and ecosystems need to ensure third-party access is properly secured to prevent malicious use. In addition, design of access services should incorporate mechanisms to isolate partner activity from other interfaces, including the vendor’s native app (or apps), voice interfaces and other partners.

This ensures the activity by each partner can be tracked and limited as needed, including the ability to shut down a “bad player” (whether intentional or due to poor implementation) without impacting service to other partners or customers. Third-party access must also be done in a manner that seeks consumer consent in several areas, including data sharing, security and liability, especially if the functionality includes access to safety and security features delivered by those products, such as garage doors and door locks.

Lastly, modern user authentication methods increasingly leverage a framework called OAUTH which facilitates linking of a user’s existing accounts including social media, e-mail and popular connected home ecosystems. Since OAUTH enables the creation of automatically revocable security tokens between a third-party app and the provider’s software platform, it eliminates the need to store and protect user credentials, greatly improving security for all parties involved.

Technological Capabilities

In order to provide access to partners, the vendor’s software design needs to include APIs that are founded on a vision that supports scalable and resilient services. For example, exposing interfaces that embed efficient publish/subscribe messaging services rather than those that depend on repetitive and resource (and communication) intensive queries can have long-term consequences. Examples for such platforms are Amazon's Simple Notification Service, Emitter, Microsoft’s SignalR, PubNub and a host of others.

Ultimately, the design should support a growing number of partners and allow successful adoption by thousands if not millions of users concurrently accessing the system through different apps and interfaces. Designing these systems, including the microservices they enable for scalability and efficient use of resources, is not a trivial software engineering undertaking, nor is it a business decision that should be taken lightly, given the financial and operational implications.

Over the years, as adoption of connected home and mobile devices grew, cloud service economics changed, and related technologies evolved, consequently morphing best practices. Certain approaches that were state-of-the-art several years ago are no longer operationally and economically viable now. The once standard multi-tier architecture implemented with virtual-machines gave way to container technology, and while still suitable for many applications, it is increasingly overshadowed by the accelerated adoption of serverless computing.

For brands that do not have the capacity or aspirations to build elaborate software practices, it may make sense to partner with an IoT platform specialist that would offer many of the required capabilities as a service, such as device firmware, fully functioning apps, APIs and more. There are countless IoT platforms in the market, the majority of which have an industrial or M2M focus. The list of companies that already enable consumer-grade connected home brands seems to have gotten longer in recent years. Some of these (alphabetically) are Ayla Networks, EVRYTHNG, Greenwave Systems, iDevices, meShare, Prodea, Tuya and Yonomi.

While such a decision can have far-reaching implications that are further detailed below, it is a valid option for many; it's certainly superior than trying to deploy a service that lacks the security and reliability consumers expect.

Before choosing which technology approach to take, device vendors should consider the long-term and strategic implications. On one hand, there are shifts to alternative interfaces, such as voice and the role of AI. On the other, business opportunities facilitated by interoperability can traverse beyond the connected home space into adjacent industries, including home security, communication, utilities, insurance and more.

When choosing a software stack, cloud service provider or IoT platform, partner brands should incorporate considerations spanning software engineering complexity, risk of vendor lock-in and the operational and financial aspects of consuming IT resources for the expected life cycle of the products in question.

Operational Flexibility

Not all companies operating in the connected device space are created equal. Companies that are born into this domain benefit from the flexibility of building software operations that leverage modern cloud technologies and are optimized for the agility needed by a new business. Established brands that enter the connected home arena by supplementing their existing product portfolios have various constraints to contend with. Many of them partner with external app developers and specialized IoT platform vendors such as those mentioned above. Whether these decisions are taken due to core competencies, the need to move fast, or the desire to innovate without distracting current business, they continue to make sense for some companies.

Whatever the reason, product companies that rely on external technology providers may eventually find that their technical and business agility are constrained, requiring them to be more selective when exploring opportunities for partnership and innovation.

Another phenomenon that seems to incumber various connected home products is the roll out of devices (and their supporting apps) without enough planning for integrations, flexible business models or development of value-add services and revenue streams to offset operational costs. In some cases, established brands as well as device innovators that were successful in their respective crowdfunding campaigns found themselves struggling to sustain all the software and service components required by the device, and at times, they succumbed under the burden of these accumulating costs.

In recent years, industry maturity yielded a paradigm shift in this area. For example, service plans for retention of video, advanced analytics and security, such as those offered by Arlo and Ring, have been shaped as the norm for connected camera providers, generating crucial revenue streams to run operations and to grow their business. In other situations, decisions to charge a nominal subscription fee to support certain integrations, such as that done by Chamberlain, despite initial consumer backlash, seem to be gaining acceptance, judging from the discussions on Facebook user groups dedicated to smart home automation.

Developer Support

The “works with” mantra illustrates affiliation with leading brands and provides the highly desirable network effect that helps promote product sales. As such, vendors should generally be seeking to facilitate interoperability opportunities if these can offer complementary solutions, whether add-on products that provide additional value or service offerings that can be layered in a manner that reinforces the core value of the product. To do so, a device vendor should encourage app developers and other service providers to sign-up for and use published interfaces with the least amount of friction, so they can quickly assemble solutions that leverage the devices. This assumes of course the services were designed in an operationally and financially scalable manner.

Image Credit: Morty

Whether these interfaces are APIs with basic documentation or a full-fledged software development kit (SDK) with code samples and troubleshooting information, the provider must examine ways in which developer relationships can be sustained without imposing an excessive burden on the organization.

Developer support, as well as access to the services, should be constrained with established expectations. For example, self-service support including online communities would reduce the staff required, and the quantity and frequency of API calls, as well as the traffic these generate, should be capped. Transparent and easy-to-follow (and ideally tiered) programs covering pricing of API usage, partner benefits and other criteria are also the signs of a company that has a mature stance towards building a partner ecosystem.

Conclusion

With industry research indicating close to half of U.S. households have smart home devices, there's no doubt the accelerated adoption of connected home products, particularly in North America, is reaching the mainstream.

The long-term success of connected home technology is predicated on overcoming the current market fragmentation and resulting disjointed user experience to provide homeowners with meaningful functionality they can rely on. Intuitive, intelligent and automated capabilities that hinge on interoperability between various brands need to exceed the discrete function each device or sensor provides and manifest the value people expect from the technology. Holistic whole home understanding and control is key to enabling the multiple benefits that underscore the smart home promise, spanning intuitive safety, comfort and efficiency.

To do so, the industry should strive to employ best practices and efficient methods for API and data exchange, supported by better documentation and usage metering to allow the exchange of value, be it monetization of API calls or the responsible consumption of valuable data devices and sensors generate.

Companies that embed application-level interoperability as a key tenant of the product and corporate strategy cannot only transcend the effort, cost and complexity required but yield a superior market position. This will not only help them reap the business opportunities enabled through partnerships, but it will enhance their ability to protect against the increasingly dominant forces of big tech companies.

Written by Adi Kabazo, VP Marketing and Alliances, Plasmatic Technologies