Re: Insteon Transmitter

["BruceR" <br@xxxxxxxxxxxxxxxx>]

From:Dave Houston
nobody@xxxxxxxxxxxx


Comments/Answers interspersed:

One other problem is when trying to flash a light. When the mail is
delivered my desklamp flashes on & off twice. Until I s-l-o-w down that
flash rate Insteon can only turn it on and then gets swamped on the
rest.

> 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?

The JDS controller leaves all signalling matters to the TW523 so a lost
transmission is gone.
Yes, I can add delays after each transmission which is what I'm going to
try tonight if I can. I'll just do it to a small area of the program as
there are over 1500 lines of code involved in doing the whole thing.  I
was going to add more modules over last weekend but decided to wait till
the defective RF repeater is in before taking that step.  I agree that a
true TW523 replacement is needed! Or, even better, JDS could add native
support for Insteon. They've just done that for UPB but the phone board
has to come out!

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

The translator, as does every Insteon device, tries a few times and
gives up. Unfortunately, the translator sends nothing back to the TW523
to tell the JDS controller to try again. Although I'me sure there's a
way to do it with the USB controller, I cannot query the status of an
Insteon module from the JDS unit.
>
> With the translator approach total traffic is going to be higher so
> more frequent collisions are a given.

An incentive to try another protocal perhaps. Since the X10 signals come
from the TW 523, there seems to be no way to overcome this unless a
deleay is added after each X10 code is sent or Insteon adds a "wait till
line is clear for a few seconds" option for its transmissions.
>
> 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.