Re: Insteon Translator (title corrected from transmitter)

["BruceR" <br@xxxxxxxxxxxxxxxx>]

That makes sense; I might play with that a bit this weekend when I add
some more modules. I haven't done any dimming yet as I only installed a
couple of appliance modules and a non-dimming wall switch so far. When I
put in the dimmers things should get interesting.  Another thought I had
is that, in the macros, I had some strings like A1, A3, A4, A ON to cut
down on traffic. If, for example, A1 or A3 were an Insteon target it
might not trigger since the ON command came after another X10 code. Yet
another thing to test!

It turns out that this weekend may get jammed as we're roughing in the
low voltage cable in the spec house I'm building next door. Saturday
will be spent nailing up mud rings and drilling holes with a helper and
Sunday the cable pulling guys will be there to start pulling them in.
There will be about 70 jack locations so we'll be busy!   You can watch
the house being built live (and control the camera) at:
  http://portlock5.gotdns.com:2345. The webcam is active during Hawaii
daylight hours.

From:Dave Houston
nobody@xxxxxxxxxxxx

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