Re: Lighting switch state communication

[Marc_F_Hult <MFHult@xxxxxxxxxxxxxxxxxxxxx>]

On Wed, 14 Feb 2007 16:57:09 GMT, "Jeff Volp" <JeffVolp@xxxxxxx> wrote in
message  <FbHAh.42810$2m6.40511@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>:

>"Marc_F_Hult" <MFHult@xxxxxxxxxxxxxxxxxxxxx> wrote in message
>news:uhu4t21i3suv69ku2l1ccu4is9sn3b9li3@xxxxxxxxxx
>>
>> This collision problem is much more severe with X-10 than INSTEON because
>> of X-10's much slower data transmission rate.
>
>I've been working on a "polite" mode for the XTB-II where it will sense a
>collision immediately, abort the transmission, and re-transmit when the line
>is clear.
>
>While some report significant collision problems, I wondered why we don't
>see that problem here.  Pushing the numbers, it appears that collisions
>should not be much of a problem unless the installation includes X10 motion
>detectors in high activity areas.
>
>As most of you know, it takes almost a second for a typical X10
>transmission.  Our installation runs about 200 transmissions a day.  All but
>a few come directly from the Ocelot.  So, a collision would only show up if
>one of the manual transmissions managed to occur during an Ocelot
>transmission.

To clarify: the INSTEON collision I described occurs when there are two
dimmers side-by-side at least one of which is a SLAVE (hot and neutral
connections only) that are physically pushed (manually) simultaneously (<
~1/5th second difference).

Granted, I am doing something with INSTEON that ABIK cannot be done at all
with standard X-10 dimmers, namely, communicating from SLAVE to MASTER Dimmer
without using physical ("traveler") wires as standard X-10 3-way switches do
and without recourse to an intermediary controller (Ocelot, Elk, Homeseer,
etc).

All that is needed is a hot and a neutral for any INSTEON switch/dimmer to
control any other INSTEON load in the system.

This is a powerful tool that is not only convenient and adds great
flexibility, but can save many $ and grief when the inspector says you need a
second light switch to an existing load. With X-10, this can be done through
a custom-programmed, proprietary computer/controller with all the attendant
issues -- as well as the minimum ~2-second delay for even a single command to
be sent and relayed -- and assuming no collisions. (I also have a few Leviton
X-10 keypads that can be used for this sort of thing that will be in my porch
sale.)

Note too that if one has deterministic commands in one's controller that
specify multiple instructions at the same time, something will have to give.
In the case of both X-10 and INSTEON, it is typically that the instructions
are not put on the AC line at the 'same' time.  In many/most cases this lag
is not significant if , as in Jeff's case, collisions do not occur.  But in
some cases, long, multiple lags resulting from separate commands to multiple
devices may be undesirable if one is trying to create a lighting effect.

For example, the variable time lag of X-10 rendered next-to-useless a nifty
feature of the Savoy CyberHouse software I used for years. What Savoy dubbed
"lighting vectors" and others have described as "lighting paths" (having
lights turn on in sequence in response to motion detectors) depends on timely
response to the occupancy sensors. The time lag of X-10 is/was such (in my
case) that it jist didn't work well enough. (I also had another, non X-10
source of lag owing to the slow response of NAPCO relays to sensors.)

.... Marc
Marc_F_Hult
www.ECOntrol.org