Re: Insteon Translator (title corrected from transmitter)

["BruceR" <br@xxxxxxxxxxxxxxxx>]

Well, it turns out that my cable puller's wife decided to give birth
last night so my Sunday freed up. I've been doing some more Insteon
testing and the more I use it the more I like it.  The translator is
doing its job nicely with a 100% success rate as long as I keep the X10
controller commands seperated in strings. I can live with that.
 I have a couple of lamps by the entertainment center where X10 control
was virtually impossible - even with a controller in the same outlet.
Insteon also experienced a problem but it was completely solved with the
installation of a plug-in repeater - the 3d one to be installed (2 are
required at a minimum).  I'm going to get a couple more repeaters to
keep on hand as they seem to be the "magic bullets" to solve localized
problems.
 Most of my X10 locations are solid and reliable so it's nice to be able
to let the two systems coexist somewhat seamlessly and not have to throw
out my embedded investment.  It's safe to say though that I won't be
buying any more X10 based products as I migrate to Insteon.
 So far I've just been installing relay type (appliance) modules and
switches and I'm about to install some dimmers. I'll report later on how
the dimmers work through the translator.


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