Re: Insteon Translator (title corrected from transmitter)

["BruceR" <br@xxxxxxxxxxxxxxxx>]

More on the Insteon Translator:  Last night I went through my Stargate
program and rearranged all the events and macros that had X10 strings
that included Insteon modules.  I pulled them out of their strings and
placed a delay of 2 seconds at the end of the string and then added the
X10 commands for the Insteon modules with each command seperated from
the preceeding command by 2 seconds. IOW, I eliminated the X10/Insteon
collissions.  All works well now.

 The replacement repeater is due here tomorrow so this weekend I hope to
install more Insteon stuff.


From: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.