Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[jeff h]

I just ordered the AHP SW and CM15A.  I'm
starting out slow - motion dectectors only
at first.  Can I just leave the CM15A hooked
up to a PC all the time?  For now, I'm only
wanting to know when someone is *near* my
house (beep.beep.beep).  We didn't like
the "Chime" sound and returned it.  If AHP
can't beep then I'll use the SDK and write a
program myself.

Assuming all this works, I'd love to add
lights, cameras, etc.  But, it sounds like
the HW/SW may not quite be up to speed.
Bummer.

Also, can an X10 transceiver extend the RF
range of the CM15A?

Thanks.  Jeff....

[X10 Pro]

Jeff: Leaving the CM15A connected to a PC all
the time should work fine. The best way to
extend the RF range of your X10 products is
with the Smart RF Repeater, model SR731.

[Tuicemen]

If you leave you CM15A connected you'll have
far less problems. Mine has worked flawless
since the last SW update Just wish the SW
would.You'll have to use the SDK for now AHP
won't beep!

[joe s.]

To make a more pointed comment - CM15a ONLY
EVER works well when constantly connected to
the PC...you may be the "perfect" customer
for their current version of hardware/software.

[jeff h]

I just thought of something - Is the SDK
another way to "program" the interface - or
does it actually communicate with the X10
components in real time.

Otherwise, can I write a program to "know"
when a sensors gets triggered and then do
what I want programatically (email, beep,
turn on X10 lights, etc.)

From what I read, it's not a real SDK -
which made me wonder whether it can
actually "know" the states of X10
compenents.

Also, I have a collection of PC's.  What the
best OS.  Sounds like 98 maybe....

Thanks again!

[X10 Pro]

Jeff H: You can use the SDK to write a
program to read incoming commands from the
CM15A and respond to them in whatever way you
want. A couple of the samples show how to do
that in different contexts.

[andyd]

Joe S - It's not true that CM15a only works
when connected to a computer.  I've been
running disconnected for 14 days and timed
macros and timed modules all run on time
every day.

Andy

[jeff h]

Thanks for all the feedback.  I'm looking
forward to having some fun with this.  If
all goes well, I'll hopefully have a pretty
extensive X10 system.  One step at a time of
course....

Maybe I can catch the (probably neighborhood
kids) that keep messing with everyones
cars

"This house protected by a Nerd with too
much time on his hands"

[arf1410]

AndyD - are you using any dusk or dawn
timers?

[andyd]

No dusk/dawn timers.

[joe s.]

My apologies, Andy.  You are indeed
envied.  And I remember you did identify
yourself as a successful user in the forum
once before.  I should have said only the
*vast majority* of CM15a's perform reliably
when constantly connected to a PC.

[arf1410]

I stand by my early comment that the flaw
must be related to the dusk dawn timers, as
the only people who can successfully use the
CM15A disconnected from the PC are NOT using
dusk / dawn timers...

[andyd]

ARF - I disagree.  My CM15a locked up nearly
every day without any dusk/dawn timers. As
reported elsewhere in this forum I
eliminated lockups by reducing line noise
and improving phase coupling.

It may also be significant that I am not
using the CM15a for RF.

Andy

[arf1410]

Andy -
Lock ups is one problem, timers and macros
not executing may be an independent
problem.  You had the lock up problem, which
MIGHT be caused by line noise, at least in
part.  Phase coupling really shouldn't
effect anything, as the CM15A has no way of
knowing if your phase is coupled, though of
course a light might not turn on.

Sounds like you NEVER had the other problem,
of timers and macros not executing after a
couple of days (but the CM15A NOT "locked
up"), and you never used dusk dawn.

BTW - what do you mean by "locked up"?

[Burdy]

There's almost certainly more than one
failure mode at work here, and its difficult
to correlate the symptoms because each user
may have slightly different hardware quality
and make use of different programmable features.

For example, some CM15A's clocks drift; some
do not-- I make this conclusion based on a
sample of 2, because I have one of each.. one
CM15A keeps time accurate enough to correlate
to within a second or two with my radio
controlled 'atomic' clock, one drifts several
minutes a day... both M15A's are on the same
powerstrip.  Likewise, some complain of RF
range, some don't (mine are OK, though one
seems more 'ok' than the other).

Some  users may use smart macros with time
delays and flag conditionals, dusk/dawn, etc.
Do these users have more hangs than those
that don't?

With both the CM15A's I use, I can create a
single timer file that will cause either of
them to fail (by that I mean not execute
timed events) overnight consistently. I've
already forwarded it to X10 pro.  I can also
modify that same file to remove a few motion
detectors and it will run a week or longer
perfectly (it might have run longer because I
intentionally reloaded it after a week-- and
yes, it *does* use dusk/dawn and timers, and
always runs disconnected from the USB port!)

But I've also observed the scenario of CM15A
silently dying when running standalone, then
coming back to life (to some extent) when
being reattached to the PC's USB port.  I
don't know enough to even guess whether the
'silent death' is a hard hang, or memory
corruption, but I do know that I can
alleviate this problem by running a timer
file that doesn't use certain features (as I
described above).

Likewise I can make a simple file that does
nothing but control 3 lights and associated
motion detectors, and it will fail within a
few hours.  It does *not* use dusk/dawn, but
*does* use time delays, smart macros and flags.

Hopefully the X10 developers are sorting the
details and correlating the problems before
concluding what 'the' problem is, because it
sure seems there is more than one.  For the
most part I don't see enough details being
provided by users in the forum (I'm guilty of
this as well) to allow them to make much
headway with this, unfortunately.  A more
formal 'beta' program with a problem
reporting and tracking system is really
useful when there are so many variables
involving the user's  application,
environment, and hardware. Without this, some
kind of standardized problem report which
ferrets out the relevant details should be
provided.