Device Integration Dos and Don’ts: Programming Solutions, Module Development and Manufacturer Support

When does it matter how a driver or module is developed for a manufacture’s device as long as it works? How do you know if you are working with an authorized third party interface or not?

High tech products are more readily available to users, remote control systems and programming are more mainstream, and devices are more software-driven and customizable. This means that a supported API can be the difference maker in the adoption and effectiveness of a manufacturer’s product.

It’s All in the API

Although the use of an unofficial or unsupported control interface can lead to a desired result, in lieu of an official API or control module, it is not only a difficult development task, but can be rendered useless at any time if the manufacturer chooses.  A third party interface is effective because it is supported by the manufacturer and the manufacturer has made a commitment to maintain its usefulness and effectiveness for third party integration.

In a recent article focused on challenges related to Nest integration, CE Pro identified where and how breakdowns can occur between hardware components and system integration when a manufacturer does not make an authorized and supported API available.

Sustainable Software Solutions Start with Manufacturer Partnerships

In our experience, we understand how manufacturers can benefit from a consistent, robust API that is sustainable for the life of the product.  Taking it one step further, the value of a supported, proven, documented, control system certified module or driver can overcome the need for technically challenging programming and lead to ease of adoption and integration.

At Control Concepts, we have been asked about “scraping” a webpage to provide control functionality in lieu of an API.  We discourage this approach.   Jeff Mackie, our Director of Product Development, warns that this approach is unstable.  His argument is that if anything on the webpage changes, we can no longer communicate effectively with devices to keep the system running smoothly.  Further, and this is important for DIY solutions and custom solutions across the board, to achieve the essential feature of stability across the life of the product, developers should use standard formatting like XML or JSON.  Standard formatting allows for flexibility as well as stability, adding the value of custom solutions to integration while preserving the reliability and essential functionality of the products.

Test Firmware and Modules to Prevent Breaks

We have encountered situations in which firmware “breaks” something and control or functionality is impeded in cases in which the manufacturer is trying to support external control.  Consider what would happen if external control was not taken into consideration.  At anytime, either intentionally or not, a manufacturer could make changes to firmware rendering the external control or module useless, and wasting a lot time and effort.

Use Programming to Support Product Adoption
Taking the time to design and support a robust API is key to product adoption and product success.  For a manufacturer, a relationship with a control system programmer helps to provide the security and confidence needed to allow their product to work well.  As such, external control enhances product capability and market acceptance.  A third party control module or driver minimizes the variables in integration, limits the support needs, and ensures that the product is represented in the ways that the manufacturer intends and users want.