I noticed that there's an oddity in the Activity Monitor. It's reporting all timer events as MACRO, as well as MACRO events. I have one keypress macro, that turns off all lights on housecodes A, C & F at the press of A5 OFF. Every other event is a timer.
Obviously a bug that needs to be fixed. Timer events should be reported as timers.
Then why, if I have ONE MACRO ONLY and 23 modules have timers amd my single macro doesn't have a timer, what dioes your statement about "binary level" have do with what the Activiry Monitor displays? Macros and timers are different, or is AHP's descriptions of each wrong?
Thanks. Perhaps X10 needs to refine how the data is recorded. The fact that according to the ahpeeprom_w.txt, any action by the CM15A is a macro of some kind, but when you look at the Active Home Pro software, the two actions are seperate and different. Timers are attached to modules, Macros are generated by the Macro Generator.
I'm referring to the base Active Home Pro, I don't have any of the plug-ins.
For historical reasons probably related to decoding the module code wheels (although I haven't yet figured out the logic), when an X10 firmware transmitter sends a sequence of unit addresses on the same housecode, they're transmitted in this order:
13, 5, 3, 11, 15, 7, 1, 9, 14, 6, 4, 12, 16, 8, 2, 10
Unit Code . . . | Binary Code . . . | Decimal Code |
13 | 0 0 0 0 | 00 |
05 | 0 0 0 1 | 01 |
03 | 0 0 1 0 | 02 |
11 | 0 0 1 1 | 03 |
15 | 0 1 0 0 | 04 |
07 | 0 1 0 1 | 05 |
01 | 0 1 1 0 | 06 |
09 | 0 1 1 1 | 07 |
14 | 1 0 0 0 | 08 |
06 | 1 0 0 1 | 09 |
04 | 1 0 1 0 | 10 |
12 | 1 0 1 1 | 11 |
16 | 1 1 0 0 | 12 |
08 | 1 1 0 1 | 13 |
02 | 1 1 1 0 | 14 |
10 | 1 1 1 1 | 15 |
...but don't understand the logic behind its development, i.e., why that particular encoding was chosen by X10.
...but don't understand the logic behind its development, i.e., why that particular encoding was chosen by X10.
WAG: When running traces on the PCB from the 4 input pins on the IC to the pads under the code wheel, *THIS* order avoided the need for a multi-layed PCB since traces didn't have to crossover one another.
[Of course, we all have to now go and look at a disassembled module to see how good this guess was... ;) ]