Print

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

[Dan Lawrence]

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.

[Charles Sullivan]

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.

At the binary code level there's no difference - regardless of how they may be programmed in the AHP GUI, timers execute macros.  Simple timers merely execute simple macros.

[Dan Lawrence]

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?

[Charles Sullivan]

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?

A timer is just a timer.   When a timer "goes off" it triggers a macro.   Beneath the surface you actually have 24 macros, 23 of which are triggered by timers, the other only by you manually sending a trigger signal.  When a macro is executed by either timer or manual trigger, that event is displayed in the Activity Monitor as a macro execution.

Take a look at the file ahpeeprom_w.txt generated when you download your program to the CM15A, i.e.,
   C:\Documents and Settings\All Users\Application Data\Active Home Professional\ahpeeprom_w.txt
Go past the summary at the beginning down to to the section marked "*** Hex Dump and Annotations ***".   You'll be able to recognize a "timer initiator" for each of your timers and note there are pointers to macros for the start and stop times.  Further down you'll come to the Trigger section, again with pointers to macros.  Following that will be the actual macro blocks.

I don't know enough about the detailed communication between the Activity Monitor and the CM15A to say whether or not the message sent back from the CM15A to the Activity Monitor when a macro is executed even distinguishes whether it was triggerd by a timer or a manual trigger.

[Dan Lawrence]

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.

[Charles Sullivan]

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.

The idea in AHP is to simplify user input for the common task of turning a specific module On and Off (as you are doing 23 times).  Otherwise this task would require creating two separate macros in the macro designer, which would be cumbersome and probably confusing for more than just a few timers.  The functionality emulates setting the On and Off times on a mechanical timer, which is a familiar concept for most people.

The old ActiveHome/CM11A  works the same way, both in the user interface and beneath the surface.

[marty619]

They used to say that you can get a model T ford in any color you want so long as you want black.

I have been chasing my tail for months trying to log visitors with my PR511 motion detector and the activity monitor.
I troubleshot for noise, phase coupling, and bought filters and repeaters.

I had the monitorded house code set to D because,  understandably, I want to use every available button on my palmpad which is addressed
at housecode A.  Further, I did not want to be able to press a remote button that would log a visit.

The PR511 issues B16-ON to trigger the chime and also at B16-ON there's a macro which issues a D1 command
to a phantom switch. The activity monitor was set to monitor house code D so that (I thought) it would contain ONLY records
of D1 , my visits..  THIS DID NOT WORK!!

I just switched the PHANTOM SWITCH to A3 and the monitored house code to house A. NOW IT WORKS!
But I have used one of my presious buttons and can trigger a vist record inadvertently.

It seems like the activity monitor will monitor any house code you want so long as it's house A

The Activehome pro software has a long way to go to become reliable.

The other thing that kept my desired system from working was I had the PR511 base code at B14 and +1 and +2 set.
The +1 was intended to trigger a garage light at B15 and the +2 was for chime and Macro at B16.
The quirk of the PR511 was to issue the sequence B16,B15, BON. This will trigger a macro at B15 only.
Another curve X10 threw at me, costing months of effort! So avoid this.

I'll pass along another discovery made just a few minutes ago.
Appliance, or switches in a macro will do the same thing as the PR511, that is issue B15,B16,BON.
But if you use the advanced function appliance or switch code "devices", they will issue
B15, BON B16, BON which will trigger macros at either or both addresses.

X10 programmers: this needs revision!!

[Charles Sullivan]

A few factoids:

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
This is the case for macros consisting of the same module type and command which are downloaded to the CM15A memory, e.g., if the macro turns On sixteen Appliance Modules set to units A1 through A16, regardless of the order they appear in the macro.

If the same macro is not downloaded but triggered to run from the PC, the addresses are transmitted in ascending order, i.e., A1, A2, A3, ..., etc, regardless of the order they appear in the macro.

In both cases the On function is transmitted only once following all the addresses.

If the individual modules in the macro are separated by a delay, even a zero delay, then they are transmitted in the order they appear in the macro, and the On function is transmitted following each address.

Now I don't own a PR511 so don't know what it does.  Perhaps the OP (or anyone else having one of these devices) would run the following experiments for the edification of the rest of us:  Record the order of the entries in the Activity Monitor when the  +1 and +2 switches are turned on and motion is detected with:
  1.  Base code set to 1
  2.  Base code set to 3
  3.  Base code set to 16

(Don't have it triggering any macro at all - just record what's received by the Activity Monitor.)

[TakeTheActive]

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

I'm surprised! 

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

Reference:

[Charles Sullivan]

TTA,
I'm familiar with the translation table, but don't understand the logic behind its development, i.e., why that particular encoding was chosen by X10.

[TakeTheActive]

...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... ]

[Charles Sullivan]

...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... ]

Good thinking - that makes sense.  Time to get "cracking".

[-Bill- (of wgjohns.com)]

TTA,

Bet you're right!  I've seen similar things in all kinds of electronic design!