From: Eloy P. <pe...@ch...> - 2013-05-05 17:27:51
|
Hi Kevin, On 05/04/2013 10:30 PM, Kevin Robert Keegan wrote: > Wow, thank you Eloy. Sorry I was out in the backyard painting a wall. > Well done on the diagnosis, that was a tremendous help. I realize > that was a lot of work and time to spend on the issue, but we all > appreciate it. Nah, it was nothing. Besides, it was on my interest to get to the bottom of this -- with that In-LineLinc up there, with no easy access, I really needed to make sure that I understand what works, what doesn't, and why (and how to fix it using the manual PLM commands that you showed me). Putting that In-LineLinc there, plus the new fan, has been a lot of work anyway because I needed to run a new cable to carry electricity to that location. So, having to battle a little bit with the INSTEON part of it, wasn't a big deal. I just wish the INSTEON support guys had been a little more helpful -- they saw the ALDB entries for both devices and the answer was there, i.e. d3:0 instead of d3:1, but no, they just skimmed through it, probably very biased because I did not create the link manually and because the link was not created by their own software, and said "the link table entries look fine". Needless to say, that d3:0 in a responder record fails to control an i2CS device could be a new thing since responder records created by MH for non-i2CS devices have d3:0 too and they can be controlled with no problems. Cheers, Eloy Paris.- > On Sat, May 4, 2013 at 5:00 PM, Eloy Paris <pe...@ch... > <mailto:pe...@ch...>> wrote: > > On 05/04/2013 05:19 PM, Eloy Paris wrote: > > [...] > > >> The only difference is d3 in the responder link. Could that > explain the > >> behavior? I can manually change it from 00 to 01, if you would > like me > >> to experiment, but I'd need the PLM command to send. > > > > I figured out the command, and after executing it, I get: > > > > In-LineLinc: [Insteon::AllLinkDatabase] [0x0fe7] rspndr(01) record to > > $front_porch_light (03): onlevel=on and ramp=none (d3:01) > > > > ($front_porch_light is the KPL) > > > > Now with d3:01, instead of the d3:00 that MH is putting, the KPL does > > control the In-LineLinc. Hurray! > > > > I'll be putting everything back together and burying alive again the > > In-LineLinc, but now that we've determined the correct ALDB > entries for > > things to work I should be able to help with further testing if > anyone > > has an idea on how to fix the electronic link sync (I'll create a > Github > > issue to track this). > > Github issue: > > https://github.com/hollie/misterhouse/issues/176 > > And a final update: the controller record that MH is putting in, even if > d3 is different than what manual linking produces, is not a problem. The > issue is the value of d3 in the responder record -- d3:00 causes the > In-LineLinc to not react to on commands; d3:01 causes the In-LineLinc to > react. I confirmed by manually changing the value with direct PLM > commands via PLMTerminal.pl. > > Cheers, > > Eloy Paris.- > |