LinuxMCE Forums

General => Developers => Topic started by: ddamron on December 20, 2007, 02:35:02 am

Title: Current Status of Insteon PLM Integration
Post by: ddamron on December 20, 2007, 02:35:02 am
Just a status update..

Progress has been a bit slow as most of advanced functions have been trial and error..

Working on Automatic Linking / Spidering of devices:

I now have routines to:
1.  Read the PLM's ALL-Link database records
2.  Read a remote Device's ALL-Link database record/records
3.  Parse said databases records.

framework is in place to:
4.  Add a database entry to the PLM
5.  Add a database entry to a remote device.

although I have not tested this yet.

Reading the PLM's database was easy..
Reading a Remote device's database was not so easy..  it required PEEKing the device's memory, 1 byte at a time, and then reassembling the record.

Adding records shouldn't be hard, I DOUBT I need to POKE bytes to remote devices, I should be able to use the "assign to Group" command..
As for the PLM, I can use the "Manage All-Link Database Record" to add records...

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 20, 2007, 07:21:28 am
hmm.. It seems as of late, nobody wants to talk to me...  ???
Did I fart ???
Do I have bad breath :-\
Am I posting too much?!?  :'(

I'm trying to ENGAGE you guys into suggestions, and possible solutions to my current problems..

They are:
1.  How to save STATE information to a child device (not just ON/OFF)
2.  How to read Scenario configuration information from RUBY
3.  How to INTERCEPT scenario commands in RUBY.

  :) ;) :D ;D >:( :( :o 8) ??? ::) :P :-[ :-X :-\ :-* :'(
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 20, 2007, 10:25:20 am
I found where the STATE of a device is stored in the database...
in Pluto_main, Table 'Device', Field 'State'
In the same table, field 'PK_Device' looks like my DeviceID..
now, anyone know how I can change this in Ruby???  (Do I really have to MODIFY the database?)

And, If I modify the database directly, do I have to do anything to 'flush' the data out to the orbiters???
Thanks!

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: Todd on December 20, 2007, 06:32:01 pm
hmm.. It seems as of late, nobody wants to talk to me...  ???
Did I fart ???
Do I have bad breath :-\
Am I posting too much?!?  :'(

I'm trying to ENGAGE you guys into suggestions, and possible solutions to my current problems..

They are:
1.  How to save STATE information to a child device (not just ON/OFF)
2.  How to read Scenario configuration information from RUBY
3.  How to INTERCEPT scenario commands in RUBY.

  :) ;) :D ;D >:( :( :o 8) ??? ::) :P :-[ :-X :-\ :-* :'(

When Orville and Wilbur Wright were trying to accomplish powered flight, they went to a meeting of engineers and scientist to educate themselves on theories of flight.  Upon attending the meeting they discovered that they knew more about it than the other experts.  I suggest that perhaps you are so far in front on this aspect that no one else can give you any suggestions?
Thank you for your work.
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 20, 2007, 09:25:15 pm
Thanks for your post Todd

I know there are people out there who understand the logistics better than I..  I'm a beginner Ruby programmer at that..
(Not a beginner programmer though, been coding for 20+ years)

I'm more or less fishing to see if anyone can add comments/suggestions that I may not have looked at or know about...

Regards,

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: tschak909 on December 21, 2007, 04:32:56 pm
I'm still trying to get a grip on the code base as a whole. I had to take some time to basically get over the rash of panic attacks that have been happening (which I've found out is because of fluid that had built up in my right inner ear, totally fucking up my bearings.)

I'm also attempting my own build of the 0710 CD, hopefully this will give me what I need to learn to build packages of my stuff...

don't worry, we're on the front lines, it's just that the people that have been here on the front lines are only now starting to talk.

-Thom
Title: Re: Current Status of Insteon PLM Integration
Post by: Matthew on December 21, 2007, 04:41:45 pm
hmm.. It seems as of late, nobody wants to talk to me...  ???

I think we're all just watching in awe of your progress, your superior expertise. Like kids tracking Santa across the night skies to our chimneys.

I'll talk to you about Insteon, if you want enthusiastic ignorance :). I'm Santa's Little Helper!
Title: Re: Current Status of Insteon PLM Integration
Post by: Matthew on December 21, 2007, 04:44:51 pm
And, If I modify the database directly, do I have to do anything to 'flush' the data out to the orbiters???

If you aren't already, you should update the DB and the devices (and Orbiters/etc if necessary) inside a transaction you can rollback/commit atomically. But you probably already knew that. A single function to update a virtual "device state" for any device generically that executes that transaction on whichever device is specified would be a good API if it doesn't already exist.
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 21, 2007, 08:35:55 pm
Thanks guys, knew you were there...
Matthew,
No, I didn't know about the transaction, but it only makes sense... I would have done it that way..
Still trying to find a way to update that WITHOUT modifying the database..

Thom,
Take your time... Hope you feel better soon!

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 22, 2007, 06:34:55 am
Status as of Friday, 21-dec-2007
(from below)
1.  DONE.
2.  DONE.
3.  DONE.
4.  DONE.
5.  not done.

In the case where a child device is not 'linked' to the PLM,
I have the driver automagically adding links into the PLM.

I have figured out a way to store configuration data to the child.  I'm not happy with it, but for now, it works.
I'm 2 layers deep in my spider routine.. One layer to go, and it'll be done..

