Re: Insteon Translator (title corrected from transmitter)

[nobody@xxxxxxxxxxxx (Dave Houston)]

This is pure guesswork but I think the delays may not be needed now that the
commands that have Insteon targets are the last item in the macro.

My guess is a delay is only needed to prevent a subsequent X-10 command from
colliding with the Insteon command from the translator. IOW, I think you
could have left them where they were and added a 1 second (or less?) delay
*after* each command that will get translated.

"BruceR" <br@xxxxxxxxxxxxxxxx> wrote:

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