From: Marc M. <ma...@me...> - 2011-05-14 05:44:57
|
Thanks to Gregg, I'm limping along on my slowly dying PLM. It now needs to be rebooted about daily after getting this: [Insteon_PLM] Button Pressed. Ignoring. which is typically when it stops working now. I'm going to have to replace my PLM, which means redoing about 130 links, which is a royal pita with the trunk svn code. So, for those on the svn branch, is it ready for switching if I'm hoping to use it to reconfigure all my links in the house? 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: Bill D. <dr...@dm...> - 2011-05-14 12:26:46
|
On 05/14/2011 01:44 AM, Marc MERLIN wrote: > Thanks to Gregg, I'm limping along on my slowly dying PLM. > It now needs to be rebooted about daily after getting this: > [Insteon_PLM] Button Pressed. Ignoring. > which is typically when it stops working now. Let me add my thanks to Gregg as well. I think it's been some months since Gregg added additional error handling to the trunk. That small change cleaned up almost all the odd errors I was getting. > I'm going to have to replace my PLM, which means redoing about 130 > links, which is a royal pita with the trunk svn code. I feel your pain. > So, for those on the svn branch, is it ready for switching if I'm hoping > to use it to reconfigure all my links in the house? I'm still on the trunk because of this very issue. Let us know if you are able to get past it. I'd love to switch to the branch as well. Thanks, Bill |
From: Eloy P. <pe...@ch...> - 2011-05-14 14:07:07
|
Hi Marc, On 05/14/2011 01:44 AM, Marc MERLIN wrote: > Thanks to Gregg, I'm limping along on my slowly dying PLM. > It now needs to be rebooted about daily after getting this: > [Insteon_PLM] Button Pressed. Ignoring. > which is typically when it stops working now. > > I'm going to have to replace my PLM, which means redoing about 130 > links, which is a royal pita with the trunk svn code. > > So, for those on the svn branch, is it ready for switching if I'm hoping > to use it to reconfigure all my links in the house? Nope, sorry, nothing has changed on the "insteon" branch in a while. I am running it and haven't experienced major problems (nightly link table scans are still getting stuck and not completing, but that is something minor for me). Link synchronization is something that is definitely not working :-( I don't have many devices and links so this is not a deal breaker for me. Cheers, Eloy Paris.- |
From: Gregg L. <gr...@li...> - 2011-05-18 14:15:52
|
> -----Original Message----- > From: Eloy Paris [mailto:pe...@ch...] > Hi Marc, > > On 05/14/2011 01:44 AM, Marc MERLIN wrote: > > > Thanks to Gregg, I'm limping along on my slowly dying PLM. > > It now needs to be rebooted about daily after getting this: > > [Insteon_PLM] Button Pressed. Ignoring. > > which is typically when it stops working now. > > > > I'm going to have to replace my PLM, which means redoing about 130 > > links, which is a royal pita with the trunk svn code. > > > > So, for those on the svn branch, is it ready for switching if I'm > hoping > > to use it to reconfigure all my links in the house? > > Nope, sorry, nothing has changed on the "insteon" branch in a while. I > am running it and haven't experienced major problems (nightly link > table > scans are still getting stuck and not completing, but that is something > minor for me). Eloy, if you get a chance, please send me a snippet of your log w/ full PLM debug on. > Link synchronization is something that is definitely not working :-( Yes--sorry, no joy as yet. |
From: Gregg L. <gr...@li...> - 2011-05-20 21:16:26
|
On 5/18/2011 9:59 AM, Gregg Liming wrote: >> -----Original Message----- >> From: Eloy Paris [mailto:pe...@ch...] > >> Hi Marc, >> >> On 05/14/2011 01:44 AM, Marc MERLIN wrote: >> >>> Thanks to Gregg, I'm limping along on my slowly dying PLM. >>> It now needs to be rebooted about daily after getting this: >>> [Insteon_PLM] Button Pressed. Ignoring. >>> which is typically when it stops working now. >>> >>> I'm going to have to replace my PLM, which means redoing about 130 >>> links, which is a royal pita with the trunk svn code. >>> >>> So, for those on the svn branch, is it ready for switching if I'm >> hoping >>> to use it to reconfigure all my links in the house? >> >> Nope, sorry, nothing has changed on the "insteon" branch in a while. I >> am running it and haven't experienced major problems (nightly link >> table >> scans are still getting stuck and not completing, but that is something >> minor for me). > > Eloy, if you get a chance, please send me a snippet of your log w/ full PLM > debug on. Actually, try updating to current branch. I just committed changes that should improve error detection and handling during scanning. |
From: Eloy P. <pe...@ch...> - 2011-05-23 15:39:18
|
On 05/20/2011 05:16 PM, Gregg Liming wrote: [...] >>> Nope, sorry, nothing has changed on the "insteon" branch in a while. I >>> am running it and haven't experienced major problems (nightly link >>> table >>> scans are still getting stuck and not completing, but that is something >>> minor for me). >> >> Eloy, if you get a chance, please send me a snippet of your log w/ full PLM >> debug on. > > Actually, try updating to current branch. I just committed changes that > should improve error detection and handling during scanning. Thanks Gregg; I'll be updating as soon as I get a chance. I'll also provide a log snippet showing a link table scan with full PLM debugging. Cheers, Eloy Paris.- |
From: Gregg L. <gr...@li...> - 2011-06-10 17:18:07
|
On 5/20/2011 5:16 PM, Gregg Liming wrote: > On 5/18/2011 9:59 AM, Gregg Liming wrote: >>> -----Original Message----- >>> From: Eloy Paris [mailto:pe...@ch...] >> >>> Hi Marc, >>> >>> On 05/14/2011 01:44 AM, Marc MERLIN wrote: >>> >>>> Thanks to Gregg, I'm limping along on my slowly dying PLM. >>>> It now needs to be rebooted about daily after getting this: >>>> [Insteon_PLM] Button Pressed. Ignoring. >>>> which is typically when it stops working now. >>>> >>>> I'm going to have to replace my PLM, which means redoing about 130 >>>> links, which is a royal pita with the trunk svn code. >>>> >>>> So, for those on the svn branch, is it ready for switching if I'm >>> hoping >>>> to use it to reconfigure all my links in the house? >>> >>> Nope, sorry, nothing has changed on the "insteon" branch in a while. I >>> am running it and haven't experienced major problems (nightly link >>> table >>> scans are still getting stuck and not completing, but that is something >>> minor for me). >> >> Eloy, if you get a chance, please send me a snippet of your log w/ full PLM >> debug on. > > Actually, try updating to current branch. I just committed changes that > should improve error detection and handling during scanning. And, I just posted a bunch of additional commits. There are a number of very notable issues addressed: 1) I realized that the inheritance order for SwitchLinc and KeypadLinc objects caused the restore_data to not work for those objects. That means the ALDB records get clobbered during reload. These usually are also the objects that often have the biggest ALDB records (especially KPLs). Obviously, problems with maintaining ALDB sync is a big deal as all of the link syncing and orphan management rely on accuracy. 2) I implemented an AUDIT mode for the "delete orphan links" function. This is pretty important if you value your existing (i.e., "working") links as I need to ensure that it is fully accurate before actually allowing the main function to go. If possible, I would appreciate any feedback on cases where this AUDIT mode does not report back what you expect. Definitely DO NOT use the non-AUDIT mode unless you like living on the edge. 3) Numerous (to many to mention) link management bugs. I managed to run the delete orphan links in AUDIT mode when it didn't fully implement full AUDIT. So, it clobbered a bunch of my devices. The good news is this forced me to get device-specific link syncing working. Don't assume that this means everything works--I am watching for corner cases. But, it did work enough for me. Definitely, DO NOT assume that the full sync links service works. It won't. Next, I'll be adding an AUDIT mode for sync links--both the full version and device specific version. This should allow people to gain confidence before allowing to work for real. I also need to address how to handle known "problem devices". These exist in two categories: a) those that are usually "deaf" (like motion sensors and remote control) and b) those that have "signal propagation" problems (usually due to home environment issues). Fortunately (well, not fortunate for me), I have both. So, this will be the next area of focus. Likely, I'll just "blindly" skip all of the category "a" devices for system-wide services (e.g., full sync links and delete orphan links) as you can't usually control the timing of when those devices begin listening. Then, you'd have to run an explicit (targeted) service for each problem device. I haven't quite decided on the "b" category; but, I may start tracking devices that routinely have requeue problems. Lastly, and before the question gets asked again... I still don't have an ETA on when this branch is ready for prime time use. But, it's getting close for people that don't mind peering over the edge but not living there. Gregg |
From: Matthew C. <dv...@gm...> - 2011-06-11 15:02:23
|
Augh Gregg, bad pun at the end there. Thanks sooo much for all your work, I just can't wait! Matt On Fri, Jun 10, 2011 at 10:18 AM, Gregg Liming <gr...@li...> wrote: > On 5/20/2011 5:16 PM, Gregg Liming wrote: >> On 5/18/2011 9:59 AM, Gregg Liming wrote: >>>> -----Original Message----- >>>> From: Eloy Paris [mailto:pe...@ch...] >>> >>>> Hi Marc, >>>> >>>> On 05/14/2011 01:44 AM, Marc MERLIN wrote: >>>> >>>>> Thanks to Gregg, I'm limping along on my slowly dying PLM. >>>>> It now needs to be rebooted about daily after getting this: >>>>> [Insteon_PLM] Button Pressed. Ignoring. >>>>> which is typically when it stops working now. >>>>> >>>>> I'm going to have to replace my PLM, which means redoing about 130 >>>>> links, which is a royal pita with the trunk svn code. >>>>> >>>>> So, for those on the svn branch, is it ready for switching if I'm >>>> hoping >>>>> to use it to reconfigure all my links in the house? >>>> >>>> Nope, sorry, nothing has changed on the "insteon" branch in a while. I >>>> am running it and haven't experienced major problems (nightly link >>>> table >>>> scans are still getting stuck and not completing, but that is something >>>> minor for me). >>> >>> Eloy, if you get a chance, please send me a snippet of your log w/ full PLM >>> debug on. >> >> Actually, try updating to current branch. I just committed changes that >> should improve error detection and handling during scanning. > > And, I just posted a bunch of additional commits. There are a number of > very notable issues addressed: > > 1) I realized that the inheritance order for SwitchLinc and KeypadLinc > objects caused the restore_data to not work for those objects. That > means the ALDB records get clobbered during reload. These usually are > also the objects that often have the biggest ALDB records (especially > KPLs). Obviously, problems with maintaining ALDB sync is a big deal as > all of the link syncing and orphan management rely on accuracy. > > 2) I implemented an AUDIT mode for the "delete orphan links" function. > This is pretty important if you value your existing (i.e., "working") > links as I need to ensure that it is fully accurate before actually > allowing the main function to go. If possible, I would appreciate any > feedback on cases where this AUDIT mode does not report back what you > expect. Definitely DO NOT use the non-AUDIT mode unless you like living > on the edge. > > 3) Numerous (to many to mention) link management bugs. I managed to run > the delete orphan links in AUDIT mode when it didn't fully implement > full AUDIT. So, it clobbered a bunch of my devices. The good news is > this forced me to get device-specific link syncing working. Don't > assume that this means everything works--I am watching for corner cases. > But, it did work enough for me. Definitely, DO NOT assume that the > full sync links service works. It won't. > > Next, I'll be adding an AUDIT mode for sync links--both the full version > and device specific version. This should allow people to gain > confidence before allowing to work for real. > > I also need to address how to handle known "problem devices". These > exist in two categories: a) those that are usually "deaf" (like motion > sensors and remote control) and b) those that have "signal propagation" > problems (usually due to home environment issues). Fortunately (well, > not fortunate for me), I have both. So, this will be the next area of > focus. Likely, I'll just "blindly" skip all of the category "a" devices > for system-wide services (e.g., full sync links and delete orphan links) > as you can't usually control the timing of when those devices begin > listening. Then, you'd have to run an explicit (targeted) service for > each problem device. I haven't quite decided on the "b" category; but, > I may start tracking devices that routinely have requeue problems. > > Lastly, and before the question gets asked again... I still don't have > an ETA on when this branch is ready for prime time use. But, it's > getting close for people that don't mind peering over the edge but not > living there. > > Gregg > > ------------------------------------------------------------------------------ > EditLive Enterprise is the world's most technically advanced content > authoring tool. Experience the power of Track Changes, Inline Image > Editing and ensure content is compliant with Accessibility Checking. > http://p.sf.net/sfu/ephox-dev2dev > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > > -- Matthew Campbell Storage Solution Consultant Storage Platform Engineering Management IT | Kaiser Permanente |
From: Eloy P. <pe...@ch...> - 2011-06-13 02:49:00
|
Hi Gregg, On 06/10/2011 01:18 PM, Gregg Liming wrote: > On 5/20/2011 5:16 PM, Gregg Liming wrote: [...] >> Actually, try updating to current branch. I just committed changes that >> should improve error detection and handling during scanning. > > And, I just posted a bunch of additional commits. There are a number of > very notable issues addressed: > > 1) I realized that the inheritance order for SwitchLinc and KeypadLinc > objects caused the restore_data to not work for those objects. That > means the ALDB records get clobbered during reload. These usually are > also the objects that often have the biggest ALDB records (especially > KPLs). Obviously, problems with maintaining ALDB sync is a big deal as > all of the link syncing and orphan management rely on accuracy. > > 2) I implemented an AUDIT mode for the "delete orphan links" function. > This is pretty important if you value your existing (i.e., "working") > links as I need to ensure that it is fully accurate before actually > allowing the main function to go. If possible, I would appreciate any > feedback on cases where this AUDIT mode does not report back what you > expect. Definitely DO NOT use the non-AUDIT mode unless you like living > on the edge. > > 3) Numerous (to many to mention) link management bugs. I managed to run > the delete orphan links in AUDIT mode when it didn't fully implement > full AUDIT. So, it clobbered a bunch of my devices. The good news is > this forced me to get device-specific link syncing working. Don't > assume that this means everything works--I am watching for corner cases. > But, it did work enough for me. Definitely, DO NOT assume that the > full sync links service works. It won't. > > Next, I'll be adding an AUDIT mode for sync links--both the full version > and device specific version. This should allow people to gain > confidence before allowing to work for real. > > I also need to address how to handle known "problem devices". These > exist in two categories: a) those that are usually "deaf" (like motion > sensors and remote control) and b) those that have "signal propagation" > problems (usually due to home environment issues). Fortunately (well, > not fortunate for me), I have both. So, this will be the next area of > focus. Likely, I'll just "blindly" skip all of the category "a" devices > for system-wide services (e.g., full sync links and delete orphan links) > as you can't usually control the timing of when those devices begin > listening. Then, you'd have to run an explicit (targeted) service for > each problem device. I haven't quite decided on the "b" category; but, > I may start tracking devices that routinely have requeue problems. > > Lastly, and before the question gets asked again... I still don't have > an ETA on when this branch is ready for prime time use. But, it's > getting close for people that don't mind peering over the edge but not > living there. I am finally running the latest code. I just upgraded so I don't have much feedback to provide yet. There is one minor issue that I ran into, though: I use the Tk interface and the ':' character has apparently some special meaning because when it is present in voice commands, the Tk interface breaks. Here's the message that I get on start up: ------------------------------------- Creating Frames Error found in user code file: /home/mrhouse/data/mh_temp.user_code (error_count 1) 06/12/11 09:17:16 PM: parent element "Insteon: plm audit" does not exist at /usr/lib/perl5/Tk.pm line 250. Error logged to: /home/mrhouse/data/error.log ------------------------------------- I know you don't use the Tk interface, which is why you didn't notice this issue before. I am running locally with the simple "fix" of removing the ':' from the voice command name: Index: Insteon.pm =================================================================== --- Insteon.pm (revision 1907) +++ Insteon.pm (working copy) @@ -274,7 +274,7 @@ $object_string .= &main::store_object_data($object_name_v, 'Voice_Cmd', 'Insteon', 'Insteon_item_commands'); push @_insteon_device, $object_name if $group eq '01'; # don't allow non-base items to participate } elsif ($object->isa('Insteon_PLM')) { - my $cmd_states = "complete linking as responder,cancel linking,delete link with PLM,scan link table,show link table to log,messaging debug on,messaging debug off,delete orphan links,AUDIT: delete orphan links,scan link tables"; + my $cmd_states = "complete linking as responder,cancel linking,delete link with PLM,scan link table,show link table to log,messaging debug on,messaging debug off,delete orphan links,AUDIT delete orphan links,scan link tables"; $object_string .= "$object_name_v = new Voice_Cmd '$command [$cmd_states]';\n"; $object_string .= "$object_name_v -> tie_event('$object_name->complete_linking_as_responder','complete linking as responder');\n\n"; $object_string .= "$object_name_v -> tie_event('$object_name->initiate_unlinking_as_controller','initiate unlinking');\n\n"; @@ -282,7 +282,7 @@ $object_string .= "$object_name_v -> tie_event('$object_name->log_alllink_table','show link table to log');\n\n"; $object_string .= "$object_name_v -> tie_event('$object_name->scan_link_table(\"" . '\$self->log_alllink_table' . "\")','scan link table');\n\n"; $object_string .= "$object_name_v -> tie_event('$object_name->delete_orphan_links','delete orphan links');\n\n"; - $object_string .= "$object_name_v -> tie_event('$object_name->delete_orphan_links(1)','AUDIT: delete orphan links');\n\n"; + $object_string .= "$object_name_v -> tie_event('$object_name->delete_orphan_links(1)','AUDIT delete orphan links');\n\n"; $object_string .= "$object_name_v -> tie_event('$object_name->debug(1)','messaging debug on');\n\n"; $object_string .= "$object_name_v -> tie_event('$object_name->debug(0)','messaging debug off');\n\n"; $object_string .= "$object_name_v -> tie_event('&Insteon::scan_all_linktables','scan link tables');\n\n"; Happy to commit this if you'd like. Cheers, Eloy Paris.- |
From: Gregg L. <gr...@li...> - 2011-06-13 11:54:55
|
On 6/12/2011 10:07 PM, Eloy Paris wrote: > I know you don't use the Tk interface, which is why you didn't notice > this issue before. > > I am running locally with the simple "fix" of removing the ':' from the > voice command name: Thank-you for catching that. It would be nice if there was some reasonable delimiter (I'm guessing a hyphen also breaks it), but leaving it blank is fine. Yes, please do commit unless you can think of and confirm an alternate delimiter that tk doesn't choke on. Gregg |
From: Eloy P. <pe...@ch...> - 2011-06-13 16:36:47
|
Hi Gregg, On 06/13/2011 07:54 AM, Gregg Liming wrote: > On 6/12/2011 10:07 PM, Eloy Paris wrote: > >> I know you don't use the Tk interface, which is why you didn't notice >> this issue before. >> >> I am running locally with the simple "fix" of removing the ':' from the >> voice command name: > > Thank-you for catching that. It would be nice if there was some > reasonable delimiter (I'm guessing a hyphen also breaks it), but leaving > it blank is fine. Yes, please do commit unless you can think of and > confirm an alternate delimiter that tk doesn't choke on. Using '-' as the delimiter does not cause any problems with the Tk interface so I've committed the change to replace ':' with '-'. Cheers, Eloy Paris.- |
From: Eloy P. <pe...@ch...> - 2011-06-14 19:24:46
|
Hi Gregg, On 06/12/2011 10:07 PM, Eloy Paris wrote: > On 06/10/2011 01:18 PM, Gregg Liming wrote: > >> And, I just posted a bunch of additional commits. There are a number of >> very notable issues addressed: >> >> 1) I realized that the inheritance order for SwitchLinc and KeypadLinc >> objects caused the restore_data to not work for those objects. That >> means the ALDB records get clobbered during reload. These usually are >> also the objects that often have the biggest ALDB records (especially >> KPLs). Obviously, problems with maintaining ALDB sync is a big deal as >> all of the link syncing and orphan management rely on accuracy. >> >> 2) I implemented an AUDIT mode for the "delete orphan links" function. >> This is pretty important if you value your existing (i.e., "working") >> links as I need to ensure that it is fully accurate before actually >> allowing the main function to go. If possible, I would appreciate any >> feedback on cases where this AUDIT mode does not report back what you >> expect. Definitely DO NOT use the non-AUDIT mode unless you like living >> on the edge. >> >> 3) Numerous (to many to mention) link management bugs. I managed to run >> the delete orphan links in AUDIT mode when it didn't fully implement >> full AUDIT. So, it clobbered a bunch of my devices. The good news is >> this forced me to get device-specific link syncing working. Don't >> assume that this means everything works--I am watching for corner cases. >> But, it did work enough for me. Definitely, DO NOT assume that the >> full sync links service works. It won't. >> >> Next, I'll be adding an AUDIT mode for sync links--both the full version >> and device specific version. This should allow people to gain >> confidence before allowing to work for real. >> >> I also need to address how to handle known "problem devices". These >> exist in two categories: a) those that are usually "deaf" (like motion >> sensors and remote control) and b) those that have "signal propagation" >> problems (usually due to home environment issues). Fortunately (well, >> not fortunate for me), I have both. So, this will be the next area of >> focus. Likely, I'll just "blindly" skip all of the category "a" devices >> for system-wide services (e.g., full sync links and delete orphan links) >> as you can't usually control the timing of when those devices begin >> listening. Then, you'd have to run an explicit (targeted) service for >> each problem device. I haven't quite decided on the "b" category; but, >> I may start tracking devices that routinely have requeue problems. >> >> Lastly, and before the question gets asked again... I still don't have >> an ETA on when this branch is ready for prime time use. But, it's >> getting close for people that don't mind peering over the edge but not >> living there. > > I am finally running the latest code. I just upgraded so I don't have > much feedback to provide yet. I think I found something that I don't believe I was experiencing before this last batch of updates. You may recall an exchange we had here in the list a few months ago regarding three switches that I have in a 3-way configuration. Back then I reported that when I switched from the trunk to the "insteon" branch, the internal state of all switches part of the n-way setup was maintained automatically without the need for any glue code. In other words, if I have one master switch and slaves switches 1 and 2, doing local control on say slave switch #1, would cause MH to update the state of master switch and slave switch #2 based on local control of slave switch #1. Today I realized that this is no longer the case: for example, if all switches are off, and I turn on the load using slave switch #1, the internal state of both master switch and slave #2 is still shown as "off". Any ideas on how to troubleshoot this? The only thing I see in the log is this: 06/14/11 03:06:42 PM [Insteon::BaseObject] $upstairs_hallway_slav2_light::set(on, $upstairs_hallway_slav2_light) After this, the state of the other switches remains as "off". Cheers, Eloy Paris.- |
From: Gregg L. <gr...@li...> - 2011-06-14 19:56:25
|
On 6/14/2011 3:24 PM, Eloy Paris wrote: > Hi Gregg, > > On 06/12/2011 10:07 PM, Eloy Paris wrote: > >> On 06/10/2011 01:18 PM, Gregg Liming wrote: >> >>> And, I just posted a bunch of additional commits. There are a number of >>> very notable issues addressed: >>> >>> 1) I realized that the inheritance order for SwitchLinc and KeypadLinc >>> objects caused the restore_data to not work for those objects. That >>> means the ALDB records get clobbered during reload. These usually are >>> also the objects that often have the biggest ALDB records (especially >>> KPLs). Obviously, problems with maintaining ALDB sync is a big deal as >>> all of the link syncing and orphan management rely on accuracy. >>> >>> 2) I implemented an AUDIT mode for the "delete orphan links" function. >>> This is pretty important if you value your existing (i.e., "working") >>> links as I need to ensure that it is fully accurate before actually >>> allowing the main function to go. If possible, I would appreciate any >>> feedback on cases where this AUDIT mode does not report back what you >>> expect. Definitely DO NOT use the non-AUDIT mode unless you like living >>> on the edge. >>> >>> 3) Numerous (to many to mention) link management bugs. I managed to run >>> the delete orphan links in AUDIT mode when it didn't fully implement >>> full AUDIT. So, it clobbered a bunch of my devices. The good news is >>> this forced me to get device-specific link syncing working. Don't >>> assume that this means everything works--I am watching for corner cases. >>> But, it did work enough for me. Definitely, DO NOT assume that the >>> full sync links service works. It won't. >>> >>> Next, I'll be adding an AUDIT mode for sync links--both the full version >>> and device specific version. This should allow people to gain >>> confidence before allowing to work for real. >>> >>> I also need to address how to handle known "problem devices". These >>> exist in two categories: a) those that are usually "deaf" (like motion >>> sensors and remote control) and b) those that have "signal propagation" >>> problems (usually due to home environment issues). Fortunately (well, >>> not fortunate for me), I have both. So, this will be the next area of >>> focus. Likely, I'll just "blindly" skip all of the category "a" devices >>> for system-wide services (e.g., full sync links and delete orphan links) >>> as you can't usually control the timing of when those devices begin >>> listening. Then, you'd have to run an explicit (targeted) service for >>> each problem device. I haven't quite decided on the "b" category; but, >>> I may start tracking devices that routinely have requeue problems. >>> >>> Lastly, and before the question gets asked again... I still don't have >>> an ETA on when this branch is ready for prime time use. But, it's >>> getting close for people that don't mind peering over the edge but not >>> living there. >> >> I am finally running the latest code. I just upgraded so I don't have >> much feedback to provide yet. > > I think I found something that I don't believe I was experiencing before > this last batch of updates. You may recall an exchange we had here in > the list a few months ago regarding three switches that I have in a > 3-way configuration. > > Back then I reported that when I switched from the trunk to the > "insteon" branch, the internal state of all switches part of the n-way > setup was maintained automatically without the need for any glue code. > In other words, if I have one master switch and slaves switches 1 and 2, > doing local control on say slave switch #1, would cause MH to update the > state of master switch and slave switch #2 based on local control of > slave switch #1. > > Today I realized that this is no longer the case: for example, if all > switches are off, and I turn on the load using slave switch #1, the > internal state of both master switch and slave #2 is still shown as "off". > > Any ideas on how to troubleshoot this? The only thing I see in the log > is this: > > 06/14/11 03:06:42 PM [Insteon::BaseObject] > $upstairs_hallway_slav2_light::set(on, $upstairs_hallway_slav2_light) > > After this, the state of the other switches remains as "off". It is possible (likely, actually) that the change in inheritance order impacted this. So, I'm now explicitly identifying the class method that applies for SwitchLinc and SwitchLincRelay items. Can you svn update and see if this addresses the issue? Gregg |
From: Eloy P. <pe...@ch...> - 2011-06-14 20:29:42
|
On 06/14/2011 03:56 PM, Gregg Liming wrote: > On 6/14/2011 3:24 PM, Eloy Paris wrote: >> >> I think I found something that I don't believe I was experiencing before >> this last batch of updates. You may recall an exchange we had here in >> the list a few months ago regarding three switches that I have in a >> 3-way configuration. >> >> Back then I reported that when I switched from the trunk to the >> "insteon" branch, the internal state of all switches part of the n-way >> setup was maintained automatically without the need for any glue code. >> In other words, if I have one master switch and slaves switches 1 and 2, >> doing local control on say slave switch #1, would cause MH to update the >> state of master switch and slave switch #2 based on local control of >> slave switch #1. >> >> Today I realized that this is no longer the case: for example, if all >> switches are off, and I turn on the load using slave switch #1, the >> internal state of both master switch and slave #2 is still shown as "off". >> >> Any ideas on how to troubleshoot this? The only thing I see in the log >> is this: >> >> 06/14/11 03:06:42 PM [Insteon::BaseObject] >> $upstairs_hallway_slav2_light::set(on, $upstairs_hallway_slav2_light) >> >> After this, the state of the other switches remains as "off". > > It is possible (likely, actually) that the change in inheritance order > impacted this. So, I'm now explicitly identifying the class method that > applies for SwitchLinc and SwitchLincRelay items. Can you svn update > and see if this addresses the issue? Genius; that fixed it! Thanks a bunch. There's still the (hopefully known by you) "issue" of state being tracked as "on" and "100%", but that has nothing to do with the recent changes and is easily worked around with user code like: # Workaround possibility of light state being 100% instead # of 'on'. my ($light_state_now, $light_state); $light_state_now = state_now $upstairs_hallway_mast_light; $light_state_now = ON if $light_state_now eq '100%'; $light_state = state $upstairs_hallway_mast_light; $light_state = ON if $light_state eq '100%'; Thanks for the ultra quick fix, Gregg. Cheers, Eloy Paris.- |
From: Gregg L. <gr...@li...> - 2011-06-14 20:43:46
|
On 6/14/2011 4:29 PM, Eloy Paris wrote: > There's still the (hopefully known by you) "issue" of state being > tracked as "on" and "100%" Are you referring to items that are either SwitchLincRelay or KepPadLincRelay? If so, can you clarify a use case so that I can hopefully track down how it is getting set? If they are not of the *Relay item type, then forcing state consistency as you want isn't reasonable (since they're dimmable). Gregg |
From: Gregg L. <gr...@li...> - 2011-06-15 03:06:03
|
On 6/14/2011 5:17 PM, Eloy Paris wrote: > Hi Gregg, > > On 06/14/2011 04:43 PM, Gregg Liming wrote: > >> On 6/14/2011 4:29 PM, Eloy Paris wrote: >> >>> There's still the (hopefully known by you) "issue" of state being >>> tracked as "on" and "100%" >> >> Are you referring to items that are either SwitchLincRelay or >> KepPadLincRelay? If so, can you clarify a use case so that I can >> hopefully track down how it is getting set? >> >> If they are not of the *Relay item type, then forcing state consistency >> as you want isn't reasonable (since they're dimmable). > > I see this on SwitchLincRelay objects. The use case involves the same > 3-way setup I've mentioned before: in the initial state all switches are > in the "off" state. When I locally turn on slave switch #1, the new > state for the three devices is as follows: > > master: 100% > slave #1: on > slave #2: 100% > When you get a chance, please svn update and see if the changes help you here. Gregg |
From: Eloy P. <pe...@ch...> - 2011-06-15 03:58:44
|
On 06/14/2011 11:05 PM, Gregg Liming wrote: > On 6/14/2011 5:17 PM, Eloy Paris wrote: >> Hi Gregg, >> >> On 06/14/2011 04:43 PM, Gregg Liming wrote: >> >>> On 6/14/2011 4:29 PM, Eloy Paris wrote: >>> >>>> There's still the (hopefully known by you) "issue" of state being >>>> tracked as "on" and "100%" >>> >>> Are you referring to items that are either SwitchLincRelay or >>> KepPadLincRelay? If so, can you clarify a use case so that I can >>> hopefully track down how it is getting set? >>> >>> If they are not of the *Relay item type, then forcing state consistency >>> as you want isn't reasonable (since they're dimmable). >> >> I see this on SwitchLincRelay objects. The use case involves the same >> 3-way setup I've mentioned before: in the initial state all switches are >> in the "off" state. When I locally turn on slave switch #1, the new >> state for the three devices is as follows: >> >> master: 100% >> slave #1: on >> slave #2: 100% >> > > When you get a chance, please svn update and see if the changes help you > here. It's magic; it works! :-) Now I just see either 'on' or 'off', never a percentage. Beautiful. You're a rock star; thanks for the quick fix. I'm on my way to commenting out the user code I was using to work around the different "on" states. Cheers, Eloy Paris.- |
From: Eloy P. <pe...@ch...> - 2011-06-14 21:17:44
|
Hi Gregg, On 06/14/2011 04:43 PM, Gregg Liming wrote: > On 6/14/2011 4:29 PM, Eloy Paris wrote: > >> There's still the (hopefully known by you) "issue" of state being >> tracked as "on" and "100%" > > Are you referring to items that are either SwitchLincRelay or > KepPadLincRelay? If so, can you clarify a use case so that I can > hopefully track down how it is getting set? > > If they are not of the *Relay item type, then forcing state consistency > as you want isn't reasonable (since they're dimmable). I see this on SwitchLincRelay objects. The use case involves the same 3-way setup I've mentioned before: in the initial state all switches are in the "off" state. When I locally turn on slave switch #1, the new state for the three devices is as follows: master: 100% slave #1: on slave #2: 100% The original discussion we had on this in January is archived here: http://old.nabble.com/'on'-versus-'100-'-and-'off'-versus-'0-'-td30789454.html Cheers, Eloy Paris.- |
From: Eloy P. <pe...@ch...> - 2011-06-14 21:28:23
|
On 06/14/2011 05:17 PM, Eloy Paris wrote: [...] > I see this on SwitchLincRelay objects. The use case involves the same > 3-way setup I've mentioned before: in the initial state all switches are > in the "off" state. When I locally turn on slave switch #1, the new > state for the three devices is as follows: > > master: 100% > slave #1: on > slave #2: 100% > > The original discussion we had on this in January is archived here: > > http://old.nabble.com/'on'-versus-'100-'-and-'off'-versus-'0-'-td30789454.html I also have a PLM scene to set the state of all the switches in this 3-way setup. When I use the scene to turn on these switches the state of all of them goes to "100%". Cheers, Eloy Paris.- |
From: Gregg L. <gr...@li...> - 2011-05-20 17:04:13
|
On 5/20/2011 12:46 AM, Marc MERLIN wrote: > On Wed, May 18, 2011 at 09:59:22AM -0400, Gregg Liming wrote: >>> Link synchronization is something that is definitely not working :-( >> >> Yes--sorry, no joy as yet. > > Without asking you for any commitment, do you have some idea on how far off > that is? > - is it written but not working for some reason? > - is it only partially written? > - is it missing entirely? > > This is just to have an idea if and when I can think about switching and > whether I may be able to contribute a bit or if I'd have to invest a > significant amount of time first. If you need link management, I would stick with trunk. |
From: Marc M. <ma...@me...> - 2011-06-05 00:37:23
|
On Fri, May 20, 2011 at 01:04:08PM -0400, Gregg Liming wrote: > On 5/20/2011 12:46 AM, Marc MERLIN wrote: > > On Wed, May 18, 2011 at 09:59:22AM -0400, Gregg Liming wrote: > >>> Link synchronization is something that is definitely not working :-( > >> > >> Yes--sorry, no joy as yet. > > > > Without asking you for any commitment, do you have some idea on how far off > > that is? > > - is it written but not working for some reason? > > - is it only partially written? > > - is it missing entirely? > > > > This is just to have an idea if and when I can think about switching and > > whether I may be able to contribute a bit or if I'd have to invest a > > significant amount of time first. > > If you need link management, I would stick with trunk. Hopefully this doesn't make me sound insistent, but my PLM is apparently dying faster now. My 1-wire hub seems to have to reset it every other day or so. I'm going to have to order a new one and swap it soon. Maybe I can hold off another month, but not much longer. I'm not really looking forward to remaking 100+ links with the old code, but obviously I'll do what's needed. If I hang on a bit longer, am I likely to be able to use the new branch to rebuild my insteon network, or there is just too much code missing still? Out of curiosity, if you add a device to your house, do you manually link it, or do you switch to the old code for linking and then back to the new code for runtime? 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-05 02:19:37
|
On 6/4/2011 4:39 PM, Marc MERLIN wrote: > On Fri, May 20, 2011 at 01:04:08PM -0400, Gregg Liming wrote: >> On 5/20/2011 12:46 AM, Marc MERLIN wrote: >>> On Wed, May 18, 2011 at 09:59:22AM -0400, Gregg Liming wrote: >>>>> Link synchronization is something that is definitely not working :-( >>>> >>>> Yes--sorry, no joy as yet. >>> >>> Without asking you for any commitment, do you have some idea on how far off >>> that is? >>> - is it written but not working for some reason? >>> - is it only partially written? >>> - is it missing entirely? >>> >>> This is just to have an idea if and when I can think about switching and >>> whether I may be able to contribute a bit or if I'd have to invest a >>> significant amount of time first. >> >> If you need link management, I would stick with trunk. > > Hopefully this doesn't make me sound insistent, but my PLM is apparently > dying faster now. My 1-wire hub seems to have to reset it every other > day or so. > > I'm going to have to order a new one and swap it soon. Maybe I can hold > off another month, but not much longer. > I'm not really looking forward to remaking 100+ links with the old code, > but obviously I'll do what's needed. > > If I hang on a bit longer, am I likely to be able to use the new branch > to rebuild my insteon network, or there is just too much code missing > still? It's not necessarily the absence of code since I'm reusing/refactoring some of the original. It's more a case of making it work properly. So, it's hard to estimate. I also obviously am not devoting enough time to get it completed quickly. That probably isn't going to change soon. I'm sorry about that. > Out of curiosity, if you add a device to your house, do you manually > link it, or do you switch to the old code for linking and then back > to the new code for runtime? If I were to add one, then I'd manually link it unless I need to worry about dim levels. That's just too much of a pain. Fortunately (or perhaps unfortunately for everyone else), I haven't had any new devices for quite a while. If I were to switch back to the old code, I'd try to make sure that it was just done once. FWIW: I'll likely get some of the "scene at a time" (call it "semi-manual) linking done first. That would make your 100+ links still overly manual; but, would certainly handle the single additions. Gregg |
From: Marc M. <ma...@me...> - 2011-05-20 04:46:43
|
On Wed, May 18, 2011 at 09:59:22AM -0400, Gregg Liming wrote: > > Link synchronization is something that is definitely not working :-( > > Yes--sorry, no joy as yet. Without asking you for any commitment, do you have some idea on how far off that is? - is it written but not working for some reason? - is it only partially written? - is it missing entirely? This is just to have an idea if and when I can think about switching and whether I may be able to contribute a bit or if I'd have to invest a significant amount of time first. 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/ |