Announcement

Collapse
No announcement yet.

2477D seems to respond to commands, but doesn't turn light on/off

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    2477D seems to respond to commands, but doesn't turn light on/off

    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

    #2
    Do you have the Modem Developers Guide. That explains the commands and what is needed to properly control and receive the modules? Like responded and controller links in both the modules and the PLM? You may also have to consider the present I2SC {I2 with Check Sum} protocol. My play into some of this.

    Comment


      #3
      Thank you. Yes I found the INSTEON Modem Developer's Guide and the INSTEON Developers Guide, both from 2007. It is from those documents that I figured out how to send commands and interpret responses. I used the lab bench setup to test my software's ability to generate correct messages and to properly decode the replies. Everything appeared to work; I can turn the the lights on, off, dim, and brighten on all the dimmers plugged into the same power bar as the IM2314S. All the responses to IM commands seem to make sense as per the documents.

      My problem is that after moving two of the dimmers to another location, apparently on the same phase, I get the same software responses from the IM to my commands, including the '0x50' report in response to the '0x62' command - but the light connected to the 2477D dimmer doesn't change, and I do not get any unsolicited '0x50' reports from a dimmer that I control manually.

      In other words, the behaviour of the dimmer when co-located on the same power bar as the IM is different than when it is through some house wiring. If the target dimmer is able to cause the '0x50' report in response to a '0x62' command, why doesn't the light bulb change, and why do I not receive the unsolicited '0x50' reports when I manually turn the light on/off?

      I would look at connecting the range extender / phase bridge, although it appears that everything is on the same phase at the moment. I thought I would ask here before I start down that path.



      Comment


        #4
        I would check to make sure that your switch wire is a connected in the wire nut. Sometimes they fall out of not tightened properly.

        I would also check to ensure that the switch you replaced isn't a multiway switch. If it is, it could be wired to the secondary switch and not the actual primary

        Comment


          #5
          Power Bar?
          The PLM should not be on a power bar, if it has any type of AC noise filtering. It would probably effect the Insteon Power Line signals forcing you count on the Insteon RF signals getting back to the PLM. Other things like the AC input of an UPS or computing equipment power supplies can also effect the Insteon Power Line signals.

          Comment


            #6
            Good suggestions, thanks!

            Both lights did turn on/off from the dimmer switches, but I rechecked the wire connections anyway - look good. Both lights are single switch; I didn't want to attempt to wire any 3-ways until I got the simple circuits working.

            The power bar is actually an 8 outlet power strip attached to a work bench; it has an on/off switch, but no filter of any kind. The PC that I'm running the IDE/Debugger is physically nearby, behind a UPS, but not connected to the same circuit as the workbench power strip.

            In further testing last night, the lights were working. Absolutely nothing changed in the setup, so I'm thinking that I probably don't have enough devices to create a good network of repeaters. Perhaps my setup is marginal at the moment, may work sometimes, but not other times - depending on other AC or RF interference?.

            In the next week, I'll go nuts and replace more of the old X10 switches with Insteon. That would make 9 Insteon devices total + a range extended if I need it. I'm hoping that will eliminate the problem.

            I'm still puzzled though by how a 2477D can send a positive respond to a Standard Message command - indicating that a bi-directional message signal path is established, but not turn the light on/off. I tried sending a command to a device that was disconnected; the IM echoed the command and responded with ACK, but I didn't get the Receive Standard Message. This is exactly what I would expect if the device was out of range.

            After almost 20 years of putting up with X10 lights that worked 'most of the time', I hope I get more stable results from the Insteon switches, especially after the cost & time I spent to upgrade.

            Comment

            Working...
            X