I'm still not sure how I'm going to handle 'new' devices that I find..
I WILL be able to determine what type of device it is, (if it's a dimmable switch, or a sprinkler controller, etc.)

Maybe someone can chime in here and point me in the right direction...  I'm thinking about what to do when I do find new devices...
is there a LIGHTING WIZARD I can fire, or a SECURITY wizard, or anything like that.. to assist the user in setting the device up..
Lighting, I was thinking of possibly blinking the light, and asking the user which room the BLINKING light is in.. LOL

I'll be on for a bit for any comments...

Dan


Just a status update..

Progress has been a bit slow as most of advanced functions have been trial and error..

Working on Automatic Linking / Spidering of devices:

I now have routines to:
1.  Read the PLM's ALL-Link database records
2.  Read a remote Device's ALL-Link database record/records
3.  Parse said databases records.

framework is in place to:
4.  Add a database entry to the PLM
5.  Add a database entry to a remote device.

although I have not tested this yet.

Reading the PLM's database was easy..
Reading a Remote device's database was not so easy..  it required PEEKing the device's memory, 1 byte at a time, and then reassembling the record.

Adding records shouldn't be hard, I DOUBT I need to POKE bytes to remote devices, I should be able to use the "assign to Group" command..
As for the PLM, I can use the "Manage All-Link Database Record" to add records...

Dan

Title: Re: Current Status of Insteon PLM Integration
Post by: hari on December 22, 2007, 01:21:37 pm
Status as of Friday, 21-dec-2007
(from below)
1.  DONE.
2.  DONE.
3.  DONE.
4.  DONE.
you are awesome!
Title: Re: Current Status of Insteon PLM Integration
Post by: Matthew on December 22, 2007, 04:50:15 pm
Reading a Remote device's database was not so easy..  it required PEEKing the device's memory, 1 byte at a time, and then reassembling the record.

Adding records shouldn't be hard, I DOUBT I need to POKE bytes to remote devices, I should be able to use the "assign to Group" command..

PEEK and POKE? Hey, I was kidding when I said (http://forum.linuxmce.org/index.php?topic=3433.msg17795#msg17795):

Personally, the only games I'm interested in are the ones that run under the atari800 emulator (I was an Atari geek in the early 1980s).

I am an old Atari800 hacker from the 1980s, myself.. still am (looking at my Ben Heckendorn Atari 800 Laptop).

Let's reimplement DCE as CIO and run it on an 800XL! :)
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 22, 2007, 09:35:57 pm
Matthew,
LOL, Yeah, I know what you mean!

I started on the old TRS-80 Model 1..
still remember POKES for the Color Computer... 65495,0 65496, 0

lol

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: tschak909 on December 22, 2007, 11:04:08 pm
I had a model I as well (along with far too many other machines now in an air conditioned airplane hanger... even a Lisa 1 and an Alto!), it's funny how the system didn't clear its memory until after the display hardware initialized (the garbage screen)... then again, I remember the original Apple I and II had this problem too......

-Thom
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 22, 2007, 11:19:43 pm
Man, those were the days...
The Coco was the first machine I really learned to 'hack' on...
My Model 1 was 16K BASIC, no disk drives, TAPE only, serial bitbanger port..

I remember being so intrigued when I found specifics on a 'chip' in the coco, and was able to exploit that..
heh, it's been so long, I can't remember what the chips were... I do remember it was 6809 based..
there was a hack to increase the clockspeed from 1Mhz to 2Mhz, but it screwed up the video.. LOL
I remember also, loading the Disk Controller routines into RAM and modifying them so I could get 6ms Track-Track instead of the default 28ms...

I regress...
Those were just the start.. look at what's available now...
i2c, Microcontrollers, Insteon, zwave, LINUXMCE, UIRT, 1-wire..., INTERNET....
These are the days... :)

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: tschak909 on December 22, 2007, 11:29:29 pm
what's funny, I remember doing this the first time, with my father... using the first X10 to Computer interface (what's sad? it hasn't changed at all, it even has the same case.).. the CM11 has been around a _VERY_ long time... I saw the first ones in 1986. I had versions of their software to control stuff in the house in Apple II (nice little graphical display of house), to my IBM PC at the time (piece of crap text interface that was horrendous!)..... we had attempted this several times since.. but only  with Pluto has anything approaching full home unification been possible (without being more rich than god.)

-Thom
Title: Re: Current Status of Insteon PLM Integration
Post by: Matthew on December 23, 2007, 12:09:14 am
what's funny, I remember doing this the first time, with my father... using the first X10 to Computer interface (what's sad? it hasn't changed at all, it even has the same case.).. the CM11 has been around a _VERY_ long time... I saw the first ones in 1986. I had versions of their software to control stuff in the house in Apple II (nice little graphical display of house), to my IBM PC at the time (piece of crap text interface that was horrendous!)..... we had attempted this several times since.. but only  with Pluto has anything approaching full home unification been possible (without being more rich than god.)

Do you know any ($free/?OSS?) simple floorplan applet/Flash/Javascript that we can embed in an LMCE webpage window that just sends the floorplan data back to be saved on the server?
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 23, 2007, 01:10:34 am
Matthew,
Sorry, I don't quite follow what you're trying to do, but I have not found anything even remotely like that...

Tschak909,
LOL, I wrote an application for a pool hall once.. used X10 commands to turn the pool table lights on/off, and activated a timer, and calculated the charge...
that was WAY back.. even before VGA graphics... drew the 'floorplan' using ASCII graphics...

The ironic thing is, the pool hall I created it for is STILL using it.. almost 20 years later...

I remember the communication being a BIOTCH.. this was way before the CM11A, all I had was a PW523(I think) to communicate with..
had to do all the timing myself.. zero crossing, bit by bit output.. ugh!
Title: Re: Current Status of Insteon PLM Integration
Post by: Matthew on December 23, 2007, 03:28:37 am
using the first X10 to Computer interface (...) the CM11 has been around a _VERY_ long time... I saw the first ones in 1986. I had versions of their software to control stuff in the house in Apple II (nice little graphical display of house) (...) but only  with Pluto has anything approaching full home unification been possible (without being more rich than god.)

Do you know any ($free/?OSS?) simple floorplan applet/Flash/Javascript that we can embed in an LMCE webpage window that just sends the floorplan data back to be saved on the server?

Sorry, I don't quite follow what you're trying to do, but I have not found anything even remotely like that...

What I want to do is make the floorplan wizard fully interactive in an LMCE webpage. Without relying on an external program for generating the floorplan images, or (necessarily) uploading image files, etc. So I'm looking for a Java or Flash applet that offers simple floorplan drawing, which sends the drawn floorplan back to the server when complete. I guess a really simple drawing applet could be used, but drag & drop floorplan symbols would be good. I'll keep looking.
Title: Re: Current Status of Insteon PLM Integration
Post by: tschak909 on December 23, 2007, 04:34:10 pm
there isn't one.. it would have to be created.

I see it in two pieces

1. a web based floorplan creator, this would be a server side app that would in the end generate a png, to be fed into the database, controlled using a UI using AJAX and SVG to create the floorplans using a set of very simplified vector drawing tools.

I see this as a good alternative to building something in flash, it's entirely standards compliant, and I've done SVG based UIs (we're not doing anything crazy, so the load on the browser should be minimal.) Firefox or Safari would be required for now..... While I do know Flash extensively, I do not have a copy anymore, and would prefer not to be dependent on commercial software to do the development if possible.

2. creating a native version of the web UI as a native application that can be spawned from the setup wizard...this one is going to take some serious thought to make it blend in nicely.

-Thom
Title: Re: Current Status of Insteon PLM Integration
Post by: Matthew on December 23, 2007, 06:19:50 pm
there isn't one.. it would have to be created.

I see it in two pieces

1. a web based floorplan creator, this would be a server side app that would in the end generate a png, to be fed into the database, controlled using a UI using AJAX and SVG to create the floorplans using a set of very simplified vector drawing tools.

I see this as a good alternative to building something in flash, it's entirely standards compliant, and I've done SVG based UIs (we're not doing anything crazy, so the load on the browser should be minimal.) Firefox or Safari would be required for now..... While I do know Flash extensively, I do not have a copy anymore, and would prefer not to be dependent on commercial software to do the development if possible.

2. creating a native version of the web UI as a native application that can be spawned from the setup wizard...this one is going to take some serious thought to make it blend in nicely.

I place a high priority on unifying the "UI" and "Adminsite" GUIs. A Java applet could serve in both contexts, and there are lots of existing GPL Java drawing applets (http://www.google.com/search?q=java+%22drawing+applet%22+png+gpl), and even some that support SVG (http://www.google.com/search?hl=en&safe=off&q=java+%22drawing+applet%22+svg+gpl&btnG=Search).

If the floorplan is accessed in two cases, editing and using, the editor could be accessible from more full-featured Orbiter devices (ie. PC, whether in UI or Adminsite), while the floorplan as PNG or SVG can be used as a GUI in simpler orbiters like mobile phones, IP phones, simple remotes...
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 24, 2007, 08:12:14 am
Matthew, I see where your going..  and I agree with you.
Start another thread re:Floorplan designer in Java, or something like that...
I'd rather try to keep this thread for status of PLM Integration.

I'll be the first to reply in your new thread!


Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 24, 2007, 08:19:12 am
K, lots happened today.

did MAJOR debugging of the spider routines..

fixed a bug with receiving data..

implemented cmd #760 in preperation for Reporting Child Devices to LinuxMCE.

more optimizations,

lots more bugs fixed, too many to put here..

Fixed bugs in Child Configuration Saving.. (now, it works)

Child devices are now sensed eg: Light Switch (dimmable) is really a keypadlinc dimmable, or a Lamplinc dimmable, or a Switchlinc Dimmable
as compared to a Light Switch (on/Off) is a non-dimmable insteon device
as compared to an Irrigation controller.. which SHOULD automagically get added to the setup wizard..
as compared to a generic I/O controller.. which, I dunno.

lol

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 25, 2007, 11:57:06 pm
Well, After a few MAJOR hiccups yesterday, (had to reinstall) I think I'm ready to start again..
Generating orbiter screens for my Living Room Station 2"
Then, I can start firing the Reporting Child Events...

Will keep you posted..

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 26, 2007, 01:06:55 am
Ok, Couple of notes:

I have to report ALL devices.. if I fail to report a device, it REMOVES it!

When I fire the Report Child Devices event.. it ADDs the children, but does NOT start the wizard..

Do I have to fire another event?  Maybe Device Detected?? or possibly a PNP event??

Thanks ahead of time...

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: PeteK on December 26, 2007, 01:41:03 am
I believe the wizard itself is started when a lighting PNP device is detected.
Title: Re: Current Status of Insteon PLM Integration
Post by: PeteK on December 26, 2007, 01:58:13 am
So this is where it gets a little trickier for a serial device.

Looking at the 20_SharpTV.sh detection script we have the following line:

/usr/pluto/bin/TestSerialPort -p $3 -P N81 -b 9600 -t "POWR0   \r\s500mPOWR1   \r" -i 1 -s "OK\r"

The source for TestSerialPort is src/TestSerialPort/

Looking at the main.cpp file, it looks like it's only capable of testing strings as arguments, as opposed to hex values.  I'm guessing is that this fit with the other CE devices they were intending to detect.

So the following would need to be done:

1) You find a string to send to the PLM that will reply with a string to positively identify it.  Looking at the PLM command guide, I don't know if this is possible, but you're more familiar with the command set than I am.

or

2) Someone expands the TestSerialPort program to also accept and compare hex values.  This looks to be fairly straightforward.

I could probably handle 2), but not tonight.  Probably by the end of the week.
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 26, 2007, 02:39:27 am
So this is where it gets a little trickier for a serial device.

Looking at the 20_SharpTV.sh detection script we have the following line:

/usr/pluto/bin/TestSerialPort -p $3 -P N81 -b 9600 -t "POWR0   \r\s500mPOWR1   \r" -i 1 -s "OK\r"

The source for TestSerialPort is src/TestSerialPort/

Looking at the main.cpp file, it looks like it's only capable of testing strings as arguments, as opposed to hex values.  I'm guessing is that this fit with the other CE devices they were intending to detect.

So the following would need to be done:

1) You find a string to send to the PLM that will reply with a string to positively identify it.  Looking at the PLM command guide, I don't know if this is possible, but you're more familiar with the command set than I am.

or

2) Someone expands the TestSerialPort program to also accept and compare hex values.  This looks to be fairly straightforward.

I could probably handle 2), but not tonight.  Probably by the end of the week.


Heh, Pete, We're definately on the same page!

I just slapped together a quick script: InsteonPLM.sh
#!/bin/bash

echo "Insteon PLM Detection Script  queue $2"
/usr/pluto/bin/TestSerialPort -p $3 -P N81 -b 19200 -t "\02\60" -i 5 -s
"\03\05"
if [[ "$?" -ne 0 ]]; then
echo "It's not a PLM"
/usr/pluto/bin/MessageSend dcerouter -r 0 $1 1 806 224 $2 13 "$4" 44 0
else
echo "It is a PLM"
/usr/pluto/bin/MessageSend dcerouter -r 0 $1 1 806 224 $2 13 "$4" 44
1901
fi


I can definately send a 0x02 0x60 - which is Get IM Info..
This should respond with
ie 0x02 0x60 0x11 0x11 0x11 0x03 0x05 0x53 0x06 where:
02 60 is the command echoed back
11 11 11 is the PLM's Insteon ID
03 05 is the Cat / Subcat (This is the Identification)
53 is the firmware version
06 is ACK

I haven't tested it yet.. still working on it.

I copied most of that from the 60_apex configure script..

I will try it with the hex values.. if it fails, I should be able to 'build' a string consisting of those hex values in sh.

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 26, 2007, 02:45:26 am
On a side note though...

Because I had to reinstall, all my lights were lost..

This was a PERFECT situation to test the Spider...

I added ONE light switch to my configuration... the bathroom light.

It went out and SENSED 23 devices on FIRST RUN!!!

AND installed them all as children!

Pretty cool...

(Most of those, it got from the PLM's database)

Also, once I've reported my Child devices, it installs them, the orbiter says
'New Software has been installed. 
Quick reload Router now?'

Heh,

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 26, 2007, 03:09:08 am
I just ran into another GOTCHA

It seems my Spider routine is TOO sensitive!

It found my Access Points, and is trying to add them! (They should be treated as passive devices)
I was scratching my head, trying to figure out why it's attempting to add Insteon ID FA.FB.FC to my PLM...
That seems to be some form of routing in the Access Points..
I haven't figured that out yet..., so I think I'm just going to ignore them for now.


heh, another bug to fix...


Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 26, 2007, 03:18:52 am
I think I found what I need to do...

It's in the wiki under Plug&Play...

Title: Re: Current Status of Insteon PLM Integration
Post by: tschak909 on December 26, 2007, 06:12:01 am
holy shit, dude! you rock!!!!

damn it, i'm itching to code on my mame plugin :-/

-thom
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 26, 2007, 06:26:58 am
Merry Christmas Thom!
Hope your feeling better..

Thanks for the comments.. it's always uplifting when you post! :)

I've now had about 3 people enquire about beta testing the PLM interface..
To those people:
  I haven't forgot about you, cam across a couple bugs that lock the driver up..
(access points)

I want to fix those before I release more code...

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: tschak909 on December 26, 2007, 06:29:49 am
we need to get together and start documenting our work

1. how to add support for other home automation systems
2. how to create support for a new type of media

;)

-Thom

Title: Re: Current Status of Insteon PLM Integration
Post by: PeteK on December 26, 2007, 03:56:46 pm
Heh, Pete, We're definately on the same page!

I just slapped together a quick script: InsteonPLM.sh
#!/bin/bash

echo "Insteon PLM Detection Script  queue $2"
/usr/pluto/bin/TestSerialPort -p $3 -P N81 -b 19200 -t "\02\60" -i 5 -s
"\03\05"
if [[ "$?" -ne 0 ]]; then
echo "It's not a PLM"
/usr/pluto/bin/MessageSend dcerouter -r 0 $1 1 806 224 $2 13 "$4" 44 0
else
echo "It is a PLM"
/usr/pluto/bin/MessageSend dcerouter -r 0 $1 1 806 224 $2 13 "$4" 44
1901
fi


I can definately send a 0x02 0x60 - which is Get IM Info..
This should respond with
ie 0x02 0x60 0x11 0x11 0x11 0x03 0x05 0x53 0x06 where:
02 60 is the command echoed back
11 11 11 is the PLM's Insteon ID
03 05 is the Cat / Subcat (This is the Identification)
53 is the firmware version
06 is ACK

I haven't tested it yet.. still working on it.

I copied most of that from the 60_apex configure script..

