Re: X10 Code Translator

["Robert Green" <ROBERT_GREEN1963@xxxxxxxxx>]

"Dan Lanciani" <ddl@danlan.*com> wrote in message

ROBERT_GREEN1963@xxxxxxxxx (Robert Green) writes:

> | I'm assuming from your first paragraph you mean you after you send the
> | ON/OFF function, the unit reverts to the base housecode.  Or by "escaped
> | function" do you mean until you send another code your interpreter sees
as
> | the escape code the unit stays shifted?  Does that mean you can't send
> | stacked escape commands?
>
> The sole purpose of my escape code is to change the current house code,
> so there is no reason to stay in escaped mode.  Once you change the house
> code it remains changed until you change it again or the power fails (at
> which point it returns to the default from eeprom).  Remember, the whole
> goal was to get multi-house code operation in IR mode where the IR code
> does not include house code information.


I'm curious as to why you chose IR control over RF control of your X-10 via
their 8-in-1 (?) remotes.  I'm a little confused because I thought you were
doing all this magic via a new PIC installed in the RR501 - the one where
you had to do a pin swap via a socket sandwich to get it to accept a new
chip.


> | When using the X-10 remote, I'd love to be able to stack commands for
> | individual units, just like the Maxicontrollers do.  Do you think that
would
> | be possible with the 8-in-1 remote and controller like the CM15A and
Smart
> | macros?
>
> Not for RF mode using the normal X10 protocol, for the reason you note
> below.

That's too bad. I'd love to be able to stack commands via the remote as I do
with the Maxi as well as be able to issue a command that's the equivalent of
"ALL OFF EXCEPT UNITS 5 & 8"


> | > In my unix mapping implementation I look for three All Units Off in a
> | short
> | > time (or the equivalent held key) on my main house code and tack on
All
> | Units
> | > Off for the other house codes.  I also expand a single All Lights On
in
> | > a similar way.
> |
> | I'm not sure I understand that despite having read it numerous times.
What
> | happens after you send three AUF's?
>
> My mapping program sends All Units Off to a couple of other house codes.
>
> | Is that how you enter the escape mode?
>
> Sorry, no, I changed topic to a completely different mapping function that
> takes place on a unix box.  It has nothing to do with the RR501.


OK, that explains why I couldn't see the relationship!  :-)


> | Or are we discussing how you've implemented AUF's for different
housecodes?
> | I'll go check out your site to get some more background.
>
> I don't think the mapping program in on my web site.  It's pretty simple.
> It listens to power line messages from x10d and runs macros based on
> value, count, and current select mask.  It's been so long since I
> configured it that I don't quite remember its full capabilities. :)

I looked for information about it but couldn't find any.  I did search
through all your sample programs, though, until I got dizzy.  I get the same
kind of feeling I got in kindergarten when I saw the big kids doing math
homework.  It's not just beyond me, it's *way* beyond me.  For example, I
think:

ftp://ftp.danlan.com/ftp.danlan.com/homeauto/x10rfd.mr26.txt

Is a program to create a log of RF traffic monitored by the MR26.  But
beyond that, I don't have a clue.  :-(


> | I've been reading through the embedded program comments at your site and
> | have a question:  Are "sychronized collisions" and "tailgating" the same
> | thing?
>
> No, tailgating is when one transmitter sends so soon after the completion
> of another transmission that a receiver might take the (presumably)
different
> transmission as a repeat of the first because of the small gap.  X10 talks
> about three cycles of gap but actual requirements vary with, IIRC, ACT's
> being the smallest.  The CM11a doesn't like gaps less than 3 cycles after
> its own transmissions either, which is why it behaves oddly when querying
> a PR511 for status.  (The PR511 leaves only 5 zero crossings between the
> end of the query and the beginning of its response.)
>
> | I ask because since using the XTB with the Decora AHT, I don't
experience
> | the same collision problems I did with multiple TM751's deployed
throughout
> | the house (even though the are still deployed).  My sense is that the
XTB
> | equipped transmitter always prevails in a collision, which was not
always
> | the case with equally powered devices.
>
> It isn't obvious how a transmitter can prevail in a collision based on
> its strength alone unless the receiver has some sort of AGC or automatic
> threshold determination.  But the effects of collisions can be pretty
> hard to analyze with destructive and constructive interference possible
> depending on the relative phase of the carriers at various points, so I
> wouldn't be quick to rule anything out...


I suspect that my changing my setup around to accomodate the XTB's has had
more of an effect than using the Decora AHT.   Whatever the reason the
serious problem of the lights turning out an instant after they had been
turned on via an EagleEye has now become one of the light turning itself
back on after being turned off remotely.  That's far more tolerable than a
sudden lights out, especially one that occurs within seconds of entering a
room.  I supposed I'll have to finally swap out that switch, a step I have
been avoiding because of the fragile state of the 60 year old cloth covered
wiring.  Fortunately the X-10 switches are pigtailed, so it makes short box
wires a little easier to deal with.

I also discovered that a wall switch that's always exhibited a "bounce" (If
I turn it off, it sometimes turns itself back on a second later)  is still
giving me problems.  I thought it was the result of a RF or TM751 PLC
collision but it has to be something else because I see it even when I turn
it out via Maxi controller/XTB combo.

Like any other complex system, some of the tiniest problems eat up the most
debugging time.  I suspect now that the switch is bad and has been all along
and my TM751's have been taking the blame.  If only the Monterey had a
logging function . . .

Thanks for your input, Dan.

--
Bobby G.