Yeah cool, please keep this item in your TODO list. I think getting INSTEON support is getting more and more interesting for us and if you're able to set this up we can get more people to participate in developing that support.

This is premature but I'll ask anyway -- I understood that when constructing the message the firmware will add the CRC byte at the end -- does that mean I should send a message one byte short, or full size but expect the last byte to be overwritten by the PLM? Do you know?

Juha Lindfors wrote on Jul 24, 2008 19:00:
Yeah cool, please keep this item in your TODO list. I think getting INSTEON support is getting more and more interesting for us and if you're able to set this up we can get more people to participate in developing that support.

This is premature but I'll ask anyway -- I understood that when constructing the message the firmware will add the CRC byte at the end -- does that mean I should send a message one byte short, or full size but expect the last byte to be overwritten by the PLM? Do you know?

Off the top of my head; no, but I'm not sure I understand the question. Can you give an example of a command you are trying to send? You could also take a look at the Misterhouse code (it's Perl). Code is Code to me but I've worked with everything from hex code to Java so I'm used to reading gibberish. ;-)

Neil Cherry wrote on Jul 25, 2008 01:31:

Juha Lindfors wrote on Jul 24, 2008 19:00:
Yeah cool, please keep this item in your TODO list. I think getting INSTEON support is getting more and more interesting for us and if you're able to set this up we can get more people to participate in developing that support.

This is premature but I'll ask anyway -- I understood that when constructing the message the firmware will add the CRC byte at the end -- does that mean I should send a message one byte short, or full size but expect the last byte to be overwritten by the PLM? Do you know?

Off the top of my head; no, but I'm not sure I understand the question. Can you give an example of a command you are trying to send? You could also take a look at the Misterhouse code (it's Perl). Code is Code to me but I've worked with everything from hex code to Java so I'm used to reading gibberish. ;-)

I mean the CRC in the INSTEON standard and extended messages (see here for fancy ASCII art).

Not sending anything yet, just trying to conceptualize in my head the code I need to write once I have a device available to me to write code to (nudge nudge).

Looking at this page, there's a sample line on how to test an INSTEON PLM device (I think):

$: rs232 -d /dev/ttyS6 -b 19200 -s "\h02 62 FF FF FF 0F 13\n" --hex --verbose -r9 --wait .4 

1. Device (-d /dev/ttyS6): on my system the PLM is connected to /dev/ttyS6
 
2. Baud rate (-b 19200): 19,200 was the only rate that gave me joy.
 
3. Send string (-s "\h02 62 FF FF FF 0F 11 FF"): This is the hexadecimal
Insteon command that gets sent to the PLM. The \h is a hex toggle. The
"02" is the 'start of text'. The '62' tells the PLM an Insteon command
is coming. The next three bytes 'FF FF FF' is the Insteon ID. I got this
off the label on the back of the device itself. The '0F' is a flag
indicator. The next two bytes are the Insteon command that gets passed
to the LampLinc. The '11 FF' is ON with full brightness. The '13' is
OFF. I had to put a \n at the end to get the command to work.
 
4. Display in Hex (--hex): Displays the out put in hex.
 
5. Verbose output (--verbose): Self explanatory
 
6. Wait 0.4 seconds (--wait .4): This setting seems to work

So from this it looks like CRC is not required (which is what I expected, the spec says firmware does this).

But these strings are also one or two bytes short from standard message, looks like ToAddress is as expected 'FF FF FF' at three bytes, then flags 'OF' and then two byte command.

'From Address' is omitted which I suppose in this case makes sense. Instead '02 62' is used which is vaguely described as 'start text' and 'command arriving' sent to PLM.

So I'm wondering

1. if PLM defines an interface that doesn't take the standard message in its complete form (looks like it)?
2. do you have PLM documentation to know exactly what format of commands it can accept?
3. is PLM the device through which we'd always integrate to INSTEON network?
4. am I completely lost?

Juha Lindfors wrote on Jul 25, 2008 20:43:

Neil Cherry wrote on Jul 25, 2008 01:31:

Juha Lindfors wrote on Jul 24, 2008 19:00:
Yeah cool, please keep this item in your TODO list. I think getting INSTEON support is getting more and more interesting for us and if you're able to set this up we can get more people to participate in developing that support.

This is premature but I'll ask anyway -- I understood that when constructing the message the firmware will add the CRC byte at the end -- does that mean I should send a message one byte short, or full size but expect the last byte to be overwritten by the PLM? Do you know?

Off the top of my head; no, but I'm not sure I understand the question. Can you give an example of a command you are trying to send? You could also take a look at the Misterhouse code (it's Perl). Code is Code to me but I've worked with everything from hex code to Java so I'm used to reading gibberish. ;-)

I mean the CRC in the INSTEON standard and extended messages (see here for fancy ASCII art). Not sending anything yet, just trying to conceptualize in my head the code I need to write once I have a device available to me to write code to (nudge nudge). Looking at this page, there's a sample line on how to test an INSTEON PLM device (I think):

$: rs232 -d /dev/ttyS6 -b 19200 -s "\h02 62 FF FF FF 0F 13\n" --hex --verbose -r9 --wait .4 

1. Device (-d /dev/ttyS6): on my system the PLM is connected to /dev/ttyS6
 
2. Baud rate (-b 19200): 19,200 was the only rate that gave me joy.
 
3. Send string (-s "\h02 62 FF FF FF 0F 11 FF"): This is the hexadecimal
Insteon command that gets sent to the PLM. The \h is a hex toggle. The
"02" is the 'start of text'. The '62' tells the PLM an Insteon command
is coming. The next three bytes 'FF FF FF' is the Insteon ID. I got this
off the label on the back of the device itself. The '0F' is a flag
indicator. The next two bytes are the Insteon command that gets passed
to the LampLinc. The '11 FF' is ON with full brightness. The '13' is
OFF. I had to put a \n at the end to get the command to work.
 
4. Display in Hex (--hex): Displays the out put in hex.
 
5. Verbose output (--verbose): Self explanatory
 
6. Wait 0.4 seconds (--wait .4): This setting seems to work

So from this it looks like CRC is not required (which is what I expected, the spec says firmware does this).

But these strings are also one or two bytes short from standard message, looks like ToAddress is as expected 'FF FF FF' at three bytes, then flags 'OF' and then two byte command.

'From Address' is omitted which I suppose in this case makes sense. Instead '02 62' is used which is vaguely described as 'start text' and 'command arriving' sent to PLM.

So I'm wondering

1. if PLM defines an interface that doesn't take the standard message in its complete form (looks like it)?
   
2. do you have PLM documentation to know exactly what format of commands it can accept?
   
3. is PLM the device through which we'd always integrate to INSTEON network?
   
4. am I completely lost?
   

I found this on the Misterhouse list, you can use it as an example:

root@Misterhouse:/# rs232 -d /dev/ttyUSB2 -b 19200 \
    -s "\h02 62 05 CA FE 0F 13\n" --hex --verbose -r9 --wait .4
/dev/ttyUSB2 19200 8n1 +dtr -rts -cts -dsr
send <hex>(2)(62)(5)(ca)(fe)(f)(13)<lf>
wait 0.400000 seconds
read 9 characters
78 1c fc b7 d4 9d bc bf d0

root@Misterhouse:/# rs232 -d /dev/ttyUSB2 -b 19200 \
    -s "\h02 62 05 CA FE 0F 11 FF" --hex --verbose -r9 --wait .4
/dev/ttyUSB2 19200 8n1 +dtr -rts -cts -dsr
send <hex>(2)(62)(5)(ca)(fe)(f)(11)(ff)
wait 0.400000 seconds
read 9 characters
78 ec fb b7 84 75 9c bf 80

This makes it seem that the CRC isn't sent (I think). I'll continue checking. I still have to get everything set up.

Ok, 9 bytes makes perfect sense, thanks Neil :-)

Juha Lindfors wrote on Jul 26, 2008 10:42:
Ok, 9 bytes makes perfect sense, thanks Neil :-)

The 10th byte may be present on the hardware only. After all here we are looking at an API of some sort (GAH! these are scary!). In any case the CRC is none of your concerns and is handled in firmware anyway that is what they sell in their plugs and switches afterall. So the 10 byte is relevant information over the AC wire, to you it isn't however.

