From: Chris E. <chr...@gm...> - 2012-04-19 01:53:20
|
So one of my appliancelincs died so I bought a new one and I'm unable to get it to work. The only thing I have found that works is manually running a status will tell me correctly if it is off or on, however I can't control it and I seem be getting issues with the link tables. First off this is not with the insteon branch but with the main trunk that I updated a couple of weeks ago. If I run scan link it runs for at least longer then 10 minutes. I haven't waited for it to complete. In the latest one I reset the device, Then ran a scan link table, after a minute or so I killed MH. Then I brought it back up. Here is a section the output of the scan link table: 18/04/2012 20:41:30 [Insteon_Device] $masterbed_fan2 command queued but not yet sent; awaiting ack from prior command 18/04/2012 20:41:30 [Insteon_PLM] Parsing serial data: 02621cf02a0f2b7e06 18/04/2012 20:41:30 [Insteon_PLM] Parsing serial data: 02501cf02a0fdf4d2b2bff 18/04/2012 20:41:30 [Insteon_PLM] Processing message for $masterbed_fan2 18/04/2012 20:41:30 [Insteon_Device] $masterbed_fan2 command queued but not yet sent; awaiting ack from prior command 18/04/2012 20:41:30 [Insteon_PLM] Parsing serial data: 02621cf02a0f2b7f06 18/04/2012 20:41:31 [Insteon_PLM] Parsing serial data: 02501cf02a0fdf4d2b2bff 18/04/2012 20:41:31 [Insteon_PLM] Processing message for $masterbed_fan2 18/04/2012 20:41:31 [Insteon_Device] $masterbed_fan2 accessing memory at location: 0x0F70 18/04/2012 20:41:31 [Insteon_Device] $masterbed_fan2 command queued but not yet sent; awaiting ack from prior command 18/04/2012 20:41:31 [Insteon_PLM] Parsing serial data: 02621cf02a0f280f06 18/04/2012 20:41:31 [Insteon_PLM] Parsing serial data: 02501cf02a0fdf4d2b28ff 18/04/2012 20:41:31 [Insteon_PLM] Processing message for $masterbed_fan2 18/04/2012 20:41:31 [Insteon_Device] $masterbed_fan2 command queued but not yet sent; awaiting ack from prior command 18/04/2012 20:41:31 [Insteon_PLM] Parsing serial data: 02621cf02a0f2b7006 18/04/2012 20:41:31 [Insteon_PLM] Parsing serial data: 02501cf02a0fdf4d2b2bff 18/04/2012 20:41:31 [Insteon_PLM] Processing message for $masterbed_fan2 18/04/2012 20:41:31 [Insteon_Device] $masterbed_fan2 command queued but not yet sent; awaiting ack from prior command 18/04/2012 20:41:32 [Insteon_PLM] Parsing serial data: 02621cf02a0f2b7106 18/04/2012 20:41:32 [Insteon_PLM] Parsing serial data: 02501cf02a0fdf4d2b2bff 18/04/2012 20:41:32 [Insteon_PLM] Processing message for $masterbed_fan2 18/04/2012 20:41:32 [Insteon_Device] $masterbed_fan2 command queued but not yet sent; awaiting ack from prior command 18/04/2012 20:41:32 [Insteon_PLM] Parsing serial data: 02621cf02a0f2b7206 18/04/2012 20:41:33 [Insteon_PLM] Parsing serial data: 02501cf02a0fdf4d2b2bff 18/04/2012 20:41:33 [Insteon_PLM] Processing message for $masterbed_fan2 18/04/2012 20:41:33 [Insteon_Device] $masterbed_fan2 command queued but not yet sent; awaiting ack from prior command 18/04/2012 20:41:33 [Insteon_PLM] Parsing serial data: 02621cf02a0f2b7306 18/04/2012 20:41:33 [Insteon_PLM] Parsing serial data: 02501cf02a0fdf4d2b2bff 18/04/2012 20:41:33 [Insteon_PLM] Processing message for $masterbed_fan2 18/04/2012 20:41:33 [Insteon_Device] $masterbed_fan2 command queued but not yet sent; awaiting ack from prior command 18/04/2012 20:41:33 [Insteon_PLM] Parsing serial data: 02621cf02a0f2b7406 18/04/2012 20:41:34 [Insteon_PLM] Parsing serial data: 02501cf02a0fdf4d2b2bff 18/04/2012 20:41:34 [Insteon_PLM] Processing message for $masterbed_fan2 18/04/2012 20:41:34 [Insteon_Device] $masterbed_fan2 command queued but not yet sent; awaiting ack from prior command 18/04/2012 20:41:34 [Insteon_PLM] Parsing serial data: 02621cf02a0f2b7506 18/04/2012 20:41:34 [Insteon_PLM] Parsing serial data: 02501cf02a0fdf4d2b2bff 18/04/2012 20:41:34 [Insteon_PLM] Processing message for $masterbed_fan2 18/04/2012 20:41:34 [Insteon_Device] $masterbed_fan2 command queued but not yet sent; awaiting ack from prior command 18/04/2012 20:41:34 [Insteon_PLM] Parsing serial data: 02621cf02a0f2b7606 18/04/2012 20:41:35 [Insteon_PLM] Parsing serial data: 02501cf02a0fdf4d2b2bff 18/04/2012 20:41:35 [Insteon_PLM] Processing message for $masterbed_fan2 18/04/2012 20:41:35 [Insteon_Device] $masterbed_fan2 command queued but not yet sent; awaiting ack from prior command 18/04/2012 20:41:35 [Insteon_PLM] Parsing serial data: 02621cf02a0f2b7706 18/04/2012 20:41:35 [Insteon_PLM] Parsing serial data: 02501cf02a0fdf4da72bff 18/04/2012 20:41:35 [Insteon_PLM] Processing message for $masterbed_fan2 18/04/2012 20:41:35 [Insteon_Device] WARN!! encountered a nack message for $masterbed_fan2 ... waiting for retry 18/04/2012 20:41:40 [Insteon_Device] WARN: queue timer on $masterbed_fan2 expired. Attempting resend: peek 18/04/2012 20:41:40 [Insteon_PLM] Parsing serial data: 02621cf02a0f2b7706 18/04/2012 20:41:40 [Insteon_PLM] Parsing serial data: 02501cf02a0fdf4d2b2bff 18/04/2012 20:41:40 [Insteon_PLM] Processing message for $masterbed_fan2 18/04/2012 20:41:40 [Insteon_Device] $masterbed_fan2 accessing memory at location: 0x0F68 18/04/2012 20:41:40 [Insteon_Device] $masterbed_fan2 command queued but not yet sent; awaiting ack from prior command 18/04/2012 20:41:40 [Insteon_PLM] Parsing serial data: 02621cf02a0f280f06 18/04/2012 20:41:41 [Insteon_PLM] Parsing serial data: 02501cf02a0fdf4d2b28ff 18/04/2012 20:41:41 [Insteon_PLM] Processing message for $masterbed_fan2 18/04/2012 20:41:41 [Insteon_Device] $masterbed_fan2 command queued but not yet sent; awaiting ack from prior command When I brought MH back up and ran log links here is the output 18/04/2012 20:42:23 Running: masterbed fan2 log links 18/04/2012 20:42:23 [Insteon_Device] WARN: queue timer on $upstairshall_kpl_A expired. Attempting resend: status_request 18/04/2012 20:42:23 [Insteon_Device] link table for $masterbed_fan2 (devcat: 0209): 18/04/2012 20:42:23 [Insteon_Device] aldb ffffffff1ff [0x0FF8] contlr(ff) record to ffffff(ff), (d1:ff, d2:ff, d3:ff) 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0F40] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0F48] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0F50] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0F58] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0F60] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0F68] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0F70] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0F78] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0F80] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0F88] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0F90] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0F98] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0FA0] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0FA8] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0FB0] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0FB8] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0FC0] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0FC8] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0FD0] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0FD8] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0FE0] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0FE8] holds a duplicate entry 18/04/2012 20:42:23 [Insteon_Device] adlb [0x0FF0] holds a duplicate entry Here is my insteon.mht entry IPLD, 1C.F0.2A, masterbed_fan2, MasterBedroom, PLM,0209 The appliancelinc is a 2456S3 Rev 4.6 Anybody run into this ? -- Chris |
From: Marc M. <ma...@me...> - 2012-04-19 16:44:30
|
On Wed, Apr 18, 2012 at 08:53:11PM -0500, Chris Engel wrote: > So one of my appliancelincs died so I bought a new one and I'm unable to > get it to work. The only thing I have found that works is manually running > a status will tell me correctly if it is off or on, however I can't control > it and I seem be getting issues with the link tables. Have you tried plugging the appliancelinc just next to your PLM to rule out powerline issues? Also, I suppose it's conceivable that it's not working right out of the box? Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
From: Chris E. <chr...@gm...> - 2012-04-19 19:35:16
|
I moved it to another outlet in my kitchen near the PLM and same issue On Thu, Apr 19, 2012 at 11:44 AM, Marc MERLIN <ma...@me...> wrote: > On Wed, Apr 18, 2012 at 08:53:11PM -0500, Chris Engel wrote: > > So one of my appliancelincs died so I bought a new one and I'm unable to > > get it to work. The only thing I have found that works is manually > running > > a status will tell me correctly if it is off or on, however I can't > control > > it and I seem be getting issues with the link tables. > > Have you tried plugging the appliancelinc just next to your PLM to rule out > powerline issues? > > Also, I suppose it's conceivable that it's not working right out of the > box? > > Marc > -- > "A mouse is a device used to point at the xterm you want to type in" - > A.S.R. > Microsoft is to operating systems .... > .... what McDonalds is to gourmet > cooking > Home page: http://marc.merlins.org/ > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > -- Chris |
From: Jim D. <ji...@du...> - 2012-04-20 01:05:05
|
On 04/19/2012 03:35 PM, Chris Engel wrote: > I moved it to another outlet in my kitchen near the PLM and same issue > nnu I would try an manally link it to some controller (switch) outside of MH to see if it just works as a normal Insteon device. If it doesn't you can RMA it back to smarthome. Jim |
From: Chris E. <chr...@gm...> - 2012-04-20 13:40:43
|
Good idea, I will try that later tonight. On Thu, Apr 19, 2012 at 8:04 PM, Jim Duda <ji...@du...> wrote: > On 04/19/2012 03:35 PM, Chris Engel wrote: > > I moved it to another outlet in my kitchen near the PLM and same issue > > nnu > > I would try an manally link it to some controller (switch) outside of > MH to see if it just works as a normal Insteon device. If it doesn't > you can RMA it back to smarthome. > > Jim > > > > ------------------------------------------------------------------------------ > For Developers, A Lot Can Happen In A Second. > Boundary is the first to Know...and Tell You. > Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! > http://p.sf.net/sfu/Boundary-d2dvs2 > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > -- Chris |
From: Chris E. <chr...@gm...> - 2012-04-27 00:46:19
|
I would try an manally link it to some controller (switch) outside of > MH to see if it just works as a normal Insteon device. If it doesn't >> you can RMA it back to smarthome. >> >> Jim >> > I finally got around to manual linking and it works just fine. So I decided to dig into the trace more to figure out what was going on. Here is the first command sent out to a working appliancelinc with older firmware : 26/04/2012 19:10:49 [Insteon_PLM] Executing command:0262145E900F280F: 26/04/2012 19:10:49 [Insteon_PLM] Parsing serial data: 0262145e900f280f06 26/04/2012 19:10:49 [Insteon_PLM] Parsing serial data: 0250145e900fdf4d27280f The first is the command going out (I added this into Insteon_PLM as it was commented out) The command portion is 280f This command is Set Address MSB (0x28) to value 0x0f The second line is the ack on the command (notice same command with 0x06 on end) The third is the results from the command with the data portion being 28 0f , so it appears to just resend the command and value back. Now however when I run this against the failing one I get this : 26/04/2012 19:22:47 [Insteon_PLM] Executing command:02621CF02A0F280F: 26/04/2012 19:22:47 [Insteon_PLM] Parsing serial data: 02621cf02a0f280f06 26/04/2012 19:22:47 [Insteon_PLM] Parsing serial data: 02501cf02a0fdf4d2728ff The first is the command going out again, same command but different address (1cf02a) Then the ack back Finally the data returned, which doesn't appear correct 28 ff , it is sending back ff instead of 0f. Not sure if this is it's way of saying there is an issue. So, looking at this document that was dated 2007 http://www.*insteon* .net/pdf/*INSTEON*_Command_Tables_20070925a.pdf. On page 10 you will find the description of command 0x28 'Set Address MSB' and it says : Deprecated (do not use in the future). So if this instruction was due to be deprecated in 2007 is it possible that with my new appliancelinc it has actually been removed ? Does the insteon branch use this same mechanism to scan the link tables ? This still doesn't explain why simple on/off commands do not work to this device. -- Chris |
From: Michael B. <bro...@ya...> - 2012-04-27 00:53:29
|
On 2012-04-26, at 20:42, Chris Engel <chrisengel@> wrote: > I would try an manally link it to some controller (switch) outside of > MH to see if it just works as a normal Insteon device. If it doesn't > you can RMA it back to smarthome. > > Jim > > I finally got around to manual linking and it works just fine. So I decided to dig into the trace more to figure out what was going on. > > Here is the first command sent out to a working appliancelinc with older firmware : > 26/04/2012 19:10:49 [Insteon_PLM] Executing command:0262145E900F280F: > 26/04/2012 19:10:49 [Insteon_PLM] Parsing serial data: 0262145e900f280f06 > 26/04/2012 19:10:49 [Insteon_PLM] Parsing serial data: 0250145e900fdf4d27280f > > The first is the command going out (I added this into Insteon_PLM as it was commented out) > The command portion is 280f > This command is Set Address MSB (0x28) to value 0x0f > The second line is the ack on the command (notice same command with 0x06 on end) > The third is the results from the command with the data portion being 28 0f , so it appears to just resend the command and value back. > > Now however when I run this against the failing one I get this : > 26/04/2012 19:22:47 [Insteon_PLM] Executing command:02621CF02A0F280F: > 26/04/2012 19:22:47 [Insteon_PLM] Parsing serial data: 02621cf02a0f280f06 > 26/04/2012 19:22:47 [Insteon_PLM] Parsing serial data: 02501cf02a0fdf4d2728ff > > The first is the command going out again, same command but different address (1cf02a) > Then the ack back > Finally the data returned, which doesn't appear correct 28 ff , it is sending back ff instead of 0f. Not sure if this is it's way of saying there is an issue. > > So, looking at this document that was dated 2007 http://www.insteon.net/pdf/INSTEON_Command_Tables_20070925a.pdf. On page 10 you will find the description of command 0x28 'Set Address MSB' and it says : Deprecated (do not use > in the future). > > So if this instruction was due to be deprecated in 2007 is it possible that with my new appliancelinc it has actually been removed ? > > Does the insteon branch use this same mechanism to scan the link tables ? > > This still doesn't explain why simple on/off commands do not work to this device. > > > -- > Chris Chris, I was reading the SmartHome forums, and around mid-march they started shipping devices with i2cs (Insteon 2 Check-Summing), which is a new Insteon protocol. The statements in the forums is that software will have to be updated to work with the new protocol. So, MH's Insteon support will need an update before your new device will work under MH control. HTH! /Mike |
From: Chris E. <chr...@gm...> - 2012-04-27 03:06:15
|
Interesting stuff about this i2cs, for my particular issue I found this comment : (We know it can take advantage of other features such as using extended msg link records, like Brian previously mentioned in another post, getting rid of peek and poke) The Set Address MSB command I was referring to is setting up an address to be later used with the peek command, so if that command is completely gone that explains my issue. And yah, it sounds like everything after sometime in March shipped with this new I2CS protocol. On Thu, Apr 26, 2012 at 7:52 PM, Michael Brown <bro...@ya...> wrote: > On 2012-04-26, at 20:42, Chris Engel <chrisengel@> wrote: > > I would try an manally link it to some controller (switch) outside of > >> MH to see if it just works as a normal Insteon device. If it doesn't >>> you can RMA it back to smarthome. >>> >>> Jim >>> >> > I finally got around to manual linking and it works just fine. So I > decided to dig into the trace more to figure out what was going on. > > Here is the first command sent out to a working appliancelinc with older > firmware : > 26/04/2012 19:10:49 [Insteon_PLM] Executing command:0262145E900F280F: > 26/04/2012 19:10:49 [Insteon_PLM] Parsing serial data: 0262145e900f280f06 > 26/04/2012 19:10:49 [Insteon_PLM] Parsing serial data: > 0250145e900fdf4d27280f > > The first is the command going out (I added this into Insteon_PLM as it > was commented out) > The command portion is 280f > This command is Set Address MSB (0x28) to value 0x0f > The second line is the ack on the command (notice same command with 0x06 > on end) > The third is the results from the command with the data portion being 28 > 0f , so it appears to just resend the command and value back. > > Now however when I run this against the failing one I get this : > 26/04/2012 19:22:47 [Insteon_PLM] Executing command:02621CF02A0F280F: > 26/04/2012 19:22:47 [Insteon_PLM] Parsing serial data: 02621cf02a0f280f06 > 26/04/2012 19:22:47 [Insteon_PLM] Parsing serial data: > 02501cf02a0fdf4d2728ff > > The first is the command going out again, same command but different > address (1cf02a) > Then the ack back > Finally the data returned, which doesn't appear correct 28 ff , it is > sending back ff instead of 0f. Not sure if this is it's way of saying > there is an issue. > > So, looking at this document that was dated 2007 http://www.*insteon* > .net/pdf/*INSTEON*_Command_Tables_20070925a.pdf. On page 10 you will > find the description of command 0x28 'Set Address MSB' and it says : > Deprecated (do not use > > in the future). > > So if this instruction was due to be deprecated in 2007 is it possible > that with my new appliancelinc it has actually been removed ? > > Does the insteon branch use this same mechanism to scan the link tables ? > > This still doesn't explain why simple on/off commands do not work to this > device. > > > -- > Chris > > > Chris, > > I was reading the SmartHome forums, and around mid-march they started > shipping devices with i2cs (Insteon 2 Check-Summing), which is a new > Insteon protocol. The statements in the forums is that software will have > to be updated to work with the new protocol. So, MH's Insteon support will > need an update before your new device will work under MH control. > > HTH! > > /Mike > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 > > > -- Chris |
From: Chris E. <chr...@gm...> - 2012-04-27 03:28:02
|
FIXED my issue ... Interesting info especially here : http://forum.universal-devices.com/viewtopic.php?f=30&t=8434&start=15 Here is a nice post : I updated the device list at http://www.madreporite.com/insteon/Inst ... e_list.htm <http://www.madreporite.com/insteon/Insteon_device_list.htm>(it's now also split into several tabs across the bottom of the table). Not much more info than is already posted here though. For the sake of summing everything up, here is what I have gathered about i2cs so far: CS in the name refers to "checksum". All extended messages place a checksum byte in D14. How this is computed or checked... uncertain. Wired i2cs devices must specifically be linked as a responder before they will accept commands. It is no longer possible to send direct commands to unlinked devices. (Uncertain whether this refers to all i2cs devices or only some.) After an i2cs device sends a broadcast message, it will send a report of how many devices didn't respond with a cleanup message. It is possible to set how many times cleanup direct messages are set after a group broadcast. Also, previously any other Insteon traffic would cancel these messages. It is now possible to turn on a message that forces a device to finish cleanup. x10 is removed from some devices The Get Insteon Engine Version command will return a value of 0xFF and a NAK if the i2cs device is not linked to the PLM. If it is linked, it will return a 0x02 which is the i2cs indicator. i2cs devices mostly do not support Peek/Poke. As with other aspects of the protocol, not every device supports every command. ------- So as you can see there the peek/poke method of access the link table are gone and the one that was getting in my way is wired devices no longer respond to dircect commands (on/off) from unlinked devices. So to fix my issue so I can at least switch on/off the appliancelinc with MH I had to manually link the PLM to the appliancelinc by holding down the set button on the PLM for 10 secs. Then I pressed the set button on the appliancelinc. Now I can control it properly. Do the people working on the insteon branch know about these changes coming ? -- Chris |
From: Gregg L. <gr...@li...> - 2012-04-27 13:16:17
|
On 4/26/2012 11:27 PM, Chris Engel wrote: > Do the people working on the insteon branch know about these changes > coming ? Hi Chris, First, thank-you for the write-up; I'm sure it will be useful to those that may continue insteon development. Personally, I've been very distracted from contributing to the insteon branch. What time that I have had has been investigating issues that Marc has identified for me. By the way, Marc has been extremely helpful in testing out the branch. I suspect that my contributions to the branch are not only waning but they will not extend into i2c specific support. Without a doubt, it should be far more possible to incorporate i2c messaging in the branch whereas the trunk code is essentially impossible. But, either way, it will require a champion or champions to pursue it. Regards, Gregg |
From: John B. <pm...@gm...> - 2012-05-02 19:43:03
|
Chris Engel wrote: > > CS in the name refers to "checksum". All extended messages place a > checksum > byte in D14. How this is computed or checked... uncertain. > For those out there that are interested, I did a bit of research to try to figure out how to use the PLM to send commands to the devices using the new i2CS. From various online sources I collected a few command traces that use i2CS: 1. 0262 XXXXXX 1F 6B 09 00000000000000000000000000 8C 2. 0262 XXXXXX 1F 2F 000000 0F FF 01 0000000000000000 C2 3. 0262 XXXXXX 1F 2F 000000 0F F7 01 0000000000000000 CA 4. 0262 XXXXXX 1F 2F 000000 0F EF 01 0000000000000000 D2 I quickly noticed that the bytes representing the device ID (XXXXXX) are not used to compute the checksum as I was able to send the first command to a new thermostat adapter (using i2CS) and it worked to turn it off. While I did not figure out how the checksum is computed, I noticed that, from one command to another, the offset in the addition of all the bytes, after the device ID bytes, matches the inverse offset in the checksum. Let us look at the commands 2 and 3 above for an example. The checksum of command 2 is 0xC2 which is smaller than the checksum of command 3, 0xCA, by 0x08 units. The sum of the extended command bytes in command 2 is 0x10F and for the command 3 is 0x107. The difference between the two sums is again 0x08. But as the difference in sums is positive, the difference in the checksums is negative. This is what I mean by "inverse" offset. By using this approach, various other commands can be built. These are examples of commands used for the thermostat adapter: 1. 0262 XXXXXX 1F 6B 09 00000000000000000000000000 8C - thermostat off 2. 0262 XXXXXX 1F 6B 04 00000000000000000000000000 91 - heat on 3. 0262 XXXXXX 1F 6B 0A 00000000000000000000000000 8B - heat program 4. 0262 XXXXXX 1F 6D 90 00000000000000000000000000 03 - heat at 72F Looking forward to learn about the actual algorithm used to compute the checksum. Form what I can tell it may be the 16 bit 2's complement checksum. Cheers, JB -- View this message in context: http://old.nabble.com/Problems-with-new-insteon-appliancelinc-tp33711714p33763391.html Sent from the Misterhouse - User mailing list archive at Nabble.com. |
From: Marc M. <ma...@me...> - 2012-05-05 22:48:51
|
On Wed, May 02, 2012 at 12:42:57PM -0700, John Branch wrote: > > > Chris Engel wrote: > > > > CS in the name refers to "checksum". All extended messages place a > > checksum > > byte in D14. How this is computed or checked... uncertain. > > > > For those out there that are interested, I did a bit of research to try to > figure out how to use the PLM to send commands to the devices using the new > i2CS. From various online sources I collected a few command traces that use > i2CS: > > 1. 0262 XXXXXX 1F 6B 09 00000000000000000000000000 8C > 2. 0262 XXXXXX 1F 2F 000000 0F FF 01 0000000000000000 C2 > 3. 0262 XXXXXX 1F 2F 000000 0F F7 01 0000000000000000 CA > 4. 0262 XXXXXX 1F 2F 000000 0F EF 01 0000000000000000 D2 > > I quickly noticed that the bytes representing the device ID (XXXXXX) are not > used to compute the checksum as I was able to send the first command to a > new thermostat adapter (using i2CS) and it worked to turn it off. > > While I did not figure out how the checksum is computed, I noticed that, > from one command to another, the offset in the addition of all the bytes, > after the device ID bytes, matches the inverse offset in the checksum. Let > us look at the commands 2 and 3 above for an example. > > The checksum of command 2 is 0xC2 which is smaller than the checksum of > command 3, 0xCA, by 0x08 units. The sum of the extended command bytes in > command 2 is 0x10F and for the command 3 is 0x107. The difference between > the two sums is again 0x08. But as the difference in sums is positive, the > difference in the checksums is negative. This is what I mean by "inverse" > offset. > > By using this approach, various other commands can be built. These are > examples of commands used for the thermostat adapter: > > 1. 0262 XXXXXX 1F 6B 09 00000000000000000000000000 8C - thermostat off > 2. 0262 XXXXXX 1F 6B 04 00000000000000000000000000 91 - heat on > 3. 0262 XXXXXX 1F 6B 0A 00000000000000000000000000 8B - heat program > 4. 0262 XXXXXX 1F 6D 90 00000000000000000000000000 03 - heat at 72F > > Looking forward to learn about the actual algorithm used to compute the > checksum. Form what I can tell it may be the 16 bit 2's complement checksum. Thanks for the updates. I'm sure that you know you will get fame and glory if you add some of this support in misterhouse when you figure it out :) In your case, I absolutely recommend that you look at the insteon branch for adding code, since Gregg cleaned it up massively so that it would allow for adding new objects and support of protocols like this one. Thanks for looking into this. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |