When incorporating smart devices as part of your business strategy, the device maker has a significant impact on your ability to execute successfully. When looking devices, there are some key considerations to help guide your decision:
a. Market penetration can be a good indicator of longevity but not always
b. Look for smart device makers; avoid marketing companies. For example, mall-based gadget stores outsource their products and, as a generalization, are not reliable IoT device makers.
c. Technical Support and reliable support channels/response times are critical for your business.
d. The best device makers are focused; making lots of different device types by nature means less focus on each device. Nest vs. Wyze
e. Diversity of device brands is actually a good thing (see below)
f. Find out where the company is based. Is it geographically located in a country that has reliable data privacy standards? If not, you should consider the associated risks.
g. Find out where the data is hosted. Ensure there are processes in place to protect data and ensure the privacy of your user data.
h. Test devices, device apps, and all APIs available for a device. If you are concerned about quality, response times, user experience, etc., dig deeper and compare to alternatives
There are several popular communication protocols used by smart devices to communicate within a home/business/space. ZigBee, Z-Wave, Thread, and Bluetooth Low-Energy are all options for device makers to use when building their devices. They're all great. You can trust that device makers will make the right choice for their device. But on which standard should you standardize?
My answer is none of them. Or all of them. Because the local communication protocols don't matter all that much when using smart devices to facilitate business operations, moreover, the pending and already popular Matter standard will simplify this choice in the future, when all devices will communicate with each other and the apps that support them in symphonic perfection. What is important is the device's ability to communicate over the Internet, allowing for remote control, remote events, and regular dispatch of important information meaningful for business purposes. Businesses should choose the best devices that serve their purposes, and the cloud-accessible capabilities of those devices allow the business to rely on them for operational use. If the device does not expose itself via a cloud-based API, it simply cannot be effectively integrated with your business strategy.
Walled-garden providers look to satisfy all your device needs, so you don't need to source devices from anyone else. Devices in walled gardens typically work well together from unified interfaces, and walled-garden providers may even support cloud-based APIs for integration. Perfect...?
Choosing a single device maker to source all your devices is an easy decision. If a company makes a good smart thermostat, the smart lock and noise sensor are probably just as good, right? Well, maybe. The fact is, making hardware is... hard. It's not typically a high margin for makers, and smart devices require after-market support that can eat into profits. Specialization still has significant benefits in smart homes, and companies that diversify too much run a very real risk of making subpar products as compared to the market-available alternatives. Indeed, many companies who don't specialize up-front end up looking for cash in later stages to fund their expanding support, maintenance, and supply chain needs, resulting in them having to revisit pricing to support their business.
But what about the companies you trust consistently make solid products across categories? Unfortunately, there still lies a risk of being a hostage of a single-source strategy. Companies discontinue devices that don't gain market traction—even if they're great products. And, support for discontinued products is finite—it eventually ends.
Even worse than discontinued products is a decision to simply change strategy. Some of the largest and most popular device makers have simply cut the API lifeline to dependent businesses to support changing internal business conditions. This leaves field devices stranded, and having built to a single-source API, a full migration of hardware and software is a ruinous proposition that some companies have suffered based on their decision to single-source.
Diversity in device mix and selection is a smart decision. Not only does it help shield a business from the turmoil device makers will face in the market, it also ensures your customers have a choice in the selection process and can migrate without heavy lifting if necessary. But to achieve this, businesses need to use APIs that standardize and commoditize the downstream device integration. In this way, if a device maker sunsets a product in the mix, customers can simply replace the devices and configure them for use with minimal to no code modifications.
This may seem like an overstated point, but there are "smart" device options in the market that can take inputs but cannot send responses (think TV remote and TV or IR Blaster-controlled window A/C). These devices can be instructed to perform a request, but they do not respond if the request was successful. They also can't provide notifications when they are manually controlled, not from an API-based request source. These devices are half-smart. The user experience is subject to be poor and inconsistent where devices rely on one-way communication.
One of the more important factors of working with smart devices in the real world is considering the device's operating environment. Smart locks are subject to myriad climate conditions and physical environments throughout the world, not the least important of which is the need for internet connectivity.
While we enjoy stable internet service from our computers in indoor comfort, smart devices are subject not just to potential constraints and blips in Internet availability but also to wild temperature swings, rain/snow, physical abuse, and even battery challenges.
These conditions require us to account for them in IoT integration to optimize the user experience. Smart device integration benefits from an asynchronous interaction model between cloud, device, and user/app experience. In this model, API calls made from the cloud to the device are non-blocking, and the cloud can receive a response after the device has successfully processed it. In this model, if the device takes extra time to respond due to environmental conditions, the user experience doesn't suffer, and retries can be used where a device fails to respond in a timely fashion.
This design approach doesn't mean IoT devices such as locks should not be expected to lock/unlock immediately when requested - they certainly should. The asynchronous model affords a more robust mechanism for handling any issues that could arise in communication with real-world devices.
The good thing about smart devices is that they can receive firmware updates that can enhance their features and offer owners more over time. When integrating with a device, keep an eye on the device roadmap and API updates to determine when you can take advantage of these new features in your solution.
An important point to keep in mind as you evaluate smart device makers: Cloud-connected smart devices cost something to operate, even if it's fractions of a cent to remotely turn on a light or lock a door. Those costs add up over time, and their real. We call this "cost-of-cloud" - or the real, long-term operating cost to support devices in the field for the life of the device. Imagine a smart lock that is locked/unlocked a few times a day, reporting its state to a cloud-based device shadow so that when you open your lock control app you can immediately see the state of that lock. Each time that lock transmits its state, it costs some fractions of a cent. We can assume for this example that over a week's worth of time, locking and unlocking has a cloud cost of 0.7 cents. That's nothing, until you think about the fact that a lock is expected to operate for no less than 10 years, and often owners expect much longer than that. That 0.7 cents a week times 520 (10 years worth of weeks) means that lock cost $3.64 to operate for 10 years. Now, if you're a successful device maker selling 300k last year, you've also incurred at least $1.09 million in cloud costs over the next 10 years.
A straight-forward solution for device makers here is simple; consider cost-of-cloud a part of the bill of materials and account for the expected cloud cost in the price of the device. If you buy a device and it doesn't include a subscription to use it, that SHOULD mean the cost is already accounted for in the price you paid for it. This also means subscriptions aren't always a bad thing; if a device has a reasonable subscription fee then it should also have been cheaper than alternative products to get to market.
A troublesome problem that plagues less experienced IoT devices makers is the added aftermarket subscription fee. When not account for, these fees are typically added just to continue to use the same functionality that was free when the device was first released to market. This trend shows there are cases where less planning and foresight is being done by device makers to account for the cost-of-cloud (among other costs). It's important to look into the operating lifespan of a device and if you can ask the device maker how cost of cloud is recovered. If they don't have an answer, look out for subscription fees in the future.
The IoT industry is certainly subject to the theory of natural selection, and every year device makers come and go into the market. There are plenty of enduring brands building great devices, so this isn't a reason to be fearful, but it's still important to plan for the worst-case scenarios that can impact business operations. One of those ways is to have a diversity of devices available to support your business goals. Another way is to build interactions to devices using APIs that allow your code to run with little to no modification regardless of device brand. Yonomi Platform is particularly suited to support this contingency.
Quality will continue to be an important factor in selecting the devices to meet your business goals. Be critical of device makers that sell the app and cloud along with the device, especially if you're looking to source thousands of units or more for your business. In these situations, you are essentially outsourcing device manufacturing to a 3rd-party, and the results are often undesirable and result in significant cost and vendor lock-in for sub-par products. Relying on the open market to reveal the products that yield the highest customer satisfaction and quality assessments is a good way to filter the selection process.
Let us know what you think!
Yonomi is the fastest way to integrate your application with smart, connected devices to your property management, energy management, wellness, and insurance software applications.
Our mission is to enable and accelerate the building and delivery of rich, smart home applications for solution providers. To do this, we’ve built an IoT Platform connecting to 100+ mass-market consumer devices and devices required for specific vertical industry use cases that is traits based, so you don't have to worry about an evolving IoT Market.
If you are interested in testing the platform, visit our developer portal.
Alternatively, if you would like to speak to someone and take a deeper dive, please schedule a meeting directly with our sales team.
Check out our other posts on IoT Platforms, IoT Integration, and the best smart devices.
IoT Platform Examples
10 Things You Should Know About IoT Security
10 Things You Should Know About IoT Integration
Schlage Keyless Entry for Vacation Rental Properties
How to integrate a Schlage Encode Smart Lock
Best Smart Devices for Vacation Rentals
What is an IoT Platform?
Schlage Encode: A Great Smart Lock for Vacation Rental