RE: Re: All Lights On/All Units Off and Modifying an MT10

["Phil Harris" <phillip.harris1@xxxxxxx>]

So are we all friends again?

Phil

> -----Original Message-----
> From: Mark Hetherington
[mailto:mark.egroups@xxxxxxx]
> Sent: 12 November 2001 21:06
> To: ukha_d@xxxxxxx
> Subject: RE: [ukha_d] Re: All Lights On/All Units Off and Modifying an
> MT10
>
> > I might just have to start an off topic thread to kill this one!
>
> Like you need an excuse <g>
>
> > Mark, you seem very keen to nail someone who certainly should
know
what
> > they're talking about ... Li knows X10 and X10 products inside
out
and
> > has produced some great "enhanced" units that I
couldn't do without.
>
> No, I took exception to the manner in which I was responded to. I
expected
> better of someone who as you say should not only know the product
inside
> out, but dealt with people on a regular basis in his business and has
> always
> seemed so reasonable and moderate in other postings.
>
> > Your original query (which I've long since deleted) went along
the
lines
> > of "Groan, why is X10 so pants ... they implement All Lights
On and
All
> > Units Off but don't implement these other functions which I
want."
....
>
> To confirm, there are 7 commands before you hit the extended commands
-
> on,
> off, bright, dim, all lights on, all lights off and all units on. Only
one
> (all lights off) is not implemented in any controller I have used and
in
> some lighting modules which is why it was noticable. I didn't ask why
> don't
> X10 do all these commands for me, I asked why one command in the set
> seemed
> generally unsupported. I thought that a reasonable query despite the
lack
> of
> references to epods, bt, m**lins and cheesy chips :)
>
> > well, believe it or not X10 wasn't implemented for you alone. It
was
set
> > up to cover a mass market. I've already posted why All Lights On
and
All
> > Units Off were implemented in preference to other commands on the
> > controllers.
>
> Yes, where you went on to "groan" about the limit of 16 in a
house
code
> IIRC
> :) I also further discussed this.
>
> But there is only one command missing from the basic set so it is not
> really
> these instead of those, it is all except one. The answer could be as
> simple
> as the all lights off command was a late addition to the basic set but
I
> have yet to locate a document describing the progression of the
command
> set
> other than wrt the addition of the extended codes so cannot confirm
one
> way
> or the other. There are many reasons why all lights off is useful
besides
> the uses I have for it so that is the only logical reason I can think
of
> for
> it's absence since why provide 7 commands but only ever implement 6?
>
> I never suggested X10 was invented for me alone and rather than asking
for
> them to do it queried it's lack of support and was making an effort to
do
> it
> myself. I do not see how you perceived the converse but it was
definitely
> not intended that way.
>
> As for griping about X10, I could spend hours doing so, as I am sure
we
> all
> could, if I were so inclined so that was not my intent either.
Everyone on
> the list seems to agree it is imperfect and wishes for more from it
and
> since in your own response that you mention earlier you had a short
"rant"
> about the 16 house code limit, even were I griping I do not see it as
a
> bad
> thing to have been doing :)
>
> > If you need to add functionality to X10 commands then you can do
so
by
> > using a CM12 and triggering macros by using other X10 commands
that
you
> > can send which is what the rest of us do and which works very
well.
>
> In order to remap all units off to all lights off means losing all
direct
> control via the controller to macros resulting in a slower process
> overall.
> Using a different button for a macro for this one task means losing
that
> button on the controller for controlling something. So a macro is a
very
> imperfect solution and if a better one were available I would prefer
to
> use
> it hence my investigation into it. If we all just put up with the way
> everyone does it we would not have much innovation. Admittedly
altering an
> MT10 isn't *that* innovative and isn't going to win me any awards or
> anything but we all have to start somewhere :)
>
> The LM12 does not respond to All lights off which is a further issue,
but
> LD11s do and I assume the LM14 will so it is not an insurmountable
problem
> that the LM12 does not. I haven't found any technical specs for the
LM14
> yet
> though. X10's site seems pretty poor for in depth info and obviously
none
> of
> the better European sites have info since it is currently unavailable
to
> us.
> :(
>
> > You started on about your friends being able to extract the code
>from
> > PICs etc. - well, PICs have hardware code protection fuses which
are
no
> > more difficult to use than checking a box on the programming
software
> > and -
>
> Sorry, don't quite follow your point there. I think you might have an
> extra
> no or something or maybe I am just plain not following :)
>
> > given the huge numbers of X10 products that are sold - the
> > controllers for many of the modules are hard coded rather than
> > programmable units so you're not going to extract the code or
modify
it
> > by poking a byte with a different value.
>
> Generally controllers transmit commands and modules receive. If a
> controller
> was modified to send a different command and a module supported it, it
> would
> respond appropriately. Not quite sure what point you are trying to
make
> wrt
> hard coding and programmability. I am not trying to invent my own
> commands,
> just access one that already exists.
>
> > Also ... something that you have also completely ignored is the
fact
> > that X10 hold patents and copyright on their products and code
and
so
> > "reverse engineering" units might well be completely
illegal even if
it
> > were possible.
>
> I am completely ignoring it yes. Given that a number of companies have
> commercial enterprises reverse engineering chips and modifying
hardware
> with
> devices like defeating macro vision and territory locks on AV hardware
and
> games consoles, I do not think the chances too high that X10 will sue
me
> for
> resetting 2 bytes in a mini timer... well I would hope not anyway :)
>
> There are a number of other possibilities besides reprogramming if it
does
> prove not to be an option. Starting with a new PIC and reprogramming
>from
> the ground up for example. That might even be a better solution in the
> long
> run since I could then make other alterations to the controller.
However,
> it
> would require a much better working knowledge of the interfaces that
the
> PIC
> is well interfacing with.
>
> > This is my only posting on this matter ... I'm not going to get
drawn
> > into a pissing contest ... I hope we can all settle down and get
on
with
> > something useful.
>
> Then my apologies if I have further annoyed by responding and it is
not
> intended as an entry into any pissing contest. But your post did
actually
> give me the opportunity to introduce the possibility of replacing the
PIC
> completely which only recently occurred to me. Until it gets shot down
in
> a
> ball of flames at least :)
>
> Hopefully after Paul has worked on his Ultra Mini Timer project he
will
> have
> some information which would prove useful in "upgrading" the
mini
timer.
>
>
> Mark.
>
> P.S. Apologies for the over zealous use of smileys in this post.
>
>
> For more information: http://www.automatedhome.co.uk
> Post message: ukha_d@xxxxxxx
> Subscribe:  ukha_d-subscribe@xxxxxxx
> Unsubscribe:  ukha_d-unsubscribe@xxxxxxx
> List owner:  ukha_d-owner@xxxxxxx
>
> Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
>



For more information: http://www.automatedhome.co.uk
Post message: ukha_d@xxxxxxx
Subscribe:  ukha_d-subscribe@xxxxxxx
Unsubscribe:  ukha_d-unsubscribe@xxxxxxx
List owner:  ukha_d-owner@xxxxxxx

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/