Author Topic: Ruby code for EZ-Bridge (Insteon) RC1  (Read 25992 times)

ddamron

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
Re: Beta Ruby code for EZ-Bridge (Insteon)
« Reply #15 on: December 12, 2007, 11:28:33 pm »
Code: [Select]
#### Written by Dan Damron
#### #350 Process Incoming Data ####


#$recvBuff = ''
#while (true)
# buff = conn_.RecvDelimited($responseString, 100)
# if (buff.length() == 0)
# break
# end
# $recvbuff = $recvbuff + buff
#end

log('In----------Processing Incoming Data')
while(true)
    buff=conn_.Recv(128,100)
    if(buff.length() == 0)
        break
    end
    $recvbuff = $recvbuff + buff
end

$recvbuff = parsestring($recvbuff)
Code: [Select]
#### Written by Dan Damron
#### #355 Process Initialize ####
$log = ''
$cmdTo = ''
$cmdFrom = ''
$cmdPriority = ''
$cmdType = ''
$cmdID = ''
$cmdParams = {}
$children = {}
$recvbuff = ''
$wAIT = false
$currentCmd = {}
$flagsBroadcastMessage = 128
$flagsDirectMessage = 0
$flagsAckDirectMessage = 32
$flagsNackDirectMessage = 160
$flagsGroupBroadcaseMessage = 192
$flagsGroupCleanupDirectMessage = 64
$flagsGroupAckDirectMessage =96
$flagsGroupNackDirectMessage = 224
$cmdqueue = []
$currentcmd = 0 # to save state of command when receiving more data.
$resetNext = 0 # used in Process IDLE to trap stalled responses.
$savedstate = nil
$dcequeue = []
$X10HouseCodes = {
'6', 'A',
'E', 'B',
'2', 'C',
'A', 'D',
'1', 'E',
'9', 'F',
'5', 'G',
'D', 'H',
'7', 'I',
'F', 'J',
'3', 'K',
'B', 'L',
'0', 'M',
'8', 'N',
'4', 'O',
'C', 'P'}
$X10UnitCodes = {'6', '1', 'E', '2', '2', '3', 'A', '4',
'1', '5', '9', '6', '5', '7', 'D', '8',
'7', '9', 'F', '10', '3', '11', 'B', '12',
'0', '13', '8', '14', '4', '15', 'C', '16'}
$X10CommandCodes = {'6', 'All Lights Off', 'E', 'Status = off',
'2', 'On', 'A', 'Pre-Set Dim',
'1', 'All Lights On', '9', 'Hail Ack',
'5', 'Bright', 'D', 'Status=on',
'7', 'Extended Code','F', 'Status Request',
'3', 'Off', 'B', 'Pre-set Dim',
'0', 'All Units Off', '8', 'Hail Request',
'4', 'Dim', 'C', 'Extended Data(analog)'}
$responseString = '<' + '/' + 'Response>'
log('Finding Children..')


device_.childdevices_.each{|c| $children[device_.childdevices_[c.to_s.to_i].devdata_[12].chomp.lstrip.rstrip] = c.to_s.to_i}
$children.keys.each{|c| log(c + ' = ' + $children[c].to_s)}
#children found... get the status of each child...
$children.keys.each{|c|
if c.length > 2 #filter out X10 for now
  #pack insteon message here, and send it out!
# receive message in parsemessage and relay commands back in it.
insteonID = c.chomp.split('.')
param = {'Command' => 'SndIns',
'Parameter1' => insteonID[0],
'Parameter2' => insteonID[1],
'Parameter3' => insteonID[2],
'Parameter4' => '0F', #flags
'Parameter5' => '19', #Status Request
'Parameter6' => '00'} #not used.
$cmdqueue << param

end
}
#lastly, put the PLM in monitor mode.
param = {'Command' => 'SetCfg', 'Parameter1' => '40'}
$cmdqueue << param
SndIns() #Lastly, start executing commands in order.
Code: [Select]
#### Written by Dan Damron
#### #384 Process Receive Command for Child ####


log('------dce--- PRCFC:$wAIT=' + $wAIT.to_s)
#add DCE command to DCE queue




