Re: Insteon Translator (title corrected from transmitter)

["BruceR" <br@xxxxxxxxxxxxxxxx>]

Ok, here's a report on using the Insteon Icon Dimmer wall switch with
the translator.  Installation was normal and then I tested the dimming
function from both an X10 Maxi Controller plugged into an Insteon
Translator and an Insteon Tabletop Controller.  Dimming with the Insteon
controller was expectedly smooth but each press of the Dim or Bright on
the X10 controller generated a choppy 3 or 4 step dim. So, while the
translator will do Dim & Bright it isn't pretty. Preset Dim commands
don't do well either probably due to collisions between the X10 and
Insteon Dim commands.
 The other test was programming the preset brightness level. X10 is a
much simpler method in that you adjust the brightness on the switch and
that's it. With Insteon you have to program it into the controller. That
means going to the translator, pressing the program button for 10
seconds, sending the X10 code 3 times and then going to the switch,
setting the level, pressing the set button and then holding down the
paddle for 10 seconds.  Want to change it? Just do the whole thing all
over again!
 Unless running back and forth through your house is your idea of
aerobics you are well advised to bring the translator with you and to
plugit in nearby to where your switch is.  This process must be repeated
with each Insteon Controller you want to control the light from.
 The reason for that is, unlike an X10 module with a "public" address of
say, J9, that any X10 controller can send to, each Insteon unit has a
unique address code (like a MAC address on an ethernet device) requiring
that each switch/module be individually bonded to each controller.
Indeed, it appears that each controller could be programmed with a
different dim level so that if I send an ON through the translator it
could turn at  90% but if I turn it on with the tabletop controller it
could go to 70%.

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