Print

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

[Boiler]

As I was putting together a test macro (to help another forum member) I learned something new.

My test configuration consisted of the following:
1) Lamp on A12
2) Lamp on C9
3) Motion sensor on C9.
4) Housecode B Monitored
5) All Housecodes transceived.

With the above configuration I would simulate the motion sensor with a Rf remote and turn on lamp C9.  No problems, everything worked as expected.  I was trying to demonstrate some of the problems that can occur when activity (high traffic) from motion sensors is transcieved onto the powerline. 

I then added a macro at address C9 which triggered Lamp A12.

1) Lamp on A12
2) Lamp on C9
3) Motion sensor on C9.
4) Housecode B Monitored
5) All Housecodes transceived.
6) Macro on C9.  Turn A12 on.

When I again simulated the motion sensor (Rf-C9 on) the macro executed and lamp A12 turned on.  No problem - WRONG.  My lamp at address C9 did not turn on.  I checked the configuration an verified that all addresses were transceived.  Checked activity monitor - the CM15a was not transceiving the Rf C9 on command (also verified with a testerlinc).

Event    Date/Time    Action    Data
0    06/10/2007 10:26:34 pm    Receive RF    C9 On
1    06/10/2007 10:26:35 pm    Macro    A12 (AM466 TV)
2    06/10/2007 10:26:35 pm    Macro    A On (AM466 TV)


I removed the C9 macro and the CM15a began to transceive the C9 on command again.  Definitely not what I had expected!  The Macro execution is taking precedence over the command being transcieved and effectively blocking it.

Bottom line is - Adding a macro to the same address as a lamp module blocks transeived inputs to that address. 

I have this situation in a number of places in my home where I use macros to track the status of lights in the house.  I haven't noticed the problem because I don't typically use the Rf remote to activate these lights.  There are of course work arounds, but in order to generate a work around you need to know the problem exists.

I'm not sure if this has been documented before - if not, hopefully it will help the forum readers.

The Boiler


Update 6-18-07: To those of you with "older" CM15a's

The above tests were conducted on my "new" CM15a (Date code 06L50, Firmware revision M) and I stand by the stated conclusion.

When I performed the same test on my "old" interface (Date code 04I38, Firmware revision E) I found that it did transceive the Rf command and then executed the macro. 

Rf handling/Macro execution if very dependent on the Firmware revision!

Firmware revision M
Event    Date/Time    Action    Data
0    06/10/2007 10:26:34 pm    Receive RF    C9 On
1    06/10/2007 10:26:35 pm    Macro    A12 (AM466 TV)
2    06/10/2007 10:26:35 pm    Macro    A On (AM466 TV)


Firmware revision E
Event    Date/Time    Action    Data
0    06/18/2007 5:06:13 pm    Receive RF    C9 On
1    06/18/2007 5:06:13 pm    Receive    C9 (New Module)
2    06/18/2007 5:06:13 pm    Receive    C On (New Module)
3    06/18/2007 5:06:16 pm    Receive    A On (AM466 TV)
4    06/18/2007 5:06:19 pm    Macro    A12 (AM466 TV)
5    06/18/2007 5:06:19 pm    Macro    A On (AM466 TV)

[Brian H]

Thank you for the data. It may assist others doing a similar thing.

[JMac]

Bottom line is - Adding a macro to the same address as a lamp module blocks transeived inputs to that address. 

Thanks for this.  I had found that using the same House/Unit code for a module and a macro was not reliable, but I never took the time to figure out why.  This is good information.