insteonID = device_.childdevices_[cmd.devidto_].devdata_[12].chomp.split('.')
###
#log('INSPECT:'+ device_.childdevices_[cmd.devidto_].devdata_[])
###
$cmdID = cmd.id_
$cmdTo = cmd.devidto_
childType = device_.childdevices_[cmd.devidto_].devtemplid_
$cmdFrom = cmd.devidfrom_
$cmdPriority = cmd.priority_
$cmdType = cmd.type_
$cmdParams = cmd.params_
log('------dce--- cmdID:' + $cmdID.to_s + ', cmdFrom:' + $cmdFrom.to_s + ', cmdTo:' + $cmdTo.to_s + ', cmdType:' + $cmdType.to_s + ', Priority:' + $cmdPriority.to_s)
$cmdParams.keys.each {|p| log('------dce--- Param_[' + p.to_s + ']=' + $cmdParams[p])}
case cmd.id_
when 192 # ON
if insteonID.length > 2 then

param = {'Command' => 'SndIns',
'Parameter1' => insteonID[0],
'Parameter2' => insteonID[1],
'Parameter3' => insteonID[2],
'Parameter4' => '0F',
'Parameter5' => '11',
'Parameter6' => 'FF'}
$cmdqueue << param
SndIns()
else
log "------dce--- X10 DEVICE!!!"


param = {'Command' => 'SndX10',
'Parameter1' => rawX10(device_.childdevices_[cmd.devidto_].devdata_[12]),
'Parameter2' => X10Flag('On')}
$cmdqueue << param
SndIns()
end
# resp = Command.new($cmdTo, 1, $cmdPriority, $cmdType, $cmdID)
# resp.params_ = $cmdParams
# SendCommand(resp)
when 193 #OFF
if insteonID.length > 2 then

param = {'Command' => 'SndIns',
'Parameter1' => insteonID[0],
'Parameter2' => insteonID[1],
'Parameter3' => insteonID[2],
'Parameter4' => '0F',
'Parameter5' => '13',
'Parameter6' => '00'}
$cmdqueue << param
SndIns()
else
log "------dce--- X10 DEVICE!!!"
param = {'Command' => 'SndX10',
'Parameter1' => rawX10(device_.childdevices_[cmd.devidto_].devdata_[12]),
'Parameter2' => X10Flag('Off')}
$cmdqueue << param
SndIns()

end
# resp = Command.new($cmdTo, 1, $cmdPriority, $cmdType, $cmdID)
# resp.params_ = $cmdParams
# SendCommand(resp)

when 184 #SetLevel
# convert from percent to hex
dim_level = percenttohex(cmd.params_[76])
log("------dce--- Dim Level:" + dim_level.to_s)
if insteonID.length > 2 then

param = {'Command' => 'SndIns',
'Parameter1' => insteonID[0],
'Parameter2' => insteonID[1],
'Parameter3' => insteonID[2],
'Parameter4' => '0F',
'Parameter5' => '11',
'Parameter6' => dim_level}
$cmdqueue << param
SndIns()
else
log "X10 DEVICE!!! relative Dimming command"
# have to send 2 commands
#param = {'Command' => 'SndX10',
#'Parameter1' => rawX10(device_.childdevices_[cmd.devidto_].devdata_[12]),
#'Parameter2' => $X10CommandCodes.index['Bright'] + $X10UnitCodes.index[dim_level]
#$cmdqueue << param
#param = {'Command' => 'SndX10',
#dim_level = ((cmd.params_[76] * 16 + 1)/100).to_i.to_s
#'Parameter1' => rawX10(device_.Childdevices_[cmd.devidto_].devdata_[12]),
#'Parameter2' => $X10CommandCodes.index['Dim'] + $X10UnitCodes.index[dim_level]}

SndIns()

end
# resp = Command.new($cmdTo, 1, $cmdPriority, $cmdType, $cmdID)
# resp.params_ = $cmdParams
# SendCommand(resp)
end

Key features:
1.  Entirely in Ruby
2.  Distinguishes EXTERNAL insteon commands and sends events to LMCE based on them.
  (eg.  if you turn on a light switch manually, lmce will automatically be updated.)
3.  Full command queueing with failure recovery.
4.  following the log, you can actually 'peer' in on insteon activity.
5.  Structure in place for future expansion / enhancements.
6.  Requests initial status of each device (in initialize), then puts the PLM into monitor mode.