just thinking out loud here.

Agreed on the CRC and it's supposed to be handled by firmware per the spec (on both send and receive) so I'm not surprised it doesn't appear on the response (it's 9 bytes).

The sends here are still 7 and 8 bytes though, so if that's what PLM expects then yes it is an API of some sort. I'd expect 9 bytes or maybe 6 if the source ID is omitted (PLM could just prefix it with its own ID). Right now it looks like 'magic bytes' 02 62 are expected.

Maybe decoding the message flags helps...

Since we are sending from PC we won't have an assigned INSTEON ID anyway, so then yes I think it makes sense..

02 62 to let PLM know command is coming (this is API for PLM)

then 05 CA FE as target address, then flags 0F

finally command without parameters (one byte '13') or command and parameters ('11 FF')

so for the first example I'd guess PLM creates the message and automatically sets its source ID and ('00') command params at the end and then finally the CRC (so total 10 bytes standard direct msg)

So that kind of brings me back to the original question, that is, these bytes integrate with PLM device specifically, it's not a standard INSTEON message. So if we would get to the INSTEON network through some other device, it needs specific message handling.

However, the response bytes make no sense to me whatsoever... grrr.

Ok, maybe just wait Neil to set everything up.

Juha Lindfors wrote on Jul 26, 2008 22:22:
However, the response bytes make no sense to me whatsoever... grrr. Ok, maybe just wait Neil to set everything up.

I'm currently having a little trouble with the Cisco CS516 but before anyone freaks note the Compiled date:

CS516#sh hard
CS Software (CS500-K), INTERIM SOFTWARE Version 9.1A(0.2)
Copyright (c) 1986-1992 by cisco Systems, Inc.
Compiled Thu 04-Jun-92 18:43

System Bootstrap, Version 4.4A(0.2), INTERIM SOFTWARE

CS516 uptime is 38 minutes
System restarted by power-on
Running default software

Cisco-500 (68331) processor with 2048K bytes of memory.
1 Ethernet/IEEE 802.3 interface.
16 terminal lines.
32K bytes of non-volatile configuration memory.
Configuration register is 0x101

Yeah, I'm trying to remember commands from 1992, surprisingly I remember a lot more than I thought I would. I've got routing up and running and I'll have it NAT'd soon. Juha, you and I need to have a private conversation about IP addressing and port numbers. Sorry folks but I'm not opening this up to the entire world.

ok, send me email or if you have IM or skype

Paul,

I know Juha Lindfors is travelling at the moment (relocating to Thailand :) but he was very interested in what you are talking about. On the price points. I think that the point here is integration of various products. If EZSrve is a popular solution with a set of peeople then having a module that sends the messages over TCP may be a valuable goal. We are going through the moves of building a few modules (X10 being the most advanced at the moment with Wade) so we will have better example of what it means to integrate.

Paul, first of all thank you. It sounds like you've gone through the rounds with INSTEON already. I'd really appreciate if you like to hang around OR and give your expert feedback.

Paul Niklewski wrote on Jul 30, 2008 21:53:
There are only a few ways to communicate via Insteon - the standard message format is on the powerline between the PLM and device.

Ok makes sense, and I was suspecting this...

Paul Niklewski wrote on Jul 30, 2008 21:53:
What you are seeing from the PLM is a serial interpretation of the commands.

Gotcha. I was hoping it wouldn't be the case (your point later about integration becoming a pain) and we could deal with the standard message format for all integration. No such luck it seems :-(

Paul Niklewski wrote on Jul 30, 2008 21:53:
It can be a pain. Also, make sure you are specific on the PLM version you are supporting - the older ones require you to send a byte, what for an echo, then send the next byte, etc... you couldn't send the whole message in one batch. I do not recommend backwards compatibility - just make sure users with old PLMs out there know the compatibility versions.

Ok, thanks for that info. You're right this sounds like a pain. It seems the only way to get a quality INSTEON integration is to recruit a community of INSTEON users around OR -- with different hardware and firmware versions to test the integration.

