Re: [mh] Trying out the updated insteon branch -> scan all and
orphan deletes still not quite there.
From: Marc M. <ma...@me...> - 2011-06-19 00:23:08
Attachments:
items.mht
|
Gregg, you don't know how good your timing was. My PLM finally mostly died beyond a state where it was usable for more than a few hours at a time between power cycles. I got a 2413U which I'm configuring with your new insteon code right now. Let me look back at my last status Email to see how things are as of r1914. My config file is attached at the end of this mail. Summary of showstoppers: A) scan link table with PLM is not working but it works for other devices B) delete orphan links deletes too much C) lamp update onlevel/ramprate kills mh (not a showstopper) D) scan all link tables never finishes for me (lots of details below). If you can help me, I think A) is important but I might be able to do without B) is absolutely blocking, I need to unlink my dead PLM from all my devices without breaking other links. D) is problematic to say the least, but with 10 full scans and hand scans of my last 2 devices I think I got mh to have a snapshot of all my devices for now. So B is the most important for now. On Sat, Oct 02, 2010 at 12:11:48PM -0700, Marc MERLIN wrote: > 2) > How about this: > 02/10/2010 11:51:59 Running: yard lights kpls sync links > 02/10/2010 11:51:59 [Insteon::ALDB_i1] adding link record $gar_outlights_kpl light level controlled by $PLM and group: 72 with on level: 100% and ramp rate: 0.1 > 02/10/2010 11:51:59 [Insteon::ALDB_i1] WARN: $gar_outlights_kpl write_link failure: no address available for record to device: 129dfb and group: 72 and is_controller: 0 This works now. > So things are definitely better, but a few problems, all showstoppers more or less: > 5) scan all links kills mh: Can't locate object method "scan_link_table" via package "Voice_Cmd" at This was the biggest one for me, and it works now, thanks. I recommend you rename 'scan link tables' into 'scan all devices link tables' Well, it starts that is, individual scan tables still fail randomly for me, which in turn does affect doing a full scan. See below for scan all links hanging in the middle. A) scan link table with PLM is not working but it works for other devices 18/06/2011 17:06:38 Running: PLM scan link table 18/06/2011 17:06:38 [Insteon_PLM] DEBUG: Parsing serial data: 026915 18/06/2011 17:06:47 Running: PLM show link table to log 18/06/2011 17:06:50 Running: PLM scan link table 18/06/2011 17:06:51 [Insteon_PLM] DEBUG: Parsing serial data: 026915 B) delete orphan links doesn't seem to take into account links with remotelincs, which get excluded from the scan (but the audit function rocks, thanks for that). 18/06/2011 15:59:42 [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $fmr_outside(01) as responder and $rlink_blk1_1(06) Similarly, motion sensors: Delete orphan because no reverse link defined for: $garage1_neon_kpl(05) as responder and $gar_mos1(01) I think my full scan which I thought was full, may not be as full as I think yet. I still get a lot of these: (AUDIT) Delete orphan because no reciprocal link defined for: $dining_kpl(02) as controller and $kitchen_kpl(01) those should not happen since those devices were scanned and aren't excluded from the scan like rlink. C) lvr lamp update onlevel/ramprate still kills mh: > I tried another one and mh died: > Running: lvr lamp update onlevel/ramprate > [Insteon::ALDB_i1] $lvr_lamp accessing memory at location: 0x0032 > [Insteon_PLM] Parsing serial data: 02620a99e505280006 > [Insteon_PLM] DEBUG: received interface acknowledge: obj=$lvr_lamp; command=set_address_msb; extra=00 > [Insteon_PLM] Parsing serial data: 02500a99e5129dfb212800d4 > [Insteon_PLM] Parsing serial data: 02620a99e5052b3206 > [Insteon_PLM] DEBUG: received interface acknowledge: obj=$lvr_lamp; command=peek; extra=32 > [Insteon_PLM] Parsing serial data: 02500a99e5129dfb212bfed4 > Can't locate object method "local_onlevel" via package "Insteon::ALDB_i1" at ../lib/Insteon/AllLinkDatabase.pm line 508. > gargamel:/var/local/src/misterhouse/mh/bin$ This still fails: 18/06/2011 17:11:22 Running: lvr lamp update onlevel/ramprate 18/06/2011 17:11:22 [Insteon::ALDB_i1] $lvr_lamp accessing memory at location: 0x0032 18/06/2011 17:11:22 [Insteon_PLM] DEBUG: Parsing serial data: 02620a99e505280006 18/06/2011 17:11:22 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$lvr_lamp; command=set_address_msb; extra=00 18/06/2011 17:11:23 [Insteon_PLM] DEBUG: Parsing serial data: 02500a99e518d4ce212800 18/06/2011 17:11:23 [Insteon_PLM] DEBUG: Parsing serial data: 02620a99e5052b3206 18/06/2011 17:11:23 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$lvr_lamp; command=peek; extra=32 18/06/2011 17:11:23 [Insteon_PLM] DEBUG: Parsing serial data: 02500a99e518d4ce212bfe Can't locate object method "local_onlevel" via package "Insteon::ALDB_i1" at ../lib/Insteon/AllLinkDatabase.pm line 534. D) scan link tables still hangs pseudo randomly > 1) scan link table stops in the middle with > 'PLM command timer expired but no transmission in place. Moving on..' This still happens for me: 18/06/2011 14:51:06 Running: PLM scan link tables 18/06/2011 14:51:06 [Scan all link tables] Now scanning: $PLM (1 of 25) 18/06/2011 14:51:06 [Insteon_PLM] DEBUG: Parsing serial data: 026915 18/06/2011 14:51:06 [Scan all link tables] Now scanning: $mbr_kpl (2 of 25) 18/06/2011 14:51:06 [Insteon::ALDB_i1] $mbr_kpl accessing memory at location: 0x0FF8 18/06/2011 14:51:06 [Insteon_PLM] DEBUG: Parsing serial data: 026211e19d05280f06 (...) 18/06/2011 14:56:41 [Scan all link tables] Now scanning: $fmr_slav (9 of 25) 18/06/2011 14:56:41 [Insteon::ALDB_i1] $fmr_slav accessing memory at location: 0x0FF8 (...) 18/06/2011 14:56:58 [Insteon::ALDB_i1] $fmr_slav accessing memory at location: 0x0FC8 18/06/2011 14:56:58 [Insteon_PLM] DEBUG: Parsing serial data: 02620f0f2a05280f06 18/06/2011 14:56:58 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_slav; command=set_address_msb; extra=0F 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: Parsing serial data: 02500f0f2a18d4ce26280f 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: Parsing serial data: 02620f0f2a052bc806 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_slav; command=peek; extra=C8 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: Parsing serial data: 02500f0f2a18d4ce212ba2 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: Parsing serial data: 02620f0f2a052bc906 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_slav; command=peek; extra=C9 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: Parsing serial data: 02500f0f2a18d4ce212b10 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: Parsing serial data: 02620f0f2a052bca06 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_slav; command=peek; extra=CA 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: Parsing serial data: 02500f0f2a18d4ce212b12 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: Parsing serial data: 02620f0f2a052bcb06 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_slav; command=peek; extra=CB 18/06/2011 14:57:00 : Saving object states ... done 18/06/2011 14:57:00 [Insteon_PLM] DEBUG: Parsing serial data: 02500f0f2a18d4ce212b9d 18/06/2011 14:57:01 [Insteon_PLM] PLM command timer expired but no transmission in place. Moving on... trying again said: 18/06/2011 14:59:49 Running: PLM scan link tables 18/06/2011 14:59:49 [Scan all linktables] WARN: link already underway. Ignoring request for new scan ... At this point, the state is wedged and I need to restart mh to recover. Another time it hung here: 18/06/2011 15:34:28 [Insteon::ALDB_i1] $fmr_kpl accessing memory at location: 0x0DA8 18/06/2011 15:34:28 [Insteon_PLM] DEBUG: Parsing serial data: 02620e074905280d06 18/06/2011 15:34:28 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_kpl; command=set_address_msb; extra=0D 18/06/2011 15:34:28 [Insteon_PLM] DEBUG: Parsing serial data: 02500e074918d4ce21280d02500e074918d4ce21280d 18/06/2011 15:34:28 [Insteon::ALDB_i1] $fmr_kpl completed link memory scan 18/06/2011 15:34:28 [Scan all link tables] Now scanning: $fmr_slav (9 of 25) 18/06/2011 15:34:28 [Insteon::ALDB_i1] $fmr_slav accessing memory at location: 0x0FF8 18/06/2011 15:34:28 [Insteon_PLM] DEBUG: Parsing serial data: 02620e0749052ba806 18/06/2011 15:34:28 [Insteon_PLM] DEBUG: Prepending prior data fragment: 02620e0749052ba806 18/06/2011 15:34:28 [Insteon_PLM] DEBUG: Parsing serial data: 02620e0749052ba80602500e074918d4ce212be2 18/06/2011 15:34:28 [Insteon::BaseObject] received command/state acknowledge from $fmr_kpl: peek and data: e2 Next time around it hung there too: 18/06/2011 15:43:18 [Insteon::ALDB_i1] $fmr_kpl completed link memory scan 18/06/2011 15:43:18 [Scan all link tables] Now scanning: $fmr_slav (9 of 25) 18/06/2011 15:43:18 [Insteon::ALDB_i1] $fmr_slav accessing memory at location: 0x0FF8 18/06/2011 15:43:18 [Insteon_PLM] DEBUG: Parsing serial data: 02620e0749052be806 18/06/2011 15:43:18 [Insteon_PLM] DEBUG: Prepending prior data fragment: 02620e0749052be806 18/06/2011 15:43:18 [Insteon_PLM] DEBUG: Parsing serial data: 02620e0749052be80602500e074918d4ce212ba2 18/06/2011 15:43:18 [Insteon::BaseObject] received command/state acknowledge from $fmr_kpl: peek and data: a2 Next time around it didn't go nearly as far before stopping: 18/06/2011 15:55:06 [Insteon::ALDB_i1] $mbr_kpl accessing memory at location: 0x0FC8 18/06/2011 15:55:06 [Insteon_PLM] DEBUG: Parsing serial data: 026211e19d052bd706 18/06/2011 15:55:06 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026211e19d052bd706 18/06/2011 15:55:06 [Insteon_PLM] DEBUG: Parsing serial data: 026211e19d052bd706025011e19d18d4ce212b05025011e19d18d4ce212b05 18/06/2011 15:55:06 [Insteon::ALDB_i1] $mbr_kpl completed link memory scan 18/06/2011 15:55:06 [Scan all link tables] Now scanning: $mbr_lamp2 (3 of 25) 18/06/2011 15:55:06 [Insteon::ALDB_i1] $mbr_lamp2 accessing memory at location: 0x0FF8 18/06/2011 15:55:06 [Insteon_PLM] DEBUG: Parsing serial data: 026211e19d05280f06 18/06/2011 15:55:07 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026211e19d05280f06 18/06/2011 15:55:07 [Insteon_PLM] DEBUG: Parsing serial data: 026211e19d05280f06025011e19d18d4ce21280f By then I had to power cycle my PLM for scans to last more than a minute and then I got back to this: 18/06/2011 16:07:21 [Insteon::ALDB_i1] $fmr_kpl completed link memory scan 18/06/2011 16:07:21 [Scan all link tables] Now scanning: $fmr_slav (9 of 25) 18/06/2011 16:07:21 [Insteon::ALDB_i1] $fmr_slav accessing memory at location: 0x0FF8 18/06/2011 16:07:21 [Insteon_PLM] DEBUG: Parsing serial data: 02620e0749052b7006 18/06/2011 16:07:21 [Insteon_PLM] DEBUG: Prepending prior data fragment: 02620e0749052b7006 18/06/2011 16:07:21 [Insteon_PLM] DEBUG: Parsing serial data: 02620e0749052b700602500e074918d4ce212ba2 18/06/2011 16:07:21 [Insteon::BaseObject] received command/state acknowledge from $fmr_kpl: peek and data: a2 If I run scan link table directly on fmr_slav, it works better. [Insteon::ALDB_i1] $fmr_slav completed link memory scan [Insteon::ALDB_i1] link table for $fmr_slav (devcat: ): [Insteon::ALDB_i1] [0x0F68] is empty [Insteon::ALDB_i1] [0x0F70] contlr(a2) record to 0511aa (1b), (d1:8d, d2:fe, d3:1b) [Insteon::ALDB_i1] [0x0F78] rspndr(01) record to $rlink_blk1_1 (05): onlevel=100% and ramp=2s (d3:00) [Insteon::ALDB_i1] [0x0F80] contlr(01) record to $fmr_lamp (01), (d1:ff, d2:1b, d3:00) [Insteon::ALDB_i1] [0x0F88] rspndr(01) record to 129dfb (15): onlevel=100% and ramp=2s (d3:00) [Insteon::ALDB_i1] [0x0F90] rspndr(01) record to 0a3835 (05): onlevel=100% and ramp=2s (d3:00) [Insteon::ALDB_i1] [0x0F98] rspndr(01) record to $lvr_kpl (05): onlevel=100% and ramp=2s (d3:00) [Insteon::ALDB_i1] [0x0FA0] contlr(01) record to $fmr_kpl (01), (d1:ff, d2:1f, d3:01) [Insteon::ALDB_i1] [0x0FA8] rspndr(01) record to $kitchen_kpl (02): onlevel=100% and ramp=2s (d3:00) [Insteon::ALDB_i1] [0x0FB0] rspndr(01) record to $fmr_kpl (01): onlevel=100% and ramp=2s (d3:00) [Insteon::ALDB_i1] [0x0FB8] rspndr(01) record to 129dfb (50): onlevel=100% and ramp=0.1s (d3:00) [Insteon::ALDB_i1] [0x0FC0] contlr(01) record to 129dfb (01), (d1:ff, d2:1f, d3:00) [Insteon::ALDB_i1] [0x0FC8] rspndr(01) record to 129dfb (10): onlevel=100% and ramp=2s (d3:00) [Insteon::ALDB_i1] [0x0FD0] contlr(01) record to $lvr_kpl (05), (d1:ff, d2:1f, d3:05) [Insteon::ALDB_i1] [0x0FD8] contlr(01) record to $kitchen_kpl (02), (d1:ff, d2:1f, d3:02) [Insteon::ALDB_i1] [0x0FE0] rspndr(01) record to 129dfb (14): onlevel=100% and ramp=0.3s (d3:00) [Insteon::ALDB_i1] [0x0FE8] rspndr(01) record to 0a39d1 (05): onlevel=100% and ramp=2s (d3:00) [Insteon::ALDB_i1] [0x0FF0] contlr(01) record to $dining_kpl (03), (d1:ff, d2:1f, d3:03) [Insteon::ALDB_i1] [0x0FF8] rspndr(01) record to $dining_kpl (03): onlevel=100% and ramp=2s (d3:00) After doing this one manually, somehow my scan all went a lot farther and almost finished: 18/06/2011 16:37:58 [Insteon::ALDB_i1] $iolinc_garside accessing memory at location: 0x0FF0 18/06/2011 16:37:58 [Insteon_PLM] DEBUG: Parsing serial data: 026215e76205280f06 18/06/2011 16:37:58 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$iolinc_garside; command=set_address_msb; extra=0F 18/06/2011 16:37:58 [Insteon_PLM] DEBUG: Parsing serial data: 025015e76218d4ce21280f 18/06/2011 16:37:58 [Insteon_PLM] DEBUG: Parsing serial data: 026215e762052bf006 18/06/2011 16:37:58 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$iolinc_garside; command=peek; extra=F0 18/06/2011 16:37:58 [Insteon_PLM] DEBUG: Parsing serial data: 025015e76218d4ce212b00 18/06/2011 16:37:58 [Insteon::ALDB_i1] $iolinc_garside completed link memory scan 18/06/2011 16:37:58 [Scan all link tables] Now scanning: $fan_fmr (24 of 25) 18/06/2011 16:37:58 [Insteon::ALDB_i1] $fan_fmr accessing memory at location: 0x0FF8 18/06/2011 16:38:00 : Saving object states ... done 18/06/2011 16:38:07 Main Omnistat RC-90: Indoor temp is 73, HVAC Command: off, heat to 63, cool to 75, mode: off 18/06/2011 16:38:32 MYLOGC: Computer closet: turning fan on (temp 85.55) 18/06/2011 16:38:33 [Insteon_PLM] DEBUG: Parsing serial data: 0252ce000252c280 18/06/2011 16:38:33 X10: Unmatched incoming data=X 18/06/2011 16:38:33 X10: Duplicate data ignored data=X time=0 18/06/2011 16:38:37 MBR Omnistat RC-80: Indoor temp is 73, HVAC Command: off, heat to 50, cool to 88, mode: program_cool Just trying to scan fan_fmr did not work, but its adjacent fan_mbr worked: 18/06/2011 16:43:10 Running: fan fmr scan link table 18/06/2011 16:43:10 [Insteon::ALDB_i1] $fan_fmr accessing memory at location: 0x0FF8 18/06/2011 16:43:21 [Insteon_PLM] DEBUG: Parsing serial data: 0252e000 18/06/2011 16:43:21 X10: Unmatched incoming data=X 18/06/2011 16:43:22 [Insteon_PLM] DEBUG: Parsing serial data: 0252e380 18/06/2011 16:43:22 X10: Duplicate data ignored data=X time=460.39794921875 18/06/2011 16:43:24 XBDBK: outside_motion3 still 18/06/2011 16:43:31 Running: fan mbr scan link table 18/06/2011 16:43:31 [Insteon::ALDB_i1] $fan_mbr accessing memory at location: 0x0FF8 18/06/2011 16:43:31 [Insteon_PLM] DEBUG: Parsing serial data: 02621513c205280f06 18/06/2011 16:43:31 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fan_mbr; command=set_address_msb; extra=0F 18/06/2011 16:43:31 [Insteon_PLM] DEBUG: Parsing serial data: 02501513c218d4ce21280f 18/06/2011 16:43:32 [Insteon_PLM] DEBUG: Parsing serial data: 02621513c2052bf806 18/06/2011 16:43:32 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fan_mbr; command=peek; extra=F8 18/06/2011 16:43:32 [Insteon_PLM] DEBUG: Parsing serial data: 02501513c218d4ce212b00 18/06/2011 16:43:32 [Insteon::ALDB_i1] $fan_mbr completed link memory scan 18/06/2011 16:43:32 [Insteon::ALDB_i1] link table for $fan_mbr (devcat: ): 18/06/2011 16:43:32 [Insteon::ALDB_i1] [0x0FF8] is empty 18/06/2011 16:43:37 MBR Omnistat RC-80: Indoor temp is 73, HVAC Command: off, heat to 50, cool to 88, mode: program_cool 18/06/2011 16:43:41 Running: fan fmr scan link table 18/06/2011 16:43:41 [Insteon::ALDB_i1] $fan_fmr accessing memory at location: 0x0FF8 The same scan worked after restarting mh: 18/06/2011 16:44:44 Running: fan fmr scan link table 18/06/2011 16:44:44 [Insteon::ALDB_i1] $fan_fmr accessing memory at location: 0x0FF8 18/06/2011 16:44:44 [Insteon_PLM] DEBUG: Parsing serial data: 026215154905280f06 18/06/2011 16:44:44 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fan_fmr; command=set_address_msb; extra=0F 18/06/2011 16:44:44 [Insteon_PLM] DEBUG: Parsing serial data: 025015154918d4ce21280f 18/06/2011 16:44:44 [Insteon_PLM] DEBUG: Parsing serial data: 0262151549052bf806 18/06/2011 16:44:44 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fan_fmr; command=peek; extra=F8 18/06/2011 16:44:44 [Insteon_PLM] DEBUG: Parsing serial data: 025015154918d4ce212b00 18/06/2011 16:44:44 [Insteon::ALDB_i1] $fan_fmr completed link memory scan 18/06/2011 16:44:44 [Insteon::ALDB_i1] link table for $fan_fmr (devcat: ): 18/06/2011 16:44:44 [Insteon::ALDB_i1] [0x0FF8] is empty Next time around, full scan didn't get that far (16 out of 25) 18/06/2011 16:57:39 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$yard_lights; command=peek; extra=E6 18/06/2011 16:57:39 [Insteon::ALDB_i1] $yard_lights accessing memory at location: 0x0FD8 18/06/2011 16:57:40 [Insteon_PLM] DEBUG: Parsing serial data: 02500f828718d4ce212b0002500f828718 18/06/2011 16:57:40 [Insteon_PLM] DEBUG: Prepending prior data fragment: 02500f828718 18/06/2011 16:57:40 [Insteon_PLM] DEBUG: Parsing serial data: 02500f828718d4ce212b0002620f828705280f06 18/06/2011 16:57:40 [Insteon::ALDB_i1] $yard_lights completed link memory scan 18/06/2011 16:57:40 [Scan all link tables] Now scanning: $kitchen_kpl (16 of 25) 18/06/2011 16:57:40 [Insteon::ALDB_i1] $kitchen_kpl accessing memory at location: 0x0FF8 18/06/2011 16:57:40 [Insteon_PLM] DEBUG: Prepending prior data fragment: 02620f828705280f06 18/06/2011 16:57:40 [Insteon_PLM] DEBUG: Parsing serial data: 02620f828705280f0602500f828718d4ce21280f 18/06/2011 16:57:40 [Insteon::BaseObject] received command/state acknowledge from $yard_lights: set_address_msb and data: 0f I'm not sure if the extra runs are useful, but hopefully they give you an idea. That's it for now :) Thanks, 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/ |
Re: [mh] Trying out the updated insteon branch -> scan
all and orphan deletes still not quite there.
From: Gregg L. <gr...@li...> - 2011-06-24 12:17:51
|
On 6/24/2011 1:58 AM, Marc MERLIN wrote: > This is also better: >> Running: PLM AUDIT - delete orphan links >> [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_blk1_1 because health: unknown. Please rescan this device!! >> [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_grey2_1 because health: unknown. Please rescan this device!! >> [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_blk1_1 because health: unknown. Please rescan this device!! >> [Insteon::ALDB_i1] Delete orphan links: skipping $gar_mos1 because health: unknown. Please rescan this device!! > > note, those 3 are remotelinks and motion sensor. > Are them being flagged as 'unknown' and 'please rescan' expected? No--I'll need to track them down so that the output isn't "clutter". But, obviously, that's all it is. So, ignoring is the appropriate policy in the near-term. > Now, let's work on a full scan. > > Ok, more details below, but I got one to complete: > 23/06/2011 22:47:00 [Scan all link tables] All tables have completed scanning > 23/06/2011 22:47:00 [Scan all link tables] However, some failures were noted: > 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $lvr_kpl > 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $kitchen_kpl > 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $dining_kpl > 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $garage1_neon_kpl > 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $garage2_neon_kpl > 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $gar_outlights_kpl As you might have noticed, I've been adding some different/additional diagnostics to some of the output in hopes that it helps confirm that things did or didn't work. As things go along, feel free to suggest additions/changes. > I'll rescan those by hand after upping the retry count to 64 and see what > delete orphan links does. I'll comment on the retry count issue below. > Ok, so this is what I have for now in addition to the above. > > 1) Scan all tables still stops from time to time. I tracked it down to the fact > that some of my triggers generated other insteon commands during the full scan, > and one of those commands just stops the scan with no error. > Do you want me to look more into this? I have one log attached below, although > for now I just removed all my triggers to get a full scan to work. I won't have time to investigate until I return after this weekend. But, it may be that I'll need more info. I'll let you know. Definitely, any cases that you can offer may help--especially if they are different. > 2) Insteon retries, should maybe include an exponential backoff in case the > power line is dirty due to a spike from some device (fridge starting up or > whatever). > At the same time, there may just be some hard to reach devices, and it's nice > to have the option to retry longer if your bus isn't great. I put mine to 16 > retries, see patch below. > It would also be nice to actually set a big retry count during a scan all links > where it is much more important to get a full scan than to get an immediate > reply or drop. I'll likely add your diff--realizing that it may soon get replaced w/ a different, less brute-force mechanism. There are two factors: (1) retry count and (2) retry delay. The insteon spec calls for specific timing for the early delays. But, I may need to look at "tweaks", especially for higher retry counts, to reduce failure rates. I have a couple of "problem devices" now myself. I've just not yet had time to focus on this specific issue. Also, since the messages are now encapsulated objects, it probably means it would be easier to have "per message" retry profiles to occur. So, increase retry counts/delays for critical memory operations and leave them aggressive for less critical pieces. I need to think this through and make it relatively flexible for experimentation. One reason that I haven't tried to solve it myself is that the couple of "problem devices" make it easier for me to test "problem device" handling (and, avoid guessing). Thanks for all of the feedback, Marc. Gregg |
Re: [mh] Trying out the updated insteon branch -> scan
all and orphan deletes still not quite there.
From: Marc M. <ma...@me...> - 2011-06-24 13:14:47
|
Good thing you're on the east coast, bright and early there already :) On Fri, Jun 24, 2011 at 08:17:41AM -0400, Gregg Liming wrote: > On 6/24/2011 1:58 AM, Marc MERLIN wrote: > > > This is also better: > >> Running: PLM AUDIT - delete orphan links > >> [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_blk1_1 because health: unknown. Please rescan this device!! > >> [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_grey2_1 because health: unknown. Please rescan this device!! > >> [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_blk1_1 because health: unknown. Please rescan this device!! > >> [Insteon::ALDB_i1] Delete orphan links: skipping $gar_mos1 because health: unknown. Please rescan this device!! > > > > note, those 3 are remotelinks and motion sensor. > > Are them being flagged as 'unknown' and 'please rescan' expected? > > No--I'll need to track them down so that the output isn't "clutter". > But, obviously, that's all it is. So, ignoring is the appropriate > policy in the near-term. Ok. > > Now, let's work on a full scan. > > > > Ok, more details below, but I got one to complete: > > 23/06/2011 22:47:00 [Scan all link tables] All tables have completed scanning > > 23/06/2011 22:47:00 [Scan all link tables] However, some failures were noted: > > 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $lvr_kpl > > 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $kitchen_kpl > > 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $dining_kpl > > 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $garage1_neon_kpl > > 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $garage2_neon_kpl > > 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $gar_outlights_kpl > > As you might have noticed, I've been adding some different/additional > diagnostics to some of the output in hopes that it helps confirm that > things did or didn't work. As things go along, feel free to suggest > additions/changes. I like what I'm seeing so far :) > I'll likely add your diff--realizing that it may soon get replaced w/ a > different, less brute-force mechanism. There are two factors: (1) retry > count and (2) retry delay. The insteon spec calls for specific timing exactly, that's what I meant by exponential backoff. It doesn't have to be exponential per se, but something more than once per second would be good for higher retry counts and not so good networks like mine. > objects, it probably means it would be easier to have "per message" > retry profiles to occur. So, increase retry counts/delays for critical > memory operations and leave them aggressive for less critical pieces. I > need to think this through and make it relatively flexible for > experimentation. That sounds like a perfect plan. > One reason that I haven't tried to solve it myself is that the couple of > "problem devices" make it easier for me to test "problem device" > handling (and, avoid guessing). Worst case, remove the filters you have in your house, or put dimmable CFLs in all your fixtures like I did :) This brings us to the orphan link audit. I know we discussed this, and I realize it's both difficult to do now and will be pointless once the code is bulletproof, but it would have been nice for me ot select some of those log lines that I know are good deletes, feed them into some script and get them to be acted upon. (in other words, manually review/approve some deletes, and make them happen). Anyway, I went through the logs and categorized the output for review: > [Insteon::ALDB_i1] Delete orphan links: ignoring link from 'deaf' device: $gar_mos1 > [Insteon::ALDB_i1] Delete orphan links: ignoring link from 'deaf' device: $gar_mos1 > [Insteon::ALDB_i1] Delete orphan links: ignoring link from 'deaf' device: $gar_mos1 > [Insteon::ALDB_i1] Delete orphan links: ignoring link from 'deaf' device: $rlink_blk1_1 > [Insteon::ALDB_i1] Delete orphan links: ignoring link from 'deaf' device: $rlink_blk1_1 > [Insteon::ALDB_i1] Delete orphan links: ignoring link from 'deaf' device: $rlink_blk1_1 that's good. But a lot more output like that: > [Insteon::ALDB_i1] Delete orphan links: skipping $gar_mos1 because health: unknown. Please rescan this device!! > [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_blk1_1 because health: unknown. Please rescan this device!! > [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_blk1_1 because health: unknown. Please rescan this device!! > [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_grey2_1 because health: unknown. Please rescan this device!! > [Insteon::ALDB_i1] Delete orphan links: skipping check for reciprocal links from $gar_mos1 because health: unknown. Please rescan this device!! > [Insteon::ALDB_i1] Delete orphan links: skipping check for reciprocal links from $gar_mos1 because health: unknown. Please rescan this device!! > [Insteon::ALDB_i1] Delete orphan links: skipping check for reciprocal links from $gar_mos1 because health: unknown. Please rescan this device!! > [Insteon::ALDB_i1] Delete orphan links: skipping check for reciprocal links from $rlink_blk1_1 because health: unknown. Please rescan this device!! I think it's still doing the right thing, but 1) health that was 'deaf' is now 'unknown', which is weird 2) obviously I shouldn't be asked to rescan I've then seen a few of these: > [Insteon::ALDB_i1] (AUDIT) $PLM now deleting orphaned link w/ details: responder, deviceid=18d4ce, group=16, data=06 > [Insteon::ALDB_i1] (AUDIT) $PLM now deleting orphaned link w/ details: responder, deviceid=18d4ce, group=16, data=06 > [Insteon::ALDB_i1] (AUDIT) $PLM now deleting orphaned link w/ details: responder, deviceid=18d4ce, group=16, data=08 > [Insteon::ALDB_i1] (AUDIT) $PLM now deleting orphaned link w/ details: responder, deviceid=18d4ce, group=18, data=04 The deviceid is the PLM itself. This means I don't understand what the orphan is here or what's wrong with that link. I get a lot of these: > [Insteon::ALDB_i1] (AUDIT) $br2_sw now deleting orphaned link w/ details: controller, deviceid=129dfb, group=01 > [Insteon::ALDB_i1] (AUDIT) $dining_kpl now deleting orphaned link w/ details: controller, deviceid=129dfb, group=02 > [Insteon::ALDB_i1] (AUDIT) $dining_kpl now deleting orphaned link w/ details: controller, deviceid=129dfb, group=07 > [Insteon::ALDB_i1] (AUDIT) $dining_kpl now deleting orphaned link w/ details: responder, deviceid=129dfb, group=05 That's good, unlinking my old PLM > Then some of these: > [Insteon::ALDB_i1] (AUDIT) $dining_kpl now deleting orphaned link w/ details: controller, deviceid=0ed9ee, group=02 > [Insteon::ALDB_i1] (AUDIT) $dining_kpl now deleting orphaned link w/ details: controller, deviceid=0ed9ee, group=04 > [Insteon::ALDB_i1] (AUDIT) $dining_kpl now deleting orphaned link w/ details: controller, deviceid=0ed9ee, group=05 > [Insteon::ALDB_i1] (AUDIT) $dining_kpl now deleting orphaned link w/ details: controller, deviceid=0ed9ee, group=07 > [Insteon::ALDB_i1] (AUDIT) $dining_kpl now deleting orphaned link w/ details: responder, deviceid=0ed9ee, group=10 > [Insteon::ALDB_i1] (AUDIT) $dining_kpl now deleting orphaned link w/ details: responder, deviceid=0ed9ee, group=14 (...) That's also good, those seem to be links to an old kpl I replaced a while ago. Now, some more interesting ones: > [Insteon::ALDB_i1] (AUDIT) Delete orphan because duplicate found $garage1_neon_kpl address=0E90 > [Insteon::ALDB_i1] (AUDIT) Delete orphan because duplicate found $garage1_neon_kpl address=0F70 -> ok, I'll buy that they're dupes > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no PLM link defined to: responder=$fmr_kpl(18), data=04 Left over cruft it seems, good > [Insteon::ALDB_i1] (AUDIT) Delete orphan responder link from $fmr_kpl to PLM because no SCENE_MEMBER entry could be found in items.mht for INSTEON_ICONTROLLER: $all_out_scene Very useful message (good job!) :) This was a correct fix. > [Insteon::ALDB_i1] (AUDIT) Delete orphan responder link from $fmr_kpl to PLM because no SCENE_MEMBER entry could be found in items.mht for INSTEON_ICONTROLLER: $fmr_lvr_scene_slow This one, I'm not sure about, fmr_kpl is part of $fmr_lvr_scene_slow: INSTEON_ICONTROLLER, 15, fmr_lvr_scene_slow, all_scenes SCENE_MEMBER, fmr_kpl, fmr_lvr_scene_slow, 100%, 2s SCENE_MEMBER, fmr_slav, fmr_lvr_scene_slow, 100%, 2s SCENE_MEMBER, lvr_lamp, fmr_lvr_scene_slow, 100%, 2s SCENE_MEMBER, lvr_kpl, fmr_lvr_scene_slow, 100%, 2s SCENE_MEMBER, kitchen_kpl_fmr_all, fmr_lvr_scene_slow SCENE_MEMBER, dining_kpl_fmr_all, fmr_lvr_scene_slow SCENE_MEMBER, lvr_kpl_fmr_all, fmr_lvr_scene_slow > [Insteon::ALDB_i1] (AUDIT) Delete orphan responder link from $gar_outlights_kpl to PLM because no SCENE_MEMBER entry could be found in items.mht for INSTEON_ICONTROLLER: $yard_lights_kpls This is also correct. > [Insteon::ALDB_i1] (AUDIT) $entryway now deleting orphaned link w/ details: responder, deviceid=0a3835, group=03 > [Insteon::ALDB_i1] (AUDIT) $fmr_kpl now deleting orphaned link w/ details: responder, deviceid=0a3835, group=03 > [Insteon::ALDB_i1] (AUDIT) $fmr_kpl now deleting orphaned link w/ details: responder, deviceid=0a3835, group=04 > [Insteon::ALDB_i1] (AUDIT) $fmr_lamp now deleting orphaned link w/ details: responder, deviceid=0a3835, group=06 > [Insteon::ALDB_i1] (AUDIT) $fmr_slav now deleting orphaned link w/ details: responder, deviceid=0a3835, group=05 > [Insteon::ALDB_i1] (AUDIT) $lvr_kpl now deleting orphaned link w/ details: responder, deviceid=0a3835, group=01 > [Insteon::ALDB_i1] (AUDIT) $lvr_kpl now deleting orphaned link w/ details: responder, deviceid=0a3835, group=05 > [Insteon::ALDB_i1] (AUDIT) $lvr_lamp now deleting orphaned link w/ details: responder, deviceid=0a3835, group=02 That's an old remote I RMA'ed, good. Then these look like random corruption/garbage. It seems to confirm that the link layer's CRCs don't work in at least some cases (I verified the device IDs and I never had them). It's interesting to see a couple of links to 18d4xx where the 2 first bytes are my new PLM and the last byte is garbage. > [Insteon::ALDB_i1] (AUDIT) $kitchen_kpl now deleting orphaned link w/ details: responder, deviceid=000000, group=00 > [Insteon::ALDB_i1] (AUDIT) $garage1_neon_kpl now deleting orphaned link w/ details: responder, deviceid=07d4ce, group=72 > [Insteon::ALDB_i1] (AUDIT) $gar_outlights_kpl now deleting orphaned link w/ details: responder, deviceid=07d98b, group=04 > [Insteon::ALDB_i1] (AUDIT) $kitchen_kpl now deleting orphaned link w/ details: controller, deviceid=07deee, group=07 > [Insteon::ALDB_i1] (AUDIT) $garage2_neon_kpl now deleting orphaned link w/ details: controller, deviceid=07defb, group=05 > [Insteon::ALDB_i1] (AUDIT) $gar_outlights_kpl now deleting orphaned link w/ details: controller, deviceid=09d412, group=01 > [Insteon::ALDB_i1] (AUDIT) $lvr_kpl now deleting orphaned link w/ details: controller, deviceid=0e9e12, group=01 > [Insteon::ALDB_i1] (AUDIT) $fmr_kpl now deleting orphaned link w/ details: controller, deviceid=0f2687, group=07 > [Insteon::ALDB_i1] (AUDIT) $fmr_kpl now deleting orphaned link w/ details: controller, deviceid=0f2736, group=07 > [Insteon::ALDB_i1] (AUDIT) $kitchen_kpl now deleting orphaned link w/ details: controller, deviceid=10d4ce, group=18 > [Insteon::ALDB_i1] (AUDIT) $garage2_neon_kpl now deleting orphaned link w/ details: controller, deviceid=1818d4, group=18 > [Insteon::ALDB_i1] (AUDIT) $kitchen_kpl now deleting orphaned link w/ details: controller, deviceid=18ce35, group=06 > [Insteon::ALDB_i1] (AUDIT) $fmr_kpl now deleting orphaned link w/ details: responder, deviceid=18ce68, group=11 > [Insteon::ALDB_i1] (AUDIT) $gar_outlights_kpl now deleting orphaned link w/ details: controller, deviceid=18cefb, group=03 > [Insteon::ALDB_i1] (AUDIT) $dining_kpl now deleting orphaned link w/ details: responder, deviceid=18d412, group=55 > [Insteon::ALDB_i1] (AUDIT) $iolinc_gardoor2 now deleting orphaned link w/ details: controller, deviceid=18d4d4, group=01 > [Insteon::ALDB_i1] (AUDIT) $fmr_kpl now deleting orphaned link w/ details: controller, deviceid=d40fce, group=04 After that, we're left with these as the last messages > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $fmr_kpl(07) as controller and $garage2_neon_kpl(05) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $gar_outlights_kpl(01) as controller and $garage2_neon_kpl(05) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $gar_outlights_kpl(03) as controller and $garage2_neon_kpl(03) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $gar_outlights_kpl(03) as controller and $garage2_neon_kpl(e2) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $gar_outlights_kpl(06) as controller and $garage2_neon_kpl(06) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $gar_outlights_kpl(06) as controller and $yard_lights(01) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $garage1_neon_kpl(01) as controller and $garage2_neon_kpl(03) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $garage1_neon_kpl(04) as controller and $garage2_neon_kpl(01) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $garage1_neon_kpl(05) as controller and $garage2_neon_kpl(05) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $garage1_neon_kpl(06) as controller and $garage2_neon_kpl(06) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $kitchen_kpl(07) as controller and $garage2_neon_kpl(05) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $fmr_kpl(05) as responder and $kitchen_kpl(02) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $fmr_kpl(08) as responder and $garage2_neon_kpl(06) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $gar_outlights_kpl(01) as responder and $garage1_neon_kpl(03) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $gar_outlights_kpl(04) as responder and $garage2_neon_kpl(01) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $gar_outlights_kpl(06) as responder and $garage2_neon_kpl(06) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $garage1_neon_kpl(04) as responder and $garage2_neon_kpl(01) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $garage1_neon_kpl(06) as responder and $garage2_neon_kpl(06) > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $kitchen_kpl(01) as responder and $fmr_kpl(04) Those are debatable. They are correct links, but their other half is missing somehow. It's not a huge deal if delete orphan removes them and I resync both sides later with a sync all links. Is that something you'd like to fix, or is that working as intended? Thanks for your new code and reviewing all this. Marc -- "A mouse is a device used to point at the xterm you want to type in" - A.S.R. Microsoft is to operating systems .... .... what McDonalds is to gourmet cooking Home page: http://marc.merlins.org/ |
Re: [mh] Trying out the updated insteon branch -> scan
all and orphan deletes still not quite there.
From: Marc M. <ma...@me...> - 2011-06-24 14:38:59
|
I should add that I think I can run the delete orphans code as of right now, but I'll wait just in case you want to make some adjustments before I do since I'll lose all my 'interesting' state that may be useful to testing your code. It took me a while to write my last Email and analyse the results, so I'll just look at what may need to be addressed before I do the cleaning. On Fri, Jun 24, 2011 at 06:14:35AM -0700, Marc MERLIN wrote: > I've then seen a few of these: > > [Insteon::ALDB_i1] (AUDIT) $PLM now deleting orphaned link w/ details: responder, deviceid=18d4ce, group=16, data=06 > > [Insteon::ALDB_i1] (AUDIT) $PLM now deleting orphaned link w/ details: responder, deviceid=18d4ce, group=16, data=06 > > [Insteon::ALDB_i1] (AUDIT) $PLM now deleting orphaned link w/ details: responder, deviceid=18d4ce, group=16, data=08 > > [Insteon::ALDB_i1] (AUDIT) $PLM now deleting orphaned link w/ details: responder, deviceid=18d4ce, group=18, data=04 > The deviceid is the PLM itself. This means I don't understand what the orphan is here or what's wrong with that link. Those are likely ok, I just don't know what they mean. > > [Insteon::ALDB_i1] (AUDIT) Delete orphan responder link from $fmr_kpl to PLM because no SCENE_MEMBER entry could be found in items.mht for INSTEON_ICONTROLLER: $fmr_lvr_scene_slow > > This one, I'm not sure about, fmr_kpl is part of $fmr_lvr_scene_slow: > > INSTEON_ICONTROLLER, 15, fmr_lvr_scene_slow, all_scenes > SCENE_MEMBER, fmr_kpl, fmr_lvr_scene_slow, 100%, 2s > SCENE_MEMBER, fmr_slav, fmr_lvr_scene_slow, 100%, 2s > SCENE_MEMBER, lvr_lamp, fmr_lvr_scene_slow, 100%, 2s > SCENE_MEMBER, lvr_kpl, fmr_lvr_scene_slow, 100%, 2s > SCENE_MEMBER, kitchen_kpl_fmr_all, fmr_lvr_scene_slow > SCENE_MEMBER, dining_kpl_fmr_all, fmr_lvr_scene_slow > SCENE_MEMBER, lvr_kpl_fmr_all, fmr_lvr_scene_slow Unless I misread the delete above might be an issue, but it's a single scene I can resync, so it's not a bit deal. > After that, we're left with these as the last messages > > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $fmr_kpl(07) as controller and $garage2_neon_kpl(05) > > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $gar_outlights_kpl(01) as controller and $garage2_neon_kpl(05) > > [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $gar_outlights_kpl(03) as controller and $garage2_neon_kpl(03) (...) > Those are debatable. They are correct links, but their other half is missing somehow. > It's not a huge deal if delete orphan removes them and I resync both sides > later with a sync all links. > Is that something you'd like to fix, or is that working as intended? On this one, it's mostly a matter of whether people are expected to do 1) read all link tables 2) delete orphans 3) sync all links. If so, the fact that delete orphans deletes some half links is slightly sub-optimal since it creates un-needed bus work in steps 2 and 3, but it's mostly a one time thing and step 3 should recreate all the links, making sure both sides are there. So all in all, I'm pretty much good to go anytime with the deletes but I'll wait until you tell me that you don't need me to try new code before I lose my current state. After all that's done, we can worry about why your insteon command streams (mostly scan all) are interrupted and put in limbo by some of my triggers (for now I can move them out of the way while updating the links). Thanks, 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: Gregg L. <gr...@li...> - 2011-06-29 17:48:29
|
On 6/29/2011 10:27 AM, Marc MERLIN wrote: > On Tue, Jun 28, 2011 at 09:24:43PM -0400, Gregg Liming wrote: >>> That said, if you changed orphan tracking code, it may make sense for me to >>> wait until I can do a full scan again, and see what I get. >> >> Yes, lot's of changes. > > Ok, I ran the new code and I diffed the output with my last one. > As a side note, if there is any way you can sort the data structures before > outputting them to a log file, it would make diffing 2 runs a lot easier. > The same running mh gave me different ordering on 2 orphan log dumps. That's odd; I'll try to remember to get to that. > Short story the new code is good outside of a small issue in 4) below but > since I fixed my state that caused it, I just went ahead and ran the delete orphan > links since after I fixed 4), the audit log looked good. > > In other words, great job! :) Excellent! > But now I feel stupid, I don't find the 'sync all links' options on the insteon > page or the list of voice commands. > Where is it? Same answer as why insteon branch isn't on the wiki :) You're not ready for it yet (or, rather... you don't want to try running it unless you like doing factory resets). It will be next on my list. For what it's worth, individual syncs seem to do just fine. I realize that you have more than a few; so, I don't mean to trivialize the effort for multiple syncs. Also, I really want to get to the root cause of the full system scan failure because the last thing that I want to see happen is an interruption during a sync links. Otherwise, you'll be getting more practice running delete orphan links. > Here are the details from my last run if you are curious > 2) I still get this, but only once, not a big a deal: > [Insteon::ALDB_i1] Delete orphan links: skipping $gar_mos1 because health: unknown. Please rescan this device!! > [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_blk1_1 because health: unknown. Please rescan this device!! > [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_blk1_1 because health: unknown. Please rescan this device!! > [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_grey2_1 because health: unknown. Please rescan this device!! I thought I'd fixed that. I'll look again. > 4b) (AUDIT) Delete orphan responder link from $lvr_kpl [button:1f] to PLM because no SCENE_MEMBER entry could be found in items.mht for INSTEON_ICONTROLLER: $mbr_kpls > > I'll assume it's correct, but 'button 1f' isn't clear what button that is :) Well, that should give you an indication that there is a problem, right? :) Seriously, though--as far as mh is concerned, you do have such a button. So, one of the two situations is fact when the button listed isn't what is expected: 1) the data in mh's link tables is corrupted (implying you might want to rescan the KPL in this case) or 2) the real link table is corrupted (implying that you want to allow the deletion to occur and then sync links again so that the correct entry is added. The change in the log wording was such as to provide some diagnostic info but not a full help tutorial. Maybe there is some better wording; but, realize that it can't be too context specific as there are other cases beyond the two listed above that may be the culprit. I'm definitely up for rewording suggestions, though. > 4c1) (AUDIT) Now deleting orphaned responder link in $dining_kpl [button:02] because PLM does not have a corresponding controller record with group (52) > > I would add the following after 'with group(52)': ' defined by PLM:52 in config file, try resyncing scene to PLM if config file is correct'. > > I have: > IPLL, 09.9E.68:02, dining_kpl_kitchen_kpl, dining_kplB|buttons, PLM, > > IPLL, PLM:52, kitchen_kpls, kpl_tie_scenes, PLM > SCENE_MEMBER, fmr_kpl_kitchen_kpl, kitchen_kpls > SCENE_MEMBER, dining_kpl_kitchen_kpl, kitchen_kpls > SCENE_MEMBER, lvr_kpl_kitchen_kpl, kitchen_kpls > > So it looks like my config file is correct, but likely my PLM didn't have the matching data. > > Interestingly I got thise while syncing that scene. > 29/06/2011 07:05:46 [Insteon_PLM] WARN: received NACK for obj=$PLM; interface_data=40E2100e0749010001. If this is a light fixture, check bulb > I don't have light fixtures :) Well, I think some more effective log messages would be appropriate then. I've adjusted the text accordingly. Gregg |
From: Marc M. <ma...@me...> - 2011-06-29 20:45:12
|
On Wed, Jun 29, 2011 at 01:48:12PM -0400, Gregg Liming wrote: > > But now I feel stupid, I don't find the 'sync all links' options on the insteon > > page or the list of voice commands. > > Where is it? > > Same answer as why insteon branch isn't on the wiki :) You're not ready > for it yet (or, rather... you don't want to try running it unless you > like doing factory resets). It will be next on my list. For what it's > worth, individual syncs seem to do just fine. I realize that you have > more than a few; so, I don't mean to trivialize the effort for multiple > syncs. Funny how eyes work. I could I sworn it was there already :) I think I should wait until the scan all code works reliably. After that I'll run the orphan audit again to see whether I really have as many one way links as the code is thinking I do (I didn't check yet, but I'm dubious about it because I'd have lots of light switches not working if that were the case). After that, I'll wait for your scan all code (maybe with an audit first too) before I try. I could of course try and fix it with the old code, but I'm not actually sure it's broken to that extent :) So let's reconvene after scan all works reliably and work from there. > Also, I really want to get to the root cause of the full system scan > failure because the last thing that I want to see happen is an > interruption during a sync links. Otherwise, you'll be getting more > practice running delete orphan links. Right :) > > 4b) (AUDIT) Delete orphan responder link from $lvr_kpl [button:1f] to PLM because no SCENE_MEMBER entry could be found in items.mht for INSTEON_ICONTROLLER: $mbr_kpls > > > > I'll assume it's correct, but 'button 1f' isn't clear what button that is :) > > Well, that should give you an indication that there is a problem, right? > :) Seriously, though--as far as mh is concerned, you do have such a > button. So, one of the two situations is fact when the button listed Ah, ok. I thought it was as print bug. > isn't what is expected: 1) the data in mh's link tables is corrupted > (implying you might want to rescan the KPL in this case) or 2) the real > link table is corrupted (implying that you want to allow the deletion to > occur and then sync links again so that the correct entry is added. The I know I have a bunch of corrupted data in my devices, which I reported in my deletions. Some were clearly off by one bits. I was mentioning in an earlier Email that I'm not impressed with the fact that CRCs are clearly not working in insteon devices. (i.e. I know I have a crappy bus, but the devices should reject bad data). > change in the log wording was such as to provide some diagnostic info > but not a full help tutorial. Maybe there is some better wording; but, > realize that it can't be too context specific as there are other cases > beyond the two listed above that may be the culprit. Not a biggie, that can go in the insteon wiki. > > 4c1) (AUDIT) Now deleting orphaned responder link in $dining_kpl [button:02] because PLM does not have a corresponding controller record with group (52) > > > > I would add the following after 'with group(52)': ' defined by PLM:52 in config file, try resyncing scene to PLM if config file is correct'. How about 'with group(52) (based off PLM:52 scene in config file)' So the possible AI on the 4) series just in case it was missed is that the delete orphan code should not delete half links with a PLM scene if that scene is properly defined in the config file. But if it does deletes, it's not the end of the world, sync links will refix it later. Cheers, 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/ |
Re: [mh] Trying out the updated insteon branch -> scan all and
orphan deletes still not quite there.
From: Gregg L. <gr...@li...> - 2011-06-22 18:16:15
|
Hi Mark, Sorry about the delay in responding. I'm still working through portions of it, but at least wanted to let you know I've been trying to think through it. Details follow: On 6/18/2011 8:22 PM, Marc MERLIN wrote: > Summary of showstoppers: > A) scan link table with PLM is not working but it works for other devices There are really two significant issues here: 1) I need to better understand the specific cause of why your scans are stopping and 2) I need to implement date-time and health codes for the ALDB objects. I was really surprised by your logs as I was expecting to see other info like timeouts. Instead, they "just stopped". Not to diminish the importance of having full scanning working (which of course it does for me), I think it's more important to focus on #2. The reason is that I would also provide a diagnostic utility that would list all the devices and the status and time of last successful scan. That way, you would know which devices might require manual scans. It also wouldn't leave you guessing. I'm hoping to get to this in the next couple of days. > B) delete orphan links deletes too much Yes. As you noted, this is specific to the "deaf" devices which get ignored by the full scans and the possibility of the full scans not getting to a device. I really think that focusing on A above will address the issue. Also, I could address the "deaf" devices more properly by using the date-time health code info rather than a brute force "isa" against their type. So, doing "B" relies on my interim solution for "A". > C) lamp update onlevel/ramprate kills mh (not a showstopper) Thanks for letting me know; but, yes, that's the least of my immediate worries. > D) scan all link tables never finishes for me (lots of details below). Isn't this the same as "A"? Or, am I not understanding something? > If you can help me, I think > A) is important but I might be able to do without > B) is absolutely blocking, I need to unlink my dead PLM from all my devices > without breaking other links. > D) is problematic to say the least, but with 10 full scans and hand scans of my last 2 devices > I think I got mh to have a snapshot of all my devices for now. > > So B is the most important for now. > > > On Sat, Oct 02, 2010 at 12:11:48PM -0700, Marc MERLIN wrote: >> 2) >> How about this: >> 02/10/2010 11:51:59 Running: yard lights kpls sync links >> 02/10/2010 11:51:59 [Insteon::ALDB_i1] adding link record $gar_outlights_kpl light level controlled by $PLM and group: 72 with on level: 100% and ramp rate: 0.1 >> 02/10/2010 11:51:59 [Insteon::ALDB_i1] WARN: $gar_outlights_kpl write_link failure: no address available for record to device: 129dfb and group: 72 and is_controller: 0 > > This works now. > >> So things are definitely better, but a few problems, all showstoppers more or less: >> 5) scan all links kills mh: Can't locate object method "scan_link_table" via package "Voice_Cmd" at > > This was the biggest one for me, and it works now, thanks. > > I recommend you rename 'scan link tables' into 'scan all devices link tables' > > Well, it starts that is, individual scan tables still fail randomly for me, > which in turn does affect doing a full scan. > See below for scan all links hanging in the middle. > > A) scan link table with PLM is not working but it works for other devices > 18/06/2011 17:06:38 Running: PLM scan link table > 18/06/2011 17:06:38 [Insteon_PLM] DEBUG: Parsing serial data: 026915 > 18/06/2011 17:06:47 Running: PLM show link table to log > 18/06/2011 17:06:50 Running: PLM scan link table > 18/06/2011 17:06:51 [Insteon_PLM] DEBUG: Parsing serial data: 026915 > > B) delete orphan links doesn't seem to take into account links with > remotelincs, which get excluded from the scan (but the audit function rocks, > thanks for that). > > 18/06/2011 15:59:42 [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $fmr_outside(01) as responder and $rlink_blk1_1(06) > > Similarly, motion sensors: > Delete orphan because no reverse link defined for: $garage1_neon_kpl(05) as responder and $gar_mos1(01) > > I think my full scan which I thought was full, may not be as full as I think > yet. I still get a lot of these: > (AUDIT) Delete orphan because no reciprocal link defined for: $dining_kpl(02) as controller and $kitchen_kpl(01) > those should not happen since those devices were scanned and aren't excluded from > the scan like rlink. > > C) lvr lamp update onlevel/ramprate still kills mh: >> I tried another one and mh died: >> Running: lvr lamp update onlevel/ramprate >> [Insteon::ALDB_i1] $lvr_lamp accessing memory at location: 0x0032 >> [Insteon_PLM] Parsing serial data: 02620a99e505280006 >> [Insteon_PLM] DEBUG: received interface acknowledge: obj=$lvr_lamp; command=set_address_msb; extra=00 >> [Insteon_PLM] Parsing serial data: 02500a99e5129dfb212800d4 >> [Insteon_PLM] Parsing serial data: 02620a99e5052b3206 >> [Insteon_PLM] DEBUG: received interface acknowledge: obj=$lvr_lamp; command=peek; extra=32 >> [Insteon_PLM] Parsing serial data: 02500a99e5129dfb212bfed4 >> Can't locate object method "local_onlevel" via package "Insteon::ALDB_i1" at ../lib/Insteon/AllLinkDatabase.pm line 508. >> gargamel:/var/local/src/misterhouse/mh/bin$ > > This still fails: > 18/06/2011 17:11:22 Running: lvr lamp update onlevel/ramprate > 18/06/2011 17:11:22 [Insteon::ALDB_i1] $lvr_lamp accessing memory at location: 0x0032 > 18/06/2011 17:11:22 [Insteon_PLM] DEBUG: Parsing serial data: 02620a99e505280006 > 18/06/2011 17:11:22 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$lvr_lamp; command=set_address_msb; extra=00 > 18/06/2011 17:11:23 [Insteon_PLM] DEBUG: Parsing serial data: 02500a99e518d4ce212800 > 18/06/2011 17:11:23 [Insteon_PLM] DEBUG: Parsing serial data: 02620a99e5052b3206 > 18/06/2011 17:11:23 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$lvr_lamp; command=peek; extra=32 > 18/06/2011 17:11:23 [Insteon_PLM] DEBUG: Parsing serial data: 02500a99e518d4ce212bfe > Can't locate object method "local_onlevel" via package "Insteon::ALDB_i1" at ../lib/Insteon/AllLinkDatabase.pm line 534. > > > D) scan link tables still hangs pseudo randomly >> 1) scan link table stops in the middle with >> 'PLM command timer expired but no transmission in place. Moving on..' > > This still happens for me: > 18/06/2011 14:51:06 Running: PLM scan link tables > 18/06/2011 14:51:06 [Scan all link tables] Now scanning: $PLM (1 of 25) > 18/06/2011 14:51:06 [Insteon_PLM] DEBUG: Parsing serial data: 026915 > 18/06/2011 14:51:06 [Scan all link tables] Now scanning: $mbr_kpl (2 of 25) > 18/06/2011 14:51:06 [Insteon::ALDB_i1] $mbr_kpl accessing memory at location: 0x0FF8 > 18/06/2011 14:51:06 [Insteon_PLM] DEBUG: Parsing serial data: 026211e19d05280f06 > (...) > 18/06/2011 14:56:41 [Scan all link tables] Now scanning: $fmr_slav (9 of 25) > 18/06/2011 14:56:41 [Insteon::ALDB_i1] $fmr_slav accessing memory at location: 0x0FF8 > (...) > 18/06/2011 14:56:58 [Insteon::ALDB_i1] $fmr_slav accessing memory at location: 0x0FC8 > 18/06/2011 14:56:58 [Insteon_PLM] DEBUG: Parsing serial data: 02620f0f2a05280f06 > 18/06/2011 14:56:58 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_slav; command=set_address_msb; extra=0F > 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: Parsing serial data: 02500f0f2a18d4ce26280f > 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: Parsing serial data: 02620f0f2a052bc806 > 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_slav; command=peek; extra=C8 > 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: Parsing serial data: 02500f0f2a18d4ce212ba2 > 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: Parsing serial data: 02620f0f2a052bc906 > 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_slav; command=peek; extra=C9 > 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: Parsing serial data: 02500f0f2a18d4ce212b10 > 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: Parsing serial data: 02620f0f2a052bca06 > 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_slav; command=peek; extra=CA > 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: Parsing serial data: 02500f0f2a18d4ce212b12 > 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: Parsing serial data: 02620f0f2a052bcb06 > 18/06/2011 14:56:59 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_slav; command=peek; extra=CB > 18/06/2011 14:57:00 : Saving object states ... done > 18/06/2011 14:57:00 [Insteon_PLM] DEBUG: Parsing serial data: 02500f0f2a18d4ce212b9d > 18/06/2011 14:57:01 [Insteon_PLM] PLM command timer expired but no transmission in place. Moving on... > > trying again said: > 18/06/2011 14:59:49 Running: PLM scan link tables > 18/06/2011 14:59:49 [Scan all linktables] WARN: link already underway. Ignoring request for new scan ... > > At this point, the state is wedged and I need to restart mh to recover. > > Another time it hung here: > 18/06/2011 15:34:28 [Insteon::ALDB_i1] $fmr_kpl accessing memory at location: 0x0DA8 > 18/06/2011 15:34:28 [Insteon_PLM] DEBUG: Parsing serial data: 02620e074905280d06 > 18/06/2011 15:34:28 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_kpl; command=set_address_msb; extra=0D > 18/06/2011 15:34:28 [Insteon_PLM] DEBUG: Parsing serial data: 02500e074918d4ce21280d02500e074918d4ce21280d > 18/06/2011 15:34:28 [Insteon::ALDB_i1] $fmr_kpl completed link memory scan > 18/06/2011 15:34:28 [Scan all link tables] Now scanning: $fmr_slav (9 of 25) > 18/06/2011 15:34:28 [Insteon::ALDB_i1] $fmr_slav accessing memory at location: 0x0FF8 > 18/06/2011 15:34:28 [Insteon_PLM] DEBUG: Parsing serial data: 02620e0749052ba806 > 18/06/2011 15:34:28 [Insteon_PLM] DEBUG: Prepending prior data fragment: 02620e0749052ba806 > 18/06/2011 15:34:28 [Insteon_PLM] DEBUG: Parsing serial data: 02620e0749052ba80602500e074918d4ce212be2 > 18/06/2011 15:34:28 [Insteon::BaseObject] received command/state acknowledge from $fmr_kpl: peek and data: e2 > > Next time around it hung there too: > 18/06/2011 15:43:18 [Insteon::ALDB_i1] $fmr_kpl completed link memory scan > 18/06/2011 15:43:18 [Scan all link tables] Now scanning: $fmr_slav (9 of 25) > 18/06/2011 15:43:18 [Insteon::ALDB_i1] $fmr_slav accessing memory at location: 0x0FF8 > 18/06/2011 15:43:18 [Insteon_PLM] DEBUG: Parsing serial data: 02620e0749052be806 > 18/06/2011 15:43:18 [Insteon_PLM] DEBUG: Prepending prior data fragment: 02620e0749052be806 > 18/06/2011 15:43:18 [Insteon_PLM] DEBUG: Parsing serial data: 02620e0749052be80602500e074918d4ce212ba2 > 18/06/2011 15:43:18 [Insteon::BaseObject] received command/state acknowledge from $fmr_kpl: peek and data: a2 > > Next time around it didn't go nearly as far before stopping: > 18/06/2011 15:55:06 [Insteon::ALDB_i1] $mbr_kpl accessing memory at location: 0x0FC8 > 18/06/2011 15:55:06 [Insteon_PLM] DEBUG: Parsing serial data: 026211e19d052bd706 > 18/06/2011 15:55:06 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026211e19d052bd706 > 18/06/2011 15:55:06 [Insteon_PLM] DEBUG: Parsing serial data: 026211e19d052bd706025011e19d18d4ce212b05025011e19d18d4ce212b05 > 18/06/2011 15:55:06 [Insteon::ALDB_i1] $mbr_kpl completed link memory scan > 18/06/2011 15:55:06 [Scan all link tables] Now scanning: $mbr_lamp2 (3 of 25) > 18/06/2011 15:55:06 [Insteon::ALDB_i1] $mbr_lamp2 accessing memory at location: 0x0FF8 > 18/06/2011 15:55:06 [Insteon_PLM] DEBUG: Parsing serial data: 026211e19d05280f06 > 18/06/2011 15:55:07 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026211e19d05280f06 > 18/06/2011 15:55:07 [Insteon_PLM] DEBUG: Parsing serial data: 026211e19d05280f06025011e19d18d4ce21280f > > By then I had to power cycle my PLM for scans to last more than a minute and then I got back to this: > > 18/06/2011 16:07:21 [Insteon::ALDB_i1] $fmr_kpl completed link memory scan > 18/06/2011 16:07:21 [Scan all link tables] Now scanning: $fmr_slav (9 of 25) > 18/06/2011 16:07:21 [Insteon::ALDB_i1] $fmr_slav accessing memory at location: 0x0FF8 > 18/06/2011 16:07:21 [Insteon_PLM] DEBUG: Parsing serial data: 02620e0749052b7006 > 18/06/2011 16:07:21 [Insteon_PLM] DEBUG: Prepending prior data fragment: 02620e0749052b7006 > 18/06/2011 16:07:21 [Insteon_PLM] DEBUG: Parsing serial data: 02620e0749052b700602500e074918d4ce212ba2 > 18/06/2011 16:07:21 [Insteon::BaseObject] received command/state acknowledge from $fmr_kpl: peek and data: a2 > > If I run scan link table directly on fmr_slav, it works better. > [Insteon::ALDB_i1] $fmr_slav completed link memory scan > [Insteon::ALDB_i1] link table for $fmr_slav (devcat: ): > [Insteon::ALDB_i1] [0x0F68] is empty > [Insteon::ALDB_i1] [0x0F70] contlr(a2) record to 0511aa (1b), (d1:8d, d2:fe, d3:1b) > [Insteon::ALDB_i1] [0x0F78] rspndr(01) record to $rlink_blk1_1 (05): onlevel=100% and ramp=2s (d3:00) > [Insteon::ALDB_i1] [0x0F80] contlr(01) record to $fmr_lamp (01), (d1:ff, d2:1b, d3:00) > [Insteon::ALDB_i1] [0x0F88] rspndr(01) record to 129dfb (15): onlevel=100% and ramp=2s (d3:00) > [Insteon::ALDB_i1] [0x0F90] rspndr(01) record to 0a3835 (05): onlevel=100% and ramp=2s (d3:00) > [Insteon::ALDB_i1] [0x0F98] rspndr(01) record to $lvr_kpl (05): onlevel=100% and ramp=2s (d3:00) > [Insteon::ALDB_i1] [0x0FA0] contlr(01) record to $fmr_kpl (01), (d1:ff, d2:1f, d3:01) > [Insteon::ALDB_i1] [0x0FA8] rspndr(01) record to $kitchen_kpl (02): onlevel=100% and ramp=2s (d3:00) > [Insteon::ALDB_i1] [0x0FB0] rspndr(01) record to $fmr_kpl (01): onlevel=100% and ramp=2s (d3:00) > [Insteon::ALDB_i1] [0x0FB8] rspndr(01) record to 129dfb (50): onlevel=100% and ramp=0.1s (d3:00) > [Insteon::ALDB_i1] [0x0FC0] contlr(01) record to 129dfb (01), (d1:ff, d2:1f, d3:00) > [Insteon::ALDB_i1] [0x0FC8] rspndr(01) record to 129dfb (10): onlevel=100% and ramp=2s (d3:00) > [Insteon::ALDB_i1] [0x0FD0] contlr(01) record to $lvr_kpl (05), (d1:ff, d2:1f, d3:05) > [Insteon::ALDB_i1] [0x0FD8] contlr(01) record to $kitchen_kpl (02), (d1:ff, d2:1f, d3:02) > [Insteon::ALDB_i1] [0x0FE0] rspndr(01) record to 129dfb (14): onlevel=100% and ramp=0.3s (d3:00) > [Insteon::ALDB_i1] [0x0FE8] rspndr(01) record to 0a39d1 (05): onlevel=100% and ramp=2s (d3:00) > [Insteon::ALDB_i1] [0x0FF0] contlr(01) record to $dining_kpl (03), (d1:ff, d2:1f, d3:03) > [Insteon::ALDB_i1] [0x0FF8] rspndr(01) record to $dining_kpl (03): onlevel=100% and ramp=2s (d3:00) > > After doing this one manually, somehow my scan all went a lot farther and almost finished: > 18/06/2011 16:37:58 [Insteon::ALDB_i1] $iolinc_garside accessing memory at location: 0x0FF0 > 18/06/2011 16:37:58 [Insteon_PLM] DEBUG: Parsing serial data: 026215e76205280f06 > 18/06/2011 16:37:58 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$iolinc_garside; command=set_address_msb; extra=0F > 18/06/2011 16:37:58 [Insteon_PLM] DEBUG: Parsing serial data: 025015e76218d4ce21280f > 18/06/2011 16:37:58 [Insteon_PLM] DEBUG: Parsing serial data: 026215e762052bf006 > 18/06/2011 16:37:58 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$iolinc_garside; command=peek; extra=F0 > 18/06/2011 16:37:58 [Insteon_PLM] DEBUG: Parsing serial data: 025015e76218d4ce212b00 > 18/06/2011 16:37:58 [Insteon::ALDB_i1] $iolinc_garside completed link memory scan > 18/06/2011 16:37:58 [Scan all link tables] Now scanning: $fan_fmr (24 of 25) > 18/06/2011 16:37:58 [Insteon::ALDB_i1] $fan_fmr accessing memory at location: 0x0FF8 > 18/06/2011 16:38:00 : Saving object states ... done > 18/06/2011 16:38:07 Main Omnistat RC-90: Indoor temp is 73, HVAC Command: off, heat to 63, cool to 75, mode: off > 18/06/2011 16:38:32 MYLOGC: Computer closet: turning fan on (temp 85.55) > 18/06/2011 16:38:33 [Insteon_PLM] DEBUG: Parsing serial data: 0252ce000252c280 > 18/06/2011 16:38:33 X10: Unmatched incoming data=X > 18/06/2011 16:38:33 X10: Duplicate data ignored data=X time=0 > 18/06/2011 16:38:37 MBR Omnistat RC-80: Indoor temp is 73, HVAC Command: off, heat to 50, cool to 88, mode: program_cool > > Just trying to scan fan_fmr did not work, but its adjacent fan_mbr worked: > 18/06/2011 16:43:10 Running: fan fmr scan link table > 18/06/2011 16:43:10 [Insteon::ALDB_i1] $fan_fmr accessing memory at location: 0x0FF8 > 18/06/2011 16:43:21 [Insteon_PLM] DEBUG: Parsing serial data: 0252e000 > 18/06/2011 16:43:21 X10: Unmatched incoming data=X > 18/06/2011 16:43:22 [Insteon_PLM] DEBUG: Parsing serial data: 0252e380 > 18/06/2011 16:43:22 X10: Duplicate data ignored data=X time=460.39794921875 > 18/06/2011 16:43:24 XBDBK: outside_motion3 still > 18/06/2011 16:43:31 Running: fan mbr scan link table > 18/06/2011 16:43:31 [Insteon::ALDB_i1] $fan_mbr accessing memory at location: 0x0FF8 > 18/06/2011 16:43:31 [Insteon_PLM] DEBUG: Parsing serial data: 02621513c205280f06 > 18/06/2011 16:43:31 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fan_mbr; command=set_address_msb; extra=0F > 18/06/2011 16:43:31 [Insteon_PLM] DEBUG: Parsing serial data: 02501513c218d4ce21280f > 18/06/2011 16:43:32 [Insteon_PLM] DEBUG: Parsing serial data: 02621513c2052bf806 > 18/06/2011 16:43:32 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fan_mbr; command=peek; extra=F8 > 18/06/2011 16:43:32 [Insteon_PLM] DEBUG: Parsing serial data: 02501513c218d4ce212b00 > 18/06/2011 16:43:32 [Insteon::ALDB_i1] $fan_mbr completed link memory scan > 18/06/2011 16:43:32 [Insteon::ALDB_i1] link table for $fan_mbr (devcat: ): > 18/06/2011 16:43:32 [Insteon::ALDB_i1] [0x0FF8] is empty > 18/06/2011 16:43:37 MBR Omnistat RC-80: Indoor temp is 73, HVAC Command: off, heat to 50, cool to 88, mode: program_cool > 18/06/2011 16:43:41 Running: fan fmr scan link table > 18/06/2011 16:43:41 [Insteon::ALDB_i1] $fan_fmr accessing memory at location: 0x0FF8 > > The same scan worked after restarting mh: > 18/06/2011 16:44:44 Running: fan fmr scan link table > 18/06/2011 16:44:44 [Insteon::ALDB_i1] $fan_fmr accessing memory at location: 0x0FF8 > 18/06/2011 16:44:44 [Insteon_PLM] DEBUG: Parsing serial data: 026215154905280f06 > 18/06/2011 16:44:44 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fan_fmr; command=set_address_msb; extra=0F > 18/06/2011 16:44:44 [Insteon_PLM] DEBUG: Parsing serial data: 025015154918d4ce21280f > 18/06/2011 16:44:44 [Insteon_PLM] DEBUG: Parsing serial data: 0262151549052bf806 > 18/06/2011 16:44:44 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fan_fmr; command=peek; extra=F8 > 18/06/2011 16:44:44 [Insteon_PLM] DEBUG: Parsing serial data: 025015154918d4ce212b00 > 18/06/2011 16:44:44 [Insteon::ALDB_i1] $fan_fmr completed link memory scan > 18/06/2011 16:44:44 [Insteon::ALDB_i1] link table for $fan_fmr (devcat: ): > 18/06/2011 16:44:44 [Insteon::ALDB_i1] [0x0FF8] is empty > > Next time around, full scan didn't get that far (16 out of 25) > 18/06/2011 16:57:39 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$yard_lights; command=peek; extra=E6 > 18/06/2011 16:57:39 [Insteon::ALDB_i1] $yard_lights accessing memory at location: 0x0FD8 > 18/06/2011 16:57:40 [Insteon_PLM] DEBUG: Parsing serial data: 02500f828718d4ce212b0002500f828718 > 18/06/2011 16:57:40 [Insteon_PLM] DEBUG: Prepending prior data fragment: 02500f828718 > 18/06/2011 16:57:40 [Insteon_PLM] DEBUG: Parsing serial data: 02500f828718d4ce212b0002620f828705280f06 > 18/06/2011 16:57:40 [Insteon::ALDB_i1] $yard_lights completed link memory scan > 18/06/2011 16:57:40 [Scan all link tables] Now scanning: $kitchen_kpl (16 of 25) > 18/06/2011 16:57:40 [Insteon::ALDB_i1] $kitchen_kpl accessing memory at location: 0x0FF8 > 18/06/2011 16:57:40 [Insteon_PLM] DEBUG: Prepending prior data fragment: 02620f828705280f06 > 18/06/2011 16:57:40 [Insteon_PLM] DEBUG: Parsing serial data: 02620f828705280f0602500f828718d4ce21280f > 18/06/2011 16:57:40 [Insteon::BaseObject] received command/state acknowledge from $yard_lights: set_address_msb and data: 0f > > I'm not sure if the extra runs are useful, but hopefully they give you an idea. > > That's it for now :) > > Thanks, > Marc |
Re: [mh] Trying out the updated insteon branch -> scan all and
orphan deletes still not quite there.
From: Eloy P. <pe...@ch...> - 2011-06-22 18:36:37
|
Hi Gregg, On 06/22/2011 02:15 PM, Gregg Liming wrote: [...] >> D) scan all link tables never finishes for me (lots of details below). > > Isn't this the same as "A"? Or, am I not understanding something? The nightly link table scan was not always finishing for me. You asked me to upgrade to the latest SVN code, which I did, but I have not re-enabled the nightly scan yet. I'll do that and report back. Cheers, Eloy Paris.- |
Re: [mh] Trying out the updated insteon branch -> scan all and
orphan deletes still not quite there.
From: Marc M. <ma...@me...> - 2011-06-22 19:44:11
|
On Wed, Jun 22, 2011 at 02:15:56PM -0400, Gregg Liming wrote: > Hi Mark, > > Sorry about the delay in responding. I'm still working through portions > of it, but at least wanted to let you know I've been trying to think > through it. Details follow: Thanks. > On 6/18/2011 8:22 PM, Marc MERLIN wrote: > > >Summary of showstoppers: > >A) scan link table with PLM is not working but it works for other devices Note, by that I did write "scan link table" (not tables). In other words, I can scan devices, but I can't scan the PLM's own table. > There are really two significant issues here: 1) I need to better > understand the specific cause of why your scans are stopping and 2) I > need to implement date-time and health codes for the ALDB objects. I > was really surprised by your logs as I was expecting to see other info > like timeouts. Instead, they "just stopped". Not to diminish the > importance of having full scanning working (which of course it does for > me), I think it's more important to focus on #2. The reason is that I > would also provide a diagnostic utility that would list all the devices > and the status and time of last successful scan. That way, you would > know which devices might require manual scans. It also wouldn't leave > you guessing. I'm hoping to get to this in the next couple of days. Sounds good. > >B) delete orphan links deletes too much > > Yes. As you noted, this is specific to the "deaf" devices which get > ignored by the full scans and the possibility of the full scans not > getting to a device. I really think that focusing on A above will > address the issue. Also, I could address the "deaf" devices more > properly by using the date-time health code info rather than a brute > force "isa" against their type. So, doing "B" relies on my interim > solution for "A". Good to know. > >D) scan all link tables never finishes for me (lots of details below). > > Isn't this the same as "A"? Or, am I not understanding something? No, it's not the same. A) was indeed that I couldn't scan the PLM's own table and D is a full scan of my network. Thanks, 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/ |
Re: [mh] Trying out the updated insteon branch -> scan all and
orphan deletes still not quite there.
From: Gregg L. <gr...@li...> - 2011-06-22 20:01:33
|
On 6/22/2011 3:43 PM, Marc MERLIN wrote: >>> Summary of showstoppers: >>> A) scan link table with PLM is not working but it works for other devices > > Note, by that I did write "scan link table" (not tables). In other words, I > can scan devices, but I can't scan the PLM's own table. Thanks for clarifying. Now, I do see it happily returning 026915--meaning the PLM's database is empty. I guess that makes sense if this is a brand new PLM--right? So, what would be better is appropriate feedback telling you that. This should be a relatively quick fix. But, shouldn't really impact any of the other issues. >> There are really two significant issues here: 1) I need to better >> understand the specific cause of why your scans are stopping and 2) I >> need to implement date-time and health codes for the ALDB objects. I >> was really surprised by your logs as I was expecting to see other info >> like timeouts. Instead, they "just stopped". Not to diminish the >> importance of having full scanning working (which of course it does for >> me), I think it's more important to focus on #2. The reason is that I >> would also provide a diagnostic utility that would list all the devices >> and the status and time of last successful scan. That way, you would >> know which devices might require manual scans. It also wouldn't leave >> you guessing. I'm hoping to get to this in the next couple of days. > > Sounds good. Now that I understand, all of the above relates to "D". >>> B) delete orphan links deletes too much >> >> Yes. As you noted, this is specific to the "deaf" devices which get >> ignored by the full scans and the possibility of the full scans not >> getting to a device. I really think that focusing on A above will >> address the issue. Also, I could address the "deaf" devices more >> properly by using the date-time health code info rather than a brute >> force "isa" against their type. So, doing "B" relies on my interim >> solution for "A". > > Good to know. > >>> D) scan all link tables never finishes for me (lots of details below). >> >> Isn't this the same as "A"? Or, am I not understanding something? > > No, it's not the same. A) was indeed that I couldn't scan the PLM's own > table and D is a full scan of my network. Got it. |
Re: [mh] Trying out the updated insteon branch -> scan all and
orphan deletes still not quite there.
From: Marc M. <ma...@me...> - 2011-06-22 20:08:20
|
On Wed, Jun 22, 2011 at 04:01:16PM -0400, Gregg Liming wrote: > On 6/22/2011 3:43 PM, Marc MERLIN wrote: > > >>> Summary of showstoppers: > >>> A) scan link table with PLM is not working but it works for other devices > > > > Note, by that I did write "scan link table" (not tables). In other words, I > > can scan devices, but I can't scan the PLM's own table. > > Thanks for clarifying. Now, I do see it happily returning > 026915--meaning the PLM's database is empty. I guess that makes sense > if this is a brand new PLM--right? So, what would be better is > appropriate feedback telling you that. This should be a relatively > quick fix. But, shouldn't really impact any of the other issues. Oh, I see. I thought I had synced a couple of things that would have made links already, but maybe not. I guess I first have to go through all my devices and select 'link to plm', but I don't yet have a good way to delete all the old PLM links without running the orphan links code which will delete too much. Eh, I'll live like that for now, not a huge deal. Thanks, 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/ |
Re: [mh] Trying out the updated insteon branch -> scan all
and orphan deletes still not quite there.
From: Gregg L. <gr...@li...> - 2011-06-23 13:31:52
|
> Marc MERLIN wrote: > On Wed, Jun 22, 2011 at 04:01:16PM -0400, Gregg Liming wrote: > > On 6/22/2011 3:43 PM, Marc MERLIN wrote: > > > > >>> Summary of showstoppers: > > >>> A) scan link table with PLM is not working but it works for other > devices > > > > > > Note, by that I did write "scan link table" (not tables). In other > words, I > > > can scan devices, but I can't scan the PLM's own table. > > > > Thanks for clarifying. Now, I do see it happily returning > > 026915--meaning the PLM's database is empty. I guess that makes > sense > > if this is a brand new PLM--right? So, what would be better is > > appropriate feedback telling you that. This should be a relatively > > quick fix. But, shouldn't really impact any of the other issues. > > Oh, I see. > I thought I had synced a couple of things that would have made links > already, but maybe not. > > I guess I first have to go through all my devices and select 'link to > plm', > but I don't yet have a good way to delete all the old PLM links without > running the orphan links code which will delete too much. > > Eh, I'll live like that for now, not a huge deal. I am now tracking the "health state" of the ALDB tables for all devices. They are initially set as "unknown" and then marked according to what is seen during a scan. Other possible values are "empty", "corrupt" and "good". I've revised the delete orphan links to specifically ignore RemoteLinc and MotionSensor devices. In time, this will need to be adapted to utilize the health values; but, it should get you by for the time being. Also, I've revised delete orphan links to ignore and complain if it tries to compare a device's ALDB values if the ALDB health of the device is either "unknown" or "corrupt". This implies that once I commit the changes, all of the device (and PLM) link tables will have to be rescanned so that the health state is adjusted appropriately. The good news is that the output of the AUDIT mode should not only tell you what it's about to do, but also notify you of any device's whose ALDB table is "unknown" or "corrupt". BTW: "corrupt" doesn't mean that it definitely is corrupt, but that a communications error happened somewhere along the way. So, mh has to assume that its internal mapping of the device's ALDB table is corrupt--not that the device's real ALDB table is corrupt (hopefully, that's clear). I need to do some more testing this evening. But, believe that it's pretty close and will commit thereafter. BTW: I still plan to add a separate utility for listing out unknown or corrupt device ALDBs that is exhaustive. That might be useful in identifying the "problem devices" that are on your network. Most likely, I'm going to "auto-set" the deaf devices (e.g., MotionSensor and RemoteLinc) to "unknown" during a full scan (to include the overnight), but would allow a real state (e.g., corrupt or good) if scanned explicitly. Then, in time, I'd allow delete orphan links to work against those devices. Also, sync links needs to have similar instrumentation applied. Gregg |
Re: [mh] Trying out the updated insteon branch -> scan all
and orphan deletes still not quite there.
From: Marc M. <ma...@me...> - 2011-06-24 05:58:46
|
On Thu, Jun 23, 2011 at 09:31:43AM -0400, Gregg Liming wrote: > > Marc MERLIN wrote: > > On Wed, Jun 22, 2011 at 04:01:16PM -0400, Gregg Liming wrote: > > > On 6/22/2011 3:43 PM, Marc MERLIN wrote: > > > > > > >>> Summary of showstoppers: > > > >>> A) scan link table with PLM is not working but it works for other > > devices > > > > > > > > Note, by that I did write "scan link table" (not tables). In other > > words, I > > > > can scan devices, but I can't scan the PLM's own table. > > > > > > Thanks for clarifying. Now, I do see it happily returning > > > 026915--meaning the PLM's database is empty. I guess that makes > > sense > > > if this is a brand new PLM--right? So, what would be better is > > > appropriate feedback telling you that. This should be a relatively > > > quick fix. But, shouldn't really impact any of the other issues. > > > > Oh, I see. > > I thought I had synced a couple of things that would have made links > > already, but maybe not. > > > > I guess I first have to go through all my devices and select 'link to > > plm', > > but I don't yet have a good way to delete all the old PLM links without > > running the orphan links code which will delete too much. > > > > Eh, I'll live like that for now, not a huge deal. > > I am now tracking the "health state" of the ALDB tables for all devices. > They are initially set as "unknown" and then marked according to what is > seen during a scan. Other possible values are "empty", "corrupt" and > "good". SVN revision 1917 Indeed, I scanned my PLM and things looked good: 23/06/2011 20:39:39 [Insteon::ALDB_PLM] Link table health: good 23/06/2011 20:39:39 [Insteon::ALDB_PLM] cntlr(10) record to $fmr_lamp (d1=01, d2=00, d3=00) 23/06/2011 20:39:39 [Insteon::ALDB_PLM] cntlr(14) record to $fmr_lamp (d1=01, d2=00, d3=00) 23/06/2011 20:39:39 [Insteon::ALDB_PLM] responder record to $garage2_neon_kpl(01) (d1=00, d2=00, d3=00) 23/06/2011 20:39:39 [Insteon::ALDB_PLM] responder record to $garage2_neon_kpl_garage1_neon(03) (d1=00, d2=00, d3=00) 23/06/2011 20:39:39 [Insteon::ALDB_PLM] responder record to $garage2_neon_kpl_kplB(04) (d1=00, d2=00, d3=00) 23/06/2011 20:39:39 [Insteon::ALDB_PLM] responder record to $garage2_neon_kpl_gar_outlights(05) (d1=00, d2=00, d3=00) This is also better: > Running: PLM AUDIT - delete orphan links > [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_blk1_1 because health: unknown. Please rescan this device!! > [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_grey2_1 because health: unknown. Please rescan this device!! > [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_blk1_1 because health: unknown. Please rescan this device!! > [Insteon::ALDB_i1] Delete orphan links: skipping $gar_mos1 because health: unknown. Please rescan this device!! note, those 3 are remotelinks and motion sensor. Are them being flagged as 'unknown' and 'please rescan' expected? > [Insteon::ALDB_i1] Delete orphan links: skipping $mbr_kpl because health: unknown. Please rescan this device!! > [Insteon::ALDB_i1] Delete orphan links: skipping $mbr_lamp2 because health: unknown. Please rescan this device!! > [Insteon::ALDB_i1] Delete orphan links: skipping $mbr_lamp3 because health: unknown. Please rescan this device!! > [Insteon::ALDB_i1] Delete orphan links: skipping $mbr_outside because health: unknown. Please rescan this device!! > (...) these are good. Now, let's work on a full scan. Ok, more details below, but I got one to complete: 23/06/2011 22:47:00 [Scan all link tables] All tables have completed scanning 23/06/2011 22:47:00 [Scan all link tables] However, some failures were noted: 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $lvr_kpl 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $kitchen_kpl 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $dining_kpl 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $garage1_neon_kpl 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $garage2_neon_kpl 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $gar_outlights_kpl I'll rescan those by hand after upping the retry count to 64 and see what delete orphan links does. > device's whose ALDB table is "unknown" or "corrupt". BTW: "corrupt" doesn't > mean that it definitely is corrupt, but that a communications error happened > somewhere along the way. So, mh has to assume that its internal mapping of > the device's ALDB table is corrupt--not that the device's real ALDB table is > corrupt (hopefully, that's clear). Yep, that's clear. Ok, so this is what I have for now in addition to the above. 1) Scan all tables still stops from time to time. I tracked it down to the fact that some of my triggers generated other insteon commands during the full scan, and one of those commands just stops the scan with no error. Do you want me to look more into this? I have one log attached below, although for now I just removed all my triggers to get a full scan to work. 2) Insteon retries, should maybe include an exponential backoff in case the power line is dirty due to a spike from some device (fridge starting up or whatever). At the same time, there may just be some hard to reach devices, and it's nice to have the option to retry longer if your bus isn't great. I put mine to 16 retries, see patch below. It would also be nice to actually set a big retry count during a scan all links where it is much more important to get a full scan than to get an immediate reply or drop. The sad thing is that I even wired a power plug next to $garage2_neon_kpl and plugged an access point into it hoping the access point would regenerate a strong signal right next to the switch. Needless to say that it doesn't seem to help at all :( But this is not a problem with your code, it just makes it more difficult for your code to do its job. Here's a proposed diff I'll submit if you're ok with it: Index: lib/Insteon/Message.pm =================================================================== --- lib/Insteon/Message.pm (revision 1916) +++ lib/Insteon/Message.pm (working copy) @@ -88,7 +88,7 @@ sub send { my ($self, $interface) = @_; - if ($self->send_attempts < 5) + if ($self->send_attempts < ($::config_parms{'Insteon_retry_count'} || 5)) { if ($self->send_attempts > 0) And the before and after: 23/06/2011 21:41:10 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_kpl; command=peek; extra=C4 23/06/2011 21:41:11 [Insteon::BaseMessage] WARN: now resending obj=$fmr_kpl; command=peek; extra=C4 after 2 attempts. 23/06/2011 21:41:11 [Insteon_PLM] DEBUG: Parsing serial data: 02620e07490f2bc406 23/06/2011 21:41:11 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_kpl; command=peek; extra=C4 23/06/2011 21:41:13 [Insteon::BaseMessage] WARN: now resending obj=$fmr_kpl; command=peek; extra=C4 after 3 attempts. 23/06/2011 21:41:13 [Insteon_PLM] DEBUG: Parsing serial data: 02620e07490f2bc406 23/06/2011 21:41:13 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_kpl; command=peek; extra=C4 23/06/2011 21:41:15 [Insteon::BaseMessage] WARN: now resending obj=$fmr_kpl; command=peek; extra=C4 after 4 attempts. 23/06/2011 21:41:15 [Insteon_PLM] DEBUG: Parsing serial data: 02620e07490f2bc406 23/06/2011 21:41:15 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_kpl; command=peek; extra=C4 23/06/2011 21:41:17 [Insteon::BaseInterface] WARN: number of retries (5) for obj=$fmr_kpl; command=peek; extra=C4 exceeds limit. N ow moving on... 23/06/2011 21:41:17 [Insteon::BaseInterface] WARN: Now calling callback: &Insteon::_get_next_linkscan_failure() 23/06/2011 21:41:17 [Scan all link tables] WARN: failure occurred when scanning $fmr_kpl. Moving on... 23/06/2011 21:41:17 [Scan all link tables] Now scanning: $fmr_slav (9 of 25) Yes, I know it's dirty, but it helps for me. fmr_kpl and kitchen_kpl are on my light switch leg. I should not have signal suckers there since there are no power plugs, and yet it's not one of my best legs as you can see. I have no idea if I can make it better although it's usually good enough and only has issues on occasion. 23/06/2011 22:33:56 [Insteon::ALDB_i1] $fmr_kpl accessing memory at location: 0x0CA0 23/06/2011 22:33:56 [Insteon_PLM] DEBUG: Parsing serial data: 02620e074905280c06 23/06/2011 22:33:56 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_kpl; command=set_address_msb; extra=0C 23/06/2011 22:33:58 [Insteon::BaseMessage] WARN: now resending obj=$fmr_kpl; command=set_address_msb; extra=0C after 1 attempts. 23/06/2011 22:33:58 [Insteon_PLM] DEBUG: Parsing serial data: 02620e07490a280c06 23/06/2011 22:33:58 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_kpl; command=set_address_msb; extra=0C 23/06/2011 22:33:59 [Insteon::BaseMessage] WARN: now resending obj=$fmr_kpl; command=set_address_msb; extra=0C after 2 attempts. 23/06/2011 22:34:00 : Saving object states ... done 23/06/2011 22:34:00 [Insteon_PLM] DEBUG: Parsing serial data: 02620e07490f280c06 23/06/2011 22:34:00 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_kpl; command=set_address_msb; extra=0C 23/06/2011 22:34:01 [Insteon::BaseMessage] WARN: now resending obj=$fmr_kpl; command=set_address_msb; extra=0C after 3 attempts. 23/06/2011 22:34:01 [Insteon_PLM] DEBUG: Parsing serial data: 02620e07490f280c06 23/06/2011 22:34:01 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_kpl; command=set_address_msb; extra=0C 23/06/2011 22:34:03 [Insteon::BaseMessage] WARN: now resending obj=$fmr_kpl; command=set_address_msb; extra=0C after 4 attempts. 23/06/2011 22:34:03 [Insteon_PLM] DEBUG: Parsing serial data: 02620e07490f280c06 23/06/2011 22:34:03 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_kpl; command=set_address_msb; extra=0C 23/06/2011 22:34:05 [Insteon::BaseMessage] WARN: now resending obj=$fmr_kpl; command=set_address_msb; extra=0C after 5 attempts. 23/06/2011 22:34:06 [Insteon_PLM] DEBUG: Parsing serial data: 02620e07490f280c06 23/06/2011 22:34:06 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_kpl; command=set_address_msb; extra=0C 23/06/2011 22:34:08 [Insteon::BaseMessage] WARN: now resending obj=$fmr_kpl; command=set_address_msb; extra=0C after 6 attempts. 23/06/2011 22:34:08 [Insteon_PLM] DEBUG: Parsing serial data: 02620e07490f280c06 23/06/2011 22:34:08 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_kpl; command=set_address_msb; extra=0C 23/06/2011 22:34:08 [Insteon_PLM] DEBUG: Parsing serial data: 02500e174918d4ce20d7cc 23/06/2011 22:34:08 [Insteon::BaseInterface] Warn! Unable to locate object for source: 0e1749 and group: 23/06/2011 22:34:10 [Insteon::BaseMessage] WARN: now resending obj=$fmr_kpl; command=set_address_msb; extra=0C after 7 attempts. 23/06/2011 22:34:10 [Insteon_PLM] DEBUG: Parsing serial data: 02620e07490f280c06 23/06/2011 22:34:10 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_kpl; command=set_address_msb; extra=0C 23/06/2011 22:34:11 [Insteon_PLM] DEBUG: Parsing serial data: 02500e074918d4ce23280c 23/06/2011 22:34:11 [Insteon_PLM] DEBUG: Parsing serial data: 02620e0749052ba006 23/06/2011 22:34:11 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_kpl; command=peek; extra=A0 23/06/2011 22:34:11 [Insteon_PLM] DEBUG: Parsing serial data: 02500e074918d4ce212ba2 23/06/2011 22:34:11 [Insteon_PLM] DEBUG: Parsing serial data: 02620e0749052ba106 23/06/2011 22:34:11 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$fmr_kpl; command=peek; extra=A1 23/06/2011 22:34:11 [Insteon_PLM] DEBUG: Parsing serial data: 02500e074918d4ce212b52 23/06/2011 22:34:11 [Insteon_PLM] DEBUG: Parsing serial data: 02620e0749052ba206 then again, it only helped so much: 23/06/2011 22:47:00 [Scan all link tables] All tables have completed scanning 23/06/2011 22:47:00 [Scan all link tables] However, some failures were noted: 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $lvr_kpl 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $kitchen_kpl 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $dining_kpl 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $garage1_neon_kpl 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $garage2_neon_kpl 23/06/2011 22:47:00 [Scan all link tables] WARN: failure occurred when scanning $gar_outlights_kpl As for the next issue, this is an example of a full scan that just stops in the middle (there is no other data/reports after this log). I can give more such examples if it helps. --------------------------------------------------------------- > 23/06/2011 21:10:18 [Insteon::ALDB_i1] $gar_outlights_kpl accessing memory at location: 0x0F50 > 23/06/2011 21:10:19 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06 > 23/06/2011 21:10:19 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$gar_outlights_kpl; command=set_address_msb; extra=0F > 23/06/2011 21:10:19 [Insteon_PLM] DEBUG: Parsing serial data: 025007de8b18d4ce21280f > 23/06/2011 21:10:19 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b5006 > 23/06/2011 21:10:19 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$gar_outlights_kpl; command=peek; extra=50 > (...) > 23/06/2011 21:10:22 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b5606025007 > 23/06/2011 21:10:22 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b5606025007 > 23/06/2011 21:10:22 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b5606025007de8b18d4ce212b1f > 23/06/2011 21:10:22 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b5606 > 23/06/2011 21:10:22 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b5606026207de8b052b5706 > 23/06/2011 21:10:22 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b5606026207de8b052b5706 > 23/06/2011 21:10:22 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b5606026207de8b052b5706025007de8b18d4ce212b06 > 23/06/2011 21:10:22 [Insteon::ALDB_i1] $gar_outlights_kpl accessing memory at location: 0x0F48 > 23/06/2011 21:10:37 MBR Omnistat RC-80: Indoor temp is 72, HVAC Command: off, heat to 50, cool to 88, mode: program_cool > 23/06/2011 21:10:42 MBR Omnistat: Setting outside temperature to 64 > 23/06/2011 21:10:49 MYLOGC: got computer closet temp 80.2625, last was 80.4875 and diff is 0.224999999999994. Fan state is on > 23/06/2011 21:11:00 : Saving object states ... done > 23/06/2011 21:11:07 Main Omnistat RC-90: Indoor temp is 73, HVAC Command: off, heat to 66, cool to 76, mode: program_auto > 23/06/2011 21:11:37 MBR Omnistat RC-80: Indoor temp is 72, HVAC Command: off, heat to 50, cool to 88, mode: program_cool > 23/06/2011 21:12:00 : Saving object states ... done > 23/06/2011 21:12:07 Main Omnistat RC-90: Indoor temp is 73, HVAC Command: off, heat to 66, cool to 76, mode: program_auto > 23/06/2011 21:12:21 MR26 got data > 23/06/2011 21:12:21 MR26 data is not dupe > 23/06/2011 21:12:37 MBR Omnistat RC-80: Indoor temp is 72, HVAC Command: off, heat to 50, cool to 88, mode: program_cool > 23/06/2011 21:13:00 : Saving object states ... done > 23/06/2011 21:13:07 Main Omnistat RC-90: Indoor temp is 73, HVAC Command: off, heat to 66, cool to 76, mode: program_auto > 23/06/2011 21:13:25 [Insteon_PLM] DEBUG: Parsing serial data: 02500fb705000001cb1300 > 23/06/2011 21:13:25 [Insteon::BaseInterface] command:off; type:alllink; group: 01 > 23/06/2011 21:13:26 [Insteon_PLM] DEBUG: Parsing serial data: 02500fb70518d4ce411301 > 23/06/2011 21:13:26 [Insteon::BaseInterface] command:off; type:cleanup; group: 01 > 23/06/2011 21:13:26 [Insteon::BaseObject] $mbr_lamp2::set(off, $mbr_lamp2) > 23/06/2011 21:13:26 MYLOG6: mbr_lamp2 turned off, unsetting master timer for mbr_lamp2 > 23/06/2011 21:13:37 MBR Omnistat RC-80: Indoor temp is 72, HVAC Command: off, heat to 50, cool to 88, mode: program_cool > 23/06/2011 21:13:50 MYLOGC: got computer closet temp 80.0375, last was 80.2625 and diff is 0.225000000000009. Fan state is on > 23/06/2011 21:14:00 : Saving object states ... done > 23/06/2011 21:14:07 Main Omnistat RC-90: Indoor temp is 73, HVAC Command: off, heat to 66, cool to 76, mode: program_auto > 23/06/2011 21:14:25 [Insteon_PLM] DEBUG: Parsing serial data: 025007d992000001cb1100 > 23/06/2011 21:14:25 [Insteon::BaseInterface] command:on; type:alllink; group: 01 > 23/06/2011 21:14:26 [Insteon_PLM] DEBUG: Parsing serial data: 025007d99218d4ce411101 > 23/06/2011 21:14:26 [Insteon::BaseInterface] command:on; type:cleanup; group: 01 > 23/06/2011 21:14:26 [Insteon::BaseObject] $garage1_neon_kpl::set(on, $garage1_neon_kpl) > 23/06/2011 21:14:26 MYLOGKPL: sync_kpl_lights called for state_changed on $garage1_neon_kpl to on for $garage1_neon_kpls set kpls i > n 1sec > 23/06/2011 21:14:26 MYLOG6: garage1_neon_kpl turned on, (re)setting master timer to 120mn > 23/06/2011 21:14:26 MYLOG6: set_master_timer for garage1_neon_kpl to 120mn > 23/06/2011 21:14:28 [Insteon::BaseObject] $garage1_neon_kpls::set(on, ) > 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: Parsing serial data: 02614111ff06 > 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$garage1_neon_kpls; command=on; extra=FF > 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: Parsing serial data: 025007d4fd18d4ce611141 > 23/06/2011 21:14:28 [Insteon::BaseObject] received command/state acknowledge from $garage2_neon_kpl: on and data: > 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: Parsing serial data: 025806025007de8b18d4ce611141 > 23/06/2011 21:14:28 [Insteon_PLM] Received all-link cleanup success: > 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b4806 > 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b4806 > 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b4806025007de > 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b4806025007de > 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b4806025007de8b18d4ce212be2 > 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b4806 > 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b4806026207de8b052b4906 > 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b4806026207de8b052b4906 > 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b4806026207de8b052b4906025007de8b18d4ce > 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b4806026207de8b052b4906025007de8b18d4ce > 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b4806026207de8b052b4906025007de8b18d4ce212b06 > 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b4806026207de8b052b4906 > 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b4806026207de8b052b4906026207de8b052b4a06 > 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b4806026207de8b052b4906026207de8b052b4a06 > 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b4806026207de8b052b4906026207de8b052b4a0602 > (...) > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b3706025007de8b18d4ce212b01 > 23/06/2011 21:15:47 [Insteon::ALDB_i1] $gar_outlights_kpl accessing memory at location: 0x0F28 > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06 > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06 > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06025007de > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06025007de > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06025007de8b18d4ce21280f > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06 > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06026207de8b052b2806 > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06026207de8b052b2806 > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06026207de8b052b2806025007de8b18d4 > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06026207de8b052b2806025007de8b18d4 > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06026207de8b052b2806025007de8b18d4ce212ba2 > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06026207de8b052b2806 > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06026207de8b052b2806026207de8b052b2906 > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06026207de8b052b2806026207de8b052b2906 > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06026207de8b052b2806026207de8b052b2906025007de8b18d4ce212b > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06026207de8b052b2806026207de8b052b2906025007de8b18d4ce212b > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06026207de8b052b2806026207de8b052b2906025007de8b18d4ce212b07 > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06026207de8b052b2806026207de8b052b2906 > 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06026207de8b052b2806026207de8b052b2906026207de8b052b2a06 > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06026207de8b052b2806026207de8b052b2906026207de8b052b2a06 > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06026207de8b052b2806026207de8b052b2906026207de8b052b2a06025007de8b18d4ce212b0e > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06 > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06 > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b060250 > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b060250 > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06025007de8b18d4ce212b09 > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06 > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06026207de8b052b2c06 > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06026207de8b052b2c06 > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06026207de8b052b2c06025007de8b > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06026207de8b052b2c06025007de8b > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06026207de8b052b2c06025007de8b18d4ce212b12 > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06026207de8b052b2c06 > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06 > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06 > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06025007de8b18d4ce > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06025007de8b18d4ce > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06025007de8b18d4ce212bfe > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06 > 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06026207de8b052b2e06 > 23/06/2011 21:15:49 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06026207de8b052b2e06 > 23/06/2011 21:15:49 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06026207de8b052b2e06025007de8b18d4ce212b1f > 23/06/2011 21:16:00 : Saving object states ... done > 23/06/2011 21:16:07 Main Omnistat RC-90: Indoor temp is 73, HVAC Command: off, heat to 66, cool to 76, mode: program_auto > 23/06/2011 21:16:18 [Insteon_PLM] DEBUG: Parsing serial data: 0250099e68000002cb1300 > 23/06/2011 21:16:18 [Insteon::BaseInterface] command:off; type:alllink; group: 02 > 23/06/2011 21:16:21 [Insteon_PLM] DEBUG: Parsing serial data: 0250099e6818d4ce411302 > 23/06/2011 21:16:21 [Insteon::BaseInterface] command:off; type:cleanup; group: 02 > 23/06/2011 21:16:21 [Insteon::BaseObject] $dining_kpl_kitchen_kpl::set(off, $dining_kpl_kitchen_kpl) > 23/06/2011 21:16:21 MYLOGKPL: sync_kpl_lights called for state_changed on $kitchen_kpl to off for $kitchen_kpls set kpls in 1sec > 23/06/2011 21:16:21 MYLOG6: kitchen_kpl turned off, unsetting master timer for kitchen_kpl > 23/06/2011 21:16:22 [Insteon::Bases; command=off; extra=00 After that, nothing, the scan is dead. -- "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/ |
Re: [mh] Trying out the updated insteon branch -> scan all
and orphan deletes still not quite there.
From: Marc M. <ma...@me...> - 2011-06-24 06:03:42
|
On Thu, Jun 23, 2011 at 10:58:33PM -0700, Marc MERLIN wrote: > The sad thing is that I even wired a power plug next to $garage2_neon_kpl > and plugged an access point into it hoping the access point would regenerate > a strong signal right next to the switch. > Needless to say that it doesn't seem to help at all :( I forgot to mention that I do have dimmable CFLs all over my house with dimmable KPLs. I'm going to assume that this is likely why I have more issues than the average person, but at the same time I'd rather not throw away hundreds of dollars of dimmerlincs/kpl dimmers, and have to buy non dimmable equivalents considering that with a few retries here and there on the average day, things work well enough otherwise (only by syncs tend to have issues). 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/ |
Re: [mh] Trying out the updated insteon branch -> scan
all and orphan deletes still not quite there.
From: Gregg L. <gr...@li...> - 2011-06-28 20:57:27
|
Hi Marc, I wanted to revisit the below scan "stop" issue: On 6/24/2011 1:58 AM, Marc MERLIN wrote: [... snip ...] > As for the next issue, this is an example of a full scan that just stops in the middle > (there is no other data/reports after this log). > I can give more such examples if it helps. Actually, a few more examples probably would help--especially, if it were possible to not have non-insteon events interleaved (just to make it easier for me to track what is actually occurring). If not, then no worries. Specifically, it looks like you might be getting a message from a button or paddle. Then, it looks like you might be sending some PLM-managed scene control to a KPL button. Possibly somewhere in that scenario, the scan gets hung-up. Could you run a few tests to see if you can get any consistent behavior? And, if so, describe the scenarios along with the logs? I also see a lot more fragment reprocessing than I see. I can't quite tell if it's an artifact of your environment or specific to the scan hang event. Either way, I'll get to it, but am hoping it is something separate for now. Most of those fragment "prepends" are repeated PLM acks and should be tossed (which does eventually happen). BTW: I did add your patch into Message.pm; so, you should be ok to svn update and give my latest commits a whirl. > --------------------------------------------------------------- >> 23/06/2011 21:10:18 [Insteon::ALDB_i1] $gar_outlights_kpl accessing memory at location: 0x0F50 >> 23/06/2011 21:10:19 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06 >> 23/06/2011 21:10:19 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$gar_outlights_kpl; command=set_address_msb; extra=0F >> 23/06/2011 21:10:19 [Insteon_PLM] DEBUG: Parsing serial data: 025007de8b18d4ce21280f >> 23/06/2011 21:10:19 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b5006 >> 23/06/2011 21:10:19 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$gar_outlights_kpl; command=peek; extra=50 >> (...) >> 23/06/2011 21:10:22 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b5606025007 >> 23/06/2011 21:10:22 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b5606025007 >> 23/06/2011 21:10:22 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b5606025007de8b18d4ce212b1f >> 23/06/2011 21:10:22 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b5606 >> 23/06/2011 21:10:22 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b5606026207de8b052b5706 >> 23/06/2011 21:10:22 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b5606026207de8b052b5706 >> 23/06/2011 21:10:22 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b5606026207de8b052b5706025007de8b18d4ce212b06 >> 23/06/2011 21:10:22 [Insteon::ALDB_i1] $gar_outlights_kpl accessing memory at location: 0x0F48 >> 23/06/2011 21:10:37 MBR Omnistat RC-80: Indoor temp is 72, HVAC Command: off, heat to 50, cool to 88, mode: program_cool >> 23/06/2011 21:10:42 MBR Omnistat: Setting outside temperature to 64 >> 23/06/2011 21:10:49 MYLOGC: got computer closet temp 80.2625, last was 80.4875 and diff is 0.224999999999994. Fan state is on >> 23/06/2011 21:11:00 : Saving object states ... done >> 23/06/2011 21:11:07 Main Omnistat RC-90: Indoor temp is 73, HVAC Command: off, heat to 66, cool to 76, mode: program_auto >> 23/06/2011 21:11:37 MBR Omnistat RC-80: Indoor temp is 72, HVAC Command: off, heat to 50, cool to 88, mode: program_cool >> 23/06/2011 21:12:00 : Saving object states ... done >> 23/06/2011 21:12:07 Main Omnistat RC-90: Indoor temp is 73, HVAC Command: off, heat to 66, cool to 76, mode: program_auto >> 23/06/2011 21:12:21 MR26 got data >> 23/06/2011 21:12:21 MR26 data is not dupe >> 23/06/2011 21:12:37 MBR Omnistat RC-80: Indoor temp is 72, HVAC Command: off, heat to 50, cool to 88, mode: program_cool >> 23/06/2011 21:13:00 : Saving object states ... done >> 23/06/2011 21:13:07 Main Omnistat RC-90: Indoor temp is 73, HVAC Command: off, heat to 66, cool to 76, mode: program_auto >> 23/06/2011 21:13:25 [Insteon_PLM] DEBUG: Parsing serial data: 02500fb705000001cb1300 >> 23/06/2011 21:13:25 [Insteon::BaseInterface] command:off; type:alllink; group: 01 >> 23/06/2011 21:13:26 [Insteon_PLM] DEBUG: Parsing serial data: 02500fb70518d4ce411301 >> 23/06/2011 21:13:26 [Insteon::BaseInterface] command:off; type:cleanup; group: 01 >> 23/06/2011 21:13:26 [Insteon::BaseObject] $mbr_lamp2::set(off, $mbr_lamp2) >> 23/06/2011 21:13:26 MYLOG6: mbr_lamp2 turned off, unsetting master timer for mbr_lamp2 >> 23/06/2011 21:13:37 MBR Omnistat RC-80: Indoor temp is 72, HVAC Command: off, heat to 50, cool to 88, mode: program_cool >> 23/06/2011 21:13:50 MYLOGC: got computer closet temp 80.0375, last was 80.2625 and diff is 0.225000000000009. Fan state is on >> 23/06/2011 21:14:00 : Saving object states ... done >> 23/06/2011 21:14:07 Main Omnistat RC-90: Indoor temp is 73, HVAC Command: off, heat to 66, cool to 76, mode: program_auto >> 23/06/2011 21:14:25 [Insteon_PLM] DEBUG: Parsing serial data: 025007d992000001cb1100 >> 23/06/2011 21:14:25 [Insteon::BaseInterface] command:on; type:alllink; group: 01 >> 23/06/2011 21:14:26 [Insteon_PLM] DEBUG: Parsing serial data: 025007d99218d4ce411101 >> 23/06/2011 21:14:26 [Insteon::BaseInterface] command:on; type:cleanup; group: 01 >> 23/06/2011 21:14:26 [Insteon::BaseObject] $garage1_neon_kpl::set(on, $garage1_neon_kpl) >> 23/06/2011 21:14:26 MYLOGKPL: sync_kpl_lights called for state_changed on $garage1_neon_kpl to on for $garage1_neon_kpls set kpls i >> n 1sec >> 23/06/2011 21:14:26 MYLOG6: garage1_neon_kpl turned on, (re)setting master timer to 120mn >> 23/06/2011 21:14:26 MYLOG6: set_master_timer for garage1_neon_kpl to 120mn >> 23/06/2011 21:14:28 [Insteon::BaseObject] $garage1_neon_kpls::set(on, ) >> 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: Parsing serial data: 02614111ff06 >> 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: received interface acknowledge: obj=$garage1_neon_kpls; command=on; extra=FF >> 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: Parsing serial data: 025007d4fd18d4ce611141 >> 23/06/2011 21:14:28 [Insteon::BaseObject] received command/state acknowledge from $garage2_neon_kpl: on and data: >> 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: Parsing serial data: 025806025007de8b18d4ce611141 >> 23/06/2011 21:14:28 [Insteon_PLM] Received all-link cleanup success: >> 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b4806 >> 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b4806 >> 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b4806025007de >> 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b4806025007de >> 23/06/2011 21:14:28 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b4806025007de8b18d4ce212be2 >> 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b4806 >> 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b4806026207de8b052b4906 >> 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b4806026207de8b052b4906 >> 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b4806026207de8b052b4906025007de8b18d4ce >> 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b4806026207de8b052b4906025007de8b18d4ce >> 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b4806026207de8b052b4906025007de8b18d4ce212b06 >> 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b4806026207de8b052b4906 >> 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b4806026207de8b052b4906026207de8b052b4a06 >> 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b4806026207de8b052b4906026207de8b052b4a06 >> 23/06/2011 21:14:29 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b4806026207de8b052b4906026207de8b052b4a0602 >> (...) >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b3706025007de8b18d4ce212b01 >> 23/06/2011 21:15:47 [Insteon::ALDB_i1] $gar_outlights_kpl accessing memory at location: 0x0F28 >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06 >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06 >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06025007de >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06025007de >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06025007de8b18d4ce21280f >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06 >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06026207de8b052b2806 >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06026207de8b052b2806 >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06026207de8b052b2806025007de8b18d4 >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06026207de8b052b2806025007de8b18d4 >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06026207de8b052b2806025007de8b18d4ce212ba2 >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06026207de8b052b2806 >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06026207de8b052b2806026207de8b052b2906 >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06026207de8b052b2806026207de8b052b2906 >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06026207de8b052b2806026207de8b052b2906025007de8b18d4ce212b >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06026207de8b052b2806026207de8b052b2906025007de8b18d4ce212b >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06026207de8b052b2806026207de8b052b2906025007de8b18d4ce212b07 >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06026207de8b052b2806026207de8b052b2906 >> 23/06/2011 21:15:47 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06026207de8b052b2806026207de8b052b2906026207de8b052b2a06 >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b05280f06026207de8b052b2806026207de8b052b2906026207de8b052b2a06 >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b05280f06026207de8b052b2806026207de8b052b2906026207de8b052b2a06025007de8b18d4ce212b0e >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06 >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06 >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b060250 >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b060250 >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06025007de8b18d4ce212b09 >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06 >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06026207de8b052b2c06 >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06026207de8b052b2c06 >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06026207de8b052b2c06025007de8b >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06026207de8b052b2c06025007de8b >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06026207de8b052b2c06025007de8b18d4ce212b12 >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06026207de8b052b2c06 >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06 >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06 >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06025007de8b18d4ce >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06025007de8b18d4ce >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06025007de8b18d4ce212bfe >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06 >> 23/06/2011 21:15:48 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06026207de8b052b2e06 >> 23/06/2011 21:15:49 [Insteon_PLM] DEBUG: Prepending prior data fragment: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06026207de8b052b2e06 >> 23/06/2011 21:15:49 [Insteon_PLM] DEBUG: Parsing serial data: 026207de8b052b2b06026207de8b052b2c06026207de8b052b2d06026207de8b052b2e06025007de8b18d4ce212b1f >> 23/06/2011 21:16:00 : Saving object states ... done >> 23/06/2011 21:16:07 Main Omnistat RC-90: Indoor temp is 73, HVAC Command: off, heat to 66, cool to 76, mode: program_auto >> 23/06/2011 21:16:18 [Insteon_PLM] DEBUG: Parsing serial data: 0250099e68000002cb1300 >> 23/06/2011 21:16:18 [Insteon::BaseInterface] command:off; type:alllink; group: 02 >> 23/06/2011 21:16:21 [Insteon_PLM] DEBUG: Parsing serial data: 0250099e6818d4ce411302 >> 23/06/2011 21:16:21 [Insteon::BaseInterface] command:off; type:cleanup; group: 02 >> 23/06/2011 21:16:21 [Insteon::BaseObject] $dining_kpl_kitchen_kpl::set(off, $dining_kpl_kitchen_kpl) >> 23/06/2011 21:16:21 MYLOGKPL: sync_kpl_lights called for state_changed on $kitchen_kpl to off for $kitchen_kpls set kpls in 1sec >> 23/06/2011 21:16:21 MYLOG6: kitchen_kpl turned off, unsetting master timer for kitchen_kpl >> 23/06/2011 21:16:22 [Insteon::Bases; command=off; extra=00 > > After that, nothing, the scan is dead. > > > > |
Re: [mh] Trying out the updated insteon branch -> scan
all and orphan deletes still not quite there.
From: Marc M. <ma...@me...> - 2011-06-28 23:45:37
|
On Tue, Jun 28, 2011 at 04:57:11PM -0400, Gregg Liming wrote: > Hi Marc, > > I wanted to revisit the below scan "stop" issue: > > On 6/24/2011 1:58 AM, Marc MERLIN wrote: > > [... snip ...] > > > As for the next issue, this is an example of a full scan that just stops in the middle > > (there is no other data/reports after this log). > > I can give more such examples if it helps. > > Actually, a few more examples probably would help--especially, if it > were possible to not have non-insteon events interleaved (just to make > it easier for me to track what is actually occurring). If not, then no > worries. I just did 2 scans that stopped half way but at different points. I got you full logs this time but I'm not pasting them here since they're logn. > Specifically, it looks like you might be getting a message from a button > or paddle. Then, it looks like you might be sending some PLM-managed Maybe in one log, but not in the log from today. Also it should be a cleaner run since all my CFLs are off and therefore I should have less noise on the bus. > scene control to a KPL button. Possibly somewhere in that scenario, the > scan gets hung-up. Could you run a few tests to see if you can get any > consistent behavior? And, if so, describe the scenarios along with the > logs? I removed my more bus spammy jobs, restarted mh, no one is in the house to push buttons and it failed twice anyway. http://marc.merlins.org/tmp/print.log_paused_at_9of25 http://marc.merlins.org/tmp/print.log_paused_at_11of25 http://marc.merlins.org/tmp/items.mht > I also see a lot more fragment reprocessing than I see. I can't quite > tell if it's an artifact of your environment or specific to the scan > hang event. Either way, I'll get to it, but am hoping it is something > separate for now. Most of those fragment "prepends" are repeated PLM > acks and should be tossed (which does eventually happen). It's a 2413U if that helps (no more 2412 at smarthome). > BTW: I did add your patch into Message.pm; so, you should be ok to svn > update and give my latest commits a whirl. Thanks. This scan was clean though, no big sets of retries. At least that helps rulling things out. Are those logs useful? 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/ |
Re: [mh] Trying out the updated insteon branch -> scan
all and orphan deletes still not quite there.
From: Gregg L. <gr...@li...> - 2011-06-29 01:34:16
|
On 6/28/2011 7:45 PM, Marc MERLIN wrote: > I removed my more bus spammy jobs, restarted mh, no one is in the house to > push buttons and it failed twice anyway. > > http://marc.merlins.org/tmp/print.log_paused_at_9of25 > http://marc.merlins.org/tmp/print.log_paused_at_11of25 > http://marc.merlins.org/tmp/items.mht > >> I also see a lot more fragment reprocessing than I see. I can't quite >> tell if it's an artifact of your environment or specific to the scan >> hang event. Either way, I'll get to it, but am hoping it is something >> separate for now. Most of those fragment "prepends" are repeated PLM >> acks and should be tossed (which does eventually happen). > > It's a 2413U if that helps (no more 2412 at smarthome). > >> BTW: I did add your patch into Message.pm; so, you should be ok to svn >> update and give my latest commits a whirl. > > Thanks. > This scan was clean though, no big sets of retries. > > At least that helps rulling things out. > > Are those logs useful? From an initial look, I think that they will be very helpful. Thank-you! |
Re: [mh] Trying out the updated insteon branch -> scan all and
orphan deletes still not quite there.
From: Gregg L. <gr...@li...> - 2011-06-29 01:36:50
|
On 6/28/2011 7:54 PM, Eloy Paris wrote: > Hi Marc, > > On 06/28/2011 07:45 PM, Marc MERLIN wrote: > > [...] > >> I just did 2 scans that stopped half way but at different points. >> I got you full logs this time but I'm not pasting them here since they're >> logn. > > Coincidentally, I also ran two scans a few minutes ago and they both > hung at different points. I also sent Gregg full logs. Got them. Thanks! > [...] > >> I removed my more bus spammy jobs, restarted mh, no one is in the house to >> push buttons and it failed twice anyway. > > Same here. I just tried a third time and it failed too. I have > problematic devices and I think they have something to do with the scans > failing. For some reason they seem to be more problematic now than a few > months ago. I did relocate an access point so that probably has > something to do with it. > > [...] > >> It's a 2413U if that helps (no more 2412 at smarthome). > > That's what I have too -- is it possible that messages are being > generated too fast and some bytes are being overrun? Or asked another > way, is there some kind of flow control that would prevent overruns? The > reason I ask is because I wonder if the USB version of the PLM lacks > something (like hardware flow control) that the native RS-232 version of > the PLM had. I haven't looked at the logs long enough to have a sense for where the problem is occurring. So, I wouldn't jump to conclusions. Gregg |
Re: [mh] Trying out the updated insteon branch -> scan all and
orphan deletes still not quite there.
From: Gregg L. <gr...@li...> - 2011-06-29 01:53:53
|
On 6/28/2011 9:36 PM, Gregg Liming wrote: > On 6/28/2011 7:54 PM, Eloy Paris wrote: >> On 06/28/2011 07:45 PM, Marc MERLIN wrote: > I haven't looked at the logs long enough to have a sense for where the > problem is occurring. So, I wouldn't jump to conclusions. I see a pattern in each of your logs at the point of termination. So, it's unlikely that it is coincidence (assuming the two of you live in different houses). I'll work on identifying and correcting the issue soon. Gregg |
Re: [mh] Trying out the updated insteon branch -> scan all and
orphan deletes still not quite there.
From: Eloy P. <pe...@ch...> - 2011-06-28 23:54:14
|
Hi Marc, On 06/28/2011 07:45 PM, Marc MERLIN wrote: [...] > I just did 2 scans that stopped half way but at different points. > I got you full logs this time but I'm not pasting them here since they're > logn. Coincidentally, I also ran two scans a few minutes ago and they both hung at different points. I also sent Gregg full logs. [...] > I removed my more bus spammy jobs, restarted mh, no one is in the house to > push buttons and it failed twice anyway. Same here. I just tried a third time and it failed too. I have problematic devices and I think they have something to do with the scans failing. For some reason they seem to be more problematic now than a few months ago. I did relocate an access point so that probably has something to do with it. [...] > It's a 2413U if that helps (no more 2412 at smarthome). That's what I have too -- is it possible that messages are being generated too fast and some bytes are being overrun? Or asked another way, is there some kind of flow control that would prevent overruns? The reason I ask is because I wonder if the USB version of the PLM lacks something (like hardware flow control) that the native RS-232 version of the PLM had. Cheers, Eloy Paris.- |
From: Marc M. <ma...@me...> - 2011-06-29 14:28:01
|
On Tue, Jun 28, 2011 at 09:24:43PM -0400, Gregg Liming wrote: > > That said, if you changed orphan tracking code, it may make sense for me to > > wait until I can do a full scan again, and see what I get. > > Yes, lot's of changes. Ok, I ran the new code and I diffed the output with my last one. As a side note, if there is any way you can sort the data structures before outputting them to a log file, it would make diffing 2 runs a lot easier. The same running mh gave me different ordering on 2 orphan log dumps. Short story the new code is good outside of a small issue in 4) below but since I fixed my state that caused it, I just went ahead and ran the delete orphan links since after I fixed 4), the audit log looked good. In other words, great job! :) But now I feel stupid, I don't find the 'sync all links' options on the insteon page or the list of voice commands. Where is it? Here are the details from my last run if you are curious 1) these half broken messages were removed (i.e. good): [Insteon::ALDB_i1] Delete orphan links: skipping check for reciprocal links from $gar_mos1 because health: unknown. Please rescan this device!! [Insteon::ALDB_i1] Delete orphan links: skipping check for reciprocal links from $rlink_blk1_1 because health: unknown. Please rescan this device!! 2) I still get this, but only once, not a big a deal: [Insteon::ALDB_i1] Delete orphan links: skipping $gar_mos1 because health: unknown. Please rescan this device!! [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_blk1_1 because health: unknown. Please rescan this device!! [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_blk1_1 because health: unknown. Please rescan this device!! [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_grey2_1 because health: unknown. Please rescan this device!! 3) I now get these, which is also good: [Insteon::ALDB_i1] (AUDIT) WARNING: no reciprocal link defined for: $lvr_kpl(05) as controller and $fmr_lamp(01) Please sync links with the applicable device; this link will not be deleted. [Insteon::ALDB_i1] (AUDIT) WARNING: no reverse link defined for: $dining_kpl(01) as responder and $fmr_kpl(03) Please sync links with the applicable device; this link will not be deleted. 4) I'm now left with these interesting ones: 4a) (AUDIT) Delete orphan responder link from $gar_outlights_kpl to PLM because no SCENE_MEMBER entry could be found in items.mht for INSTEON_ICONTROLLER: $yard_lights_kpls This is also correct 4b) (AUDIT) Delete orphan responder link from $lvr_kpl [button:1f] to PLM because no SCENE_MEMBER entry could be found in items.mht for INSTEON_ICONTROLLER: $mbr_kpls I'll assume it's correct, but 'button 1f' isn't clear what button that is :) For what it's worth I have: IPLL, 09.94.25:07, lvr_kpl_mbr_kpl, lvr_kplG|buttons, PLM, IPLL, PLM:80, mbr_kpls, kpl_tie_scenes, PLM SCENE_MEMBER, lvr_kpl_mbr_kpl, mbr_kpls 4c1) (AUDIT) Now deleting orphaned responder link in $dining_kpl [button:02] because PLM does not have a corresponding controller record with group (52) I would add the following after 'with group(52)': ' defined by PLM:52 in config file, try resyncing scene to PLM if config file is correct'. I have: IPLL, 09.9E.68:02, dining_kpl_kitchen_kpl, dining_kplB|buttons, PLM, IPLL, PLM:52, kitchen_kpls, kpl_tie_scenes, PLM SCENE_MEMBER, fmr_kpl_kitchen_kpl, kitchen_kpls SCENE_MEMBER, dining_kpl_kitchen_kpl, kitchen_kpls SCENE_MEMBER, lvr_kpl_kitchen_kpl, kitchen_kpls So it looks like my config file is correct, but likely my PLM didn't have the matching data. Interestingly I got thise while syncing that scene. 29/06/2011 07:05:46 [Insteon_PLM] WARN: received NACK for obj=$PLM; interface_data=40E2100e0749010001. If this is a light fixture, check bulb I don't have light fixtures :) And I got a couple more of these (same issue) 4c2) (AUDIT) Now deleting orphaned responder link in $dining_kpl [button:03] because PLM does not have a corresponding controller record with group (10) (AUDIT) Now deleting orphaned responder link in $fmr_slav because PLM does not have a corresponding controller record with group (10) (AUDIT) Now deleting orphaned responder link in $kitchen_kpl [button:02] because PLM does not have a corresponding controller record with group (10) 4c3) (AUDIT) Now deleting orphaned responder link in $garage1_neon_kpl [button:04] because PLM does not have a corresponding controller record with group (42) (AUDIT) Now deleting orphaned responder link in $gar_outlights_kpl [button:04] because PLM does not have a corresponding controller record with group (42) So I just manually resynced them via the web interface, then rescanned the PLM's link tables and those problems went away. In other words, deleting those links is also a small bug: the config file is actually correct and the PLM was out of date somehow. Thanks much, 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/ |
Re: [mh] Trying out the updated insteon branch -> scan
all and orphan deletes still not quite there.
From: Gregg L. <gr...@li...> - 2011-06-29 01:24:59
|
On 6/28/2011 8:06 PM, Marc MERLIN wrote: > On Tue, Jun 28, 2011 at 01:35:45PM -0400, Gregg Liming wrote: >> I just committed a bunch of changes. I think that they address a lot of >> your concerns, but likely not all (I just have lost track of which >> things need to be addressed). > > The 2 main ones were scan all stopping in the middle and some orphan deletes > that I couldn't quite explain as per the Email below. I'll take a look over the next day or so and try to track down the issue. > That said, if you changed orphan tracking code, it may make sense for me to > wait until I can do a full scan again, and see what I get. Yes, lot's of changes. > One of my sub points however was that if there was a wait to get print.log > output and pipe that into a command that allowed me to do a partial delete > it would be awesome (i.e. delete all the links that I have reviewed to be > ok, and it's a big list, and end up with the smaller list to review next > time). > I do however realize that there likely isn't a good way to do this without > writing a bunch of code that doesn't exist yet, so I can just wait until I > can get a full scan, print out the entire log of proposed deletions, ok > them in my list, and then just run a diff against that list later to see > what changed, if anything. Glad you understand as it probably won't happen. > The other thing we were talking about last week is that delete orphans tries > to delete half links that are correct and that are missing the other side of > the link that sync all links should add. I attempted to address that w/ warning statements vice an expectation of delete. > The rest, you can quickly re-read the mail below to see if there is still > anything relevant. That was the email that I was staring at and I think most were addressed. But, again, some things may still have fallen through the cracks. > Thanks, > Marc > > On Fri, Jun 24, 2011 at 08:17:41AM -0400, Gregg Liming wrote: >> On 6/24/2011 1:58 AM, Marc MERLIN wrote: >> >>> This is also better: >>>> Running: PLM AUDIT - delete orphan links >>>> [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_blk1_1 because health: unknown. Please rescan this device!! >>>> [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_grey2_1 because health: unknown. Please rescan this device!! >>>> [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_blk1_1 because health: unknown. Please rescan this device!! >>>> [Insteon::ALDB_i1] Delete orphan links: skipping $gar_mos1 because health: unknown. Please rescan this device!! >>> >>> note, those 3 are remotelinks and motion sensor. >>> Are them being flagged as 'unknown' and 'please rescan' expected? >> >> No--I'll need to track them down so that the output isn't "clutter". >> But, obviously, that's all it is. So, ignoring is the appropriate >> policy in the near-term. > > Ok. > > This brings us to the orphan link audit. > I know we discussed this, and I realize it's both difficult to do now and will be pointless > once the code is bulletproof, but it would have been nice for me ot select some of those > log lines that I know are good deletes, feed them into some script and get them to be > acted upon. > (in other words, manually review/approve some deletes, and make them happen). > > But a lot more output like that: >> [Insteon::ALDB_i1] Delete orphan links: skipping $gar_mos1 because health: unknown. Please rescan this device!! >> [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_blk1_1 because health: unknown. Please rescan this device!! >> [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_blk1_1 because health: unknown. Please rescan this device!! >> [Insteon::ALDB_i1] Delete orphan links: skipping $rlink_grey2_1 because health: unknown. Please rescan this device!! >> [Insteon::ALDB_i1] Delete orphan links: skipping check for reciprocal links from $gar_mos1 because health: unknown. Please rescan this device!! >> [Insteon::ALDB_i1] Delete orphan links: skipping check for reciprocal links from $gar_mos1 because health: unknown. Please rescan this device!! >> [Insteon::ALDB_i1] Delete orphan links: skipping check for reciprocal links from $gar_mos1 because health: unknown. Please rescan this device!! >> [Insteon::ALDB_i1] Delete orphan links: skipping check for reciprocal links from $rlink_blk1_1 because health: unknown. Please rescan this device!! > > I think it's still doing the right thing, but > 1) health that was 'deaf' is now 'unknown', which is weird > 2) obviously I shouldn't be asked to rescan > > > I've then seen a few of these: >> [Insteon::ALDB_i1] (AUDIT) $PLM now deleting orphaned link w/ details: responder, deviceid=18d4ce, group=16, data=06 >> [Insteon::ALDB_i1] (AUDIT) $PLM now deleting orphaned link w/ details: responder, deviceid=18d4ce, group=16, data=06 >> [Insteon::ALDB_i1] (AUDIT) $PLM now deleting orphaned link w/ details: responder, deviceid=18d4ce, group=16, data=08 >> [Insteon::ALDB_i1] (AUDIT) $PLM now deleting orphaned link w/ details: responder, deviceid=18d4ce, group=18, data=04 > The deviceid is the PLM itself. This means I don't understand what the orphan is here or what's wrong with that link. > > Now, some more interesting ones: >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because duplicate found $garage1_neon_kpl address=0E90 >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because duplicate found $garage1_neon_kpl address=0F70 > -> ok, I'll buy that they're dupes > >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no PLM link defined to: responder=$fmr_kpl(18), data=04 > Left over cruft it seems, good > >> [Insteon::ALDB_i1] (AUDIT) Delete orphan responder link from $fmr_kpl to PLM because no SCENE_MEMBER entry could be found in items.mht for INSTEON_ICONTROLLER: $all_out_scene > > Very useful message (good job!) :) This was a correct fix. > >> [Insteon::ALDB_i1] (AUDIT) Delete orphan responder link from $fmr_kpl to PLM because no SCENE_MEMBER entry could be found in items.mht for INSTEON_ICONTROLLER: $fmr_lvr_scene_slow > > This one, I'm not sure about, fmr_kpl is part of $fmr_lvr_scene_slow: > > INSTEON_ICONTROLLER, 15, fmr_lvr_scene_slow, all_scenes > SCENE_MEMBER, fmr_kpl, fmr_lvr_scene_slow, 100%, 2s > SCENE_MEMBER, fmr_slav, fmr_lvr_scene_slow, 100%, 2s > SCENE_MEMBER, lvr_lamp, fmr_lvr_scene_slow, 100%, 2s > SCENE_MEMBER, lvr_kpl, fmr_lvr_scene_slow, 100%, 2s > SCENE_MEMBER, kitchen_kpl_fmr_all, fmr_lvr_scene_slow > SCENE_MEMBER, dining_kpl_fmr_all, fmr_lvr_scene_slow > SCENE_MEMBER, lvr_kpl_fmr_all, fmr_lvr_scene_slow > >> [Insteon::ALDB_i1] (AUDIT) $entryway now deleting orphaned link w/ details: responder, deviceid=0a3835, group=03 >> [Insteon::ALDB_i1] (AUDIT) $fmr_kpl now deleting orphaned link w/ details: responder, deviceid=0a3835, group=03 >> [Insteon::ALDB_i1] (AUDIT) $fmr_kpl now deleting orphaned link w/ details: responder, deviceid=0a3835, group=04 >> [Insteon::ALDB_i1] (AUDIT) $fmr_lamp now deleting orphaned link w/ details: responder, deviceid=0a3835, group=06 >> [Insteon::ALDB_i1] (AUDIT) $fmr_slav now deleting orphaned link w/ details: responder, deviceid=0a3835, group=05 >> [Insteon::ALDB_i1] (AUDIT) $lvr_kpl now deleting orphaned link w/ details: responder, deviceid=0a3835, group=01 >> [Insteon::ALDB_i1] (AUDIT) $lvr_kpl now deleting orphaned link w/ details: responder, deviceid=0a3835, group=05 >> [Insteon::ALDB_i1] (AUDIT) $lvr_lamp now deleting orphaned link w/ details: responder, deviceid=0a3835, group=02 > > That's an old remote I RMA'ed, good. > > Then these look like random corruption/garbage. It seems to confirm that the link layer's CRCs don't work in at least some cases (I verified the device IDs and I never had them). It's interesting to see a couple of links to 18d4xx where the 2 first bytes are my new PLM and the last byte is garbage. > >> [Insteon::ALDB_i1] (AUDIT) $kitchen_kpl now deleting orphaned link w/ details: responder, deviceid=000000, group=00 >> [Insteon::ALDB_i1] (AUDIT) $garage1_neon_kpl now deleting orphaned link w/ details: responder, deviceid=07d4ce, group=72 >> [Insteon::ALDB_i1] (AUDIT) $gar_outlights_kpl now deleting orphaned link w/ details: responder, deviceid=07d98b, group=04 >> [Insteon::ALDB_i1] (AUDIT) $kitchen_kpl now deleting orphaned link w/ details: controller, deviceid=07deee, group=07 >> [Insteon::ALDB_i1] (AUDIT) $garage2_neon_kpl now deleting orphaned link w/ details: controller, deviceid=07defb, group=05 >> [Insteon::ALDB_i1] (AUDIT) $gar_outlights_kpl now deleting orphaned link w/ details: controller, deviceid=09d412, group=01 >> [Insteon::ALDB_i1] (AUDIT) $lvr_kpl now deleting orphaned link w/ details: controller, deviceid=0e9e12, group=01 >> [Insteon::ALDB_i1] (AUDIT) $fmr_kpl now deleting orphaned link w/ details: controller, deviceid=0f2687, group=07 >> [Insteon::ALDB_i1] (AUDIT) $fmr_kpl now deleting orphaned link w/ details: controller, deviceid=0f2736, group=07 >> [Insteon::ALDB_i1] (AUDIT) $kitchen_kpl now deleting orphaned link w/ details: controller, deviceid=10d4ce, group=18 >> [Insteon::ALDB_i1] (AUDIT) $garage2_neon_kpl now deleting orphaned link w/ details: controller, deviceid=1818d4, group=18 >> [Insteon::ALDB_i1] (AUDIT) $kitchen_kpl now deleting orphaned link w/ details: controller, deviceid=18ce35, group=06 >> [Insteon::ALDB_i1] (AUDIT) $fmr_kpl now deleting orphaned link w/ details: responder, deviceid=18ce68, group=11 >> [Insteon::ALDB_i1] (AUDIT) $gar_outlights_kpl now deleting orphaned link w/ details: controller, deviceid=18cefb, group=03 >> [Insteon::ALDB_i1] (AUDIT) $dining_kpl now deleting orphaned link w/ details: responder, deviceid=18d412, group=55 >> [Insteon::ALDB_i1] (AUDIT) $iolinc_gardoor2 now deleting orphaned link w/ details: controller, deviceid=18d4d4, group=01 >> [Insteon::ALDB_i1] (AUDIT) $fmr_kpl now deleting orphaned link w/ details: controller, deviceid=d40fce, group=04 > > After that, we're left with these as the last messages >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $fmr_kpl(07) as controller and $garage2_neon_kpl(05) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $gar_outlights_kpl(01) as controller and $garage2_neon_kpl(05) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $gar_outlights_kpl(03) as controller and $garage2_neon_kpl(03) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $gar_outlights_kpl(03) as controller and $garage2_neon_kpl(e2) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $gar_outlights_kpl(06) as controller and $garage2_neon_kpl(06) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $gar_outlights_kpl(06) as controller and $yard_lights(01) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $garage1_neon_kpl(01) as controller and $garage2_neon_kpl(03) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $garage1_neon_kpl(04) as controller and $garage2_neon_kpl(01) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $garage1_neon_kpl(05) as controller and $garage2_neon_kpl(05) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $garage1_neon_kpl(06) as controller and $garage2_neon_kpl(06) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reciprocal link defined for: $kitchen_kpl(07) as controller and $garage2_neon_kpl(05) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $fmr_kpl(05) as responder and $kitchen_kpl(02) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $fmr_kpl(08) as responder and $garage2_neon_kpl(06) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $gar_outlights_kpl(01) as responder and $garage1_neon_kpl(03) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $gar_outlights_kpl(04) as responder and $garage2_neon_kpl(01) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $gar_outlights_kpl(06) as responder and $garage2_neon_kpl(06) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $garage1_neon_kpl(04) as responder and $garage2_neon_kpl(01) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $garage1_neon_kpl(06) as responder and $garage2_neon_kpl(06) >> [Insteon::ALDB_i1] (AUDIT) Delete orphan because no reverse link defined for: $kitchen_kpl(01) as responder and $fmr_kpl(04) > > Those are debatable. They are correct links, but their other half is missing somehow. > It's not a huge deal if delete orphan removes them and I resync both sides > later with a sync all links. > Is that something you'd like to fix, or is that working as intended? > > Thanks for your new code and reviewing all this. > Marc |
Re: [mh] Trying out the updated insteon branch -> scan all and
orphan deletes still not quite there.
From: Jim D. <ji...@du...> - 2011-06-23 23:49:13
|
On 06/22/2011 04:08 PM, Marc MERLIN wrote: > On Wed, Jun 22, 2011 at 04:01:16PM -0400, Gregg Liming wrote: >> >> Thanks for clarifying. Now, I do see it happily returning >> 026915--meaning the PLM's database is empty. I guess that makes sense >> if this is a brand new PLM--right? So, what would be better is >> appropriate feedback telling you that. This should be a relatively >> quick fix. But, shouldn't really impact any of the other issues. > > Oh, I see. > I thought I had synced a couple of things that would have made links > already, but maybe not. > > I guess I first have to go through all my devices and select 'link to plm', > but I don't yet have a good way to delete all the old PLM links without > running the orphan links code which will delete too much. Do we expect Links to the PLM to be reported properly? When I try, I get nothing. Example: 06/23/11 07:41:28 PM Running: garage door link to interface 06/23/11 07:42:00 PM: Saving object states ... done 06/23/11 07:42:04 PM Running: PLM show link table to log 06/23/11 07:42:18 PM Running: PLM messaging debug on 06/23/11 07:42:26 PM Running: PLM scan link table 06/23/11 07:42:26 PM [Insteon_PLM] DEBUG: Parsing serial data: 0269060257e2a40e763401092d 06/23/11 07:42:27 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a00e763401092d 06/23/11 07:42:27 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a10e763401092d 06/23/11 07:42:27 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a50e763401092d 06/23/11 07:42:27 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a20e763401092d 06/23/11 07:42:28 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a30e763401092d 06/23/11 07:42:28 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a41563fc020f36 06/23/11 07:42:28 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a51563fc020f36 06/23/11 07:42:28 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a61563fc020f36 06/23/11 07:42:29 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a71563fc020f36 06/23/11 07:42:29 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2061563fc000000 06/23/11 07:42:30 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2030e7634000000 06/23/11 07:42:30 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2040e7634000000 06/23/11 07:42:30 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2050e7634000000 06/23/11 07:42:30 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2060e7634000000 06/23/11 07:42:31 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2031563fc000000 06/23/11 07:42:31 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2041563fc000000 06/23/11 07:42:31 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2051563fc000000 06/23/11 07:42:31 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2011563fc000000 06/23/11 07:42:32 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2010e7634000000 06/23/11 07:42:33 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a15 06/23/11 07:43:00 PM: Saving object states ... done 06/23/11 07:44:00 PM: Saving object states ... done 06/23/11 07:44:06 PM Running: courtyard button D link to interface 06/23/11 07:44:40 PM Running: PLM show link table to log 06/23/11 07:45:00 PM: Saving object states ... done 06/23/11 07:45:29 PM Running: PLM scan link table 06/23/11 07:45:30 PM [Insteon_PLM] DEBUG: Parsing serial data: 0269060257e2a40e763401092d 06/23/11 07:45:30 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a00e763401092d 06/23/11 07:45:30 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a10e763401092d 06/23/11 07:45:30 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a50e763401092d 06/23/11 07:45:31 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a20e763401092d 06/23/11 07:45:31 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a30e763401092d 06/23/11 07:45:31 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a41563fc020f36 06/23/11 07:45:31 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a51563fc020f36 06/23/11 07:45:32 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a61563fc020f36 06/23/11 07:45:32 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257e2a71563fc020f36 06/23/11 07:45:32 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2061563fc000000 06/23/11 07:45:34 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2030e7634000000 06/23/11 07:45:35 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2040e7634000000 06/23/11 07:45:35 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2050e7634000000 06/23/11 07:45:35 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2060e7634000000 06/23/11 07:45:35 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2031563fc000000 06/23/11 07:45:36 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2041563fc000000 06/23/11 07:45:36 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2051563fc000000 06/23/11 07:45:36 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2011563fc000000 06/23/11 07:45:37 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a060257a2010e7634000000 06/23/11 07:45:37 PM [Insteon_PLM] DEBUG: Parsing serial data: 026a15 Thanks, Jim |
Re: [mh] Trying out the updated insteon branch -> scan all and
orphan deletes still not quite there.
From: Gregg L. <gr...@li...> - 2011-06-24 02:17:13
|
On 6/23/2011 7:48 PM, Jim Duda wrote: > On 06/22/2011 04:08 PM, Marc MERLIN wrote: >> On Wed, Jun 22, 2011 at 04:01:16PM -0400, Gregg Liming wrote: >>> >>> Thanks for clarifying. Now, I do see it happily returning >>> 026915--meaning the PLM's database is empty. I guess that makes sense >>> if this is a brand new PLM--right? So, what would be better is >>> appropriate feedback telling you that. This should be a relatively >>> quick fix. But, shouldn't really impact any of the other issues. >> >> Oh, I see. >> I thought I had synced a couple of things that would have made links >> already, but maybe not. >> >> I guess I first have to go through all my devices and select 'link to plm', >> but I don't yet have a good way to delete all the old PLM links without >> running the orphan links code which will delete too much. > > Do we expect Links to the PLM to be reported properly? > When I try, I get nothing. That's really odd as I always get the table displayed. Also, the "health" value is now first displayed. You're running the very latest from svn branch? Gregg |
Re: [mh] Trying out the updated insteon branch -> scan all and
orphan deletes still not quite there.
From: Jim D. <ji...@du...> - 2011-06-24 03:05:19
|
On 06/23/2011 10:17 PM, Gregg Liming wrote: > > That's really odd as I always get the table displayed. Also, the > "health" value is now first displayed. You're running the very latest > from svn branch? > I was at 1914, just updated to 1916 and picked up: U Insteon_PLM.pm U Insteon/AllLinkDatabase.pm Updated to revision 1916. I will try again tomorrow. Jim |