Re: Insteon Transmitter

[nobody@xxxxxxxxxxxx (Dave Houston)]

I don't think there's any solution short of an Insteon replacement for the
TW523 as you originally wanted. A standalone, on-the-fly translator isn't
going to know anything about any underlying schedule or logic connected to
the commands but a controller that could send one or the other, as
appropriate, could. (Although some of the macro programming might need to be
done at the adapter rather than in the JDS.)

Can your JDS controller detect collisions and retransmit X-10? Can you build
delays into macros?

Does the translator attempt to retransmit Insteon commands that are not
ACKed or can you determine that?

With the translator approach total traffic is going to be higher so more
frequent collisions are a given.

It's too bad that Insteon didn't choose a frequency with enough separation
from X-10 to allow Insteon devices to hear their commands despite X-10
traffic. Of course, they probably don't really want to encourage long range
coexistence.

Technically, an adjunct to your JDS (or any controller that uses a TW523 or
equivalent) that would send Insteon or X-10 depending on how it is
programmed is certainly doable and might interest Jeff Volp. He could use it
with an Ocelot and/or Leopard.

"BruceR" <br@xxxxxxxxxxxxxxxx> wrote:

>Here's a problem with it:  If a string of X10 signals is sent and one or
>more are being translated, it's a crap shoot as to what will work.
>Let's say that in response to "It's 6:30 am" we want to turn off a bunch
>of lights with different House/Unit codes.  Let's say that the 3d code
>in a series of 7 is being translated. When the translator sends the
>Insteon code it will either block or be blocked by the other signals
>being sent resulting in either some X10 or Insteon devices not
>responding.
>
>