If you want to try this code out, post a reply and I'll put together template instructions.

Dan
« Last Edit: December 13, 2007, 02:06:33 am by ddamron »
The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.

tschak909

  • LinuxMCE God
  • ****
  • Posts: 5549
  • DOES work for LinuxMCE.
    • View Profile
Re: Ruby code for EZ-Bridge (Insteon) RC1
« Reply #16 on: December 13, 2007, 12:40:15 am »
I think you've just created the single most complete interface to a home automation control standard in LinuxMCE.

-Thom

ddamron

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
Re: Ruby code for EZ-Bridge (Insteon) RC1
« Reply #17 on: December 13, 2007, 02:03:46 am »
Thanks Thom!

I'm using it quite reliably now...

It works with Group commands and scenarios quite well, although I'd like to implement the groups differently

It is also designed to be a Interface-Specialized.. because it can talk to a variety of devices as it stands now.

I'm using it for:
Light Switches (on/off and dimmable)
ApplianceLinc V2 (insteon version of the X10 appliance module)
EZIO8SA IOboard (8 relay outputs, 8 inputs, 1-wire, 2 analog inputs, etc..) connected to a DS18S20 1-wire thermometer
EZRain1 Sprinkler controller
EZX10RF (really, an X10 receiver)

and the list goes on...

The SwitchLinc V2's have an LED Status indicator on the left side... I think I'm going to add support to use those for displaying various types of information..  If I can't figure out groups, that will be next.

I also forgot to add another feature it has... upon initialize, it goes out and gets a status request from each insteon device and fires events to the DCE to set initial status.  Then it puts the PLM into monitor mode to sense when someone manually uses a device, and reports that to DCE.

Dan
« Last Edit: December 13, 2007, 02:08:57 am by ddamron »
The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.

PeteK

  • Guru
  • ****
  • Posts: 408
    • View Profile
Re: Ruby code for EZ-Bridge (Insteon) RC1
« Reply #18 on: December 13, 2007, 03:40:50 am »
Dan--

Here are the functions I wrote for adding and deleting remote records.  I've tested these successfully on a couple of lamplinc modules.

Code: [Select]
/*
 *
 * insteon_set_remnote_link
 *
 */
int insteon_set_remote_link(ilib_t *iplc, unsigned char *target_id, unsigned char *plc_id, unsigned char group,
unsigned char on_level, unsigned char ramp)
{
unsigned char new_record[8];
unsigned char record[8];
int i = 0;
unsigned short record_address = 0xFFF8;
unsigned short write_target;
int last_record = 0;

/*insteon_write_byte(iplc,target_id,0xFFF8,0x80);*/
/*insteon_read_bytes(iplc,target_id,0x0FF8,8,record);*/

/*Build Record to write to ALDB/L  */
new_record[0] = 0x22 | ALDB_L_VALID;   //For some reason, bit 5 needs to be set...Saw this when SDM creates record
new_record[1] = group;
new_record[2] = plc_id[0];
new_record[3] = plc_id[1];
new_record[4] = plc_id[2];
new_record[5] = on_level;
new_record[6] = ramp;
new_record[7] = 0x0;

/*Find next Open Address */

do { 
insteon_read_bytes(iplc,target_id,record_address,1,record);

if ((record[0] & ALDB_L_VALID) == 0)
{
/*We found a record that has been erased.  Write it here. */
write_target = record_address;
last_record = ((record[0] & ALDB_L_HIGH_WATER) == 0);
break;
}

insteon_read_bytes(iplc,target_id,record_address+1 ,7,(record + 1));

if ((record[1] == group) && (record[2] == plc_id[0]) && (record[3] == plc_id[1])
&& (record[4] == plc_id[2]))
{
//We have found an existing record for this PLC and this group.  Go ahead and overwrite this record
write_target = record_address;
break;
}
record_address-= 8;
}
while (1);

if (last_record == 1)  //Make sure we mark the next record with a high water mark if this is the last record
{
insteon_write_byte(iplc,target_id,write_target-8,0x00);
}

  for (i = 0; i < 8; i++)
{
insteon_write_byte(iplc,target_id,write_target,new_record[i]);
++write_target;
}
return last_record;

}

