Print

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

[steven r]

My battery time keeps reseting to "0". I
haven't been able to figure out when it's
happening but it maybe after updates. I
haven't had any power interruption to use
battery time.

[JimC]

I also have been experiencing this problem.
I have noticed that when this happens my
timers and macros no longer function
properly.

[Burdy]

I've seen this several times also.  A few
times it was with the CM15A  connected to the
computer and after a message popup has
appeared (not sure of the exact text but
something like 'A communications error on the
USB interface has occurred, your timers may
not execute properly unless you hit OK to
download them to the interface again').
This message has a cancel option;  if cancel
is chosen, the CM15A doesn't seem to be
functional until the timer reload is done.

It may be coincidence, but in general my
CM15A seems to be happiest running
disconnected from my computer.  The RF range
is improved, and I haven't had a lockup when
it has been left on its own with a 'good'
timer download (longest I've let it run in
standalone mode without tinkering with it has
been 10 days, without any apparent problems).

On the other hand, I've had numerous
instances of the above mentioned USB
communication error while attached to the PC
that has seemingly hosed the CM15A.  My
experience has been that if I get a
successful timer download, the CM15A runs
like a top (known issues aside).  If the
download wasn't successful (and the 'Download
complete' message does *not* seem to be a
reliable guarantee of this) the CM15A quickly
stops running right (macros won't execute).
A repeat of the download process seems to set
it right again.

The fact that I can pull the USB cable in the
middle of a timer download and immediately
get "Download Complete" with no error
indication tells me that there isn't much (if
any) handshaking or error detection on the
USB interface.  I think some instances of
flaky operation might be caused by undetected
errors that have corrupted the download
process, or cause some other failed
initialization of the CM15A.

I would love to see a way of verifying that
a successful timer download and
initialization has occurred-- 'Download
complete' doesn't always seem to be accurate.

[X10 Pro]

I've seen this too, and we'll take a look at
it. I have a feeling this is a fairly recent
development, as I don't remember seeing this
get reset quite so often when we first released.

[joe s.]

My experience with a "detached" CM15a -
when you connect to the USB and the battery
reads zero - all timers and macros have
stopped permanently until it is reloaded.
That used to happen to me weekly - but
since we get updates and reload SW every 4
days (since 3.168) - I can't tell if it's
going to happen again.

[Burdy]

Just now had the 'mother of all resets'
happen to my CM15A, and again it was while
USB connected to the computer when an error
occurred.  I was debugging a motion
triggered macro, and as soon I stepped in
front of the motion detector, I heard the
Win98 error 'bong' and saw on the screen
that AHP had terminated with  a RUNDLL32
error box the only thing left on the
desktop.

Restarted AHP, and looking at hardware
configuration, Battery time was  gone,
monitored house code reset to A, date was
01/01/1601 (?!?) time 12:00:00, and all
transceived housecodes were cleared.

I've seen this type of mega-reset before
(also with apparent communication error to
PC) and all though the monitored housecode
can be restored via AHP, when the year gets
set to 1601, the batteries must be removed
from the CM15A to get it running again.

[Noam]

I experienced the same type of "mega reset"
once. I use WinXP2. It happened immediately
after one of the upgrades (I don't remember
which one - it was several updates ago). It
hasn't happened since.

[Burdy]

Hmm.. after the previously mentioned AHP
crash and mega-reset, I pulled 1 battery out
of the CM15A (with it still connected to AC
and the PC).  When I restarted AHP & tried
to display Hardware config, got nothing for
around 25 seconds, then the hardware config
screen displayed.  First few times I did
this (doing a save after selecting the
relevant settings), the previously
mentioned 'blank' settings and bogus clock
were still displayed. I repeated this a few
times to time the delay, and strangely the
last time I did it (battery still out of
CM15A) the hardware configuration screen
displayed the PC's time & date (off by 25
seconds), but this time showed a red dot for
battery condition.

The interesting thing is, the battery time
somehow had reset itself to the
prior 'valid' setting (it once again
displayed 47:45 as it had before the mega-
reset). Also, all transceived housecodes
became selected.

I wonder how the battery time remaining
reconstructed itself?   The 25 second delay
may be irrelevant, since I think Win98 was
not running correctly (I had not restarted
it after the RUNDLL32 crash, and  I noticed
that just closing AHP also showed a
considerable delay).

I saved the correct transceived codes, moved
the USB cable to my laptop, and displayed
the Hardware config with AHP.. all settings
looked correct, and battery remaining showed
47:45, as it had before the mega-reset.

[steven r]

"...date was 01/01/1601... ...and all
transceived housecodes were cleared..."

You got sent back to the "dark ages".
I would definitely say that qualifies
as "mother of all resets".

[Burdy]

Ok, bear with me.. the plot thickens. You can
skip to the end if you don't want the blow by
blow...

If you read my previous post, you might
conclude that everything was fine with the
CM15A (after I had restored the transceived
house codes & time and its battery remaining
time had magically reappeared) when I
re-inserted the battery, disconnected the USB
from the machine with the AHP crash &
re-connected it to my laptops USB. Not so..

Even though I did purge, clear interface
memory, download timers (and all these
completed with no bad indications), trying to
execute any RF triggered macro resulted in
'Communications error with USB...' and
apparently 'hung' CM15A (no further RF
triggered macros would execute).  On a hunch,
I performed another timer download, unplugged
the USB (before triggering any macro), and
voila, the first RF triggered macro I tried
appeared (that word is key) to work (a light
turned on). But no other attempts to trigger
a macro worked thereafter.

I then re-plugged the USB.. and strangely,
received no more 'Communication error'
messages, but a few more attempts showed that
while RF entries were being logged, any
further macros weren't otherwise executing.
Lights weren't turning on, flags weren't
getting set.  It appeared that the CM15A &
AHP were talking to each other properly, RF
was being received and logged, but macros
weren't running anymore.

Now, and this is the point of this tortured
tale, AC to the CM15A had at no time been
disconnected during this entire exercise
(this was intentional on my part).  So I
unplugged the CM15A from AC, removed a
battery, reinserted it, plugged back into AC,
and reinitialzed everything... and now
everything works (although the battery
remaining time again reset to zero).

So, the point of all this seems to be, if you
encounter a persistent 'USB Communication
Error', you will probably have problems
UNLESS the CM15A has had a complete batteries
out/AC unplugged reset.  Clear interface
memory, purge timers, downloading the
software, and removing a battery while still
on AC, and seemingly valid hardware
configuration displays (and even a single
functioning macro) from the CM15A may mislead
you into believing that it is primed to work
properly, when in fact it isn't.

This might all seem plainly obvious, but
dozens of times I have encountered the 'USB
Communications error detected' and just hit
OK to reload the timers-- and most times
things seemed to work again ok.  But all
those times I assumed that all the necessary
resets & initializations had taken place,
even though batteries were still inserted and
AC was still on.  Based on this experience it
seems that for some USB communication erros,
you really do need to start with CM15A 'total
power off' to get it working 100% again.