We’ve been getting an increasing number of why don’t you support device X type questions, where X may be a particular Z-Wave device, INSTEON device or some other hardware. We're going to give a short(ish) answer here and link to a longer version in another blog post. The goal of this post is to shed some light on the process of adding devices.
Adding devices requires a varying amount of work in Indigo for a variety of reasons. What may appear to only be just a "5 minute feature" is exceedingly rarely so. There is a lot more that goes into software development than what appears on the surface.
Take for example a new Z-Wave device. If it is a simple device and correctly implements some of the basic Z-Wave command classes (switch binary, switch multilevel) and class hierarchy, then it should work out-of-the-box even without an Indigo definition. If it is a more complex device (multi-sensor, thermostat, etc.), then we might be able to create a codeless device definition for it. And lastly, if the device doesn’t fully/correctly support a Z-Wave class, implements a Z-Wave class that Indigo doesn't support, or it implements functionality that’s not well defined by the Z-Wave spec, then it will require coding along with a device definition. This results in what is often significant work (development, testing, documentation, etc). Even devices that can be added only with a definition can require significant time – we have to research how the incoming commands should map to Indigo's device types, what configuration parameters are available, how they work, and determine which ones should be shown in Indigo's UI. It can easily take several hours with the research and QA needed.
The same applies, to a lesser extent, to Insteon devices. Brand new device types rarely appear in Insteon, so adding a new model is relatively simple in the majority of cases, but a new class of device will require more work.
Another reason why adding devices can take time is that Indigo, unlike many other smarthome hubs, attempts to balance usability with flexibility. If you go too far down the usability path, you end up in with a tightly controlled environment that’s much less flexible because the user’s ability to do complex things for themselves is limited. This is the path that many of the hardware hubs have taken.
On the other hand, if you go too far down the flexibility path, you end up with a very complicated system that’s hard to configure/modify, and often has hit-or-miss features. This is the path that most of the open source hub software has taken.
An example of this is Z-Wave device configuration parameters. Config params are unique to a given device and are not part of the Z-Wave specification. To expose them in the configuration UI in a user friendly way requires a unique device definition for that device (though we provide the user the ability to set arbitrary params). Many Z-Wave hubs only support sending arbitrary parameters and don’t spend any time making the setting of those params in the UI user friendly. We do this because we believe that’s a strength of Indigo.
A tangential question we often get asked is if users could add their own Z-Wave device definitions. This currently isn't possible with Indigo given the complexity of the device definitions, but it is an area we hope to improve in future releases. We know that this is a limitation and is something we are interested in addressing in some form.
So, that’s the short(ish) version. The other request we get is when will you support device X. Our company policy is to not comment on specific device support in future releases unless that release is imminent. We prioritize new device support depending on a variety of factors and pre-announcing specific device support would serve no useful purpose. We’re also working to make sure that we can release new device support faster. If you’re interested in a slightly longer explanation, please check out the post that discusses the Indigo Up-to-Date program we’ll be introducing with Indigo 7.