There may be some discussion of this on another post, but I could not find it after several searches, so here goes……

There is a general problem with macros that respond by sending an X10 signal. All of my macros are of this type (if receive Insteon, then send X10). I have found that I need at least a 1 second delay because the Insteon chatter (the back-and-forth communication that makes Insteon such a robust protocol) that follows a paddle press or any other signal generation will squash X10 transmissions. I can see this pretty clearly with my little Elk signal analyzer- the Insteon signals show up as a signal noise (many red bars), which is followed by the green led and a few red bars with the X10 gets sent. Without the delay, the X10 signal does not show up. If the device is linked to other devices, then I have to add about 1 second per link to get the macro to wait until the chatter is over. This works mostly, but it is not a reliable solution as other Insteon chatter can happen at any time, and the PLM just seems to send X10 regardless.

Note that the PLM device guide says it will wait for a pause in the signal noise before sending Insteon commands. So this is a nice feature for Insteon signals, and again, makes Insteon systems very robust. So the question is, why doesn’t the PLM wait for a silent gap before sending X10? My guess is that this is a problem with the PLM and not the EZServe/Bridge. At one point I thought I saw mention of a firmware update for the PLM- is that going to happen and will this problem get fixed? Can we update our older PLMs with new firmware?

Thanks!

Mitch