int insteon_delete_remote_link(ilib_t *iplc, unsigned char *target_id, unsigned char *plc_id, unsigned char group)
{
unsigned char record[8];
unsigned short record_address = 0xFFF8;
unsigned char next_record_flags;

do
{
insteon_read_bytes(iplc,target_id,record_address,1,record);

if ((record[0] & ALDB_L_VALID) != 0)
{
/*This is a valid record
* First get the rest of the record
*/
insteon_read_bytes(iplc,target_id,record_address+1,7,record + 1);

if ((record[1] == group) && (record[2] == plc_id[0]) && (record[3] == plc_id[1])
&& (record[4] == plc_id[2]))
{
/* We found the record in the ALDB */

/* Check to see if the next record has the high water mark set
* If so, we need to set the high water mark for this record after we delete it
*/
insteon_read_bytes(iplc,target_id,record_address-8,1,&next_record_flags);
if ((next_record_flags & ALDB_L_HIGH_WATER) == 0)
{
record[0] &= ~ALDB_L_HIGH_WATER;
}
/* Now clear the valid bit */
record[0] &= ~ALDB_L_VALID;
/* Write the new flags byte */
insteon_write_byte(iplc,target_id,record_address,record[0]);
return 0;
}
}
//Go to the next record
record_address -= 8;
}
while((record[0] & ALDB_L_HIGH_WATER) != 0);
return 1;
}

Let me know if you have any questions on it.

ddamron

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
Re: Ruby code for EZ-Bridge (Insteon) RC1
« Reply #19 on: December 13, 2007, 06:40:56 am »
Thanks Petek, That will come in handy..
I'll have to rewrite it in Ruby, but it saves me the 6 hours of testing...

As always, your comments are more than welcome.
The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.

PeteK

  • Guru
  • ****
  • Posts: 408
    • View Profile
Re: Ruby code for EZ-Bridge (Insteon) RC1
« Reply #20 on: December 13, 2007, 05:05:50 pm »
Sure.  This should work for the PLM, but I have no idea about the EZ-bridge.  When you say you're working with the EZ Rain valves, how do you differentiate the commands for the valve versus the commands for the generic lights?  I've created EZRain Valve ON and EZRain OFF commands that are going into the 0710 release, but the generic sprinkler command set supports Generic On and Generic OFF.  I'd like to be able to use those rather than new commands, but I have to differentiate whether the target is a generic light or the sprinkler.

ddamron

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
Re: Ruby code for EZ-Bridge (Insteon) RC1
« Reply #21 on: December 13, 2007, 06:17:03 pm »
The EZBridge, for all intents and purposes, is simply a 'pipe' to the plm.  I can issue any command the PLM can receive.
The difference is, i format an XML message, that includes all the bytes needed to send to the PLM.
so, I shouldn't have any problems at all with that.

I've created a subroutine to generate the XML, for me.  I pass it a hash param[] with the commands/values.
eg:
param['Command'] = 'SndIns'
param['Parameter1'] = '00'

sending to SndIns(param) generates

<Command>SndIns<Parameter1>00</Parameter1></Command>
and sends it out.

take a look at my initialize routine... I interrogate the Device Status of each device in a loop.
Code: [Select]
insteonID = c.chomp.split('.')
param = {'Command' => 'SndIns',
'Parameter1' => insteonID[0],
'Parameter2' => insteonID[1],
'Parameter3' => insteonID[2],
'Parameter4' => '0F', #flags
'Parameter5' => '19', #Status Request
'Parameter6' => '00'} #not used.
$cmdqueue << param
$cmdqueue is a FIFO array of commands.
There are two ways to diffrentiate, depending on what you want to do.
1.  in LMCE, look up the templateID for what type of device it should be.
and/or

2.  Interrogate the insteon devices for their Category, SubCat, and (insteon)DeviceID
Once you know that, all is well.
I use the standard ON/OFF 192/193 for valves too.
Take a look at the Insteon Command Tables Reference. DevCat 0x01 is lighting, 0x04 (I believe) is irrigation.

HTH

Dan
« Last Edit: December 13, 2007, 06:39:50 pm by ddamron »
The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.

PeteK

  • Guru
  • ****
  • Posts: 408
    • View Profile
