Print

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

[donutlou]

why is that sometimes my motion sensor triggers the wrong module, ie. eagle eye motion b1 supposed to trigger lamp on a3 but instead turns on accent lights set to a6, and..... on the active home screen it says the lamp on a3 is on???
only sometimes...

[HA Dave]

why is that sometimes my motion sensor triggers the wrong module, eagle eye motion b1 supposed to trigger lamp on a3 but instead turns on accent lights set to a6,

Anytime I've had miss-fires (like that) it was signal collisions (B1 bumping into A3). To avoid that in my AHP macros I include a 2 sec. delay between actions. I am also careful NOT to transceive codes for a housecode that I still use a transceiver with.

[brp_]

This is a similar issue, so I didn't want to start a new thread...

I have a hawkeye sensor (RMS18) that I use to control a light in my office (I realize that having the light in the same room as the sensor messes with the Code+1 dusk/dawn operation, but I just leave Code+1 vacant and don't worry about it).

When I simply have the hawkeye transmit A12 (the lamp module setting) it turns on the lamp, as expected.

Now, when I set the hawkeye to transmit a different code (say D4) and create a macro that trips on D4...turns on the A12 lamp between certain hours,delays, turns off, here's what I get:

If A12 lamp is off, motion causes D4 trigger, A On, A12 on...lamp goes on...no problem.

If lamp is on, motion causes same behavior PLUS triggering another module (either A8 or A9) depending upon which is defined. (These are an espresso machine and tea water heater...don't want those turning on when I enter my office). Both A8 and A9 have associated timers, although that shouldn't matter.

I have:

Deleted A8 and A9 and rebuilt them (including the timers)
Purged the Cm15A memory (including unplugging, removing batteies)- in case some old, deleted macro is somehow being acivated.

By the way- doesn't matter what I set the hawkeye output trigger to (C,D so far).

Any ideas?

Cheers.

[brp_]

Well, I just wanted to follow up on my own issue. I reread the suggestion aove from Dave_x10_L, and I still didn't see how it applied, but I tried it. I added a two second delay between the start of the D4-triggered macro and the turn on of lamp A12. Sure enough, the "other" module (A8 or A9) did not turn on.

What is odd is- it seems that the prior post was about signal collisions on the powerline caused by codes generated too closely- that I can understand. In my case, the AHP Activity Monitor was claiming that the macro sent out both the A12 On and the A8 On. Didn't seem like the result of a powerline colliision.

I'm not sure why it solved the problem, and any suppositions are welcome. However, in the mantra that I'm learning here- if it works one way, don't try to fix it

Cheers.

[HA Dave]

.....I reread the suggestion above from Dave_x10_L, and I still didn't see how it applied, but I tried it. I added a two second delay between the start of the D4-triggered macro and the turn on of lamp A12. Sure enough, the "other" module (A8 or A9) did not turn on.

I read in another thread somewhere...... that a 1 or 2 second delay can work like "magic pixie dust" when used with AHP. Glad you found it helpful.

[brp_]

.....I reread the suggestion above from Dave_x10_L, and I still didn't see how it applied, but I tried it. I added a two second delay between the start of the D4-triggered macro and the turn on of lamp A12. Sure enough, the "other" module (A8 or A9) did not turn on.

I read in another thread somewhere...... that a 1 or 2 second delay can work like "magic pixie dust" when used with AHP. Glad you found it helpful.

However, as with all gifts from pixies, this comes with a penalty. Elsewhere in the macros section, there is a discussion of how a leading delay
can wreak havoc with dependent Else clauses in macros, causing them th execute at the same time, and not sequentially. So, while the
delay is necessary to avoid collisions in some cases, it seems not to play well with more complex constructions.

If we assume that the collisions are restricted to the same House Code (and this seems to be the case in what I've seen and read), one
possible way to reconcile this is to have a House Code devoted only to dummy *phantom") modules. Perhaps the first action of the macro
could be to set a state on a dummy. Even a collision would still only set the wrong module in the dummy House Code (if the base
assumption is really true). Then one could have the delay and the set of the real module.

Seems that this could avoid the relevant House Code collision and also allow Else clauses to work as planned.

Cheers.

[HA Dave]

 one possible way to reconcile this is to have a House Code devoted only to dummy *phantom") modules. Perhaps the first action of the macro
could be to set a state on a dummy.

I use the "G" house code for all my Phantom, Dummy, Ghost modules.

[donutlou]

the delay is a good idea, but my problems are from two different house codes one for the bathroom, house code b and one for the living room, house code c.... go figure