I've been looking into this but haven't committed to buying anything yet.
Insteon doesn't seem well enough documented for third party controller implementations to me, although there are third party controllers available.
Z-Wave (distinctively different from Zigbee) are the main contender for me right now. They seem to have the most interoperability but it is still a closed protocol in that documentation isn't freely available. But access higher up in the stack does seem easier. It looks like I'll be able to act as a controller, rather than being forced to talk to one.
I like Insteon's dual signaling and bridging capability (between radio and signaling through the mains) but it has very limited security and it looks tricky for me to put a controller together myself (which as a developer is my test for openness).
X10 (supported by Insteon devices) has no security and is quite limited, so I don't want to invest in that now.
Zwave works great. Ppl harp on it because it's not 'open' - yet there is an open source interface library, products from dozens of vendors interoperate great, there are many choices in software to drive it (open source and commercial with more features). Meanwhile the 'open' alternatives like zigbee don't interoperate at all (in practise), and that is if you can buy products that use it at all; and now there is this hue debacle. I never got what people like about hue at all; is it that they are just screw in and don't need further setup? Home automation is so much more than turning the lights on and off with your phone. That's trivial. It was clear from the start that hue would be very narrow in application. (I'll admit though that using lights to follow what's on the tv is cool, and not available in any other system I know of)
INSTEON documentation is actually somewhat decent. But fragmented. There's some great third party software, there's some great third party hardware. The thing that excited me into building my own INSTEON controller, is that you can directly control a light with about 20 lines of VB .NET code: http://madreporite.com/insteon/plm_basics.html
Since I've been so unhappy with home automation software I've found, not doing exactly what I want, I've started building my own in VB .NET. The basics, plus what I specifically want it to do.
X10 is outright terrible. It was designed before nearly as much signal interference existed on powerline, so now you need tons of phase couplers and filters to get a good signal. INSTEON's mesh network (and dual-band powerline/RF) jumps signal issues far better. INSTEON's newer devices also drop support for X10, FYI.
> INSTEON documentation is actually somewhat decent. But fragmented.
Any help, please? For example, let's say that I want to buy a USB interface (for a controller), a motion sensor, and a light switch (eg. a micro dimmer). I want to plug the USB interface into a modern Linux distribution and speak to it to read motion and the switch and control the light (and configure the switch to operate the light directly without the controller).
Where do I find documentation on:
* What drivers I'll need for the USB interface to get to something I can talk to from userspace, whether this is Free Software, whether I'll need external drivers or not and where I might get these.
* The protocol to speak to the USB interface from userspace.
* The protocol to speak to each of the devices over the interface.
I've spent hours looking, and I only feel that I have half the answers. For example the dimmer is documented at http://www.insteon.com/developer/#devdocs but the motion sensor is not. And I still have no idea about the USB end.
I haven't tried to run the USB interface off of Linux, but I know they're supported pretty commonly, Mister House is a popular open source project that supports INSTEON on Linux. INSTEON PLMs like the 2413U are basically straight up USB-to-serial adapters, I think they might be supported directly in the Linux kernel, but I'm not positive.
The madreporite.com site I provided above has some decent documentation on device IDs and commands for a lot of devices. And as you can see from the link I provided, communication with the devices is generally pretty simple, 8 or 21 bytes sent over a serial connection, that can be written in a few lines of code. Receiving is a bit more complicated, but he provides sample code for that as well.
In my code development, I've definitely found some fun cases. i2cs (newer protocol) devices require a checksum, and they respond a bit differently in some cases. So for instance, my code that does a Product Data Request to get the model info for a device isn't working for i2cs devices right now. I'm still working on that, probably tonight.
I'd think something like Mister House would probably do the sort of simple case you need without figuring out all of the INSTEON protocol.
> I'd think something like Mister House would probably do the sort of simple case you need without figuring out all of the INSTEON protocol.
I'm a developer and I want to hook all kinds of things together. I don't need a GUI but would like full programmatic access. The case I have in mind would start off as a few lines of Python, probably using asyncio or something which is really powerful for this kind of thing. I'd prefer to just write a few lines against an API than have to use a framework, deal with maintaining a larger software deployment, etc.
Well, as I said before, I doubt you'll find many devices easier to control than like 20 lines of Visual Basic (probably less in more concise languages).
But you are right that there are holes in their documentation. The code I'm using does a good job showing unknown commands though, so it's pretty easy to fill in what's missing. I think IoT has a lot worse devices, documentation wise.
That page is helpful, but it looks to me that it is mainly from a group of hackers who have reverse engineered things. I'm appreciative of that and would find it really useful had I inherited an existing system. But I don't particularly want to buy into a new system that relies on reverse engineering rather than normative documentation. If I'm going to be spending money and have the luxury of choosing the system to use, I'd prefer a system that is better than that.
The worthwhile note there is everything regarding the "PLC" rather than the PLM is too old to work with modern devices. The 2414 is basically not supported by anything anymore. And that page is eight years old, so it's likely missing any content on most of the newer INSTEON devices and protocols.
Insteon doesn't seem well enough documented for third party controller implementations to me, although there are third party controllers available.
Z-Wave (distinctively different from Zigbee) are the main contender for me right now. They seem to have the most interoperability but it is still a closed protocol in that documentation isn't freely available. But access higher up in the stack does seem easier. It looks like I'll be able to act as a controller, rather than being forced to talk to one.
I like Insteon's dual signaling and bridging capability (between radio and signaling through the mains) but it has very limited security and it looks tricky for me to put a controller together myself (which as a developer is my test for openness).
X10 (supported by Insteon devices) has no security and is quite limited, so I don't want to invest in that now.