Insteon Trigger with X10 Action - PLM Timing Issue?

[IndyMike]

The following is a FYI. I believe this is a PLM timing issue rather than a ISY programming issue. I apologize if it has been previously reported.

 

Here's the summary -

• 
  X10 triggers followed by X10 actions work well.
  X10 triggers followed by Insteon commands work well.
  Insteon triggers followed by a X10 action must be separated by a wait period. Not doing so will produce an unintelligent House/Unit code.
  

 

Here's the long version -

 

I recently found that one of my "Insteon Triggered" X10 actions was not functioning properly. I added a controlinc to control my X10 floodlamps. The Insteon command from my controlinc triggeres an X10 action in the ISY. This command is received by my X10 CM15a which activates a X10 macro. I noticed that I could no longer activate my X10 devices with the KPL.

 

My Insteon devices queried 100% and all of my other X10 devices appeared to be functioning normally.

 

As usual, I suspected a X10 noise or signal absorber first - out come the X10 troubleshooting tools (ELK ESM1, Testerlinc, and the CM15a activity monitor).

 

Here's what I found -

 

 

Insteon triggered X10 event - doesn't work

If
       Control 'Controlinc Floods 00.79.0A.5' is switched Off

Then
       Send X10 'G6/Off (11)'

Else
  - No Actions - (To add one, press 'Action')

 

Transmission in response to the above trigger (Checked with my CM15a Activity Monitor and Testerlinc):

Receive G6 ON

 

The problem with the above is there is no Address/Housecode preceding the "G6 On" command (required by X10 devices).

 

In contrast, X10 Triggered commands followed by X10 actions work flawlessly -

 

If
       X10 'A12/On (3)' is Received

Then
       Send X10 'B3/On (3)'

Else
  - No Actions - (To add one, press 'Action')

 

X10 Transmission from the PLM-

Receive B3
Receive B ON

 

In comparing the activity between the two actions above, I noticed that my Testerlinc registered a lot of "Bad start code" and "bad blocks" during the execution of the Insteon triggered command. The testerlinc normally registers some of these codes during transmission of Insteon commands (misinterpreting Insteon activity for X10). The issue with the Insteon triggered X10 commands was that the was a LOT of bad code activity for several seconds. Very suspicious...

 

Trigger Modification-

If
       Control 'Controlinc Floods 00.79.0A.5' is switched Off

Then
       WAIT 1 SECOND  (SORRY DON'T KNOW HOW TO BOLD THIS)
       Send X10 'G6/Off (11)'

Else
  - No Actions - (To add one, press 'Action')

 

So simple...

 

From the above I would infer that the PLM is "tailgating" the X10 command too soon after receiving the Insteon transmission. X10 devices look for a gap between transmissions (protocol requires 3 cycles but many devices operate with less). The PLM is stacking transmission too closely and X10 devices are not able to distinguish the information from the previously transmitted Insteon.

 

Hope this helps. Had me going for a bit.

 

IM

 

Almost forgot - PLM firmware 5.2, ISY version 2.6

[Mark Sanctuary]

Dude you may have just help me figure out my X10 issue. Thanks!

[yardman 49]

Hello Mike:

 

You are 100% correct! I had used this same solution some time back for a similar situation. The group cleanup commands that Insteon utilizes will "step on" an X10 command that is issued immediately after an Insteon command. The wait period helps eliminate the conflict.

 

**********************************

 

Not only this, but I always issue duplicate or triplicate X10 commands with wait periods in my ISY programs. The reason for this is that my X10 signals in some parts of my network have become unreliable due the the large numbers of Insteon devices sucking up the X10 signals. That, and the weakness of the PLM.

 

So here's an example:

 

_____________________________________________________________

 

PROGRAM= Rear Floods ON

 

If

From Sunset - 9 minutes

For 1 hour

 

Then

Send X10 'E3/On (3)'

Wait 3 seconds

Send X10 'E3/On (3)'

 

Else

- No Actions - (To add one, press 'Action')

 

 

_____________________________________________________________

 

Sometimes I will use shorter wait periods (2 seconds), and also send the command in triplicate.

 

This type of approach has worked well for my applications

 

 

Best wishes

[IndyMike]

Frank,

Thank you for the reply. It's always nice to hear that I'm not totally out in left field.

 

Looking at your quote below, I was hoping that this wasn't actually the case. If the Insteon cleanup and the X10 commands are concurrent it would imply that neither is functioning properly. I would have thought that the "collision avoidance" in the PLM would prevent this from happening. I suppose it's possible that the collision avoidance doesn't function across communication modes (X10-X10 and Insteon- Insteon works, but Insteon-X10 doesn't).

 

My original assumption that the PLM is "tailgating" an X10 command too close to an Insteon command doesn't work. I had envisioned that the X10 start code was being "missed" by receivers due to an improper gap between the Insteon and X10 transmissions.

 

I forgot that every X10 command is repeated automatically per the protocol. A bad gap could affect the first command sequence, but the second should make it through.

 

Based on this, I'd have to agree that the group cleanup functions appear to be operating concurrently with the X10 sequence. This is easy enough to handle within the ISY, but what are the implications for other asynchronous X10 events. Without proper collision detection any X10 transmission (motion sensors, timed events, etc) can occur during Insteon communication.

 

You are 100% correct! I had used this same solution some time back for a similar situation. The group cleanup commands that Insteon utilizes will "step on" an X10 command that is issued immediately after an Insteon command. The wait period helps eliminate the conflict.

 

With regard to repeating the X10 commands - I was trying this for a period of time. I found that the PLM simply doesn't have enough output for my installation.

 

As present I have my PLM and CM15a located at the load panel on opposite phases (X10 repeater across the phases). I'm using the PLM/ISY as the brains, and the CM15a as the brawn (due to its higher output level). In this configuration the ISY trigger's off Insteon events and transmits X10 to my CM15a (they're close enough that this communication is reliable). The CM15a in turn runs a macro and broadcasts to the house.

 

Not the most efficient, but I do manage acceptable X10 levels in my problem areas.

 

Thanks for the insight,

IM