Would you be interested Paul?

Paul Niklewski wrote on Jul 30, 2008 21:53:
One of the areas I am going to look at contributing is an interface to the EZSrve, which has an XML command section for Insteon and X10. So, you would create a TCP socket, and send the following for sending a basic Insteon Messag:

<command>SendInsteon
<address>01.23.45</address>
<cmd1>On</cmd1>
<cmd2>75%</cmd2>
</command> 

and the EZSrve will take care of the messaging.

This sounds interesting, I will take a peek at this once I get a chance. Do you happen to have some good web resources?

I have a NetLinc on preorder and plan on breaking down the POST/GET requests for ease of Insteon control. I'm definitely willing to help out. There's already a wiki page (MyLink) for this controller that has some of the HTML that it uses (contained in the .bin files).

Dan K wrote on Jul 31, 2008 14:21:
I have a NetLinc on preorder and plan on breaking down the POST/GET requests for ease of Insteon control. I'm definitely willing to help out. There's already a wiki page (MyLink) for this controller that has some of the HTML that it uses (contained in the .bin files).

Hello Dan,

I'm putting together a list of people who have expressed interest in INSTEON integration so we can try and organize the work. I will let you know once I have something definitive.

Hey Juha throw me on that list. I've done a bunch of work with Insteon stuff and have some hardware to play with, I've got a dev box setup too. I also have some significant experience setting embedded linux stuff if Neil needs any help in that area.

David Ortiz wrote on Aug 03, 2008 22:04:
Hey Juha throw me on that list. I've done a bunch of work with Insteon stuff and have some hardware to play with, I've got a dev box setup too. I also have some significant experience setting embedded linux stuff if Neil needs any help in that area.

Neil needs help. :-) I have to keep this short as I'm still doing homework and studying for finals. I'll be done on Thursday and should be decompressed by the weekend.

Thanks

Nick Schiffelbein wrote on Aug 04, 2008 03:47:
Hi Neil,

I read that you're doing homework, I too am a college student so I know how that goes. I started playing around with the Insteon devices just a few months ago. I live in California near the Insteon corporation, and I purchased the Development Kit. I have a PDF for developers that outlines the Insteon protocol. I'd be more than happy to send you a copy. I was able in my first night of going through the booklet to write a shell script to transmit an on and off command through the serial port to a device in Ubuntu Linux. The booklet contains a large portion of the commands available on the PLM. Let me know.

Nick

Actually I work full time at AT&T Labs but I only have an Associate in Science (EET). They want something a little more substantial (and not just years experience, which I have). So back to school I went (part time). One more year and I'll have a BS degree

Thanks, I'm already a developer with Insteon, I have the original PLC's (serial and USB). Dang things are a software pain in the ... Anyway, I have all the docs going back to then. The new documentation leaves out some of the older information, which is why I keep it.

The PLM works pretty well although as Ben has noted only a select few seem to have it working properly (the EZ folks and the ISY folks). I'd like to include the Misterhouse folks also. We'll get it working properly just have to wrestle with it and the links (and the X10 too).

Hello Nick,

I'd be quite interested in seeing that PDF. Ping me on my email if you can.

Not to be a jerk but if you have the Insteon developers guide we might want to be careful about just sending that around to people. I recall when I got it there was some sort of NDA involved meaning distribution of it may put you the project at legal risk. I may be wrong but we may want to just err on the side of caution.

That said welcome :)

David Ortiz wrote on Aug 03, 2008 22:04:
Hey Juha throw me on that list. I've done a bunch of work with Insteon stuff and have some hardware to play with, I've got a dev box setup too. I also have some significant experience setting embedded linux stuff if Neil needs any help in that area.

Hello David,

Thanks for volunteering ;-)

Neil Cherry (who already responded) and Wade Wassenberg are currently leading the INSTEON integration work. Please ping them directly and we can figure out how to tackle this. We haven't really gotten into INSTEON yet so anything to help us push in that direction will be appreciated. Neil's been very busy lately with other things but he should be back soon.

It depends on what you want to do, and how fast you want to do it.

For sending basic Insteon commands, this is very straight forward.

The complexity comes in managing all the different versions of Insteon devices out there for links and scenes. We have some abstractions and an XML database for devices and links in the EZSrve - which makes coding easier. You add the links you want to the XML DB and say synchronize (can be done via the TCP socket in XML) - the EZSrve will automatically synchronize the insteon network to the XML DB, taking care of device versions, peeking/poking and sanity checking.

However, I am not sure you want to take on the complexity of scenes and links on first. Basic timers and scripting will meet the needs of a lot of users short term.... though the power users will scream bloody murder that there is no scene management (probably your biggest initial base).

I would not consider the HTML interface a plus - you will have your own unified UI. There is also no advantage of the TCP interface, you have a server.

The only reason to use the EZSrve is to let it take care of the scenes / links for you, so you don't have to worry about them except at a high level. I am not sure if the ISY does the same - it may.

If the team wants links / scenes in a second phase, then I would do a PLM. If you want to take those on first, I would look at the EZSrve or the ISY (if it handles the scenes / links in the TCP socket).

Paul Niklewski wrote on Aug 05, 2008 22:27:
It depends on what you want to do, and how fast you want to do it.

You're absolutely right, but we're kind of in chicken meet egg mode right now with the Insteon stuff, so your comments are well received here and I think will ultimately help us define our scope for version 1. So thank you in advance.

The complexity comes in managing all the different versions of Insteon devices out there for links

I apologize for my ignorance, but what is a link?

The complexity comes in managing all the different versions of Insteon devices out there for links and scenes. We have some abstractions and an XML database for devices and links in the EZSrve - which makes coding easier. You add the links you want to the XML DB and say synchronize (can be done via the TCP socket in XML) - the EZSrve will automatically synchronize the insteon network to the XML DB, taking care of device versions, peeking/poking and sanity checking.

I know that this is a long shot, but here goes... Is this XML DB something we'll be able to get our hands on assuming you and Marc work out any licensing issues? If not, I see this as something we're going to have to tackle one way or another.

However, I am not sure you want to take on the complexity of scenes and links on first. Basic timers and scripting will meet the needs of a lot of users short term.... though the power users will scream bloody murder that there is no scene management (probably your biggest initial base).

Well, I'm not 100% sure that scenes are out of the question... scenes in terms of Insteon scenes, may be out of the question, but as you stated, scripting may not be out of the question, and even though it may not be as elegant as the way Insteon Scenes are put together, a scripted scene may be included in V1.

I would not consider the HTML interface a plus - you will have your own unified UI. There is also no advantage of the TCP interface, you have a server.

Agreed, hence my response to Drawbaugh before. :)

The only reason to use the EZSrve is to let it take care of the scenes / links for you, so you don't have to worry about them except at a high level. I am not sure if the ISY does the same - it may.

I get the impression on my limited knowledge that the ISY does also provide this... That being said, again scripted scenes vs Insteon Scenes may be clunky at first, but it may be a situation where it grows/improves with time, or we may just leave it out of V1 altogether... but in any situation, we'd revisit it in later versions (no matter what).

If the team wants links / scenes in a second phase, then I would do a PLM. If you want to take those on first, I would look at the EZSrve or the ISY (if it handles the scenes / links in the TCP socket).

Your advice is very much welcomed, and very well received... again I think you are helping us determine our scope... that's where we are at right now... trying to determine what is important for the first release and what is not... Thanks again!

First, there are no licensing issues. All of the information is public. Open source projects can use it to their hearts content. Personal projects that are not open can use it. When you start to commercialize, then we handle that on a case/case basis. We are finishing setting up a wiki, and it will be placed up there. In the meantime, an email asking for the format is all it takes.

Also, here is a good read on group and links for Insteon we wrote up, since this is the most confusing part of Insteon

http://www.simplehomenet.com/Downloads/Groups%20and%20Links.pdf

Links and scenes are important. If you don't have a scene, and want to turn on your out door lights for instance, if you did it with individual direct commands, the lights would turn on incrementally. Not a big deal with 2-3, pretty poor with 5 or more. A link is an element in an Insteon device that contains information linking it to another insteon device (see the PDF).