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 |