Print

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

[Noam]

Twice in the past three weeks, we have had power outages lasting about an hour in the middle of the night.
In both cases, the CM15A did not resume running its timers after the power was restored.
In both cases, I know that it would run macros triggered from a palmpad or a PowerFlash.

The first time, I wasn't available to fix it for nearly two days, so I don't remember the specifics, but the second time, I know that the PC connected to the CM15A shut down (UPS was running low), and didn't turn back on when power was restored.
I noticed that times events weren't running, and I went to check the PC. I saw it was off, and I booted it back up (didn't do anything else like open HAP or anything - just turn on the power).
From that point, timers started running properly again.

Has anyone else seen similar issues after a power loss, where the PC is turned off, and the CM15A won't run timed events until the PC is powered back up?
all of the times were set to be stored in the interface. I verified that afterward.

[Dan Lawrence]

Once the timers and macros are loaded into the CM15A, it should begin sending X10 signals as soon as the power is restored.  The CM15 will send signals without the PC running.

[Knightrider]

Hey Noam,

Hows the batteries in the cm15 doing?  I have that problem all the time, but seldom change the batteries.

[Noam]

Once the timers and macros are loaded into the CM15A, it should begin sending X10 signals as soon as the power is restored.  The CM15 will send signals without the PC running.

Yes, that's why I think that mine is acting strangely.

Hows the batteries in the cm15 doing?  I have that problem all the time, but seldom change the batteries.

The system reports the batteries have plenty of life left in them.
However, they might be a few years old and it wouldn't hurt to change them.

The strange thing is that macros (stored in the interface) work just fine, it seems.

[Knightrider]

I used to think the batteries kept the system memory, but other users here have corrected me.  Battery power keeps the time, not the macros.

[Noam]

I used to think the batteries kept the system memory, but other users here have corrected me.  Battery power keeps the time, not the macros.

I was also under the impression that the batteries were used to store the timers in memory, AND to keep the time when the unit was disconnected from AC power (which, I think, is why come users reported that power fluctuations could cause the time to creep when the unit was disconnected from the PC - the PC keeps the time synced up when connected).

[Noam]

I forgot to add one more thing:
I noticed that after the power outage / restoration, most of the flags were set to "on," but they were all "off" beforehand. This happened both times.
Perhaps my AHX file is corrupted or something. I'm changing my timers over for the winter now, so perhaps I'll rebuild from scratch, instead of switching back to my "winter" file from last year, and then making whatever changes I need to make.

Anyone else seen this kind of strange behavior with the flags?

[-Bill- (of wgjohns.com)]

I forgot to add one more thing:
I noticed that after the power outage / restoration, most of the flags were set to "on," but they were all "off" beforehand. This happened both times.
Perhaps my AHX file is corrupted or something. I'm changing my timers over for the winter now, so perhaps I'll rebuild from scratch, instead of switching back to my "winter" file from last year, and then making whatever changes I need to make.

Anyone else seen this kind of strange behavior with the flags?

I believe from past experiments that the flags all get reset either so "Set" or "Cleared" when the CM15A powers up.  Worse, and I forget which does which, earlier versions of the CM15A reset them opposite what newer versions do!   
 

[Noam]

I believe from past experiments that the flags all get reset either so "Set" or "Cleared" when the CM15A powers up.  Worse, and I forget which does which, earlier versions of the CM15A reset them opposite what newer versions do!   
 

I'll have to play with that. It should be pretty easy to test.
The macros that rely on the flags are not 100% critical (let me clarify that - if the flags are OFF when they should be ON, that's not a big deal. If they are ON when they should be OFF, that is not so good).
If it is turning on the flags, I can always add a command in my "Power Restoration" macro to reset all the flags to "off".

I wonder if that behavior was corrected in later revisions of the CM15A, and if I could get them to replace mine 5 years out of warranty ;-)

[-Bill- (of wgjohns.com)]

I'm pretty sure they all do it.  Not sure if it's on any AC power dropout, or only when batteries are dead.

The only variable I know of is whether it defaults them all to set or cleared, and that varies by when it was manufactured.

Yeah.  The power up macro forcing all flags to your own "known state" is a great idea!
 

[Noam]

Well, I shut off that breaker for a few minutes last night, and nothing happened to the flags. (they were all off before, and they all remained off).
Perhaps the breaker needs to be off for longer or something.
I haven't checked the batteries yet (With a battery tester, that is), I really need to do that.

However, it doesn't make sense for the flags to get messed up when power is removed. If that's the design of the system, then unplugging it to move it from near your PC (after programming) over to where you normally run it would kill the flags every time. Pretty silly design, if you ask me. (please don't ask me - there are other things I think are silly, too!)

If I can't reproduce the behavior (which I hadn't ever seen until the power outage we had a few weeks ago), then I guess I'll just build in the "fail-safe" flag reset into my power outage/recovery macros.

I really wish the CM15A had a way to trigger a macro on power restoration. The PowerFlash method I use (keep the contacts shorted, set it to a single "on" command) only works if power is out for at least a few seconds (I think there are capacitors inside that need to discharge first). For blips lasting shorter than that, it doesn't trigger.

[Noam]

Yesterday, at some point in the day, all of my flags got set to "on."
I checked earlier in the morning, after doing the update to 3.293, and only the one I was using at the time (flag #2), was set.
However, by 6:30 PM, all of them got set somehow.
I went back through the logs, and didn't see any strange activity that may have triggered it.
There were no power interruptions that I am aware of, either.

Anybody have any ideas?

[Noam]

False flags are very problematic for my setup in only one direction (less of an issue if the macro DOESN'T run when it should, HUGE issue if it runs when it shouldn't). The last few times I observed this crazy flag behavior, ALL of the flags turned ON. (I have never observed them all turning OFF unexpectedly). I decided to *TRY* and create a fail-safe for my three flag-dependent macros, at least until a fix can be found.

For each of my trigger flags (2,3,4), I modified the condition to include TWO other flags that need to be OFF for the condition to be valid.

For example:
If [FLAG 2 is ON] AND [FLAGS 10,11 are OFF]

This way, if I intended to have Flag 2 on, and the flags go crazy, my macro won't run, but if I intended to have it off, it also won't run, since flags 10 and 11 would have come on when 2 was set to ON by whatever is causing the problem.

I really wish somebody could tell me why this is happening, and what I can do to fix it.