Getting a Crestron Home Driver into Development
We regularly get contact from integrators and manufacturers about writing drivers; usually an email that looks something like this:
"We need a Crestron Home driver for the "ACME Super-Deluxe Awesomeness". It's used by everybody in my area and it'd be amazing if we had support for this in Crestron Home. Please let me know if you can do it and how much it will cost."
I've written the same reply to so many of these emails that it seems like a good idea to give the nuts and bolt of the answer here. So - here we go...
The bottom line - there is no short answer here, as whether one can write an integration driver for any home automation system is partly a technical question, partly commercial, and sometimes even touches on policy for the platform. The questions that need to be answered (in no particular order) are:
- Does the device have an API (Application Programming Interface)?
Fundamentally - if the "ACME Super Deluxe Awesomeness" doesn't have an integration API - i.e. there is no programmatic way of controlling the device, then you can probably guess where that leaves us. It's true that some, very simple, devices don't need an API - perhaps they're just controlled by a simple relay - but that leads to a different question (later) and this perhaps a very small edge case, in terms of what we're talking about here. - Is that API publicly available?
Many devices have APIs, but they're not all published, and sometimes they are actively kept hidden - such as in the case of Apple's MediaRemote protocol. Using the Apple example is intentional, as we've shown that this isn't necessarily a barrier to getting a working integration module, but the point here is - it makes the task considerably harder. This isn't related to the functions of the device either. Something like a power distribution unit may have very simple functionality - switching an outlet on or off - but to make that happen may require complex authentication or involve encryption to avoid someone switching things on and off when they shouldn't. Having the API/protocol documented is a key consideration here. - Is the API any good?
Not all control protocols are created equal. For every well designed, well implemented and well document protocol, there are many more that are badly designed, poorly implemented and the documentation is vague or just plain wrong. The better the API, the easier the task of implementing it for Crestron Home. - What's the development effort?
This is a function of different aspects but, primarily, how complicated the API is to implement and how much functionality is required. APIs requiring OAuth or encryption will be more challenging than one that uses a simple ASCII CR/LF delimitered protocol. A device that requires only requires turning on and off will be much simpler that a device that has complex audio DSP control. We can only estimate development effort once we have visibility of the API and an unambiguous specification of what is required - but this will generally be measured in man-days of effort.
These points have all been technical in nature, but that isn't the only consideration when we schedule work for a new driver. - Is development equipment available?
It's been done before, but writing an integration module against documentation only is a gamble. Inevitably, the first time you fire up a new driver you immediately find a fundamental issue with the communications. Having equipment to test against is essential. That doesn't necessarily mean you need a complete system - being able to test against the communications board of a display may be sufficient (as long as it can function without the glass). Some manufacturers are happy to provide equipment which makes things much easier. Some manufacturers aren't quite as accommodating - those manufacturers don't get a driver.
There is a middle ground where people offer to "be the tester". As helpful as this is, it's far less efficient than having the device in the development environment. During a day in development, we may iterate through 20 or 30 changes and being able to debug directly, watch the low level communications and identify defects in real-time is the only way to go. When it comes to beta-testing, then we welcome integrators who can really put a device driver through its paces. - Who's covering the cost?
One way or another, we need to cover the financial cost of the development effort (and testing, any peripheral equipment, rent, power, etc.) and this is where we can take two different approaches.
Our preferred approach is that we develop a driver, bear the cost of the development, and then recoup that investment through incremental sales over time. For this approach to be viable, we need to be reasonably confident that the finished driver will sell in sufficient quantity to - at least - break even, and if the product is particularly niche, or the development effort is likely to be very high with only limited sales, then the driver is probably not a good candidate for our work pipeline.
The other common option is for a manufacturer to bear the cost of development. They naturally have a vested interest in having their device supported in Crestron Home so that would open sales opportunities that would otherwise be closed. This then means that the module is free to use to integrators.
The least common option is for an integrator to cover the full cost so that they can have some sort of exclusivity over a particular device to create a unique proposition for their clients. The risk being that someone else could take a similar view and undermine that exclusivity. - Does it "fit"?
This is a particular consideration for Crestron Home. Crestron Home uses the "Crestron Certified Driver" framework for device drivers which you could look at as a driver being block of a certain shape that will only fit into the hole of the corresponding shape in Crestron Home. So - displays have one shape, cable boxes have a different shape and some things simply don't have a shape at all. To make things more confusing, Crestron Home does support some device types, such as lighting, HVAC or media streamers that aren't available for driver developers and have to be "baked into" the Crestron Home product. Lutron and Sonos are examples of this.
When we're looking at developing a driver, we can only do this for driver types that are supported, or try to be creative and fit an unsupported type into one of the supported types - for example - our NVR drivers are masquerading to look like cable boxes from Crestron Home's point of view.
Crestron Home is expanding the list of driver types all the time, so this constraint is gradually diminishing, and we also have a special device type called "Extension Devices" which opens up the opportunities for this that can't yet be accommodated by one of the standard types, with the caveat that Crestron Home doesn't really integrate these devices other than providing simple commands in sequences and via the UI. - Timing?
Sometimes the timing just isn't right. You may need a driver for a project right now and we may be able to develop a driver quickly enough for that need; but if Crestron have already got a driver in their development pipeline and, say, it gets released shortly after, the market for the driver vanishes over night. There's certainly something to be said for being first, but this is another angle that needs consideration.
If the answers to these items are generally positive, or if you'd like to discuss the possibility of having a driver developed for Crestron Home, then we would love to hear from you. Just contact This email address is being protected from spambots. You need JavaScript enabled to view it.
