From: Steve S. <st...@sw...> - 2013-09-27 06:11:49
|
Awesome! Thank you! I merged your commit into my branch, and guess what? 09/27/13 02:02:41 AM [Scan all link tables] All tables have completed scanning I don't quite understand what you did, but this is a great step! It appears that in my network, there's a (similar?) issue with sync. Here's a small snippet of what happened, and I'll email you directly with the full log: 09/27/13 02:03:01 AM [Insteon_PLM] DEBUG3: Received PLM acknowledge: obj=$fl_kitchen_light; command=status_request 09/27/13 02:03:01 AM [Insteon_PLM] DEBUG3: Received PLM raw data: 025021cc1e223ea7211400 09/27/13 02:03:01 AM [Insteon_PLM] DEBUG4: PLM Command: (0250) insteon_received From Address: 21:cc:1e To Address: 22:3e:a7 Message Flags: 21 Message Type: (001) ACK of Direct Message Message Length: (0) Standard Length Hops Left: 0 Max Hops: 1 Insteon Message: 1400 Cmd 1: (14) Light OFF Fast Cmd 2: 00 09/27/13 02:03:01 AM [Insteon::BaseInterface] DEBUG3: PLM command:insteon_received; Device command:off_fast; type:direct; group: 09/27/13 02:03:01 AM [Insteon::BaseObject] DEBUG3: Adding hop count of 1 to hop_array of $fl_kitchen_light 09/27/13 02:03:01 AM [Insteon::BaseObject] received status for $fl_kitchen_light with on-level: 0%, hops left: 0 09/27/13 02:03:01 AM [Insteon::BaseObject] The link table for $fl_kitchen_light is in sync. 09/27/13 02:03:01 AM [Insteon::AllLinkDatabase] WARN: attempt to add link to $fl_kitchen_light that already exists! object=$PLM, group=11, is_controller=0 09/27/13 02:03:01 AM [Sync all links] Now syncing: $s_kit_fanlow (17 of 117) 09/27/13 02:03:01 AM [Insteon::BaseController] DEBUG4: queuing add for responder record to $fl_kitchen_light for $PLM with group:12; on_level:30%; ramp_rate:0 09/27/13 02:03:01 AM [Insteon::BaseInterface] Attempt to queue command already in queue; skipping ... 09/27/13 02:04:00 AM: Saving object states ... done 09/27/13 02:05:00 AM: Saving object states ... done I'd appreciate some insight into this one as well. Have a great night. Best regards, Steve Switzer --- Get world-class business I.T. services and a phone system with awesome features that won't challenge your budget! http://www.SwitzerBusinessSolutions.com On 09/26/2013 10:14 PM, Kevin Robert Keegan wrote: > I pushed a fix, I will give it a few days to make sure it doesn't > break anything else. > > In the interim you can either checkout my running branch or merge in > the fix_issue_258 into whatever branch you are working on. > > Kevin > > > On Thu, Sep 26, 2013 at 5:18 PM, Steve Switzer <st...@sw... > <mailto:st...@sw...>> wrote: > > I was REALLY trying to get it fixed myself, but it appears that > there's > more pieces to the puzzle than I currently understand. I'd love to > talk > through it sometime so I can understand it better. > > I have created a running branch in my fork, which I have updated with > all the changes I wanted in it. This should make it easier for me > moving > forward, but I think I have to understand resolving merge conflicts a > little better. If you could create a pull request of your changes > to my > branch, that'd be AWESOME. > > Thank you! > > Best regards, > Steve Switzer > > --- > Get world-class business I.T. services and a phone system with > awesome features that won't challenge your budget! > http://www.SwitzerBusinessSolutions.com > > On 09/26/2013 03:51 PM, Kevin Robert Keegan wrote: > > I agree it isn't going to be that hard to fix, the diagnosis was > much > > worse than the cure. I think I already know the solution in my > head, > > but it will require tweaking the ALDB_i2 Link parser. > > > > Making the duplicate window longer will provide a temporary > band-aid, > > but the link parser shouldn't crash if it is given bad data. Also, > > making the duplicate window longer may result in valid messages > being > > ignored. > > |