I have a home-brew automation system that used X10 for lighting control; now I'm finally ( long overdue ) porting to Insteon. I bought a 2314S modem (IM), a bunch of 2477D wall switch dimmers, a 2475SDB Relay, and a plug-in range extender. My host controller is based on an Atmel Mega128 with my own software. I set-up on the bench with the IM and 3 dimmers connected to the same plain-old power bar ( no surge protection or filter ). I did the All-LINK procedure, and I was able to control the dimmers from my software.
I observe that when I send a '0x62' command with the target address, I see the command echoed, followed by an ACK, and then followed by a '0x50' report. If I manually turn a dimmer switch on or off I get a series of 3 unsolicited '0x50' reports with different 'to address' and message flags. All is good, happy so far.
I moved two of the dimmers to their intended location, replacing the X10 modules. I did the Phase Detection Mode procedure, and both dimmers were blinking red; this means same phase, right?
Then, when I send a '0x62' command to the IM, I get the same response that I did on the bench, but the light connected to the dimmer does not turn on or off. I use the manual switch to turn the light on/off, the light changes, but I do not get the unsolicited '0x50' reports from the IM. The remaining dimmer that is still on the bench continues to behave as I first observed.
So, my question... If I assume that the '0x50' reports originate in the actual dimmer. What can make the dimmer respond to the command, but not actually control the attached light?
Here's what a '0x62' command and a '0x50' response looks like...
[0] 0x02 Start
[1] 0x62 Send Std Message
[2] 0x52 Dimmer address
[3] 0x6f ..
[4] 0x69 ..
[5] 0x0a Hops
[6] 0x11 ON
[7] 0xff Full on
[8] 0x06 ACK
[9] 0x02 Start
[10] 0x50 Receive Std Message
[11] 0x52 Dimmer Address
[12] 0x6f ..
[13] 0x69 ..
[14] 0x51 IM Address
[15] 0x11 ..
[16] 0x0b ..
[17] 0x2a ACK?
[18] 0x11 ON
[19] 0xff Full on
I observe that when I send a '0x62' command with the target address, I see the command echoed, followed by an ACK, and then followed by a '0x50' report. If I manually turn a dimmer switch on or off I get a series of 3 unsolicited '0x50' reports with different 'to address' and message flags. All is good, happy so far.
I moved two of the dimmers to their intended location, replacing the X10 modules. I did the Phase Detection Mode procedure, and both dimmers were blinking red; this means same phase, right?
Then, when I send a '0x62' command to the IM, I get the same response that I did on the bench, but the light connected to the dimmer does not turn on or off. I use the manual switch to turn the light on/off, the light changes, but I do not get the unsolicited '0x50' reports from the IM. The remaining dimmer that is still on the bench continues to behave as I first observed.
So, my question... If I assume that the '0x50' reports originate in the actual dimmer. What can make the dimmer respond to the command, but not actually control the attached light?
Here's what a '0x62' command and a '0x50' response looks like...
[0] 0x02 Start
[1] 0x62 Send Std Message
[2] 0x52 Dimmer address
[3] 0x6f ..
[4] 0x69 ..
[5] 0x0a Hops
[6] 0x11 ON
[7] 0xff Full on
[8] 0x06 ACK
[9] 0x02 Start
[10] 0x50 Receive Std Message
[11] 0x52 Dimmer Address
[12] 0x6f ..
[13] 0x69 ..
[14] 0x51 IM Address
[15] 0x11 ..
[16] 0x0b ..
[17] 0x2a ACK?
[18] 0x11 ON
[19] 0xff Full on
Comment