Re: Ruby code for EZ-Bridge (Insteon) RC1
« Reply #22 on: December 13, 2007, 07:34:23 pm »
There are two ways to diffrentiate, depending on what you want to do.
1.  in LMCE, look up the templateID for what type of device it should be.
and/or

2.  Interrogate the insteon devices for their Category, SubCat, and (insteon)DeviceID
Once you know that, all is well.
I use the standard ON/OFF 192/193 for valves too.
Take a look at the Insteon Command Tables Reference. DevCat 0x01 is lighting, 0x04 (I believe) is irrigation.

I like method 2. Is that what you're doing? If so, do you build a database each time you start the Insteon interface or do you store that data somewhere (like in the sql database)?  The Z-wave implementation grabs it each time at startup.  That may be the best way to do it.

Thanks for the info.  Two people working on a problem sure is a lot better than one (at least in this case :) )


ddamron

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
Re: Ruby code for EZ-Bridge (Insteon) RC1
« Reply #23 on: December 13, 2007, 09:07:25 pm »
Just pulled out my Insteon Dev guide..  Chapter 7, Page 83

Device Categories:

0x00 Generalized controllers
0x01 Dimmable Lighting Control
0x02 Switched Lighting Control
0x03 Network Bridges
0x04 Irrigation Control
0x05 Climate Control
...
You can query the Device's category with a Product Data Request message
cmd1=0x03, cmd2=0x00
The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.

ddamron

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
Re: Ruby code for EZ-Bridge (Insteon) RC1
« Reply #24 on: December 13, 2007, 09:30:31 pm »
Just pulled out my Insteon Dev guide..  Chapter 7, Page 83

Device Categories:

0x00 Generalized controllers
0x01 Dimmable Lighting Control
0x02 Switched Lighting Control
0x03 Network Bridges
0x04 Irrigation Control
0x05 Climate Control
...
You can query the Device's category with a Product Data Request message
cmd1=0x03, cmd2=0x00


I (will) interrogate the devices... and store them in a global hash (array of objects).
Currently, I create a 'reverse' hash for all child devices.

$children = {} # define the hash

then populate the hash like so:
device_.childdevices_.each{|c| $children[device_.childdevices_[c.to_s.to_i].devdata_[12].chomp.lstrip.rstrip] = c.to_s.to_i}

which effectively gives me this: InsteonID as the key, and the object (currently a string) has the child's LMCE device ID.

$children['11.11.11'] => '49'

Keep in mind, most commands (eg 192 ON, 193 OFF) correspond pretty much directly with Insteon Commands (11 ON, 13 OFF)
and the device Category only comes in to play when you have 'extended' properties..
Again, these extended properties correspond pretty much directly with Insteon commands...
all we are is an overglorified command massager to say "This command in LMCE is THIS command in INSTEON".

HTH

Dan
and YES, two people working on the same (or similar) project IS MUCH MUCH easier!

I still have some problems reporting back events and such...  Maybe you can tell me how you (in general terms) handle each command..

ie.  DCE sends you a '192 ON' command for a child..
How do you respond back?
I've tried sending a COMMAND (both from the child, and from my device).
I've tried sending an EVENT (from Child to DCERouter dev -1000)

Here's my problem:  When I click Office Light ON, DCE sends me the command, and it's handled fine.
Then I click Office Light OFF, I can see the command in the DCE log go out... but when it reaches my device, I get:
05   12/13/07 13:03:25.778      GSDMessageTranslator isCmdImplemented = false <0xb6016b90>
05   12/13/07 13:03:25.781      #### Pre-Process Queue = 1 <0xb6016b90>
05   12/13/07 13:03:25.781      _QueueProc Pre - 193 : 0 <0xb7819b90>
05   12/13/07 13:03:25.781      GSD-DispatchMessage - ignoring 193 because is useless. <0xb7819b90>
05   12/13/07 13:03:25.781      _QueueProc Post - 193 : 0 <0xb7819b90>

GSD-DispatchMessage - ignoring 193 because is useless..

This tells me I have to report to GSD that I have successfully turned on the child.

however, if I go into FLOORPLAN, and select the device, DIM it, then click ON (from there), I can then click OFF and the command is received.

I know most of that has to do with GSD, which your not using..

Problem is, I don't know C++ very well at all :(

The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.

PeteK

  • Guru
  • ****
  • Posts: 408
    • View Profile
