From: Michael S. <mi...@st...> - 2013-02-17 20:27:28
|
I just submitted updates to support delete_orphan_links into mstovenour/misterhouse/i2_aldb_support. The code is almost caught up with the i1 support at this point. There are a few more functions to add (update_local_properties, update_flags, get_link_record). One important issue that exists now is the mapping of I2/I2CS devices to the ALDB_i2 package at startup or reload. This is very fragile right now and requires either 1) an initial startup scan that "succeeds" to each device or 2) manually executing get engine version on every device. It is unfortunate for now but this must occur every time MH is restarted or reloaded. This is a high priority item for me and I'll be working on that next. If anyone knows how to add code that will run after the MH built in object restore you could save me a few hours of poking around in the guts (i.e. mh main Perl file). I suspect there is a way to add "hook" code for this point in the initialization but I'm not sure how. Sincerely, Michael |
From: Marc M. <ma...@me...> - 2013-02-17 22:12:27
|
On Sun, Feb 17, 2013 at 02:27:50PM -0600, Michael Stovenour wrote: > I just submitted updates to support delete_orphan_links into > mstovenour/misterhouse/i2_aldb_support. The code is almost caught up with the i1 support > at this point. There are a few more functions to add (update_local_properties, > update_flags, get_link_record). Awesome, great milestone! > One important issue that exists now is the mapping of I2/I2CS devices to the ALDB_i2 > package at startup or reload. This is very fragile right now and requires either 1) an > initial startup scan that "succeeds" to each device or 2) manually executing get engine > version on every device. It is unfortunate for now but this must occur every time MH is > restarted or reloaded. This is a high priority item for me and I'll be working on that > next. The scan works for most. I'm not sure why it failed once for me. If the last logs I sent you don't help figuring out why and you'd like more, let me know. Also, given the errors I sent you just a few days ago, and the aborted scan all, should I try again, or you're still going through the errors I sent you? > If anyone knows how to add code that will run after the MH built in object restore you > could save me a few hours of poking around in the guts (i.e. mh main Perl file). I > suspect there is a way to add "hook" code for this point in the initialization but I'm not > sure how. Are you saying you can't use $Startup? I have this in some of my non library code: IO_input.pl:if ($Startup || $Reload) Not sure if this is what you were looking for, though. 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: Marc M. <ma...@me...> - 2013-02-17 22:40:54
|
So, I tried scan all with your just updated code, and aborted with no message again. 17/02/2013 14:31:49 [Insteon_PLM] DEBUG3: Saving parsed data fragment: 025010948818d4ce 17/02/2013 14:31:49 [Insteon_PLM] DEBUG3: Prepending prior data fragment: 025010948818d4ce 17/02/2013 14:31:49 [Insteon_PLM] DEBUG3: Received PLM raw data: 025010948818d4ce262f00 17/02/2013 14:31:49 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 10:94:88 To Address: 18:d4:ce Message Flags: 26 Message Type: (001) ACK of Direct Message Message Length: (0) Standard Length Hops Left: 1 Max Hops: 2 Insteon Message: 2f00 Cmd 1: (2f) Light OFF at Ramp Rate Cmd 2: (00) Ramp Rate 17/02/2013 14:31:49 [Insteon::BaseInterface] DEBUG2: Message received with 1 hops left, delaying next transmit to avoid collisions with remaining hops. 17/02/2013 14:31:49 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 14:31:49 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0fd7] received: 00 for _mem_activity=scan _mem_action=aldb_i2read 17/02/2013 14:31:49 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0fd7] received ack 17/02/2013 14:32:00 : Saving object states ... done It looks like Saving objects causes the scan to stop. If I force a new one without restarting mh: 17/02/2013 14:33:35 Running: PLM scan all device link tables 17/02/2013 14:33:35 [Scan all linktables] WARN: link already underway. Ignoring request for new scan ... I also saw that Kevin checked in his hop count code to master. I'm not sure if it's easy for you to merge that, but it may help with some harder to reach I1 devices. So, I restarted again, and I got no initial scan. Looks like the PLM info command didn't return for some reason. 17/02/2013 14:34:51 Reading /var/local/src/misterhouse/mh.private.ini and mh.ini Voice names: Microsoft Mary, Microsoft Mike, Microsoft Sam Read 4 entries from ./../data/pronouncable_words.list 17/02/2013 14:34:51 Reading 1 .mht table files: items.mht 17/02/2013 14:34:51 Translating items.mht -> /var/local/src/misterhouse/code/items.mhp 17/02/2013 14:34:51 Initialized read_table_A.pl Reading code_dirs: /var/local/src/misterhouse/code ./../code/common 17/02/2013 14:34:51 Reading 34 code files 17/02/2013 14:34:51 hvac has 999999999999 allowed errors before being disabled 17/02/2013 14:34:51 omnistat has 999999999999 allowed errors before being disabled 17/02/2013 14:34:51 Evaluating user code 17/02/2013 14:34:51 [Insteon] Setting up initialization hooks 17/02/2013 14:34:51 [Insteon_PLM] setting default xmit delay to: 0.25 17/02/2013 14:34:51 [Insteon_PLM] setting x10 xmit delay to: 0.5 17/02/2013 14:34:51 [X10_Sensor] Calling Serial_match_add_hook 17/02/2013 14:34:51 Installed Dump Master Timers voice command 17/02/2013 14:34:51 HAI Thermostat 1 initialized 17/02/2013 14:34:51 HAI Thermostat 2 initialized 17/02/2013 14:34:51 Main Omnistat: Mh restarted, will reconfigure stat 17/02/2013 14:34:51 MBR Omnistat: Mh restarted, will reconfigure stat Good code saved 17/02/2013 14:34:51 running: play ./../sounds/sound_click1.wav Playing sound file ./../sounds/sound_click1.wav Restoring object states Object states restored 17/02/2013 14:34:51 [Insteon_PLM] DEBUG2: Sending obj=$PLM; interface_data= incurred delay of 0.00 seconds; starting hop-count: ? 17/02/2013 14:34:51 [Insteon_PLM] DEBUG3: Sending PLM raw data: 0260 17/02/2013 14:34:51 [Insteon_PLM] DEBUG4: PLM Command: (0260) plm_info 17/02/2013 14:34:51 Generating Voice commands for all Insteon objects Activating voice commands Starting monitor commands loop Latitude: 37.3, Longitude: -121.9, Time Zone: -8 sunrise=6:55 sunset=17:49 sunrise twilight=6:28 sunset twilight=18:16 The moon is Half Waxing, 47% bright, and 7 days old The next full moon is on Wednesday, March 27th 17/02/2013 14:34:53 Rereading .menu code files. 17/02/2013 14:34:53 Generating Voice commands for all X10 objects 17/02/2013 14:34:55 House Stat Output: , FMR Booster Fan: off, MBR Stat Output: off (OUTPUT CHANGED from ), MBR Booster Fan: off, Damper status: hvac 17/02/2013 14:34:55 MYLOG7: House Stat Output: , FMR Booster Fan: off, MBR Stat Output: off (OUTPUT CHANGED from ), MBR Booster Fan: off, Damper status: hvac 17/02/2013 14:35:00 : Saving object states ... done I tried yet again, and it worked then. I think what happens is that PLM info does not work if mh is killed while it's talking to the plm, and then restarted. If that info command doens't work, then the initial scan doesn't happen. IMO, the code should likely die here instead of continuing, or output a very big warning. I'll retry one more scan all and report if it works. Hope this helps. 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: Marc M. <ma...@me...> - 2013-02-17 23:07:30
|
On Sun, Feb 17, 2013 at 02:40:46PM -0800, Marc MERLIN wrote: > IMO, the code should likely die here instead of continuing, or output a very > big warning. > > I'll retry one more scan all and report if it works. So, I found a problem that was causing issues. 3 of my I1 KPLs are on their last legs it seems. They wouldn't reply to requires at startup, and it looks like the startup code has issues with some devices not responding. I power cycled them, no they respond, and now the initial scan is working better. Ok, here's my last try: 17/02/2013 14:59:18 [Scan all link tables] Now scanning: $fmr_outside (11 of 27) 17/02/2013 14:59:19 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0000] received: 00 for _mem_activity=scan _mem_action=aldb_i2read 17/02/2013 14:59:19 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 14:59:19 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0000] received: 0001010fff01a21218d4ceff000000 for _mem_activity=scan _mem_action=aldb_i2readack 17/02/2013 14:59:19 [Insteon::ALDB_i2] DEBUG4: Start of scan; initializing aldb structure 17/02/2013 14:59:19 [Insteon::ALDB_i2] DEBUG4: active link found; adding address [0fff] to aldb 17/02/2013 14:59:20 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0ff7] received: 00 for _mem_activity=scan _mem_action=aldb_i2read 17/02/2013 14:59:20 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 14:59:20 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0ff7] received: 0001010ff701a2060e0912ff000000 for _mem_activity=scan _mem_action=aldb_i2readack 17/02/2013 14:59:20 [Insteon::ALDB_i2] DEBUG4: active link found; adding address [0ff7] to aldb 17/02/2013 14:59:20 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0fef] received: 00 for _mem_activity=scan _mem_action=aldb_i2read 17/02/2013 14:59:20 [Insteon::BaseInterface] WARN: received insteon ACK/NACK message from $fmr_outside but cannot correlate to sent message! IGNORING received message!! 17/02/2013 14:59:21 [Insteon::BaseInterface] WARN: received insteon ACK/NACK message from $fmr_outside but cannot correlate to sent message! IGNORING received message!! and it stopped there ^^^^ Now, I think it's fair to say that the problem on my network are obviously hitting corner cases that the code isn't quite ready for and may not even be able to handle in any reasonable way anyway. Maybe Kevin's hop count code would help. I'll try putting my PLM into my UPS now to see if that makes a difference. Here's the unabridged log if that helps. 17/02/2013 14:59:17 [Insteon::ALDB_i2] DEBUG3: $fmr_lamp [0x0fc7] received: 00 for _mem_activity=scan _mem_action=aldb_i2read 17/02/2013 14:59:17 [Insteon::ALDB_i2] DEBUG3: $fmr_lamp [0x0fc7] received ack 17/02/2013 14:59:17 [Insteon_PLM] DEBUG3: Received PLM raw data: 0251187d5318d4ce112f0001010fc701a21018d4cefe1f0000 17/02/2013 14:59:17 [Insteon_PLM] DEBUG4: PLM Command: (0251) insteon_ext_received From Address: 18:7d:53 To Address: 18:d4:ce Message Flags: 11 Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 0 Max Hops: 1 Insteon Message: 2f0001010fc701a21018d4cefe1f0000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 01010fc701a21018d4cefe1f0000 17/02/2013 14:59:17 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 14:59:17 [Insteon::BaseInterface] DEBUG: PLM command:insteon_ext_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 14:59:17 [Insteon::BaseInterface] Processing message for $fmr_lamp 17/02/2013 14:59:17 [Insteon::ALDB_i2] DEBUG3: $fmr_lamp [0x0fc7] received: 0001010fc701a21018d4cefe1f0000 for _mem_activity=scan _mem_action=aldb_i2readack 17/02/2013 14:59:17 [Insteon::ALDB_i2] DEBUG4: active link found; adding address [0fc7] to aldb 17/02/2013 14:59:17 [Insteon_PLM] DEBUG2: Sending obj=$fmr_lamp; command=read_write_aldb; extra=0000000fbf01000000000000000000 incurred delay of 0.06 seconds; starting hop-count: 1 17/02/2013 14:59:17 [Insteon_PLM] DEBUG3: Sending PLM raw data: 0262187d53152f0000000fbf01000000000000000000 17/02/2013 14:59:17 [Insteon_PLM] DEBUG4: PLM Command: (0262) insteon_send To Address: 18:7d:53 Message Flags: 15 Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 1 Max Hops: 1 Insteon Message: 2f0000000fbf01000000000000000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 00000fbf01000000000000000000 17/02/2013 14:59:17 [Insteon_PLM] DEBUG3: Received PLM raw data: 0262187d53152f0000000fbf0100000000000000000006 17/02/2013 14:59:17 [Insteon_PLM] DEBUG4: PLM Command: (0262) insteon_send To Address: 18:7d:53 Message Flags: 15 Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 1 Max Hops: 1 Insteon Message: 2f0000000fbf01000000000000000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 00000fbf0100000000000000000006 PLM Response: (06) ACK 17/02/2013 14:59:17 [Insteon_PLM] DEBUG3: Received PLM acknowledge: obj=$fmr_lamp; command=read_write_aldb; extra=0000000fbf01000000000000000000 17/02/2013 14:59:17 [Insteon_PLM] DEBUG3: Received PLM raw data: 0250187d5318d4ce212f00 17/02/2013 14:59:17 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 18:7d:53 To Address: 18:d4:ce Message Flags: 21 Message Type: (001) ACK of Direct Message Message Length: (0) Standard Length Hops Left: 0 Max Hops: 1 Insteon Message: 2f00 Cmd 1: (2f) Light OFF at Ramp Rate Cmd 2: (00) Ramp Rate 17/02/2013 14:59:17 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 14:59:17 [Insteon::ALDB_i2] DEBUG3: $fmr_lamp [0x0fbf] received: 00 for _mem_activity=scan _mem_action=aldb_i2read 17/02/2013 14:59:17 [Insteon::ALDB_i2] DEBUG3: $fmr_lamp [0x0fbf] received ack 17/02/2013 14:59:18 [Insteon_PLM] DEBUG3: Received PLM raw data: 02 17/02/2013 14:59:18 [Insteon_PLM] DEBUG4: 17/02/2013 14:59:18 [Insteon_PLM] DEBUG3: Saving parsed data fragment: 02 17/02/2013 14:59:18 [Insteon_PLM] DEBUG3: Prepending prior data fragment: 02 17/02/2013 14:59:18 [Insteon_PLM] DEBUG3: Received PLM raw data: 0251187d5318d4ce112f0001010fbf01a2011dc5bcfe1f0000 17/02/2013 14:59:18 [Insteon_PLM] DEBUG4: PLM Command: (0251) insteon_ext_received From Address: 18:7d:53 To Address: 18:d4:ce Message Flags: 11 Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 0 Max Hops: 1 Insteon Message: 2f0001010fbf01a2011dc5bcfe1f0000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 01010fbf01a2011dc5bcfe1f0000 17/02/2013 14:59:18 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 14:59:18 [Insteon::BaseInterface] DEBUG: PLM command:insteon_ext_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 14:59:18 [Insteon::BaseInterface] Processing message for $fmr_lamp 17/02/2013 14:59:18 [Insteon::ALDB_i2] DEBUG3: $fmr_lamp [0x0fbf] received: 0001010fbf01a2011dc5bcfe1f0000 for _mem_activity=scan _mem_action=aldb_i2readack 17/02/2013 14:59:18 [Insteon::ALDB_i2] DEBUG4: duplicate link found; adding address [0fbf] to duplicates array 17/02/2013 14:59:18 [Insteon_PLM] DEBUG2: Sending obj=$fmr_lamp; command=read_write_aldb; extra=0000000fb701000000000000000000 incurred delay of 0.05 seconds; starting hop-count: 1 17/02/2013 14:59:18 [Insteon_PLM] DEBUG3: Sending PLM raw data: 0262187d53152f0000000fb701000000000000000000 17/02/2013 14:59:18 [Insteon_PLM] DEBUG4: PLM Command: (0262) insteon_send To Address: 18:7d:53 Message Flags: 15 Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 1 Max Hops: 1 Insteon Message: 2f0000000fb701000000000000000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 00000fb701000000000000000000 17/02/2013 14:59:18 [Insteon_PLM] DEBUG3: Received PLM raw data: 0262187d53152f0000000fb70100000000000000000006 17/02/2013 14:59:18 [Insteon_PLM] DEBUG4: PLM Command: (0262) insteon_send To Address: 18:7d:53 Message Flags: 15 Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 1 Max Hops: 1 Insteon Message: 2f0000000fb701000000000000000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 00000fb70100000000000000000006 PLM Response: (06) ACK 17/02/2013 14:59:18 [Insteon_PLM] DEBUG3: Received PLM acknowledge: obj=$fmr_lamp; command=read_write_aldb; extra=0000000fb701000000000000000000 17/02/2013 14:59:18 [Insteon_PLM] DEBUG3: Received PLM raw data: 0250187d5318d4ce212f00 17/02/2013 14:59:18 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 18:7d:53 To Address: 18:d4:ce Message Flags: 21 Message Type: (001) ACK of Direct Message Message Length: (0) Standard Length Hops Left: 0 Max Hops: 1 Insteon Message: 2f00 Cmd 1: (2f) Light OFF at Ramp Rate Cmd 2: (00) Ramp Rate 17/02/2013 14:59:18 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 14:59:18 [Insteon::ALDB_i2] DEBUG3: $fmr_lamp [0x0fb7] received: 00 for _mem_activity=scan _mem_action=aldb_i2read 17/02/2013 14:59:18 [Insteon::ALDB_i2] DEBUG3: $fmr_lamp [0x0fb7] received ack 17/02/2013 14:59:18 [Insteon_PLM] DEBUG3: Received PLM raw data: 0251187d5318d4ce112f0001010fb701000000000000000000 17/02/2013 14:59:18 [Insteon_PLM] DEBUG4: PLM Command: (0251) insteon_ext_received From Address: 18:7d:53 To Address: 18:d4:ce Message Flags: 11 Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 0 Max Hops: 1 Insteon Message: 2f0001010fb701000000000000000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 01010fb701000000000000000000 17/02/2013 14:59:18 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 14:59:18 [Insteon::BaseInterface] DEBUG: PLM command:insteon_ext_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 14:59:18 [Insteon::BaseInterface] Processing message for $fmr_lamp 17/02/2013 14:59:18 [Insteon::ALDB_i2] DEBUG3: $fmr_lamp [0x0fb7] received: 0001010fb701000000000000000000 for _mem_activity=scan _mem_action=aldb_i2readack 17/02/2013 14:59:18 [Insteon::ALDB_i2] DEBUG4: scan done; adding last address [0fb7] to empty array 17/02/2013 14:59:18 [Insteon::ALDB_i2] $fmr_lamp completed aldb scan: status: good 17/02/2013 14:59:18 [Scan all link tables] Now scanning: $fmr_outside (11 of 27) 17/02/2013 14:59:18 [Insteon::ALDB_i2] $fmr_outside reading ALDB at location: 0x0000 17/02/2013 14:59:18 [Insteon_PLM] DEBUG2: Sending obj=$fmr_outside; command=read_write_aldb; extra=000000000001000000000000000000 incurred delay of 0.05 seconds; starting hop-count: 2 17/02/2013 14:59:18 [Insteon_PLM] DEBUG3: Sending PLM raw data: 02621094881a2f000000000001000000000000000000 17/02/2013 14:59:18 [Insteon_PLM] DEBUG4: PLM Command: (0262) insteon_send To Address: 10:94:88 Message Flags: 1a Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 2 Max Hops: 2 Insteon Message: 2f000000000001000000000000000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 0000000001000000000000000000 17/02/2013 14:59:18 [Insteon_PLM] DEBUG3: Received PLM raw data: 02621094881a2f00000000000100000000000000000006 17/02/2013 14:59:18 [Insteon_PLM] DEBUG4: PLM Command: (0262) insteon_send To Address: 10:94:88 Message Flags: 1a Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 2 Max Hops: 2 Insteon Message: 2f000000000001000000000000000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 000000000100000000000000000006 PLM Response: (06) ACK 17/02/2013 14:59:18 [Insteon_PLM] DEBUG3: Received PLM acknowledge: obj=$fmr_outside; command=read_write_aldb; extra=000000000001000000000000000000 17/02/2013 14:59:19 [Insteon_PLM] DEBUG3: Received PLM raw data: 025010948818d4ce262f00 17/02/2013 14:59:19 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 10:94:88 To Address: 18:d4:ce Message Flags: 26 Message Type: (001) ACK of Direct Message Message Length: (0) Standard Length Hops Left: 1 Max Hops: 2 Insteon Message: 2f00 Cmd 1: (2f) Light OFF at Ramp Rate Cmd 2: (00) Ramp Rate 17/02/2013 14:59:19 [Insteon::BaseInterface] DEBUG2: Message received with 1 hops left, delaying next transmit to avoid collisions with remaining hops. 17/02/2013 14:59:19 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 14:59:19 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0000] received: 00 for _mem_activity=scan _mem_action=aldb_i2read 17/02/2013 14:59:19 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0000] received ack 17/02/2013 14:59:19 [Insteon_PLM] DEBUG3: Received PLM raw data: 025110 17/02/2013 14:59:19 [Insteon_PLM] DEBUG4: PLM Command: (0251) insteon_ext_received Message length too short for PLM command. Not parsed 17/02/2013 14:59:19 [Insteon_PLM] DEBUG3: Saving parsed data fragment: 025110 17/02/2013 14:59:19 [Insteon_PLM] DEBUG3: Prepending prior data fragment: 025110 17/02/2013 14:59:19 [Insteon_PLM] DEBUG3: Received PLM raw data: 025110948818d4ce112f0001010fff01a21218d4ceff000000 17/02/2013 14:59:19 [Insteon_PLM] DEBUG4: PLM Command: (0251) insteon_ext_received From Address: 10:94:88 To Address: 18:d4:ce Message Flags: 11 Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 0 Max Hops: 1 Insteon Message: 2f0001010fff01a21218d4ceff000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 01010fff01a21218d4ceff000000 17/02/2013 14:59:19 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 14:59:19 [Insteon::BaseInterface] DEBUG: PLM command:insteon_ext_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 14:59:19 [Insteon::BaseInterface] Processing message for $fmr_outside 17/02/2013 14:59:19 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0000] received: 0001010fff01a21218d4ceff000000 for _mem_activity=scan _mem_action=aldb_i2readack 17/02/2013 14:59:19 [Insteon::ALDB_i2] DEBUG4: Start of scan; initializing aldb structure 17/02/2013 14:59:19 [Insteon::ALDB_i2] DEBUG4: active link found; adding address [0fff] to aldb 17/02/2013 14:59:19 [Insteon_PLM] DEBUG2: Sending obj=$fmr_outside; command=read_write_aldb; extra=0000000ff701000000000000000000 incurred delay of 0.05 seconds; starting hop-count: 2 17/02/2013 14:59:19 [Insteon_PLM] DEBUG3: Sending PLM raw data: 02621094881a2f0000000ff701000000000000000000 17/02/2013 14:59:19 [Insteon_PLM] DEBUG4: PLM Command: (0262) insteon_send To Address: 10:94:88 Message Flags: 1a Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 2 Max Hops: 2 Insteon Message: 2f0000000ff701000000000000000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 00000ff701000000000000000000 17/02/2013 14:59:19 [Insteon_PLM] DEBUG3: Received PLM raw data: 02621094881a2f0000000ff70100000000000000000006 17/02/2013 14:59:19 [Insteon_PLM] DEBUG4: PLM Command: (0262) insteon_send To Address: 10:94:88 Message Flags: 1a Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 2 Max Hops: 2 Insteon Message: 2f0000000ff701000000000000000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 00000ff70100000000000000000006 PLM Response: (06) ACK 17/02/2013 14:59:19 [Insteon_PLM] DEBUG3: Received PLM acknowledge: obj=$fmr_outside; command=read_write_aldb; extra=0000000ff701000000000000000000 17/02/2013 14:59:20 CMxx: Ignoring first send of X10RF data from mochad (looking for confirmation resend): 74 8B 68 97 17/02/2013 14:59:20 CMxx: decoded data received from mochad: 02/17 14:59:20 Rx RF HouseUnit: B15 Func: Off 17/02/2013 14:59:20 [Insteon_PLM] DEBUG3: Received PLM raw data: 025010948818d4ce262f00025110948818d4ce112f0001010ff701a2060e0912ff000000 17/02/2013 14:59:20 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 10:94:88 To Address: 18:d4:ce Message Flags: 26 Message Type: (001) ACK of Direct Message Message Length: (0) Standard Length Hops Left: 1 Max Hops: 2 Insteon Message: 2f00 Cmd 1: (2f) Light OFF at Ramp Rate Cmd 2: (00) Ramp Rate 17/02/2013 14:59:20 [Insteon::BaseInterface] DEBUG2: Message received with 1 hops left, delaying next transmit to avoid collisions with remaining hops. 17/02/2013 14:59:20 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 14:59:20 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0ff7] received: 00 for _mem_activity=scan _mem_action=aldb_i2read 17/02/2013 14:59:20 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0ff7] received ack 17/02/2013 14:59:20 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 14:59:20 [Insteon::BaseInterface] DEBUG: PLM command:insteon_ext_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 14:59:20 [Insteon::BaseInterface] Processing message for $fmr_outside 17/02/2013 14:59:20 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0ff7] received: 0001010ff701a2060e0912ff000000 for _mem_activity=scan _mem_action=aldb_i2readack 17/02/2013 14:59:20 [Insteon::ALDB_i2] DEBUG4: active link found; adding address [0ff7] to aldb 17/02/2013 14:59:20 CMxx: X10RF data from mochad: 74 8B 68 97 17/02/2013 14:59:20 XBFBK: outside_motion1 still 17/02/2013 14:59:20 [Insteon_PLM] DEBUG2: Sending obj=$fmr_outside; command=read_write_aldb; extra=0000000fef01000000000000000000 incurred delay of 0.06 seconds; starting hop-count: 2 17/02/2013 14:59:20 [Insteon_PLM] DEBUG3: Sending PLM raw data: 02621094881a2f0000000fef01000000000000000000 17/02/2013 14:59:20 [Insteon_PLM] DEBUG4: PLM Command: (0262) insteon_send To Address: 10:94:88 Message Flags: 1a Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 2 Max Hops: 2 Insteon Message: 2f0000000fef01000000000000000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 00000fef01000000000000000000 17/02/2013 14:59:20 [Insteon_PLM] DEBUG3: Received PLM raw data: 02621094881a2f0000000fef0100000000000000000006 17/02/2013 14:59:20 [Insteon_PLM] DEBUG4: PLM Command: (0262) insteon_send To Address: 10:94:88 Message Flags: 1a Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 2 Max Hops: 2 Insteon Message: 2f0000000fef01000000000000000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 00000fef0100000000000000000006 PLM Response: (06) ACK 17/02/2013 14:59:20 [Insteon_PLM] DEBUG3: Received PLM acknowledge: obj=$fmr_outside; command=read_write_aldb; extra=0000000fef01000000000000000000 17/02/2013 14:59:20 CMxx: Ignoring duplicate X10RF data from mochad (dupe cnt >= 2): 74 8B 68 97 17/02/2013 14:59:20 [Insteon_PLM] DEBUG3: Received PLM raw data: 025010948818d4ce262f00 17/02/2013 14:59:20 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 10:94:88 To Address: 18:d4:ce Message Flags: 26 Message Type: (001) ACK of Direct Message Message Length: (0) Standard Length Hops Left: 1 Max Hops: 2 Insteon Message: 2f00 Cmd 1: (2f) Light OFF at Ramp Rate Cmd 2: (00) Ramp Rate 17/02/2013 14:59:20 [Insteon::BaseInterface] DEBUG2: Message received with 1 hops left, delaying next transmit to avoid collisions with remaining hops. 17/02/2013 14:59:20 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 14:59:20 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0fef] received: 00 for _mem_activity=scan _mem_action=aldb_i2read 17/02/2013 14:59:20 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0fef] received ack 17/02/2013 14:59:20 CMxx: Ignoring duplicate X10RF data from mochad (dupe cnt >= 3): 74 8B 68 97 17/02/2013 14:59:20 [Insteon_PLM] DEBUG3: Received PLM raw data: 025010948818d4ce2b2f00 17/02/2013 14:59:20 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 10:94:88 To Address: 18:d4:ce Message Flags: 2b Message Type: (001) ACK of Direct Message Message Length: (0) Standard Length Hops Left: 2 Max Hops: 3 Insteon Message: 2f00 Cmd 1: (2f) Light OFF at Ramp Rate Cmd 2: (00) Ramp Rate 17/02/2013 14:59:20 [Insteon::BaseInterface] DEBUG2: Message received with 2 hops left, delaying next transmit to avoid collisions with remaining hops. 17/02/2013 14:59:20 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 14:59:20 [Insteon::BaseInterface] WARN: received insteon ACK/NACK message from $fmr_outside but cannot correlate to sent message! IGNORING received message!! 17/02/2013 14:59:21 [Insteon_PLM] DEBUG3: Received PLM raw data: 025010948818d4ce232f00 17/02/2013 14:59:21 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 10:94:88 To Address: 18:d4:ce Message Flags: 23 Message Type: (001) ACK of Direct Message Message Length: (0) Standard Length Hops Left: 0 Max Hops: 3 Insteon Message: 2f00 Cmd 1: (2f) Light OFF at Ramp Rate Cmd 2: (00) Ramp Rate 17/02/2013 14:59:21 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 14:59:21 [Insteon::BaseInterface] WARN: received insteon ACK/NACK message from $fmr_outside but cannot correlate to sent message! IGNORING received message!! 17/02/2013 14:59:30 MYLOG7: House Stat Output: off, FMR Booster Fan: off, MBR Stat Output: off, MBR Booster Fan: off, Damper status: hvac 17/02/2013 14:59:40 MYLOG7: Full HVAC Status: 0. House Stat Heat:0, House Stat Cool:0, MBR Stat Heat:0, MBR Stat Cool:0, FMR Boost Fan State: 0, MBR Boost Fan State: 0, Dampers to Outside Air: 0, Computer Closet Fan: 0, Cool Outside Flag: , Is Away: 0, Last Heat/Cool: heat, House Stat Mode: program_auto 17/02/2013 15:00:00 MYLOG7: House Stat Output: off, FMR Booster Fan: off, MBR Stat Output: off, MBR Booster Fan: off, Damper status: hvac 17/02/2013 15:00:00 Running: AllDevices Scan -- "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: Marc M. <ma...@me...> - 2013-02-18 00:13:17
|
On Sun, Feb 17, 2013 at 02:40:46PM -0800, Marc MERLIN wrote: > So, I tried scan all with your just updated code, and aborted with no > message again. > > 17/02/2013 14:31:49 [Insteon_PLM] DEBUG3: Saving parsed data fragment: 025010948818d4ce > 17/02/2013 14:31:49 [Insteon_PLM] DEBUG3: Prepending prior data fragment: 025010948818d4ce > 17/02/2013 14:31:49 [Insteon_PLM] DEBUG3: Received PLM raw data: 025010948818d4ce262f00 > 17/02/2013 14:31:49 [Insteon_PLM] DEBUG4: > PLM Command: (0250) insteon_received > From Address: 10:94:88 > To Address: 18:d4:ce > Message Flags: 26 > Message Type: (001) ACK of Direct Message > Message Length: (0) Standard Length > Hops Left: 1 > Max Hops: 2 > Insteon Message: 2f00 > Cmd 1: (2f) Light OFF at Ramp Rate > Cmd 2: (00) Ramp Rate > > 17/02/2013 14:31:49 [Insteon::BaseInterface] DEBUG2: Message received with 1 hops left, delaying next transmit to avoid collisions with remaining hops. > 17/02/2013 14:31:49 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:read_write_aldb; type:direct; group: > 17/02/2013 14:31:49 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0fd7] received: 00 for _mem_activity=scan _mem_action=aldb_i2read > 17/02/2013 14:31:49 [Insteon::ALDB_i2] DEBUG3: $fmr_outside [0x0fd7] received ack > 17/02/2013 14:32:00 : Saving object states ... done > > It looks like Saving objects causes the scan to stop. I tried one more scan by using wireless only (I plugged my PLM into a filter). It died like this: 17/02/2013 16:03:33 [Scan all link tables] Now scanning: $entryway (12 of 27) 17/02/2013 16:03:34 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 16:03:34 [Insteon::ALDB_i2] DEBUG4: Start of scan; initializing aldb structure 17/02/2013 16:03:35 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 16:03:36 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 16:03:37 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 16:03:39 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 16:03:39 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 16:03:41 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 16:03:42 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 16:03:44 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 16:03:45 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 16:03:45 [Insteon::ALDB_i2] DEBUG3: $entryway [0x0fb7] ack not received. ignoring message 17/02/2013 16:03:46 [Insteon::BaseInterface] WARN: received insteon ACK/NACK message from $entryway but cannot correlate to sent message! IGNORING received message!! 17/02/2013 16:03:46 [Insteon::BaseInterface] WARN: received insteon ACK/NACK message from $entryway but cannot correlate to sent message! IGNORING received message!! Uneditted, it looks like this: 17/02/2013 16:03:42 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 16:03:42 [Insteon::BaseInterface] DEBUG: PLM command:insteon_ext_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 16:03:42 [Insteon::BaseInterface] Processing message for $entryway 17/02/2013 16:03:42 [Insteon::ALDB_i2] DEBUG3: $entryway [0x0fc7] received: 0001010fc701e2010e0749ff000400 for _mem_activity=scan _mem_action=aldb_i2readack 17/02/2013 16:03:42 [Insteon::ALDB_i2] DEBUG4: active link found; adding address [0fc7] to aldb 17/02/2013 16:03:42 [Insteon_PLM] DEBUG2: Sending obj=$entryway; command=read_write_aldb; extra=0000000fbf01000000000000000000 incurred delay of 0.07 seconds; starting hop-count: 3 17/02/2013 16:03:42 [Insteon_PLM] DEBUG3: Sending PLM raw data: 02620f23021f2f0000000fbf01000000000000000000 17/02/2013 16:03:42 [Insteon_PLM] DEBUG4: PLM Command: (0262) insteon_send To Address: 0f:23:02 Message Flags: 1f Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 3 Max Hops: 3 Insteon Message: 2f0000000fbf01000000000000000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 00000fbf01000000000000000000 17/02/2013 16:03:42 [Insteon_PLM] DEBUG3: Received PLM raw data: 02620f23021f2f0000000fbf0100000000000000000006 17/02/2013 16:03:42 [Insteon_PLM] DEBUG4: PLM Command: (0262) insteon_send To Address: 0f:23:02 Message Flags: 1f Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 3 Max Hops: 3 Insteon Message: 2f0000000fbf01000000000000000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 00000fbf0100000000000000000006 PLM Response: (06) ACK 17/02/2013 16:03:42 [Insteon_PLM] DEBUG3: Received PLM acknowledge: obj=$entryway; command=read_write_aldb; extra=0000000fbf01000000000000000000 17/02/2013 16:03:44 [Insteon_PLM] DEBUG3: Received PLM raw data: 02500f230218d4ce212f00 17/02/2013 16:03:44 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 0f:23:02 To Address: 18:d4:ce Message Flags: 21 Message Type: (001) ACK of Direct Message Message Length: (0) Standard Length Hops Left: 0 Max Hops: 1 Insteon Message: 2f00 Cmd 1: (2f) Light OFF at Ramp Rate Cmd 2: (00) Ramp Rate 17/02/2013 16:03:44 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 16:03:44 [Insteon::ALDB_i2] DEBUG3: $entryway [0x0fbf] received: 00 for _mem_activity=scan _mem_action=aldb_i2read 17/02/2013 16:03:44 [Insteon::ALDB_i2] DEBUG3: $entryway [0x0fbf] received ack 17/02/2013 16:03:44 [Insteon_PLM] DEBUG3: Received PLM raw data: 02510f230218d4ce112f0001010fbf01e2010e0912ff000400 17/02/2013 16:03:44 [Insteon_PLM] DEBUG4: PLM Command: (0251) insteon_ext_received From Address: 0f:23:02 To Address: 18:d4:ce Message Flags: 11 Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 0 Max Hops: 1 Insteon Message: 2f0001010fbf01e2010e0912ff000400 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 01010fbf01e2010e0912ff000400 17/02/2013 16:03:44 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 16:03:44 [Insteon::BaseInterface] DEBUG: PLM command:insteon_ext_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 16:03:44 [Insteon::BaseInterface] Processing message for $entryway 17/02/2013 16:03:44 [Insteon::ALDB_i2] DEBUG3: $entryway [0x0fbf] received: 0001010fbf01e2010e0912ff000400 for _mem_activity=scan _mem_action=aldb_i2readack 17/02/2013 16:03:44 [Insteon::ALDB_i2] DEBUG4: active link found; adding address [0fbf] to aldb 17/02/2013 16:03:44 [Insteon_PLM] DEBUG2: Sending obj=$entryway; command=read_write_aldb; extra=0000000fb701000000000000000000 incurred delay of 0.06 seconds; starting hop-count: 3 17/02/2013 16:03:44 [Insteon_PLM] DEBUG3: Sending PLM raw data: 02620f23021f2f0000000fb701000000000000000000 17/02/2013 16:03:44 [Insteon_PLM] DEBUG4: PLM Command: (0262) insteon_send To Address: 0f:23:02 Message Flags: 1f Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 3 Max Hops: 3 Insteon Message: 2f0000000fb701000000000000000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 00000fb701000000000000000000 17/02/2013 16:03:44 [Insteon_PLM] DEBUG3: Received PLM raw data: 02620f23021f2f0000000fb70100000000000000000006 17/02/2013 16:03:44 [Insteon_PLM] DEBUG4: PLM Command: (0262) insteon_send To Address: 0f:23:02 Message Flags: 1f Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 3 Max Hops: 3 Insteon Message: 2f0000000fb701000000000000000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 00000fb70100000000000000000006 PLM Response: (06) ACK 17/02/2013 16:03:44 [Insteon_PLM] DEBUG3: Received PLM acknowledge: obj=$entryway; command=read_write_aldb; extra=0000000fb701000000000000000000 17/02/2013 16:03:45 [Insteon_PLM] DEBUG3: Received PLM raw data: 02510f230218d4ce122f0001010fb70102030a39d1ff000000 17/02/2013 16:03:45 [Insteon_PLM] DEBUG4: PLM Command: (0251) insteon_ext_received From Address: 0f:23:02 To Address: 18:d4:ce Message Flags: 12 Message Type: (000) Direct Message Message Length: (1) Extended Length Hops Left: 0 Max Hops: 2 Insteon Message: 2f0001010fb70102030a39d1ff000000 Cmd 1: (2f) Read/Write ALL-Link Database Cmd 2: (00) Command in D2 D1-D14: 01010fb70102030a39d1ff000000 17/02/2013 16:03:45 [Insteon::InsteonMessage] WARN: Message has invalid checksum 17/02/2013 16:03:45 [Insteon::BaseInterface] DEBUG: PLM command:insteon_ext_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 16:03:45 [Insteon::BaseInterface] Processing message for $entryway 17/02/2013 16:03:45 [Insteon::ALDB_i2] DEBUG3: $entryway [0x0fb7] received: 0001010fb70102030a39d1ff000000 for _mem_activity=scan _mem_action=aldb_i2read 17/02/2013 16:03:45 [Insteon::ALDB_i2] DEBUG3: $entryway [0x0fb7] ack not received. ignoring message 17/02/2013 16:03:46 [Insteon_PLM] DEBUG3: Received PLM raw data: 02500f230218d4ce232f00 17/02/2013 16:03:46 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 0f:23:02 To Address: 18:d4:ce Message Flags: 23 Message Type: (001) ACK of Direct Message Message Length: (0) Standard Length Hops Left: 0 Max Hops: 3 Insteon Message: 2f00 Cmd 1: (2f) Light OFF at Ramp Rate Cmd 2: (00) Ramp Rate 17/02/2013 16:03:46 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 16:03:46 [Insteon::ALDB_i2] DEBUG3: $entryway [0x0fb7] received: 00 for _mem_activity=scan _mem_action=aldb_i2read 17/02/2013 16:03:46 [Insteon::ALDB_i2] DEBUG3: $entryway [0x0fb7] received ack 17/02/2013 16:03:46 [Insteon_PLM] DEBUG3: Received PLM raw data: 02500f230218d4ce272f00 17/02/2013 16:03:46 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 0f:23:02 To Address: 18:d4:ce Message Flags: 27 Message Type: (001) ACK of Direct Message Message Length: (0) Standard Length Hops Left: 1 Max Hops: 3 Insteon Message: 2f00 Cmd 1: (2f) Light OFF at Ramp Rate Cmd 2: (00) Ramp Rate 17/02/2013 16:03:46 [Insteon::BaseInterface] DEBUG2: Message received with 1 hops left, delaying next transmit to avoid collisions with remaining hops. 17/02/2013 16:03:46 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 16:03:46 [Insteon::BaseInterface] WARN: received insteon ACK/NACK message from $entryway but cannot correlate to sent message! IGNORING received message!! 17/02/2013 16:03:46 [Insteon_PLM] DEBUG3: Received PLM raw data: 02500f230218d4ce272f00 17/02/2013 16:03:46 [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 0f:23:02 To Address: 18:d4:ce Message Flags: 27 Message Type: (001) ACK of Direct Message Message Length: (0) Standard Length Hops Left: 1 Max Hops: 3 Insteon Message: 2f00 Cmd 1: (2f) Light OFF at Ramp Rate Cmd 2: (00) Ramp Rate 17/02/2013 16:03:46 [Insteon::BaseInterface] DEBUG2: Message received with 1 hops left, delaying next transmit to avoid collisions with remaining hops. 17/02/2013 16:03:46 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:read_write_aldb; type:direct; group: 17/02/2013 16:03:46 [Insteon::BaseInterface] WARN: received insteon ACK/NACK message from $entryway but cannot correlate to sent message! IGNORING received message!! Scan stopped here. Hope this helps, I'll stop for now. 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: Marc M. <ma...@me...> - 2013-02-18 07:04:07
|
On Sun, Feb 17, 2013 at 04:13:09PM -0800, Marc MERLIN wrote: > 17/02/2013 16:03:46 [Insteon::BaseInterface] DEBUG2: Message received with 1 hops left, delaying next transmit to avoid collisions with remaining hops. > 17/02/2013 16:03:46 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:read_write_aldb; type:direct; group: > 17/02/2013 16:03:46 [Insteon::BaseInterface] WARN: received insteon ACK/NACK message from $entryway but cannot correlate to sent message! IGNORING received message!! > > Scan stopped here. > > Hope this helps, I'll stop for now. Ok, I lied. I'll play the columbo "one more thing" :) I went back to mh git master, ran 2 scans and they both completed. So, sorry Michael, while I have broken ass devices and a bad network, I think something in your code is causing scans not to complete for me. Here's the git master branch code: 17/02/2013 18:34:24 [Scan all link tables] Now scanning: $fan_gar_roof (26 of 27) 17/02/2013 18:34:25 [Scan all link tables] Now scanning: $fan_gar_ceiling (27 of 27) 17/02/2013 18:34:26 [Scan all link tables] All tables have completed scanning And for good measure, I tried your code one last time, and it failed again: 17/02/2013 22:48:26 [Scan all link tables] Now scanning: $br2_lamp (7 of 27) 17/02/2013 22:48:28 [Insteon::BaseInterface] WARN: received insteon ACK/NACK message from $br2_lamp but cannot correlate to sent message! IGNORING received message!! 17/02/2013 22:48:28 [Insteon::BaseInterface] WARN: received insteon ACK/NACK message from $br2_lamp but cannot correlate to sent message! IGNORING received message!! 17/02/2013 22:48:28 [Insteon::BaseInterface] WARN: received insteon ACK/NACK message from $br2_lamp but cannot correlate to sent message! IGNORING received message!! 17/02/2013 22:48:28 [Insteon::BaseInterface] WARN: received insteon ACK/NACK message from $br2_lamp but cannot correlate to sent message! IGNORING received message!! Hope this helps. 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: Michael S. <mi...@st...> - 2013-02-18 16:55:30
|
On Feb 17, 2013 1:04 AM Marc wrote, > > On Sun, Feb 17, 2013 at 04:13:09PM -0800, Marc MERLIN wrote: > > 17/02/2013 16:03:46 [Insteon::BaseInterface] DEBUG2: Message received with 1 hops > left, delaying next transmit to avoid collisions with remaining hops. > > 17/02/2013 16:03:46 [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; > Device command:read_write_aldb; type:direct; group: > > 17/02/2013 16:03:46 [Insteon::BaseInterface] WARN: received insteon ACK/NACK message > from $entryway but cannot correlate to sent message! IGNORING received message!! > > > > Scan stopped here. > > > > Hope this helps, I'll stop for now. > > Ok, I lied. I'll play the columbo "one more thing" :) > > I went back to mh git master, ran 2 scans and they both completed. > > So, sorry Michael, while I have broken ass devices and a bad network, I think something > in your code is causing scans not to complete for me. Yup. Totally agree. I've seen three of your logs that all ended the same way with the aldb read state machine wedged waiting on a device aldb read response. There were two different failure modes but the same result. I agree that limiting the hop counts will greatly improve your network because I ultimately think these failures are triggered by Insteon messages stomping on each other in the powerline / RF network. However :) before I merge in Kevin's latest code; I would like to fix the issue your network seems to reliably reproduce. Then I'll merge in Kevin's code. The state machine is based on a message pump. In your 1st case MH sent a read aldb (not shown), received an ACK from the PLM (not shown), then received an ACK from the device (shown). The next step in the state machine requires the device to send the aldb record. The state machine wedged waiting on a message from the device that never arrived. This message flow is rather unique in Insteon where there is one message sent and two responses expected from the device. Why Insteon couldn't put the data in the ACK is beyond me. I need to add some logic that expects the message, starts a timer, and retries if the message doesn't arrive. In your 2nd case the device ACK and the read aldb response were out of order and 3 copies of the ACK arrived! I guess that is not unexpected given the nature of the Insteon dual band network. MH ignored the out of order message. Recorded the 1st ACK, discarded the next two ACKs, and then waited indefinitely for the aldb read response. I think this will work using the same solution as above where MH times out and retransmits the request again. Your 3rd case is exactly like the 1st case but there are also 3 ACKs. This is the same condition for MH since it ignores the extra ACKs. I also just saw the issue on my system where the startup scan was skipped with no indication. In my case the PLM did respond to the info request. I'll need to add a bunch of instrumentation to see exactly why it is failing. I like your idea that something is in the PLM serial transmit queue. I have 4 immediate development tasks before you should do more testing: Fix the startup/reload ALDB class mapping. Right now I2 devices are only mapped after a get_engine_version Add timeout and retransmission logic for aldb read responses Add instrumentation to catch the startup scan issue Modify CRC error warning message to ignore non-CRC capable devices And 3 follow up tasks: Merge Kevin's enhancements from hollie/master Look at the error cases for delete_orphan_links, scan_links, etc. and correct the callback logic Merge i1 and i2 ADLB functions which are substantially identical. Thanks again for all your help isolating the issues; I know it takes a lot of your time but your efforts to isolate and segment out each issue really helps a lot. I bestow on you the title "Official Insteon Bug Hunter"! Sincerely, Michael |
From: Kevin R. K. <ke...@kr...> - 2013-02-18 17:12:48
|
> i need to add some logic that expects the message, starts a timer, and retries if the > message doesn't arrive. I am sure you already thought of this. But I ran into a similar situation with All Link Cleanup messages. My suggestion would be that when mh receives the ACK that it does not clear the active message, but only resets the xmit timeout. This way if the data message doesn't arrive, mh will simply resend the original request. I realize this may be difficult though, Greg put the clear message code down in Insteon_plm. Far away from where the message is actually processed. |
From: Michael S. <mi...@st...> - 2013-02-18 18:05:42
|
I had forgotten about that change you mentioned a while back. I think it is a perfect solution. If you have a minute could you point me at the check-in that included this change? From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 11:13 AM To: Michael Stovenour Cc: Marc MERLIN; The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support > i need to add some logic that expects the message, starts a timer, and retries if the > message doesn't arrive. I am sure you already thought of this. But I ran into a similar situation with All Link Cleanup messages. My suggestion would be that when mh receives the ACK that it does not clear the active message, but only resets the xmit timeout. This way if the data message doesn't arrive, mh will simply resend the original request. I realize this may be difficult though, Greg put the clear message code down in Insteon_plm. Far away from where the message is actually processed. |
From: Kevin R. K. <ke...@kr...> - 2013-02-18 18:33:02
|
Sorry it looks like clear_message is actually handled in BaseInterface. So in this first commit I simply removed the call to clear_message and bumped the send_timeout to an absurd 30 seconds: https://github.com/krkeegan/misterhouse/commit/44924bdfb7e1a8a6dee0296969be3b2729712bdc Then once it was clear that would work, I removed the 30 second timeout, and then added code to reset the normal send_timeout for each ACK/NACK received: On Mon, Feb 18, 2013 at 10:05 AM, Michael Stovenour <mi...@st...>wrote: > I had forgotten about that change you mentioned a while back. I think it > is a perfect solution. If you have a minute could you point me at the > check-in that included this change? **** > > ** ** > > *From:* Kevin Robert Keegan [mailto:ke...@kr...] > *Sent:* Monday, February 18, 2013 11:13 AM > *To:* Michael Stovenour > *Cc:* Marc MERLIN; The main list for the MisterHouse home automation > program > *Subject:* Re: [mh] Insteon I2 Support**** > > ** ** > > > > i need to add some logic that expects the message, starts a timer, and > retries if the > > message doesn't arrive.**** > > I am sure you already thought of this. But I ran into a similar situation > with All Link Cleanup messages. My suggestion would be that when mh > receives the ACK that it does not clear the active message, but only resets > the xmit timeout. This way if the data message doesn't arrive, mh will > simply resend the original request.**** > > I realize this may be difficult though, Greg put the clear message code > down in Insteon_plm. Far away from where the message is actually processed. > **** > |
From: Kevin R. K. <ke...@kr...> - 2013-02-18 18:34:35
|
sent that last one too soon: https://github.com/krkeegan/misterhouse/commit/54042e40603ea7b1983492bace43236a9cd86be3 It is actually "command" timeout that you want to use, not "xmit." I would them make sure you call clear_message after the data message is received. Kevin On Mon, Feb 18, 2013 at 10:32 AM, Kevin Robert Keegan <ke...@kr...>wrote: > Sorry it looks like clear_message is actually handled in BaseInterface. > So in this first commit I simply removed the call to clear_message and > bumped the send_timeout to an absurd 30 seconds: > > > https://github.com/krkeegan/misterhouse/commit/44924bdfb7e1a8a6dee0296969be3b2729712bdc > > Then once it was clear that would work, I removed the 30 second timeout, > and then added code to reset the normal send_timeout for each ACK/NACK > received: > > > > On Mon, Feb 18, 2013 at 10:05 AM, Michael Stovenour <mi...@st... > > wrote: > >> I had forgotten about that change you mentioned a while back. I think it >> is a perfect solution. If you have a minute could you point me at the >> check-in that included this change? **** >> >> ** ** >> >> *From:* Kevin Robert Keegan [mailto:ke...@kr...] >> *Sent:* Monday, February 18, 2013 11:13 AM >> *To:* Michael Stovenour >> *Cc:* Marc MERLIN; The main list for the MisterHouse home automation >> program >> *Subject:* Re: [mh] Insteon I2 Support**** >> >> ** ** >> >> >> > i need to add some logic that expects the message, starts a timer, and >> retries if the >> > message doesn't arrive.**** >> >> I am sure you already thought of this. But I ran into a similar >> situation with All Link Cleanup messages. My suggestion would be that when >> mh receives the ACK that it does not clear the active message, but only >> resets the xmit timeout. This way if the data message doesn't arrive, mh >> will simply resend the original request.**** >> >> I realize this may be difficult though, Greg put the clear message code >> down in Insteon_plm. Far away from where the message is actually processed. >> **** >> > > |
From: Michael S. <mi...@st...> - 2013-02-18 18:52:01
|
Ok, I get the idea, thanks! I was not looking forward to figuring that one out. Sincerely, Michael From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 12:34 PM To: Michael Stovenour Cc: Marc MERLIN; The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support sent that last one too soon: https://github.com/krkeegan/misterhouse/commit/54042e40603ea7b1983492bace43236a9cd86be3 It is actually "command" timeout that you want to use, not "xmit." I would them make sure you call clear_message after the data message is received. Kevin On Mon, Feb 18, 2013 at 10:32 AM, Kevin Robert Keegan <ke...@kr...> wrote: Sorry it looks like clear_message is actually handled in BaseInterface. So in this first commit I simply removed the call to clear_message and bumped the send_timeout to an absurd 30 seconds: https://github.com/krkeegan/misterhouse/commit/44924bdfb7e1a8a6dee0296969be3b2729712bdc Then once it was clear that would work, I removed the 30 second timeout, and then added code to reset the normal send_timeout for each ACK/NACK received: On Mon, Feb 18, 2013 at 10:05 AM, Michael Stovenour <mi...@st...> wrote: I had forgotten about that change you mentioned a while back. I think it is a perfect solution. If you have a minute could you point me at the check-in that included this change? From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 11:13 AM To: Michael Stovenour Cc: Marc MERLIN; The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support > i need to add some logic that expects the message, starts a timer, and retries if the > message doesn't arrive. I am sure you already thought of this. But I ran into a similar situation with All Link Cleanup messages. My suggestion would be that when mh receives the ACK that it does not clear the active message, but only resets the xmit timeout. This way if the data message doesn't arrive, mh will simply resend the original request. I realize this may be difficult though, Greg put the clear message code down in Insteon_plm. Far away from where the message is actually processed. |
From: Michael S. <mi...@st...> - 2013-02-19 00:15:36
|
Kevin, In order to make this idea work, I need to either put a lot of device message code in BaseInterface.pm:InsteonBaseInterface->on_stnadard_insteon_received() or I could move the logic for deciding on when to clear the active message to BaseInsteon.pm:Insteon::BaseObject->_process_message(). I would like to do the latter but it means changes to some of the same areas you are working in. It could make merges a mess unless we are careful. My idea is to change all of the _process_message() calls in on_standard_insteon_received() so that they expect a return value from _process_message(). The return value will determine if clear_active_message() is called. Basically I'll let the device module tell the PLM module when to consider the message transaction complete. I think it is the cleanest way to do it. Let me know what you think. If this sounds reasonable we can negotiate how to make the change. Sincerely, Michael From: Michael Stovenour [mailto:mi...@st...] Sent: Monday, February 18, 2013 12:52 PM To: 'Kevin Robert Keegan' Cc: 'The main list for the MisterHouse home automation program' Subject: Re: [mh] Insteon I2 Support Ok, I get the idea, thanks! I was not looking forward to figuring that one out. Sincerely, Michael From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 12:34 PM To: Michael Stovenour Cc: Marc MERLIN; The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support sent that last one too soon: https://github.com/krkeegan/misterhouse/commit/54042e40603ea7b1983492bace43236a9cd86be3 It is actually "command" timeout that you want to use, not "xmit." I would them make sure you call clear_message after the data message is received. Kevin On Mon, Feb 18, 2013 at 10:32 AM, Kevin Robert Keegan <ke...@kr...> wrote: Sorry it looks like clear_message is actually handled in BaseInterface. So in this first commit I simply removed the call to clear_message and bumped the send_timeout to an absurd 30 seconds: https://github.com/krkeegan/misterhouse/commit/44924bdfb7e1a8a6dee0296969be3b2729712bdc Then once it was clear that would work, I removed the 30 second timeout, and then added code to reset the normal send_timeout for each ACK/NACK received: On Mon, Feb 18, 2013 at 10:05 AM, Michael Stovenour <mi...@st...> wrote: I had forgotten about that change you mentioned a while back. I think it is a perfect solution. If you have a minute could you point me at the check-in that included this change? From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 11:13 AM To: Michael Stovenour Cc: Marc MERLIN; The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support > i need to add some logic that expects the message, starts a timer, and retries if the > message doesn't arrive. I am sure you already thought of this. But I ran into a similar situation with All Link Cleanup messages. My suggestion would be that when mh receives the ACK that it does not clear the active message, but only resets the xmit timeout. This way if the data message doesn't arrive, mh will simply resend the original request. I realize this may be difficult though, Greg put the clear message code down in Insteon_plm. Far away from where the message is actually processed. |
From: Kevin R. K. <ke...@kr...> - 2013-02-19 00:30:59
|
I agree something needs to be done. The clearing of messages without concern for the data contained within the response is bad. I have thought about this too. I agree with you suggestion, process_message should return a value that determines whether the message is cleared. I think we (mostly me) are going to have a ton of work to do to merge the two branches. I have basically accepted that fact. On Mon, Feb 18, 2013 at 4:15 PM, Michael Stovenour <mi...@st...>wrote: > Kevin,**** > > In order to make this idea work, I need to either put a lot of device > message code in > BaseInterface.pm:InsteonBaseInterface->on_stnadard_insteon_received() or > I could move the logic for deciding on when to clear the active message to > BaseInsteon.pm:Insteon::BaseObject->_process_message(). I would like to > do the latter but it means changes to some of the same areas you are > working in. It could make merges a mess unless we are careful.**** > > ** ** > > My idea is to change all of the _process_message() calls in > on_standard_insteon_received() so that they expect a return value from > _process_message(). The return value will determine if > clear_active_message() is called. Basically I’ll let the device module > tell the PLM module when to consider the message transaction complete. I > think it is the cleanest way to do it.**** > > ** ** > > Let me know what you think. If this sounds reasonable we can negotiate > how to make the change.**** > > ** ** > > Sincerely,**** > > Michael**** > > ** ** > > *From:* Michael Stovenour [mailto:mi...@st...] > *Sent:* Monday, February 18, 2013 12:52 PM > *To:* 'Kevin Robert Keegan' > *Cc:* 'The main list for the MisterHouse home automation program' > > *Subject:* Re: [mh] Insteon I2 Support**** > > ** ** > > Ok, I get the idea, thanks! I was not looking forward to figuring that > one out.**** > > ** ** > > Sincerely,**** > > Michael**** > > ** ** > > *From:* Kevin Robert Keegan [mailto:ke...@kr...<ke...@kr...>] > > *Sent:* Monday, February 18, 2013 12:34 PM > *To:* Michael Stovenour > *Cc:* Marc MERLIN; The main list for the MisterHouse home automation > program > *Subject:* Re: [mh] Insteon I2 Support**** > > ** ** > > sent that last one too soon:**** > > ** ** > > > https://github.com/krkeegan/misterhouse/commit/54042e40603ea7b1983492bace43236a9cd86be3 > **** > > ** ** > > It is actually "command" timeout that you want to use, not "xmit." I > would them make sure you call clear_message after the data message is > received.**** > > ** ** > > Kevin**** > > ** ** > > On Mon, Feb 18, 2013 at 10:32 AM, Kevin Robert Keegan <ke...@kr...> > wrote:**** > > Sorry it looks like clear_message is actually handled in BaseInterface. > So in this first commit I simply removed the call to clear_message and > bumped the send_timeout to an absurd 30 seconds:**** > > ** ** > > > https://github.com/krkeegan/misterhouse/commit/44924bdfb7e1a8a6dee0296969be3b2729712bdc > **** > > ** ** > > Then once it was clear that would work, I removed the 30 second timeout, > and then added code to reset the normal send_timeout for each ACK/NACK > received:**** > > ** ** > > ** ** > > On Mon, Feb 18, 2013 at 10:05 AM, Michael Stovenour <mi...@st...> > wrote:**** > > I had forgotten about that change you mentioned a while back. I think it > is a perfect solution. If you have a minute could you point me at the > check-in that included this change? **** > > **** > > *From:* Kevin Robert Keegan [mailto:ke...@kr...] > *Sent:* Monday, February 18, 2013 11:13 AM > *To:* Michael Stovenour > *Cc:* Marc MERLIN; The main list for the MisterHouse home automation > program > *Subject:* Re: [mh] Insteon I2 Support**** > > **** > > > > i need to add some logic that expects the message, starts a timer, and > retries if the > > message doesn't arrive.**** > > I am sure you already thought of this. But I ran into a similar situation > with All Link Cleanup messages. My suggestion would be that when mh > receives the ACK that it does not clear the active message, but only resets > the xmit timeout. This way if the data message doesn't arrive, mh will > simply resend the original request.**** > > I realize this may be difficult though, Greg put the clear message code > down in Insteon_plm. Far away from where the message is actually processed. > **** > > ** ** > > ** ** > |
From: Michael S. <mi...@st...> - 2013-02-19 00:57:10
|
I have been keeping up with hollie/master so hopefully the final i2 merge is not too intrusive. What has me concerned right now is your pull request Fix for Issue #75 - Correct Handling of All_Link Commands <https://github.com/hollie/misterhouse/pull/78> . That will make it very difficult to merge my planned changes and I suspect we will both need to repeat all the testing after the merge. Do you think that code is ready to merge into hollie/master? If so I'll pull hollie/master and merge it into the i2_aldb_support branch. I could try pulling that branch directly from you but I'm testing the limits of my git experience. I have no idea of the unintended consequences. From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 6:31 PM To: Michael Stovenour Cc: The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support I agree something needs to be done. The clearing of messages without concern for the data contained within the response is bad. I have thought about this too. I agree with you suggestion, process_message should return a value that determines whether the message is cleared. I think we (mostly me) are going to have a ton of work to do to merge the two branches. I have basically accepted that fact. On Mon, Feb 18, 2013 at 4:15 PM, Michael Stovenour <mi...@st...> wrote: Kevin, In order to make this idea work, I need to either put a lot of device message code in BaseInterface.pm:InsteonBaseInterface->on_stnadard_insteon_received() or I could move the logic for deciding on when to clear the active message to BaseInsteon.pm:Insteon::BaseObject->_process_message(). I would like to do the latter but it means changes to some of the same areas you are working in. It could make merges a mess unless we are careful. My idea is to change all of the _process_message() calls in on_standard_insteon_received() so that they expect a return value from _process_message(). The return value will determine if clear_active_message() is called. Basically I'll let the device module tell the PLM module when to consider the message transaction complete. I think it is the cleanest way to do it. Let me know what you think. If this sounds reasonable we can negotiate how to make the change. Sincerely, Michael From: Michael Stovenour [mailto:mi...@st...] Sent: Monday, February 18, 2013 12:52 PM To: 'Kevin Robert Keegan' Cc: 'The main list for the MisterHouse home automation program' Subject: Re: [mh] Insteon I2 Support Ok, I get the idea, thanks! I was not looking forward to figuring that one out. Sincerely, Michael From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 12:34 PM To: Michael Stovenour Cc: Marc MERLIN; The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support sent that last one too soon: https://github.com/krkeegan/misterhouse/commit/54042e40603ea7b1983492bace43236a9cd86be3 It is actually "command" timeout that you want to use, not "xmit." I would them make sure you call clear_message after the data message is received. Kevin On Mon, Feb 18, 2013 at 10:32 AM, Kevin Robert Keegan <ke...@kr...> wrote: Sorry it looks like clear_message is actually handled in BaseInterface. So in this first commit I simply removed the call to clear_message and bumped the send_timeout to an absurd 30 seconds: https://github.com/krkeegan/misterhouse/commit/44924bdfb7e1a8a6dee0296969be3b2729712bdc Then once it was clear that would work, I removed the 30 second timeout, and then added code to reset the normal send_timeout for each ACK/NACK received: On Mon, Feb 18, 2013 at 10:05 AM, Michael Stovenour <mi...@st...> wrote: I had forgotten about that change you mentioned a while back. I think it is a perfect solution. If you have a minute could you point me at the check-in that included this change? From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 11:13 AM To: Michael Stovenour Cc: Marc MERLIN; The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support > i need to add some logic that expects the message, starts a timer, and retries if the > message doesn't arrive. I am sure you already thought of this. But I ran into a similar situation with All Link Cleanup messages. My suggestion would be that when mh receives the ACK that it does not clear the active message, but only resets the xmit timeout. This way if the data message doesn't arrive, mh will simply resend the original request. I realize this may be difficult though, Greg put the clear message code down in Insteon_plm. Far away from where the message is actually processed. |
From: Kevin R. K. <ke...@kr...> - 2013-02-19 01:01:21
|
It is ready to merge in, but I suspected the same thing so I have been holding off. Let me know what you would like me to do. On Mon, Feb 18, 2013 at 4:57 PM, Michael Stovenour <mi...@st...>wrote: > I have been keeping up with hollie/master so hopefully the final i2 merge > is not too intrusive. What has me concerned right now is your pull request Fix > for Issue #75 - Correct Handling of All_Link Commands<https://github.com/hollie/misterhouse/pull/78>. > That will make it very difficult to merge my planned changes and I suspect > we will both need to repeat all the testing after the merge. Do you think > that code is ready to merge into hollie/master? If so I’ll pull > hollie/master and merge it into the i2_aldb_support branch. I could try > pulling that branch directly from you but I’m testing the limits of my git > experience. I have no idea of the unintended consequences.**** > > ** ** > > ** ** > > *From:* Kevin Robert Keegan [mailto:ke...@kr...] > *Sent:* Monday, February 18, 2013 6:31 PM > *To:* Michael Stovenour > *Cc:* The main list for the MisterHouse home automation program > > *Subject:* Re: [mh] Insteon I2 Support**** > > ** ** > > I agree something needs to be done. The clearing of messages without > concern for the data contained within the response is bad.**** > > ** ** > > I have thought about this too. I agree with you suggestion, > process_message should return a value that determines whether the message > is cleared. **** > > ** ** > > I think we (mostly me) are going to have a ton of work to do to merge the > two branches. I have basically accepted that fact.**** > > ** ** > > On Mon, Feb 18, 2013 at 4:15 PM, Michael Stovenour <mi...@st...> > wrote:**** > > Kevin,**** > > In order to make this idea work, I need to either put a lot of device > message code in > BaseInterface.pm:InsteonBaseInterface->on_stnadard_insteon_received() or > I could move the logic for deciding on when to clear the active message to > BaseInsteon.pm:Insteon::BaseObject->_process_message(). I would like to > do the latter but it means changes to some of the same areas you are > working in. It could make merges a mess unless we are careful.**** > > **** > > My idea is to change all of the _process_message() calls in > on_standard_insteon_received() so that they expect a return value from > _process_message(). The return value will determine if > clear_active_message() is called. Basically I’ll let the device module > tell the PLM module when to consider the message transaction complete. I > think it is the cleanest way to do it.**** > > **** > > Let me know what you think. If this sounds reasonable we can negotiate > how to make the change.**** > > **** > > Sincerely,**** > > Michael**** > > **** > > *From:* Michael Stovenour [mailto:mi...@st...] > *Sent:* Monday, February 18, 2013 12:52 PM > *To:* 'Kevin Robert Keegan' > *Cc:* 'The main list for the MisterHouse home automation program'**** > > > *Subject:* Re: [mh] Insteon I2 Support**** > > **** > > Ok, I get the idea, thanks! I was not looking forward to figuring that > one out.**** > > **** > > Sincerely,**** > > Michael**** > > **** > > *From:* Kevin Robert Keegan [mailto:ke...@kr...<ke...@kr...>] > > *Sent:* Monday, February 18, 2013 12:34 PM > *To:* Michael Stovenour > *Cc:* Marc MERLIN; The main list for the MisterHouse home automation > program > *Subject:* Re: [mh] Insteon I2 Support**** > > **** > > sent that last one too soon:**** > > **** > > > https://github.com/krkeegan/misterhouse/commit/54042e40603ea7b1983492bace43236a9cd86be3 > **** > > **** > > It is actually "command" timeout that you want to use, not "xmit." I > would them make sure you call clear_message after the data message is > received.**** > > **** > > Kevin**** > > **** > > On Mon, Feb 18, 2013 at 10:32 AM, Kevin Robert Keegan <ke...@kr...> > wrote:**** > > Sorry it looks like clear_message is actually handled in BaseInterface. > So in this first commit I simply removed the call to clear_message and > bumped the send_timeout to an absurd 30 seconds:**** > > **** > > > https://github.com/krkeegan/misterhouse/commit/44924bdfb7e1a8a6dee0296969be3b2729712bdc > **** > > **** > > Then once it was clear that would work, I removed the 30 second timeout, > and then added code to reset the normal send_timeout for each ACK/NACK > received:**** > > **** > > **** > > On Mon, Feb 18, 2013 at 10:05 AM, Michael Stovenour <mi...@st...> > wrote:**** > > I had forgotten about that change you mentioned a while back. I think it > is a perfect solution. If you have a minute could you point me at the > check-in that included this change? **** > > **** > > *From:* Kevin Robert Keegan [mailto:ke...@kr...] > *Sent:* Monday, February 18, 2013 11:13 AM > *To:* Michael Stovenour > *Cc:* Marc MERLIN; The main list for the MisterHouse home automation > program > *Subject:* Re: [mh] Insteon I2 Support**** > > **** > > > > i need to add some logic that expects the message, starts a timer, and > retries if the > > message doesn't arrive.**** > > I am sure you already thought of this. But I ran into a similar situation > with All Link Cleanup messages. My suggestion would be that when mh > receives the ACK that it does not clear the active message, but only resets > the xmit timeout. This way if the data message doesn't arrive, mh will > simply resend the original request.**** > > I realize this may be difficult though, Greg put the clear message code > down in Insteon_plm. Far away from where the message is actually processed. > **** > > **** > > **** > > ** ** > |
From: Michael S. <mi...@st...> - 2013-02-19 01:27:04
|
--- a/lib/Insteon/BaseInterface.pm +++ b/lib/Insteon/BaseInterface.pm @@ -33,6 +33,7 @@ sub poll_all { # don't request status for objects associated w/ other than the primary group # as they are psuedo links + $insteon_device->get_engine_version(); $insteon_device->request_status(); } if ($insteon_device->devcat) { @@ -192,7 +193,7 @@ sub queue_message } else { - my $queue_size = @{$$self{command_stack2}}; +# my $queue_size = @{$$self{command_stack2}}; # &main::print_log("[Insteon_PLM] Command stack size: $queue_size") if $queue_size > 0 and $main::Debug{insteon}; if ($setby and ref($setby) and $setby->can('set_retry_timeout') and $setby->get_object_name) @@ -352,11 +353,15 @@ sub on_standard_insteon_received if ($msg{type} ne 'broadcast') { $msg{command} = $object->message_type($msg{cmd_code}); - &::print_log("[Insteon::BaseInterface] command:$msg{command}; type:$msg{type}; group: $msg{group}") + main::print_log("[Insteon::BaseInterface] PLM command:insteon_received; " + . "Device command:$msg{command}; type:$msg{type}; group: $msg{group}") if (!($msg{is_ack} or $msg{is_nack})) and $main::Debug{insteon}; } if ($msg{is_ack} or $msg{is_nack}) { + main::print_log("[Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; " + . "Device command:$msg{command}; type:$msg{type}; group: $msg{group}") + if $main::Debug{insteon} >=3; # need to confirm that this message corresponds to the current active one before clearing it # TO-DO!!! This is a brute force and poor compare technique; needs to be replaced by full compare if ($self->active_message && ref $self->active_message->setby) @@ -499,8 +504,10 @@ sub on_extended_insteon_received if ($msg{type} ne 'broadcast') { $msg{command} = $object->message_type($msg{cmd_code}); - &::print_log("[Insteon::BaseInterface] command:$msg{command}; type:$msg{type}; group: $msg{group}") - if (!($msg{is_ack} or $msg{is_nack})) and $main::Debug{insteon}; + main::print_log("[Insteon::BaseInterface] DEBUG: PLM command:insteon_ext_received; " + . "Device command:$msg{command}; type:$msg{type}; group: $msg{group}") + if( (!($msg{is_ack} or $msg{is_nack}) and $main::Debug{insteon}) + or $main::Debug{insteon} >= 3); } &::print_log("[Insteon::BaseInterface] Processing message for " . $object->get_object_name) if $main::Debug{insteon}; $object->_process_message($self, %msg); diff --git a/lib/Insteon_PLM.pm b/lib/Insteon_PLM.pm index 1ff749c..4d51fbd 100644 --- a/lib/Insteon_PLM.pm +++ b/lib/Insteon_PLM.pm @@ -41,6 +41,7 @@ Special Thanks to: package Insteon_PLM; use strict; +use Insteon; use Insteon::BaseInterface; use Insteon::BaseInsteon; use Insteon::AllLinkDatabase; @@ -238,7 +239,7 @@ sub initiate_linking_as_controller { my ($self, $group) = @_; - $group = 'FF' unless $group; + $group = '01' unless $group; # set up the PLM as the responder my $cmd = '01'; # controller code $cmd .= $group; # WARN - must be 2 digits and in hex!! diff --git a/lib/Insteon/Message.pm b/lib/Insteon/Message.pm index cc06a8b..2344da0 100755 --- a/lib/Insteon/Message.pm +++ b/lib/Insteon/Message.pm @@ -2,7 +2,7 @@ package Insteon::BaseMessage; use strict; -use Insteon; +#use Insteon; sub new { @@ -158,7 +158,7 @@ sub to_string package Insteon::InsteonMessage; use strict; -use Insteon; +#use Insteon; @Insteon::InsteonMessage::ISA = ('Insteon::BaseMessage'); @@ -186,11 +186,16 @@ sub command_to_hash $msg{hopsleft} = $hopflag >> 2; my $msgflag = hex(uc substr($p_state,12,1)); $msg{is_extended} = (0x01 & $msgflag) ? 1 : 0; + $msg{cmd_code} = substr($p_state,14,2); if ($msg{is_extended}) { + $msg{type} = 'direct'; $msg{source} = substr($p_state,0,6); $msg{destination} = substr($p_state,6,6); - $msg{extra} = substr($p_state,16,16); + $msg{extra} = substr($p_state,16,length($p_state)-16); + $msg{crc_valid} = (calculate_checksum($msg{cmd_code}.$msg{extra}) eq '00'); + main::print_log("[Insteon::InsteonMessage] WARN: Message has invalid checksum") + if( !($msg{crc_valid}) and $main::Debug{insteon}); } else { @@ -249,7 +254,6 @@ sub command_to_hash } } } - $msg{cmd_code} = substr($p_state,14,2); return %msg; } @@ -446,13 +450,45 @@ sub _derive_interface_data $cmd .= '00'; } + if( $self->command_type eq 'insteon_ext_send' and $self->setby->engine_version eq 'I2CS') { + #$message is the entire insteon command (no 0262 PLM command) + # i.e. '02622042d31f2e000107110000000000000000000000' + # 111111111122222222223333333333 + # 0123456789012345678901234567890123456789 + # '2042d31f2e000107110000000000000000000000' + if( length($cmd) < 40) { + main::print_log("[Insteon::InsteonMessage] WARN: insert_checksum " + . "failed; cmd to short: $cmd"); + } else { + $cmd = substr($cmd,0,38).calculate_checksum(substr($cmd,8,30)); + } + } + return $cmd; } +=item C<calculate_checksum( string )> + +Calculates a checksum of all hex bytes in the string. Returns two hex nibbles +that represent the checksum in hex. One useful characteristic of the checksum +is that summing over all the bytes "including" the checksum will always equal 00. +This makes it very easy to validate a checksum. + +=cut +sub calculate_checksum { + my ($string) = @_; + + #returns 2 characters as hex nibbles (e.g. AA) + my $sum = 0; + $sum += hex($_) for (unpack('(A2)*', $string)); + return unpack( 'H2', chr((~$sum + 1) & 0xff)); +} + + package Insteon::X10Message; use strict; -use Insteon; +#use Insteon; @Insteon::X10Message::ISA = ('Insteon::BaseMessage'); |
From: Kevin R. K. <ke...@kr...> - 2013-02-19 01:30:27
|
Cool sounds good. I am testing out a rebase on a duplicate branch of the Aldb_delta branch to your i2 branch. This should give me a bit of a head start on solving the conflicts as well as a chance to start coding support for i2 aldb_delta as well. On Mon, Feb 18, 2013 at 5:26 PM, Michael Stovenour <mi...@st...>wrote: > I just did a test merge of stovenour/i2_aldb_support into > mstovenour/master (my tracking branch for hollie/master). I don’t see > any overlap in the changes to your pull request. I’ve attached a diff of > the files the two branches share in common. I say go for it. Then we will > just need to address the “other” pull request later J That one will > prove to be much more fun but well worth it given the advances you made.** > ** > > ** ** > > ** ** > > *From:* Kevin Robert Keegan [mailto:ke...@kr...] > *Sent:* Monday, February 18, 2013 7:01 PM > > *To:* Michael Stovenour > *Cc:* The main list for the MisterHouse home automation program > *Subject:* Re: [mh] Insteon I2 Support**** > > ** ** > > It is ready to merge in, but I suspected the same thing so I have been > holding off. Let me know what you would like me to do.**** > > ** ** > > On Mon, Feb 18, 2013 at 4:57 PM, Michael Stovenour <mi...@st...> > wrote:**** > > I have been keeping up with hollie/master so hopefully the final i2 merge > is not too intrusive. What has me concerned right now is your pull request Fix > for Issue #75 - Correct Handling of All_Link Commands<https://github.com/hollie/misterhouse/pull/78>. > That will make it very difficult to merge my planned changes and I suspect > we will both need to repeat all the testing after the merge. Do you think > that code is ready to merge into hollie/master? If so I’ll pull > hollie/master and merge it into the i2_aldb_support branch. I could try > pulling that branch directly from you but I’m testing the limits of my git > experience. I have no idea of the unintended consequences.**** > > **** > > **** > > *From:* Kevin Robert Keegan [mailto:ke...@kr...] > *Sent:* Monday, February 18, 2013 6:31 PM > *To:* Michael Stovenour > *Cc:* The main list for the MisterHouse home automation program**** > > > *Subject:* Re: [mh] Insteon I2 Support**** > > **** > > I agree something needs to be done. The clearing of messages without > concern for the data contained within the response is bad.**** > > **** > > I have thought about this too. I agree with you suggestion, > process_message should return a value that determines whether the message > is cleared. **** > > **** > > I think we (mostly me) are going to have a ton of work to do to merge the > two branches. I have basically accepted that fact.**** > > **** > > On Mon, Feb 18, 2013 at 4:15 PM, Michael Stovenour <mi...@st...> > wrote:**** > > Kevin,**** > > In order to make this idea work, I need to either put a lot of device > message code in > BaseInterface.pm:InsteonBaseInterface->on_stnadard_insteon_received() or > I could move the logic for deciding on when to clear the active message to > BaseInsteon.pm:Insteon::BaseObject->_process_message(). I would like to > do the latter but it means changes to some of the same areas you are > working in. It could make merges a mess unless we are careful.**** > > **** > > My idea is to change all of the _process_message() calls in > on_standard_insteon_received() so that they expect a return value from > _process_message(). The return value will determine if > clear_active_message() is called. Basically I’ll let the device module > tell the PLM module when to consider the message transaction complete. I > think it is the cleanest way to do it.**** > > **** > > Let me know what you think. If this sounds reasonable we can negotiate > how to make the change.**** > > **** > > Sincerely,**** > > Michael**** > > **** > > *From:* Michael Stovenour [mailto:mi...@st...] > *Sent:* Monday, February 18, 2013 12:52 PM > *To:* 'Kevin Robert Keegan' > *Cc:* 'The main list for the MisterHouse home automation program'**** > > > *Subject:* Re: [mh] Insteon I2 Support**** > > **** > > Ok, I get the idea, thanks! I was not looking forward to figuring that > one out.**** > > **** > > Sincerely,**** > > Michael**** > > **** > > *From:* Kevin Robert Keegan [mailto:ke...@kr...<ke...@kr...>] > > *Sent:* Monday, February 18, 2013 12:34 PM > *To:* Michael Stovenour > *Cc:* Marc MERLIN; The main list for the MisterHouse home automation > program > *Subject:* Re: [mh] Insteon I2 Support**** > > **** > > sent that last one too soon:**** > > **** > > > https://github.com/krkeegan/misterhouse/commit/54042e40603ea7b1983492bace43236a9cd86be3 > **** > > **** > > It is actually "command" timeout that you want to use, not "xmit." I > would them make sure you call clear_message after the data message is > received.**** > > **** > > Kevin**** > > **** > > On Mon, Feb 18, 2013 at 10:32 AM, Kevin Robert Keegan <ke...@kr...> > wrote:**** > > Sorry it looks like clear_message is actually handled in BaseInterface. > So in this first commit I simply removed the call to clear_message and > bumped the send_timeout to an absurd 30 seconds:**** > > **** > > > https://github.com/krkeegan/misterhouse/commit/44924bdfb7e1a8a6dee0296969be3b2729712bdc > **** > > **** > > Then once it was clear that would work, I removed the 30 second timeout, > and then added code to reset the normal send_timeout for each ACK/NACK > received:**** > > **** > > **** > > On Mon, Feb 18, 2013 at 10:05 AM, Michael Stovenour <mi...@st...> > wrote:**** > > I had forgotten about that change you mentioned a while back. I think it > is a perfect solution. If you have a minute could you point me at the > check-in that included this change? **** > > **** > > *From:* Kevin Robert Keegan [mailto:ke...@kr...] > *Sent:* Monday, February 18, 2013 11:13 AM > *To:* Michael Stovenour > *Cc:* Marc MERLIN; The main list for the MisterHouse home automation > program > *Subject:* Re: [mh] Insteon I2 Support**** > > **** > > > > i need to add some logic that expects the message, starts a timer, and > retries if the > > message doesn't arrive.**** > > I am sure you already thought of this. But I ran into a similar situation > with All Link Cleanup messages. My suggestion would be that when mh > receives the ACK that it does not clear the active message, but only resets > the xmit timeout. This way if the data message doesn't arrive, mh will > simply resend the original request.**** > > I realize this may be difficult though, Greg put the clear message code > down in Insteon_plm. Far away from where the message is actually processed. > **** > > **** > > **** > > **** > > ** ** > |
From: Kevin R. K. <ke...@kr...> - 2013-02-19 02:05:42
|
OK, the rebase went fine, no major issues. So in theory, once you merge i2_aldb support in, we can merge in aldb_delta support without much difficulty. On Mon, Feb 18, 2013 at 5:30 PM, Kevin Robert Keegan <ke...@kr...>wrote: > Cool sounds good. I am testing out a rebase on a duplicate branch of the > Aldb_delta branch to your i2 branch. This should give me a bit of a head > start on solving the conflicts as well as a chance to start coding support > for i2 aldb_delta as well. > > > On Mon, Feb 18, 2013 at 5:26 PM, Michael Stovenour <mi...@st...>wrote: > >> I just did a test merge of stovenour/i2_aldb_support into >> mstovenour/master (my tracking branch for hollie/master). I don’t see >> any overlap in the changes to your pull request. I’ve attached a diff of >> the files the two branches share in common. I say go for it. Then we will >> just need to address the “other” pull request later J That one will >> prove to be much more fun but well worth it given the advances you made.* >> *** >> >> ** ** >> >> ** ** >> >> *From:* Kevin Robert Keegan [mailto:ke...@kr...] >> *Sent:* Monday, February 18, 2013 7:01 PM >> >> *To:* Michael Stovenour >> *Cc:* The main list for the MisterHouse home automation program >> *Subject:* Re: [mh] Insteon I2 Support**** >> >> ** ** >> >> It is ready to merge in, but I suspected the same thing so I have been >> holding off. Let me know what you would like me to do.**** >> >> ** ** >> >> On Mon, Feb 18, 2013 at 4:57 PM, Michael Stovenour <mi...@st...> >> wrote:**** >> >> I have been keeping up with hollie/master so hopefully the final i2 merge >> is not too intrusive. What has me concerned right now is your pull request Fix >> for Issue #75 - Correct Handling of All_Link Commands<https://github.com/hollie/misterhouse/pull/78>. >> That will make it very difficult to merge my planned changes and I suspect >> we will both need to repeat all the testing after the merge. Do you think >> that code is ready to merge into hollie/master? If so I’ll pull >> hollie/master and merge it into the i2_aldb_support branch. I could try >> pulling that branch directly from you but I’m testing the limits of my git >> experience. I have no idea of the unintended consequences.**** >> >> **** >> >> **** >> >> *From:* Kevin Robert Keegan [mailto:ke...@kr...] >> *Sent:* Monday, February 18, 2013 6:31 PM >> *To:* Michael Stovenour >> *Cc:* The main list for the MisterHouse home automation program**** >> >> >> *Subject:* Re: [mh] Insteon I2 Support**** >> >> **** >> >> I agree something needs to be done. The clearing of messages without >> concern for the data contained within the response is bad.**** >> >> **** >> >> I have thought about this too. I agree with you suggestion, >> process_message should return a value that determines whether the message >> is cleared. **** >> >> **** >> >> I think we (mostly me) are going to have a ton of work to do to merge the >> two branches. I have basically accepted that fact.**** >> >> **** >> >> On Mon, Feb 18, 2013 at 4:15 PM, Michael Stovenour <mi...@st...> >> wrote:**** >> >> Kevin,**** >> >> In order to make this idea work, I need to either put a lot of device >> message code in >> BaseInterface.pm:InsteonBaseInterface->on_stnadard_insteon_received() or >> I could move the logic for deciding on when to clear the active message to >> BaseInsteon.pm:Insteon::BaseObject->_process_message(). I would like to >> do the latter but it means changes to some of the same areas you are >> working in. It could make merges a mess unless we are careful.**** >> >> **** >> >> My idea is to change all of the _process_message() calls in >> on_standard_insteon_received() so that they expect a return value from >> _process_message(). The return value will determine if >> clear_active_message() is called. Basically I’ll let the device module >> tell the PLM module when to consider the message transaction complete. I >> think it is the cleanest way to do it.**** >> >> **** >> >> Let me know what you think. If this sounds reasonable we can negotiate >> how to make the change.**** >> >> **** >> >> Sincerely,**** >> >> Michael**** >> >> **** >> >> *From:* Michael Stovenour [mailto:mi...@st...] >> *Sent:* Monday, February 18, 2013 12:52 PM >> *To:* 'Kevin Robert Keegan' >> *Cc:* 'The main list for the MisterHouse home automation program'**** >> >> >> *Subject:* Re: [mh] Insteon I2 Support**** >> >> **** >> >> Ok, I get the idea, thanks! I was not looking forward to figuring that >> one out.**** >> >> **** >> >> Sincerely,**** >> >> Michael**** >> >> **** >> >> *From:* Kevin Robert Keegan [mailto:ke...@kr...<ke...@kr...>] >> >> *Sent:* Monday, February 18, 2013 12:34 PM >> *To:* Michael Stovenour >> *Cc:* Marc MERLIN; The main list for the MisterHouse home automation >> program >> *Subject:* Re: [mh] Insteon I2 Support**** >> >> **** >> >> sent that last one too soon:**** >> >> **** >> >> >> https://github.com/krkeegan/misterhouse/commit/54042e40603ea7b1983492bace43236a9cd86be3 >> **** >> >> **** >> >> It is actually "command" timeout that you want to use, not "xmit." I >> would them make sure you call clear_message after the data message is >> received.**** >> >> **** >> >> Kevin**** >> >> **** >> >> On Mon, Feb 18, 2013 at 10:32 AM, Kevin Robert Keegan <ke...@kr...> >> wrote:**** >> >> Sorry it looks like clear_message is actually handled in BaseInterface. >> So in this first commit I simply removed the call to clear_message and >> bumped the send_timeout to an absurd 30 seconds:**** >> >> **** >> >> >> https://github.com/krkeegan/misterhouse/commit/44924bdfb7e1a8a6dee0296969be3b2729712bdc >> **** >> >> **** >> >> Then once it was clear that would work, I removed the 30 second timeout, >> and then added code to reset the normal send_timeout for each ACK/NACK >> received:**** >> >> **** >> >> **** >> >> On Mon, Feb 18, 2013 at 10:05 AM, Michael Stovenour < >> mi...@st...> wrote:**** >> >> I had forgotten about that change you mentioned a while back. I think it >> is a perfect solution. If you have a minute could you point me at the >> check-in that included this change? **** >> >> **** >> >> *From:* Kevin Robert Keegan [mailto:ke...@kr...] >> *Sent:* Monday, February 18, 2013 11:13 AM >> *To:* Michael Stovenour >> *Cc:* Marc MERLIN; The main list for the MisterHouse home automation >> program >> *Subject:* Re: [mh] Insteon I2 Support**** >> >> **** >> >> >> > i need to add some logic that expects the message, starts a timer, and >> retries if the >> > message doesn't arrive.**** >> >> I am sure you already thought of this. But I ran into a similar >> situation with All Link Cleanup messages. My suggestion would be that when >> mh receives the ACK that it does not clear the active message, but only >> resets the xmit timeout. This way if the data message doesn't arrive, mh >> will simply resend the original request.**** >> >> I realize this may be difficult though, Greg put the clear message code >> down in Insteon_plm. Far away from where the message is actually processed. >> **** >> >> **** >> >> **** >> >> **** >> >> ** ** >> > > |
From: Marc M. <ma...@me...> - 2013-02-18 17:03:16
|
On Mon, Feb 18, 2013 at 10:55:52AM -0600, Michael Stovenour wrote: > (skipped all good points you posted on little things left to fix) Everything you wrote makes sense, and hopefully tracking those down won't take too long. I also agree that it's better to keep my network and devices broken to help find those bugs quicker and validate when they're fixed. > Thanks again for all your help isolating the issues; I know it takes a lot of your time > but your efforts to isolate and segment out each issue really helps a lot. I bestow on > you the title "Official Insteon Bug Hunter"! As a side note, I'm sorry this is all I have the time and brainpower to do right now, ideally I'd be diving into the code instead, and again the time I've been spending is nothing compared to the one you have, so we need to thank you more than you're thanking me :) 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: Joel D. <jr...@pr...> - 2013-02-18 17:21:05
|
On Mon, 18 Feb 2013, it would appear that Marc MERLIN wrote: > On Mon, Feb 18, 2013 at 10:55:52AM -0600, Michael Stovenour wrote: > >> (skipped all good points you posted on little things left to fix) > > Everything you wrote makes sense, and hopefully tracking those down won't > take too long. > I also agree that it's better to keep my network and devices broken to help > find those bugs quicker and validate when they're fixed. > >> Thanks again for all your help isolating the issues; I know it takes a lot of your time >> but your efforts to isolate and segment out each issue really helps a lot. I bestow on >> you the title "Official Insteon Bug Hunter"! > > As a side note, I'm sorry this is all I have the time and brainpower to do > right now, ideally I'd be diving into the code instead, and again the time > I've been spending is nothing compared to the one you have, so we need to > thank you more than you're thanking me :) > > Marc I don't even use Insteon right now, as I've been having good luck with all of my x10 devices for 20+ years now, but I want to thank all of you who've been putting all of this effort into improving MH and helping bring it up to date with functionality for modern hardware. It's nice to know that if/when I ever make the jump to Insteon the software will have fully functioning support. Thanks guys. Joel -- Joel Davidson Austin, TX |
From: Eloy P. <pe...@ch...> - 2013-02-19 01:17:57
|
On 02/18/2013 12:03 PM, Marc MERLIN wrote: [...] > As a side note, I'm sorry this is all I have the time and brainpower to do > right now, ideally I'd be diving into the code instead, and again the time > I've been spending is nothing compared to the one you have, so we need to > thank you more than you're thanking me :) No kidding; Michael and Kevin are kicking tail ;-) Eloy Paris.- |
From: Michael S. <mi...@st...> - 2013-02-19 05:09:49
|
I saw the merge. So here's what I would like to do: 1) Create a branch where I refactor the existing main line code but that doesn't address i2 2) Pull/merge that code into hollie/master 3) Merge the same changes into my i2 code 4) Make the additional changes necessary for the i2 code This is technically not needed but I would like to separate out the refactoring in case it is a few weeks until we are ready to merge the I2 code into hollie/master (or a branch thereof). That way you could make other changes without overly complicating the i2 merge later. I think I'm also being cautious because this change is at the heart of the Insteon processing. What do you think of the plan? From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 8:06 PM To: Michael Stovenour Cc: The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support OK, the rebase went fine, no major issues. So in theory, once you merge i2_aldb support in, we can merge in aldb_delta support without much difficulty. On Mon, Feb 18, 2013 at 5:30 PM, Kevin Robert Keegan <ke...@kr...> wrote: Cool sounds good. I am testing out a rebase on a duplicate branch of the Aldb_delta branch to your i2 branch. This should give me a bit of a head start on solving the conflicts as well as a chance to start coding support for i2 aldb_delta as well. On Mon, Feb 18, 2013 at 5:26 PM, Michael Stovenour <mi...@st...> wrote: I just did a test merge of stovenour/i2_aldb_support into mstovenour/master (my tracking branch for hollie/master). I don't see any overlap in the changes to your pull request. I've attached a diff of the files the two branches share in common. I say go for it. Then we will just need to address the "other" pull request later J That one will prove to be much more fun but well worth it given the advances you made. From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 7:01 PM To: Michael Stovenour Cc: The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support It is ready to merge in, but I suspected the same thing so I have been holding off. Let me know what you would like me to do. On Mon, Feb 18, 2013 at 4:57 PM, Michael Stovenour <mi...@st...> wrote: I have been keeping up with hollie/master so hopefully the final i2 merge is not too intrusive. What has me concerned right now is your pull request Fix for Issue #75 - Correct Handling of All_Link Commands <https://github.com/hollie/misterhouse/pull/78> . That will make it very difficult to merge my planned changes and I suspect we will both need to repeat all the testing after the merge. Do you think that code is ready to merge into hollie/master? If so I'll pull hollie/master and merge it into the i2_aldb_support branch. I could try pulling that branch directly from you but I'm testing the limits of my git experience. I have no idea of the unintended consequences. From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 6:31 PM To: Michael Stovenour Cc: The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support I agree something needs to be done. The clearing of messages without concern for the data contained within the response is bad. I have thought about this too. I agree with you suggestion, process_message should return a value that determines whether the message is cleared. I think we (mostly me) are going to have a ton of work to do to merge the two branches. I have basically accepted that fact. On Mon, Feb 18, 2013 at 4:15 PM, Michael Stovenour <mi...@st...> wrote: Kevin, In order to make this idea work, I need to either put a lot of device message code in BaseInterface.pm:InsteonBaseInterface->on_stnadard_insteon_received() or I could move the logic for deciding on when to clear the active message to BaseInsteon.pm:Insteon::BaseObject->_process_message(). I would like to do the latter but it means changes to some of the same areas you are working in. It could make merges a mess unless we are careful. My idea is to change all of the _process_message() calls in on_standard_insteon_received() so that they expect a return value from _process_message(). The return value will determine if clear_active_message() is called. Basically I'll let the device module tell the PLM module when to consider the message transaction complete. I think it is the cleanest way to do it. Let me know what you think. If this sounds reasonable we can negotiate how to make the change. Sincerely, Michael From: Michael Stovenour [mailto:mi...@st...] Sent: Monday, February 18, 2013 12:52 PM To: 'Kevin Robert Keegan' Cc: 'The main list for the MisterHouse home automation program' Subject: Re: [mh] Insteon I2 Support Ok, I get the idea, thanks! I was not looking forward to figuring that one out. Sincerely, Michael From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 12:34 PM To: Michael Stovenour Cc: Marc MERLIN; The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support sent that last one too soon: https://github.com/krkeegan/misterhouse/commit/54042e40603ea7b1983492bace43236a9cd86be3 It is actually "command" timeout that you want to use, not "xmit." I would them make sure you call clear_message after the data message is received. Kevin On Mon, Feb 18, 2013 at 10:32 AM, Kevin Robert Keegan <ke...@kr...> wrote: Sorry it looks like clear_message is actually handled in BaseInterface. So in this first commit I simply removed the call to clear_message and bumped the send_timeout to an absurd 30 seconds: https://github.com/krkeegan/misterhouse/commit/44924bdfb7e1a8a6dee0296969be3b2729712bdc Then once it was clear that would work, I removed the 30 second timeout, and then added code to reset the normal send_timeout for each ACK/NACK received: On Mon, Feb 18, 2013 at 10:05 AM, Michael Stovenour <mi...@st...> wrote: I had forgotten about that change you mentioned a while back. I think it is a perfect solution. If you have a minute could you point me at the check-in that included this change? From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 11:13 AM To: Michael Stovenour Cc: Marc MERLIN; The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support > i need to add some logic that expects the message, starts a timer, and retries if the > message doesn't arrive. I am sure you already thought of this. But I ran into a similar situation with All Link Cleanup messages. My suggestion would be that when mh receives the ACK that it does not clear the active message, but only resets the xmit timeout. This way if the data message doesn't arrive, mh will simply resend the original request. I realize this may be difficult though, Greg put the clear message code down in Insteon_plm. Far away from where the message is actually processed. |
From: Michael S. <mi...@st...> - 2013-02-19 05:27:36
|
Ok, never mind. Once I looked at the changes needed in the main line code after your merge, they really are not all that large. I'll just make the change to my i2 branch. I'm hopefully not that far from completion anyway. From: Michael Stovenour [mailto:mi...@st...] Sent: Monday, February 18, 2013 11:10 PM To: 'Kevin Robert Keegan' Cc: 'The main list for the MisterHouse home automation program' Subject: Re: [mh] Insteon I2 Support I saw the merge. So here's what I would like to do: 1) Create a branch where I refactor the existing main line code but that doesn't address i2 2) Pull/merge that code into hollie/master 3) Merge the same changes into my i2 code 4) Make the additional changes necessary for the i2 code This is technically not needed but I would like to separate out the refactoring in case it is a few weeks until we are ready to merge the I2 code into hollie/master (or a branch thereof). That way you could make other changes without overly complicating the i2 merge later. I think I'm also being cautious because this change is at the heart of the Insteon processing. What do you think of the plan? From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 8:06 PM To: Michael Stovenour Cc: The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support OK, the rebase went fine, no major issues. So in theory, once you merge i2_aldb support in, we can merge in aldb_delta support without much difficulty. On Mon, Feb 18, 2013 at 5:30 PM, Kevin Robert Keegan <ke...@kr...> wrote: Cool sounds good. I am testing out a rebase on a duplicate branch of the Aldb_delta branch to your i2 branch. This should give me a bit of a head start on solving the conflicts as well as a chance to start coding support for i2 aldb_delta as well. On Mon, Feb 18, 2013 at 5:26 PM, Michael Stovenour <mi...@st...> wrote: I just did a test merge of stovenour/i2_aldb_support into mstovenour/master (my tracking branch for hollie/master). I don't see any overlap in the changes to your pull request. I've attached a diff of the files the two branches share in common. I say go for it. Then we will just need to address the "other" pull request later J That one will prove to be much more fun but well worth it given the advances you made. From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 7:01 PM To: Michael Stovenour Cc: The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support It is ready to merge in, but I suspected the same thing so I have been holding off. Let me know what you would like me to do. On Mon, Feb 18, 2013 at 4:57 PM, Michael Stovenour <mi...@st...> wrote: I have been keeping up with hollie/master so hopefully the final i2 merge is not too intrusive. What has me concerned right now is your pull request Fix for Issue #75 - Correct Handling of All_Link Commands <https://github.com/hollie/misterhouse/pull/78> . That will make it very difficult to merge my planned changes and I suspect we will both need to repeat all the testing after the merge. Do you think that code is ready to merge into hollie/master? If so I'll pull hollie/master and merge it into the i2_aldb_support branch. I could try pulling that branch directly from you but I'm testing the limits of my git experience. I have no idea of the unintended consequences. From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 6:31 PM To: Michael Stovenour Cc: The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support I agree something needs to be done. The clearing of messages without concern for the data contained within the response is bad. I have thought about this too. I agree with you suggestion, process_message should return a value that determines whether the message is cleared. I think we (mostly me) are going to have a ton of work to do to merge the two branches. I have basically accepted that fact. On Mon, Feb 18, 2013 at 4:15 PM, Michael Stovenour <mi...@st...> wrote: Kevin, In order to make this idea work, I need to either put a lot of device message code in BaseInterface.pm:InsteonBaseInterface->on_stnadard_insteon_received() or I could move the logic for deciding on when to clear the active message to BaseInsteon.pm:Insteon::BaseObject->_process_message(). I would like to do the latter but it means changes to some of the same areas you are working in. It could make merges a mess unless we are careful. My idea is to change all of the _process_message() calls in on_standard_insteon_received() so that they expect a return value from _process_message(). The return value will determine if clear_active_message() is called. Basically I'll let the device module tell the PLM module when to consider the message transaction complete. I think it is the cleanest way to do it. Let me know what you think. If this sounds reasonable we can negotiate how to make the change. Sincerely, Michael From: Michael Stovenour [mailto:mi...@st...] Sent: Monday, February 18, 2013 12:52 PM To: 'Kevin Robert Keegan' Cc: 'The main list for the MisterHouse home automation program' Subject: Re: [mh] Insteon I2 Support Ok, I get the idea, thanks! I was not looking forward to figuring that one out. Sincerely, Michael From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 12:34 PM To: Michael Stovenour Cc: Marc MERLIN; The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support sent that last one too soon: https://github.com/krkeegan/misterhouse/commit/54042e40603ea7b1983492bace43236a9cd86be3 It is actually "command" timeout that you want to use, not "xmit." I would them make sure you call clear_message after the data message is received. Kevin On Mon, Feb 18, 2013 at 10:32 AM, Kevin Robert Keegan <ke...@kr...> wrote: Sorry it looks like clear_message is actually handled in BaseInterface. So in this first commit I simply removed the call to clear_message and bumped the send_timeout to an absurd 30 seconds: https://github.com/krkeegan/misterhouse/commit/44924bdfb7e1a8a6dee0296969be3b2729712bdc Then once it was clear that would work, I removed the 30 second timeout, and then added code to reset the normal send_timeout for each ACK/NACK received: On Mon, Feb 18, 2013 at 10:05 AM, Michael Stovenour <mi...@st...> wrote: I had forgotten about that change you mentioned a while back. I think it is a perfect solution. If you have a minute could you point me at the check-in that included this change? From: Kevin Robert Keegan [mailto:ke...@kr...] Sent: Monday, February 18, 2013 11:13 AM To: Michael Stovenour Cc: Marc MERLIN; The main list for the MisterHouse home automation program Subject: Re: [mh] Insteon I2 Support > i need to add some logic that expects the message, starts a timer, and retries if the > message doesn't arrive. I am sure you already thought of this. But I ran into a similar situation with All Link Cleanup messages. My suggestion would be that when mh receives the ACK that it does not clear the active message, but only resets the xmit timeout. This way if the data message doesn't arrive, mh will simply resend the original request. I realize this may be difficult though, Greg put the clear message code down in Insteon_plm. Far away from where the message is actually processed. |
From: Kevin R. K. <ke...@kr...> - 2013-02-19 05:28:08
|
That all sounds fine to me, but I have no training in programming and I understand even less about git. I leave it up to others to figure out what is the best process. On Feb 18, 2013 9:09 PM, "Michael Stovenour" <mi...@st...> wrote: > I saw the merge. So here’s what I would like to do:**** > > **1) **Create a branch where I refactor the existing main line code > but that doesn’t address i2**** > > **2) **Pull/merge that code into hollie/master**** > > **3) **Merge the same changes into my i2 code**** > > **4) **Make the additional changes necessary for the i2 code**** > > ** ** > > This is technically not needed but I would like to separate out the > refactoring in case it is a few weeks until we are ready to merge the I2 > code into hollie/master (or a branch thereof). That way you could make > other changes without overly complicating the i2 merge later. I think I’m > also being cautious because this change is at the heart of the Insteon > processing. What do you think of the plan?**** > > ** ** > > ** ** > > *From:* Kevin Robert Keegan [mailto:ke...@kr...] > *Sent:* Monday, February 18, 2013 8:06 PM > *To:* Michael Stovenour > *Cc:* The main list for the MisterHouse home automation program > *Subject:* Re: [mh] Insteon I2 Support**** > > ** ** > > OK, the rebase went fine, no major issues. So in theory, once you merge > i2_aldb support in, we can merge in aldb_delta support without much > difficulty.**** > > ** ** > > On Mon, Feb 18, 2013 at 5:30 PM, Kevin Robert Keegan <ke...@kr...> > wrote:**** > > Cool sounds good. I am testing out a rebase on a duplicate branch of the > Aldb_delta branch to your i2 branch. This should give me a bit of a head > start on solving the conflicts as well as a chance to start coding support > for i2 aldb_delta as well.**** > > ** ** > > On Mon, Feb 18, 2013 at 5:26 PM, Michael Stovenour <mi...@st...> > wrote:**** > > I just did a test merge of stovenour/i2_aldb_support into > mstovenour/master (my tracking branch for hollie/master). I don’t see > any overlap in the changes to your pull request. I’ve attached a diff of > the files the two branches share in common. I say go for it. Then we will > just need to address the “other” pull request later J That one will > prove to be much more fun but well worth it given the advances you made.** > ** > > **** > > **** > > *From:* Kevin Robert Keegan [mailto:ke...@kr...] > *Sent:* Monday, February 18, 2013 7:01 PM**** > > > *To:* Michael Stovenour > *Cc:* The main list for the MisterHouse home automation program > *Subject:* Re: [mh] Insteon I2 Support**** > > **** > > It is ready to merge in, but I suspected the same thing so I have been > holding off. Let me know what you would like me to do.**** > > **** > > On Mon, Feb 18, 2013 at 4:57 PM, Michael Stovenour <mi...@st...> > wrote:**** > > I have been keeping up with hollie/master so hopefully the final i2 merge > is not too intrusive. What has me concerned right now is your pull request Fix > for Issue #75 - Correct Handling of All_Link Commands<https://github.com/hollie/misterhouse/pull/78>. > That will make it very difficult to merge my planned changes and I suspect > we will both need to repeat all the testing after the merge. Do you think > that code is ready to merge into hollie/master? If so I’ll pull > hollie/master and merge it into the i2_aldb_support branch. I could try > pulling that branch directly from you but I’m testing the limits of my git > experience. I have no idea of the unintended consequences.**** > > **** > > **** > > *From:* Kevin Robert Keegan [mailto:ke...@kr...] > *Sent:* Monday, February 18, 2013 6:31 PM > *To:* Michael Stovenour > *Cc:* The main list for the MisterHouse home automation program**** > > > *Subject:* Re: [mh] Insteon I2 Support**** > > **** > > I agree something needs to be done. The clearing of messages without > concern for the data contained within the response is bad.**** > > **** > > I have thought about this too. I agree with you suggestion, > process_message should return a value that determines whether the message > is cleared. **** > > **** > > I think we (mostly me) are going to have a ton of work to do to merge the > two branches. I have basically accepted that fact.**** > > **** > > On Mon, Feb 18, 2013 at 4:15 PM, Michael Stovenour <mi...@st...> > wrote:**** > > Kevin,**** > > In order to make this idea work, I need to either put a lot of device > message code in > BaseInterface.pm:InsteonBaseInterface->on_stnadard_insteon_received() or > I could move the logic for deciding on when to clear the active message to > BaseInsteon.pm:Insteon::BaseObject->_process_message(). I would like to > do the latter but it means changes to some of the same areas you are > working in. It could make merges a mess unless we are careful.**** > > **** > > My idea is to change all of the _process_message() calls in > on_standard_insteon_received() so that they expect a return value from > _process_message(). The return value will determine if > clear_active_message() is called. Basically I’ll let the device module > tell the PLM module when to consider the message transaction complete. I > think it is the cleanest way to do it.**** > > **** > > Let me know what you think. If this sounds reasonable we can negotiate > how to make the change.**** > > **** > > Sincerely,**** > > Michael**** > > **** > > *From:* Michael Stovenour [mailto:mi...@st...] > *Sent:* Monday, February 18, 2013 12:52 PM > *To:* 'Kevin Robert Keegan' > *Cc:* 'The main list for the MisterHouse home automation program'**** > > > *Subject:* Re: [mh] Insteon I2 Support**** > > **** > > Ok, I get the idea, thanks! I was not looking forward to figuring that > one out.**** > > **** > > Sincerely,**** > > Michael**** > > **** > > *From:* Kevin Robert Keegan [mailto:ke...@kr...<ke...@kr...>] > > *Sent:* Monday, February 18, 2013 12:34 PM > *To:* Michael Stovenour > *Cc:* Marc MERLIN; The main list for the MisterHouse home automation > program > *Subject:* Re: [mh] Insteon I2 Support**** > > **** > > sent that last one too soon:**** > > **** > > > https://github.com/krkeegan/misterhouse/commit/54042e40603ea7b1983492bace43236a9cd86be3 > **** > > **** > > It is actually "command" timeout that you want to use, not "xmit." I > would them make sure you call clear_message after the data message is > received.**** > > **** > > Kevin**** > > **** > > On Mon, Feb 18, 2013 at 10:32 AM, Kevin Robert Keegan <ke...@kr...> > wrote:**** > > Sorry it looks like clear_message is actually handled in BaseInterface. > So in this first commit I simply removed the call to clear_message and > bumped the send_timeout to an absurd 30 seconds:**** > > **** > > > https://github.com/krkeegan/misterhouse/commit/44924bdfb7e1a8a6dee0296969be3b2729712bdc > **** > > **** > > Then once it was clear that would work, I removed the 30 second timeout, > and then added code to reset the normal send_timeout for each ACK/NACK > received:**** > > **** > > **** > > On Mon, Feb 18, 2013 at 10:05 AM, Michael Stovenour <mi...@st...> > wrote:**** > > I had forgotten about that change you mentioned a while back. I think it > is a perfect solution. If you have a minute could you point me at the > check-in that included this change? **** > > **** > > *From:* Kevin Robert Keegan [mailto:ke...@kr...] > *Sent:* Monday, February 18, 2013 11:13 AM > *To:* Michael Stovenour > *Cc:* Marc MERLIN; The main list for the MisterHouse home automation > program > *Subject:* Re: [mh] Insteon I2 Support**** > > **** > > > > i need to add some logic that expects the message, starts a timer, and > retries if the > > message doesn't arrive.**** > > I am sure you already thought of this. But I ran into a similar situation > with All Link Cleanup messages. My suggestion would be that when mh > receives the ACK that it does not clear the active message, but only resets > the xmit timeout. This way if the data message doesn't arrive, mh will > simply resend the original request.**** > > I realize this may be difficult though, Greg put the clear message code > down in Insteon_plm. Far away from where the message is actually processed. > **** > > **** > > **** > > **** > > **** > > ** ** > > ** ** > |