Are they any Insteon PowerLinc protocol resources?

[johnnynine]

Just for fun I have started writing my own Inteon Powerlinc interface in MS Visual Studio 2005 (C#) which does not require any smarthome software to be installed (ie. no SDM).

In the end I would like to create some kind of very simple application that does not require any smarthome software that I could interface from CQC to control insteon lighting.

I have finished the low level USB communication layer and middle layer for talking to the Powerlinc, I only have a few commands done since I having been doing it without any documentation. For example I can ask the PowerLinc for it's insteon address and firmware version.

I'm not interested in buying the SDK at this point in time since I am still in a proof of concept phase. Has anyone seen documentation on the protocol between the pc and the powerlinc? I'm not really interested in the powerline protocol as I believe the powerlinc should take care of most of that for me?

Thanks,
Johnny

Edited: Sorry for the typo in the title. they=there

 

[Dean Roddey]

If you have the development skills to write an interface in C#, you can just do a CML driver in CQC and have a formal driver available instead of having to do it through trying to execute an external app. CML is not dissimilar to Java/C#, just a lot stricter.

 

[johnnynine]

If you have the development skills to write an interface in C#, you can just do a CML driver in CQC and have a formal driver available instead of having to do it through trying to execute an external app.

Would I be able to access a .Net library from CML? ie. Would I be able to create a CML driver that interfaces with my C# library? Or would everything have to be written in CML?

 

[Dean Roddey]

It would have to be in CML. In order to maintain our very high level of stability, we don't allow drivers to be written in other languages.

 

[wuench]

From reading the SDK forum there are some special requirements in talking to the PLC directly because the unit doesn't have a FIFO queue. So you have to put pauses into the data stream, and this slows things down. Both the IBIOS (direct) and SDM are fully documented in the PDF that comes with the SDK and there is a lot of undocumented info on the forum as well as tricks and even some code sharing. I think it will really save you a lot of time and frustration to get it.

A good reason to use the SDM is that it multiplexes the connection, so multiple pieces of software can access the PLC at the same time. And it seems to be a lot simpler to code to the SDM. I realize the SDM has it drawbacks, like not being able to run as a service (as far as I can tell) and whatever the SDM bugs of the day are. But it seems to be coming along.

I understand Dean's concerns, but it would be nice to be able to setup links or backup and restore switch configurations with a utility program and not have to shut down your house's main HA program (CQC) to in order to free up the port.

 

[Dean Roddey]

If it's necessary, the driver could provide a 'back off' mode that would force it to shut down the serial port and go into a holding pattern while you talk to the device via the setup software, and then you could let it go and it would just go back through the connection dance and get back in sync.

Whatever would be used would need to be available when no one is logged in or it wouldn't be of much use, IMHO. All our drivers run in the background under a service and no one is logged in on an automation controller in a rack. So I would argue for talking directly to the box. Any other software involved is never worth it, IMHO. It just increases complexity and the odds of problems.