I will try it with the hex values.. if it fails, I should be able to 'build' a string consisting of those hex values in sh.

Dan

Dan--
I believe hat the arguments you used above will send the ACII characters '0' and '2', then '6', '0'.  I think the PLM accepts hex values for commands, correct?

-Peter
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 26, 2007, 11:41:58 pm
I'll double check that.. I was basing it off of TestSerialPort's help display...
I haven't tested this script yet..

Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 27, 2007, 10:56:53 am
Ok, I'm frustrated, and have a REALLY sore neck..
12 hours of debugging, and I'm NO CLOSER..
I guess all that forward progress came to bite me in the a$$.

I think I need a break, G'night all..  I'll make another attemp tomorrow.

Dan

Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 28, 2007, 03:00:12 am
<hmm of relief>
Well, I guess I just needed to sleep on it..

I solved my timing issue (I think), and was able to make the code even more reentrant.. (!)

What it did before, was run through the spider, finding all FIRST LEVEL devices (ie devices it knows about, and all devices in THOSE devices databases)

Now, it essentially 'loops' if it detects a new device (at the end of the routine).  All detected devices are then KNOWN..

It has to download the all the databases.. but is seems to work quite well now.

I've only implemented the "report Child Devices" as a test routine..
(This was what was giving me such a headache, it WAS finding all the devices, but didn't store their configuration, so when I called that routine, it lost some devices because it couldn't figure out the template to use...)

Now, off to PLUG&PLAY world..
Things <should> go a bit smoother now...

Regards,
Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 28, 2007, 03:01:09 am
BTW, the code is now over 2000 lines...  ;D
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 28, 2007, 05:10:18 am
It seems I'm not quite understanding the PNP side...
I send the commands as per the wiki but it's hard to determine which commands are REQUIRED.

I follow it up with a Done Detecting Devices...
the PNP log says it's doing a GOTO screen 116... but there's no activity on the MD..

Can anyone who has implemented PNP chime in here and maybe point me in the right direction?

Thanks,

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 28, 2007, 05:11:48 am
Oh, yeah. heh, here's my TEST code...
Code: [Select]
  myDevFrom = device_.devid_
  myDevTo = -1001
  myDevPriority = 1
  myDevType = 2 #event
  myDevID = 65 # Device Detected
  #create command
  cmd = Command.new(myDevFrom, myDevTo, myDevPriority, myDevType, myDevID)
  #Add params...
  cmd.params_[56] = "72" # environment
  cmd.params_[49] = "38" # Light (dimmable)
  cmd.params_[55] = "12|0A.97.0B\n" # test lamp module
  cmd.params_[13] = "TEST LampLinc V2" # text to display
  cmd.params_[52] = "10"
  cmd.params_[53] = "3"
  cmd.params_[54] = "pnpserialnumber"
  cmd.params_[59] = "Insteon PLM"
  SendCommand(cmd)
  #Now, Fire the Done Detecting event...
  cmd = Command.new(myDevFrom, myDevTo, myDevPriority, myDevType, 74) #Done detecting...
  cmd.params_[59] = "Insteon PLM"
  SendCommand(cmd)
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 28, 2007, 05:28:41 am
and here's the log...  This is right after a fresh reboot, with NO lighting devices..
Code: [Select]
07 12/27/07 21:01:32.310 Event #65 has no handlers <0x7fdf9b90>
07 12/27/07 21:01:32.310 Received Message from 37 (PLM / Office) to -1001 (unknown / ), type 2 id 65 Event:Device Detected, retry none, parameters: <0x7fdf9b90>
07 12/27/07 21:01:32.310   Parameter 5(Mac Address):  <0x7fdf9b90>
07 12/27/07 21:01:32.310   Parameter 13(Text): TEST LampLinc V2 <0x7fdf9b90>
07 12/27/07 21:01:32.311   Parameter 28(IP Address):  <0x7fdf9b90>
07 12/27/07 21:01:32.311   Parameter 49(PK_DeviceTemplate): 38 <0x7fdf9b90>
07 12/27/07 21:01:32.311   Parameter 51(VendorModelID):  <0x7fdf9b90>
07 12/27/07 21:01:32.311   Parameter 52(PK_CommMethod): 10 <0x7fdf9b90>
07 12/27/07 21:01:32.311   Parameter 53(PK_PnpProtocol): 3 <0x7fdf9b90>
07 12/27/07 21:01:32.311   Parameter 54(PNP Serial Number): pnpserialnumber <0x7fdf9b90>
07 12/27/07 21:01:32.311   Parameter 55(DeviceData): 12|0A.97.0B
 <0x7fdf9b90>