Re: Ruby code for EZ-Bridge (Insteon) RC1
« Reply #25 on: December 13, 2007, 09:44:18 pm »
Just pulled out my Insteon Dev guide..  Chapter 7, Page 83

Keep in mind, most commands (eg 192 ON, 193 OFF) correspond pretty much directly with Insteon Commands (11 ON, 13 OFF)
and the device Category only comes in to play when you have 'extended' properties..
Again, these extended properties correspond pretty much directly with Insteon commands...
all we are is an overglorified command massager to say "This command in LMCE is THIS command in INSTEON".


Cool.  I wasn't certain that there was a standard set of commands for, say all irrigation devices.  I know the EZRain Valve Open Command is not 0x11.  I didn't know if the actual commands were all generated by SimpleHomeNet or if Insteon defined them.  The implementation could be more generic if it's the latter.

ddamron

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
Re: Ruby code for EZ-Bridge (Insteon) RC1
« Reply #26 on: December 13, 2007, 11:50:09 pm »
I have only speedread the irrigation details...
Insteon Dev guide shows:
0x40 Sprinkler Valve ON
0x41 Sprinkler Valve OFF
0x42 Sprinkler Program ON
0x43 Sprinkler Program OFF
0x44 Sprinkler Control with subcommands in cmd2:
(among others)
0x44 0x02 Get Valve Status
 etc..

LinuxMCE's command Structure:
Environment-Irrigation Devices - Irrigation Command Group #75
Delay # 257
Off # 193
ON # 192

I thought there was more..

ahh well, The EZRain1 does report its device info when requested to do so..
Keep in mind, LEGACY devices (Keypadlinc, Lamplinc, etc) do NOT report device category...
The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.

ddamron

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
Re: Ruby code for EZ-Bridge (Insteon) RC1
« Reply #27 on: December 14, 2007, 12:28:34 am »
Just did some quick testing on Product Data Request cmd 0x03

here's the results:
message sent:
02 62 - Standard Insteon Message
11 11 11 - InsteonID to:
0F - flags
03 00 (cmd1&2)

Legacy devices respond with:
02 62 11 11 11 0F 03 00 06 <-- response from the PLM saying Message Sent OK.

02 50 (Standard Message Received)
11 11 11 (from ID) Lamplinc
AA AA AA (to ID) PLM
2B (flags) - Ack of Direct Message, hopsleft=2, maxhops=3
03 00 (cmd1&cmd2) echoed back as is.

end of transmission.

The EZRain1 does the EXACT SAME THING, however, it also sends (after the above)
02 51 08 9B 62 AA AA AA 36 03 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00

then: {
02 51 08 9B 62 AA AA AA 3B 03 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00
} * 4

flags are different in the first Extended Message...
Don't know why it sends  the second extended message 4 times over...

disecting the first message as a Product Data Response ED:
02 51 08 9B 62 AA AA AA 36 03 00 blah blah standard stuff

00 D1 - Always set to 0x00
00 D2 - Insteon Product Key MSB
01 D3 - Insteon Product Key 2MSB
00 D4 Insteon Procude Key LSB
00 D5 Device Category
00 D6 - Device Subcategory
00 D7 - supposed to be FF
00 D8 - supposed to be FF
00  D9-D14 - User defined

Something doesn't add up here..
The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.

ddamron

  • Alumni
  • wants to work for LinuxMCE
  • *
  • Posts: 962
    • View Profile
    • My LinuxMCE User Page
Re: Ruby code for EZ-Bridge (Insteon) RC1
« Reply #28 on: December 14, 2007, 12:43:02 am »
I've posted a problem report on simplehomenet forums... let's see what they come back with.
The only intuitive interface is the nipple.  After that it's all learned.
My other computer is your windows box.
I'm out of my mind.  Back in 5 minutes.
Q:  What's Red and smells like blue paint?

A:  Red Paint.

PeteK

  • Guru
  • ****
  • Posts: 408
    • View Profile
Re: Ruby code for EZ-Bridge (Insteon) RC1
« Reply #29 on: December 14, 2007, 01:00:31 am »
Are you going through the EZbridge to the PLM for these results?  If so, I wouldn't rule out a problem with that device.  I'll try this weekend with the PLC and let you know if I see the same thing.