Dean Roddey
Senior Member
ano said:aybe a scheme like how printers have gone is the answer. You buy a printer for your PC or Mac and they come with a driver that tells your hardware how to communicate with them. Contrast this to how it is now with Homeseer or CQC where the driver has to be written by the controller company not the device. As we have seen, this is not really a sustainable model long-term, at least in my opinion.
Instead if the controller makers could put together a driver spec. that they all followed, this might be a great start. Then it would be the device maker, not the controller maker that created the driver. If not the device maker, other people would come forward to write drivers, but only if they worked on more than a single controller platform. In other-words, the "driver" for an LG XYZ TV would work in Homeseer, CQC, Premise or any other controller.
If Dean, Mark and others could work toward this, just think how wonderful and robust the home automation market would be for us users? Will it ever happen? Probably not.
That's definitely unlikely. The problem is that, unless you make every automation system work the same, then they all need to consume the data from the device differently. And you aren't ever going to make every automation system work the same.
You could try to come up with some layered system, like the TCP/IP stack, where you defined some intermediate form that the information is exposed as, and an API that could be used. Then automation systems could write drivers to that intermediate form.
But that still wouldn't get rid of the need for the automation system vendors to write drivers, because they still have provide the system specific smarts to deal with the device, even if it's via some intermediate, generic interface. I.e. unless you can make every A/V receiver work the same, then the fact that the functionality of that receiver is exposed through some intermediate form doesn't get rid of the differences between receivers. So the automation vendor still has to write another driver to sit on top of that, which can squash that receiver's specifics to fit into its own view of what a receiver is.
Ultimately, you'd be better off trying to get hardware vendors to standardize on certain core features and to expose them via a standard control protocol. And that gets rid of the 'what language is it written in' problem that would plague any attempt at implementing something like what you are suggesting. It pushes the standardization to the devices. Then we could write a single driver that would work with any device of a given type. But, that's even less likely because there are some many of them, and various folks trying to get them to support this or that standard.
Even when it sort of happens it doesn't work. Yamaha came out with their YNC protocol, and we wrote a driver that works with it. It was great it would just adopt to any of the Yamaha models that supported the protocol. Then they promptly just completely broke it by introducing other stuff that can't be dealt with in that generic sort of way.