07 12/27/07 21:01:32.311   Parameter 56(Category): 72 <0x7fdf9b90>
07 12/27/07 21:01:32.311   Parameter 59(Signature): Insteon PLM <0x7fdf9b90>
07 12/27/07 21:01:32.339 Event #74 has no handlers <0x7fdf9b90>
07 12/27/07 21:01:32.339 Received Message from 37 (PLM / Office) to -1001 (unknown / ), type 2 id 74 Event:Done Detecting Devices, retry none, parameters: <0x7fdf9b90>
07 12/27/07 21:01:32.339   Parameter 59(Signature): Insteon PLM <0x7fdf9b90>
08 12/27/07 21:01:33.321 Received Message from 37 (PLM / Office) to OnScreen Orbiter(20),Generic Proxy Orbiter(51), type 1 id  809 Command:Display Alert, retry none, parameters: <0xa1e50b90>
08 12/27/07 21:01:33.321   Parameter 9(Text): 33429 Confirming 72Light Switch (dimmable) <0xa1e50b90>
08 12/27/07 21:01:33.321   Parameter 70(Tokens): pnp_33429 <0xa1e50b90>
08 12/27/07 21:01:33.321   Parameter 182(Timeout): 3 <0xa1e50b90>
08 12/27/07 21:01:33.321   Parameter 251(Interruption): 2 <0xa1e50b90>
08 12/27/07 21:01:33.327 Received Message from 14 (Plug And Play Plug-in / Office) to OnScreen Orbiter(20),Generic Proxy Orbiter(51), type 1 id  741 Command:Goto Screen, retry none, parameters: <0xa1e50b90>
08 12/27/07 21:01:33.328   Parameter 159(PK_Screen): 116 <0xa1e50b90>
08 12/27/07 21:01:33.328   Parameter 163(Description): Light Switch (dimmable)(Pluto / Lighting Device) <0xa1e50b90>
08 12/27/07 21:01:33.328   Parameter 224(PK_PnpQueue): 33429 <0xa1e50b90>
08 12/27/07 21:01:33.328   Parameter 251(Interruption): 3 <0xa1e50b90>
08 12/27/07 21:01:33.328   Parameter 252(Turn On): 0 <0xa1e50b90>
08 12/27/07 21:01:33.328   Parameter 253(Queue): 1 <0xa1e50b90>
08 12/27/07 21:01:33.338 Received Message from 20 (OnScreen Orbiter / Office) to 6 (Datagrid Plug-in / Office), type 1 id 35 Command:Populate Datagrid, retry none, parameters: <0x7c5f2b90>
08 12/27/07 21:01:33.338   Parameter 4(PK_Variable): 0 <0x7c5f2b90>
08 12/27/07 21:01:33.338   Parameter 5(Value To Assign):  <0x7c5f2b90>
08 12/27/07 21:01:33.338   Parameter 10(ID): 1 <0x7c5f2b90>
08 12/27/07 21:01:33.338   Parameter 15(DataGrid ID): pnp_20 <0x7c5f2b90>
08 12/27/07 21:01:33.338   Parameter 38(PK_DataGrid): 44 <0x7c5f2b90>
08 12/27/07 21:01:33.338   Parameter 39(Options): 33429 <0x7c5f2b90>
08 12/27/07 21:01:33.338   Parameter 40(IsSuccessful): 1 <0x7c5f2b90>
08 12/27/07 21:01:33.338   Parameter 44(PK_DeviceTemplate): 0 <0x7c5f2b90>
08 12/27/07 21:01:33.338   Parameter 60(Width): 3 <0x7c5f2b90>
08 12/27/07 21:01:33.338   Parameter 61(Height): 5 <0x7c5f2b90>
05 12/27/07 21:01:33.339 Plug_And_Play_Plugin::PNPDevices Parms=33429 returning sole device template 38 Light Switch (dimmable) <0x9863db90>
08 12/27/07 21:01:33.345 Received Message from 51 (Generic Proxy Orbiter / ) to 6 (Datagrid Plug-in / Office), type 1 id 35 Command:Populate Datagrid, retry none, parameters: <0x7ddf5b90>
08 12/27/07 21:01:33.345   Parameter 4(PK_Variable): 0 <0x7ddf5b90>
08 12/27/07 21:01:33.345   Parameter 5(Value To Assign):  <0x7ddf5b90>
08 12/27/07 21:01:33.345   Parameter 10(ID): 1 <0x7ddf5b90>
08 12/27/07 21:01:33.345   Parameter 15(DataGrid ID): pnp_51 <0x7ddf5b90>
08 12/27/07 21:01:33.345   Parameter 38(PK_DataGrid): 44 <0x7ddf5b90>
08 12/27/07 21:01:33.345   Parameter 39(Options): 33429 <0x7ddf5b90>
08 12/27/07 21:01:33.345   Parameter 40(IsSuccessful): 1 <0x7ddf5b90>
08 12/27/07 21:01:33.345   Parameter 44(PK_DeviceTemplate): 0 <0x7ddf5b90>
08 12/27/07 21:01:33.345   Parameter 60(Width): 3 <0x7ddf5b90>
08 12/27/07 21:01:33.345   Parameter 61(Height): 5 <0x7ddf5b90>
05 12/27/07 21:01:33.346 Plug_And_Play_Plugin::PNPDevices Parms=33429 returning sole device template 38 Light Switch (dimmable) <0x9863db90>
08 12/27/07 21:01:33.386 Received Message from 51 (Generic Proxy Orbiter / ) to 6 (Datagrid Plug-in / Office), type 1 id 34 Command:Request Datagrid Contents, retry none, parameters: <0x7ddf5b90>
08 12/27/07 21:01:33.387   Parameter 10(ID): 2 <0x7ddf5b90>
08 12/27/07 21:01:33.387   Parameter 15(DataGrid ID): pnp_51 <0x7ddf5b90>
08 12/27/07 21:01:33.387   Parameter 32(Row): 0 <0x7ddf5b90>
08 12/27/07 21:01:33.387   Parameter 33(Column): 0 <0x7ddf5b90>
08 12/27/07 21:01:33.387   Parameter 34(Row count): 5 <0x7ddf5b90>
08 12/27/07 21:01:33.387   Parameter 35(Column count): 3 <0x7ddf5b90>
08 12/27/07 21:01:33.387   Parameter 36(Keep Row Header): 0 <0x7ddf5b90>
08 12/27/07 21:01:33.387   Parameter 37(Keep Column Header): 0 <0x7ddf5b90>
08 12/27/07 21:01:33.387   Parameter 49(Add Up-Down Arrows): 1 <0x7ddf5b90>
08 12/27/07 21:01:33.387   Parameter 73(Seek):  <0x7ddf5b90>
08 12/27/07 21:01:33.387   Parameter 74(Offset): 0 <0x7ddf5b90>
08 12/27/07 21:01:33.414 Received Message from 20 (OnScreen Orbiter / Office) to 6 (Datagrid Plug-in / Office), type 1 id 34 Command:Request Datagrid Contents, retry none, parameters: <0x7c5f2b90>
08 12/27/07 21:01:33.415   Parameter 10(ID): 2 <0x7c5f2b90>
08 12/27/07 21:01:33.415   Parameter 15(DataGrid ID): pnp_20 <0x7c5f2b90>
08 12/27/07 21:01:33.415   Parameter 32(Row): 0 <0x7c5f2b90>
08 12/27/07 21:01:33.415   Parameter 33(Column): 0 <0x7c5f2b90>
08 12/27/07 21:01:33.415   Parameter 34(Row count): 5 <0x7c5f2b90>
08 12/27/07 21:01:33.415   Parameter 35(Column count): 3 <0x7c5f2b90>
08 12/27/07 21:01:33.415   Parameter 36(Keep Row Header): 0 <0x7c5f2b90>
08 12/27/07 21:01:33.415   Parameter 37(Keep Column Header): 0 <0x7c5f2b90>
08 12/27/07 21:01:33.415   Parameter 49(Add Up-Down Arrows): 1 <0x7c5f2b90>
08 12/27/07 21:01:33.415   Parameter 73(Seek):  <0x7c5f2b90>
08 12/27/07 21:01:33.415   Parameter 74(Offset): 0 <0x7c5f2b90>
05 12/27/07 21:01:55.808 Socket::ReceiveData 0x73c2de88 failed, bytes left 0 start: 1560000 1: 0 1b: 0 2: 0 2b: 0 m_Socket: 180 Incoming_Conn Socket 180 192.168.80.3 <0x65be3b90>
05 12/27/07 21:01:55.808 Socket::ReceiveString2 ReceiveData failed m_Socket: -1 Incoming_Conn Socket 180 192.168.80.3 <0x65be3b90>
05 12/27/07 21:01:55.808 TCPIP: Closing connection to -1003 (Router Dev #0) 0x73c2de88 m_Socket: -1 <0x65be3b90>
05 12/27/07 21:01:55.809 Router::RemoveAndDeleteSocket 0x73c2de88 -1003 <0x65be3b90>
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 28, 2007, 12:47:08 pm
BuMp

HeLp!
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 28, 2007, 07:50:18 pm
Ok, after MUCH trial and error, I think I figured out how to activate that DAMN wizard...

I was successful in getting it to execute ONCE that I know of...

The problem is that I munched my whole configuration, probably trying to figure it out...

Eventually, I went down to the core, and there it was, waiting for me to click 'Light'

I tried to clean up my MD's, but then it said my CORE was in my living room... EEK!

So, backed up all my code, and re-installing 0704 fresh..

Then, I can retry my code..

If all goes well, I should have a PnP Insteon PLM Driver later today! Ready for TESTING...

Will keep you all informed..

Regards,

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: PeteK on December 28, 2007, 11:18:02 pm
Looking at the TestSerialPort code, i noticed that there is no detection mechanism in there for sending hex values.  My guess is they planned to implement it, but did not finish.  I'm working on extending it to support the PLM, which will require hex send and probably a way to receive values and correctly work the compare, ignoring address bytes.
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 28, 2007, 11:46:33 pm
Thanks Pete, That'll help..

Isn't there a way to 'build' a hex string in bash?

If so, we can build 2 strings... One to send, and the other for search..
then we don't 'need' testserialport to handle hex values... it'll just be handling strings,

make sense??

Also,

I'm REALLY having troubles with this DAMN PnP...

I can get it to fire the wizard, but ONLY on the core..., and some values are NOT being updated in the new child device...

I'm going to take another stab at it...

Regards,

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: PeteK on December 29, 2007, 12:51:25 am
Dan--

OK, looking back at the code I realize I made a mistake.  your script looks correct.  It works here with my PLM.

-Peter
Title: Re: Current Status of Insteon PLM Integration
Post by: PeteK on December 29, 2007, 12:56:08 am
Dan--

One thing you may want to check in your template is adding data #162 (Only One Per PC) and #163 (Auto-assign to parents room).

I pulled these from the Zwave template and they seemed to make device discovery more stable.

Look at the Z-wave template or the Insteon template I had posted for their configuration.

-Pete
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 29, 2007, 12:56:44 am
Pete,

SWEET!

Not bad for slapping it together...

I didn't even get a change to test it yet!

Glad you did!  Thanks!
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 29, 2007, 12:59:31 am
Dan--

One thing you may want to check in your template is adding data #162 (Only One Per PC) and #163 (Auto-assign to parents room).

I pulled these from the Zwave template and they seemed to make device discovery more stable.

Look at the Z-wave template or the Insteon template I had posted for their configuration.

-Pete

Ok, I'll try that...
Really appreciate your support...
I'll add those to my template now..(if I haven't already broke my LMCE again)

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: hari on December 29, 2007, 01:07:30 am
Looking at the TestSerialPort code, i noticed that there is no detection mechanism in there for sending hex values.  My guess is they planned to implement it, but did not finish.  I'm working on extending it to support the PLM, which will require hex send and probably a way to receive values and correctly work the compare, ignoring address bytes.
don't know which revision you are looking at but there is code for sending hex values in TestSerialPort (e.g. "string ParseHex(string sInput)")
It's used by some pnp detection scripts ("\xx").

