3 ms·

> 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 control

by rlpb 11y ago

> 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 http://www.insteon.com/developer/#devdocs but the motion sensor is not. And I still have no idea about the USB end.

ocdtrekkie 11y ago
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.
striking 11y ago
I would hope that this website helps: http://www.linuxha.com/common/iplcd/ http://www.linuxha.com/common/iplcd/
- ocdtrekkie 11y ago
  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.
- rlpb 11y ago
  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.
ocdtrekkie 11y ago
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.
- rlpb 11y ago
  > 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.
  - ocdtrekkie 11y ago
    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.

by rlpb 11y ago

ocdtrekkie 11y ago

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.

striking 11y ago

I would hope that this website helps: http://www.linuxha.com/common/iplcd/ http://www.linuxha.com/common/iplcd/

ocdtrekkie 11y ago
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.
rlpb 11y ago
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.

ocdtrekkie 11y ago

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.

rlpb 11y ago
> 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.
- ocdtrekkie 11y ago
  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.