best regards,
Hari
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 29, 2007, 01:12:08 am
Thanks Hari, That's the one I was using..
I double checked it with TestSerialPort --help first (to make sure of the cmd line options)

I'm pretty sure I have MY device PnP now, it's just getting the child devices to be PnP.


Dan

Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 29, 2007, 06:54:04 am
Well, Development started off good, then quickly petered out.
I really need to talk to a developer or someone else who has experience with PnP.

I've got 2 more things to finish, but then, the driver is done.  What needs to be done:
1.  X10 integration - up till now I've been ignoring it.
2.  I still have to fix that keypadlinc bug...
(This is for 2-way communication)  The device sending the command is NOT guaranteed to be the device being controlled.
(or devices for that matter, since a SINGLE button COULD control multiple devices)

Luckily, I have ALL the device's databases in memory, so it should be a quick 30 minute subroutine.
(I don't want to rely on cleanup events as I'm not guaranteed to receive them.)

X10 shouldn't take too long either.. it follows the same flow as Insteon.. the translation tables are done, I just have to add the logic to handle it.

After that, I'm kinda stuck.

Just so we're clear, here's the details on what I'm 'Stuck' with:

1.  PROPERLY reporting Devices Detected via PnP
2.  Sending STATE information to DCE?  (I can send ON/OFF, but I want to send ON/50 --- how do the orbiters do it?!?)
3.  I've got a problem with sending OFF commands... I send them OK, They go through DCE fine, but when GSD gets them, it reports 'not executing command because it is useless'.  Now here's the kicker:  If I use an orbiter, go to the floorplan, DIM a light, then turn it FULLY ON, then OFF, it works.

PeteK, Can you confirm the Detection script I wrote worked just one more time, and document BOTH the script (I lost it) AND the PnP settings for the template here?  Thanks a ton!
Please, also unplug your PLM to verify the script FAILS too...

Hari and TotallyMaxed:  I don't know if either of you could possibly help with the 3 problems above, but If you find a spare minute, maybe see if you can help there, or possibly pm me with someone who can (pluto?)

Anyone Else:  Problem 2 above:  If you know C++, could someone look into that code and see how the orbiters do it?  Maybe they communicate to a different device or something like that... EVEN if I EMULATE an orbiter..  My problem is I don't know C++)

That will complete the PLM driver (which, I believe everyone is waiting for)
BTW, the TYPE of PLM is important.. AFAIK, GSD sends full bore to the serial device.
If you PLM is older, there was a note in the development package to 'wait until the character is echoed back to you before you send another character'

I would consider that not to be a 'bug'..  I can check the firmware of the PLM to determine which one you have.. and possibly put a (minor) delay after sending each character.  I cannot sense the character coming back through GSD...

Well, That's a wrap for tonight.

Regards,

Dan

Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 30, 2007, 08:01:59 am
Ahh, Today was more of a problem solving day...
I did do a bit of coding, put in some remarks where I need to add X10.. also that other bug... but didn't really do any coding..
(honestly, didn't feel like it today..)
Instead, I did some research... trial and error you might say, and was pretty successful!
Totallymaxed gave me the PUSH I needed with regards to PnP.. and PeteK also helped there.. I have to try it, but let's hope I have it all straight...
I was trying to get the Lighting plugin to start on a MD... Thanks to TM, he informed me it only starts on the MD where the interface is...
NO WONDER I could only get it working on the core... AHA!  Now that I understand that... I can move forward..

As you probably know by now, I figured out the state information, or atleast a work around..

so, by my calculations, I have only 1 problem left to tackle.. and a bunch of coding... hehe
PeteK has dug into the ZWave code quite a bit.. and he understands it more than I.. so if I run into a problem with PnP, I'll pick his brain..

Problem 3 in the last post:  GSD reporting that command is useless..I wonder why that happens... Maybe it has something to do with the State..
I do have a work around for that.. but I REALLY don't want to use it.. sending a DIM command, then a FULL ON command, then a FULL OFF command...

So, not much in the way of coding today, but lots in the way of brainstorming...

Regards,

Dan

Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on December 30, 2007, 08:18:23 am
Ok, I just had a hunch, tried it, and VERIFIED my hunch!

The STATE information has TWO PARTS to it...
ON/OFF is part 1, and the level is part2.

You can change part2 using setlevel (which sends a setlevel command...)
HOWEVER, INTERNALLY, the DCE sets the LEVEL, but NOT PART 1!
in the device status, it shows ON/30.. but sending an OFF command does not get processed!

this is because even though a setlevel was processed, internally it's still OFF
I can verify this by sending an ON command, setting the level to say 30, then sending an OFF command..
Looking at the State, it shows OFF/30!  proving that the TWO PARTS are NOT joined

What does this mean? Well, I need to send TWO DCE commands each time, ONE to set the level, and the other to turn the device on.

Interesting!

I haven't tested if I can set the level FIRST, then turn on the device.. or if the ON command will override the setlevel...

Conversly, when I turn OFF a device, I must SETLEVEL to 0 and turn OFF...

YAY ME!!! I ROCK!!!  I'm such a geek!!!
lol

That seems to solve all my issues!! the rest is coding...

Thanks to all who have helped out!

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on January 01, 2008, 11:55:53 am
X10 Support is almost complete.  I'm just verifying my interpretation of the commands..
Fixed a few more bugs in the spider... found a nasty one that was corrupting my database tables.
Fixed a bug during rerun of the spider which wiped out a couple remote databases...
Fixed a bug in Report Child Devices (hardcoded DeviceID)

Never did figure out how to attach the PLM to my Fiire Station.. hooked back up to the core to continue.
Added a few modifications to the template in preparation for another attempt at PnP.

Spider testing, while not perfect, is getting better..  I'm testing it by adding ONE lighting device, and letting the system find the rest.
All in all, the spider is working (every once in a while it times out, but gets right back in sync..)
Happy New Year!

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on January 01, 2008, 12:22:30 pm
Heh, Sorry guys, I want to document some stuff so I don't forget..

Insteon todo list

finish X10 (a couple hours at most)
-- Sending X10 ON/OFF done,
Setlevel NOT done,
Receiving and decoding X10 Done,
Sending decoded X10 to lmce - NOT done
fix/check that BOTH cmd192 and cmd184 are being fired on an ON or DIM command -- DONE
add code to send cmd184 to self (to set state) beware of infinate loop. -- DONE
add routine for GROUP BROADCAST command processing (keypadlinc bug)
add generic support for devices OTHER than lighting (Irrigation, generic I/O)
check code for PnP test, retry code(now that I know it only fires on the core)
Once PnP procedure is nailed down, implementing it should be a piece of cake.
Modify INSTEON dim/bright messages to send a status request.. (to get actual on-level)
Add Alert Messages to driver.

Possible features for upcoming versions:

Add support for older PLM's (pre firmware 52)
Go through remote databases confirming links..warning of broken links (This would be great for error detection)
Possible re-download remote databases (during not busy times) for database error detection
Add i2 Support (ALDB/T)
Add createController and createResponder routines to create ALDB Links.
Add createGroup routine to create Broadcast Groups
add 'lookup tables' as devicedata - to make future new hardware a simple database entry
redo code in a more OOP fashion

Please add comments/suggestions..

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on January 02, 2008, 12:56:32 am

Insteon todo list

finish X10:
  DONE  Sending X10 ON/OFF done,
  Setlevel NOT done, need more info on X10 spec
  DONE Receiving and decoding X10
  DONE Sending decoded X10 to lmce
  DONE fix/check that BOTH cmd192 and cmd184 are being fired on an ON or DIM command
  DONE add code to send cmd184 to self (to set state) beware of infinate loop.
add routine for GROUP BROADCAST command processing (keypadlinc bug)
add generic support for devices OTHER than lighting (Irrigation, generic I/O)
check code for PnP test, retry code(now that I know it only fires on the core)
Once PnP procedure is nailed down, implementing it should be a piece of cake.
Modify INSTEON dim/bright messages to send a status request.. (to get actual on-level)
Add Alert Messages to driver.

Possible features for upcoming versions:

Add support for older PLM's (pre firmware 52)
Go through remote databases confirming links..warning of broken links (This would be great for error detection)
Possible re-download remote databases (during not busy times) for database error detection
Add i2 Support (ALDB/T)
Add createController and createResponder routines to create ALDB Links.
Add createGroup routine to create Broadcast Groups
add 'lookup tables' as devicedata - to make future new hardware a simple database entry
redo code in a more OOP fashion

Please add comments/suggestions..

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on January 02, 2008, 03:18:26 am


Insteon todo list

finish X10:
  DONE  Sending X10 ON/OFF done,
  Setlevel NOT done, need more info on X10 spec
  DONE Receiving and decoding X10
  DONE Sending decoded X10 to lmce
  DONE fix/check that BOTH cmd192 and cmd184 are being fired on an ON or DIM command
  DONE add code to send cmd184 to self (to set state) beware of infinate loop.
DONE add routine for GROUP BROADCAST command processing (keypadlinc bug)
add generic support for devices OTHER than lighting (Irrigation, generic I/O)
check code for PnP test, retry code(now that I know it only fires on the core)
Once PnP procedure is nailed down, implementing it should be a piece of cake.
Modify INSTEON dim/bright messages to send a status request.. (to get actual on-level)
Add Alert Messages to driver.

Possible features for upcoming versions:

Add support for older PLM's (pre firmware 52)
Go through remote databases confirming links..warning of broken links (This would be great for error detection)
Possible re-download remote databases (during not busy times) for database error detection
Add i2 Support (ALDB/T)
Add createController and createResponder routines to create ALDB Links.
Add createGroup routine to create Broadcast Groups
add 'lookup tables' as devicedata - to make future new hardware a simple database entry
redo code in a more OOP fashion

Please add comments/suggestions..

Dan

[/quote]
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on January 02, 2008, 05:57:58 am
Interestingly enough, even when you send an EVENT 48(device ON/OFF) it doesn't change the ON/OFF state of the device...
I'm wondering why event48 was even used in the zwave template...(probably for future use)
I'm going to put that event48 in the same category as event <new> (Report Lighting STATE::int) and not use it.

In the mean time, I'm sending COMMANDS to myself to change the STATE.  It's all working quite well...  The system now accurately tracks when you externally dim or brighten a switch, as well as on/off, and 'updates' the STATE accordingly.  I'll post new code after I'm done today..




Insteon todo list

finish X10:
  DONE  Sending X10 ON/OFF done,
  Setlevel NOT done, need more info on X10 spec
  DONE Receiving and decoding X10
  DONE Sending decoded X10 to lmce
  DONE fix/check that BOTH cmd192 and cmd184 are being fired on an ON or DIM command
  DONE add code to send cmd184 to self (to set state) beware of infinate loop.
DONE add routine for GROUP BROADCAST command processing (keypadlinc bug)
  add generic support for devices OTHER than lighting (Irrigation, generic I/O)
  check code for PnP test, retry code(now that I know it only fires on the core)
  Once PnP procedure is nailed down, implementing it should be a piece of cake.
DONE Modify INSTEON dim/bright messages to send a status request.. (to get actual on-level)
Add Alert Messages to driver.

Possible features for upcoming versions:

Add support for older PLM's (pre firmware 52)
Go through remote databases confirming links..warning of broken links (This would be great for error detection)
Possible re-download remote databases (during not busy times) for database error detection
Add i2 Support (ALDB/T)
Add createController and createResponder routines to create ALDB Links.
Add createGroup routine to create Broadcast Groups
add 'lookup tables' as devicedata - to make future new hardware a simple database entry
redo code in a more OOP fashion

Please add comments/suggestions..

Dan

[/quote]
[/quote]
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on January 02, 2008, 07:54:55 am
Well, a good coding day...

Solved quite a few problems that snuck up..  implemented X10 (all but X10 Dim/Bright commands)
Added support for Insteon remote dim/brighten (I cheated, just requested a status after the command was complete)

made a lot of progress with the state information... it's almost there..

I know of one bug with setting the state information.. I just have to fix it.

I implemented the Group processing... that works quite well (aka the keypadlinc bug is squashed)

Not a bad day coding wise, I STILL have a kink in my neck... <ARGH>

I said I would post more code today, but I wanted to fix the state problem first..

I'm mentally drained, so it's time to call it a day..

I'm surprised at how big this project actually got.. well, bit by bit it's almost done.

Regards,

Dan


Title: Re: Current Status of Insteon PLM Integration
Post by: totallymaxed on January 02, 2008, 12:10:23 pm
Well, a good coding day...

Solved quite a few problems that snuck up..  implemented X10 (all but X10 Dim/Bright commands)
Added support for Insteon remote dim/brighten (I cheated, just requested a status after the command was complete)

made a lot of progress with the state information... it's almost there..

I know of one bug with setting the state information.. I just have to fix it.

I implemented the Group processing... that works quite well (aka the keypadlinc bug is squashed)

Not a bad day coding wise, I STILL have a kink in my neck... <ARGH>

I said I would post more code today, but I wanted to fix the state problem first..

I'm mentally drained, so it's time to call it a day..

I'm surprised at how big this project actually got.. well, bit by bit it's almost done.

Regards,

Dan




Hmmm... software development tends to be like that. If you'd know how much work it would be or how many 'hills' there were to climb at the beginning you probably would not have started! ;-)
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on January 02, 2008, 12:18:29 pm
Heh, Actually, I would have...
I've wanted Insteon implementation for a while now..
I just had to 'bite the bullet' and learn another language..
I suspected when I started the spider routines that it would get hairy..
and figuring out HOW to do things in lmce, that was really the hard part..

I was also suspicious of an 'embedded interpreted' language, but for all intents, Ruby has proven more than adequate.

I've done lots of software development in my years.. lots of hardware development too...
Both are about the same, estimate 4 hours to do a routine, and it takes 16.  I'm aware of that, and expect it.

ahh, the joys of being a techno geek...

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on January 04, 2008, 04:14:43 am
Well, I'm stuck.

I can't figure out how to get the Lighting Wizard working.

I'm going to release this code as is...

Once it finds all your lighting devices, you'll have to go into Lights and figure out which is which, (ON/OFF/50% works)

Then, give it a proper name, and room... Don't forget to set the ObjectType! (table lamp, sconce, etc)

The First and second times it runs, it takes a little bit..

The First time, it spiders the insteon network, looking for devices, and reports them to the system.

The Second time, it redownloads the configurations OF those newly discovered devices, and saves it into the newly created devices.

After that, it's pretty quick..

I'm still fighting with the state info bug.. ahh well..

Also:  If for some reason, it misses some configuration.. simply DELETE the string in the CONFIGURATION field of the light in question, and reload router.
It will redownload that device's configuration.

Gimme a bit to disable the state bug, and I'll upload it asap..


Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on January 04, 2008, 04:58:09 am
Code is uploaded.

Also, no need to fire a 'Report Child Devices' command from the advanced menu..
The code will do it automatically once it finishes the spider routine.

The first time it runs, it may take a minute or two, eventually, you'll get a message on your MD saying 'New devices have been installed.  Please reload the router'

When you reload router, it starts it's second run... (here, it downloads all the configuration to the child devices)
Give it about the same time as the first.

From that point, it simply checks the configuration of each device, and if it's different, it will download the database again.

X10 is functional.
State information is buggy, but other than that, it works quite well.

I've noticed once in a while, the PLM will lock up.. I can't seem to unlock it via software.. it just NACKS every command. (0x15)

If this happens, unplug your PLM from power, plug it back in, and reload router.

I'm going to consider this project as complete as it's going to get, unless someone can explain the lighting wizard to me..

I was going to write my own 'Lighting wizard' in ruby, but why reinvent the wheel...

If anyone finds any bugs, please let me know.

NOW is the time to test it.  If you have equipment, NOW is the time to try it out.

watch the PLM Logs as you send commands.. there's still a bit of debug information..

Well, I'm 3 days late, and 2 features shy (wizard and state)..

On to the next project...

Regards,

Dan

Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on January 04, 2008, 05:09:54 am
Oh, yeah,

I could only get it working if the PLM was installed off the CORE...

This could be a brain fart on my part.. (possible template problem)

If anyone has any success using the PLM off an MD, let me know!

(It could also be because I'm trying to use it off a Fiire Station)

Technically, the code should work.

Dan
Title: Re: Current Status of Insteon PLM Integration
Post by: aaron.b on January 22, 2008, 11:07:26 pm
Regarding: GSD is ignoring command because it's useless...

Unfortunately this code inside GSD is kind of hard to get to and follow.  But basically what it's for is if you send the same on or off command repeatedly it only does it once.  This was supposed to be done for i/r devices with toggle power (ie if you send 2 off's, and they're toggle power, the 2nd one will actually turn it on, so gsd needs to ignore it).  There's a parameter you can add to the on or off command to force it to send it again.  I think it's "retransmit" or something.  I'd need to look in the code again.  You can see it if you use the orbiter and when media is playing choose the option to resend i/r codes.  You'll see when you hit the device name, the on command is sent with a retransmit, since presumably the first one didn't go through.

GSD should probably check for a device data and not ignore repeat on/off's if some device data is set.

As far as the events, look in the Lighting_Plugin.cpp code (it runs on the DCERouter as a plugin).  You'll see it intercepts some commands and events.  I don't recall how it works: I think it intercepts on/off/set level commands going to lights, and that the 'device on/off' events aren't used.
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on January 23, 2008, 04:08:56 am
Regarding: GSD is ignoring command because it's useless...

Unfortunately this code inside GSD is kind of hard to get to and follow.  But basically what it's for is if you send the same on or off command repeatedly it only does it once.  This was supposed to be done for i/r devices with toggle power (ie if you send 2 off's, and they're toggle power, the 2nd one will actually turn it on, so gsd needs to ignore it).  There's a parameter you can add to the on or off command to force it to send it again.  I think it's "retransmit" or something.  I'd need to look in the code again.  You can see it if you use the orbiter and when media is playing choose the option to resend i/r codes.  You'll see when you hit the device name, the on command is sent with a retransmit, since presumably the first one didn't go through.

GSD should probably check for a device data and not ignore repeat on/off's if some device data is set.

As far as the events, look in the Lighting_Plugin.cpp code (it runs on the DCERouter as a plugin).  You'll see it intercepts some commands and events.  I don't recall how it works: I think it intercepts on/off/set level commands going to lights, and that the 'device on/off' events aren't used.

Aaron,

Thanks for you post!
Since then, I did manage to trace the code, and found where it sends that message (consequently ignoring the command)

Once I found it, looking at the code a bit closer, it only makes sense, and I am working around it by keeping state information in my code.

Thanks again for the hint about the retransmit though..  I'll look into that.

I'll also take a closer look at Lighting_Plugin.cpp for the event info.

Regards,

Dan

P.S.  It was nice seeing you at the conference..  (I was on webcam)
Title: Re: Current Status of Insteon PLM Integration
Post by: Matthew on January 23, 2008, 05:08:12 am
Since then, I did manage to trace the code, and found where it sends that message (consequently ignoring the command)

Once I found it, looking at the code a bit closer, it only makes sense, and I am working around it by keeping state information in my code.

Thanks again for the hint about the retransmit though..  I'll look into that.

I'll also take a closer look at Lighting_Plugin.cpp for the event info.

I haven't been able to find how these various devices send their messages to the DCERouter. Where in the code did you find that?


P.S.  It was nice seeing you at the conference..  (I was on webcam)

Next time, more dogs on the set. If only for the hairstyle variety ;).
Title: Re: Current Status of Insteon PLM Integration
Post by: ddamron on January 23, 2008, 07:08:49 pm
matthew,
in Generic_serial_driver.
Title: Re: Current Status of Insteon PLM Integration
Post by: Matthew on January 23, 2008, 07:59:05 pm
matthew,
in Generic_serial_driver.

Which method sends the event?
Title: Re: Current Status of Insteon PLM Integration
Post by: tom_say on January 24, 2008, 03:43:08 am
not sure if this will help you all i am sure you all have seen it :)

http://misterhouse.svn.sourceforge.net/svnroot/misterhouse/trunk/lib/Insteon_PLM.pm