Please login or register.

Login with username, password and session length

Author Topic: Oddity in the Activty Monitor  (Read 6807 times)

Dan Lawrence

  • Hero Member
  • *****
  • Helpful Post Rating: 68
  • Posts: 3991
Oddity in the Activty Monitor
« on: September 23, 2006, 07:54:21 PM »

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.
Logged
I don't SELL this stuff... BUT I sure do ENJOY using it!!!

Charles Sullivan

  • Hero Member
  • *****
  • Helpful Post Rating: 94
  • Posts: 1565
    • HEYU - X10 Automation for Linux, Unix, and Mac OSX
Re: Oddity in the Activty Monitor
« Reply #1 on: September 23, 2006, 10:28:42 PM »

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.



Logged
Yesterday it worked.
Today it doesn't work.
X10 on Windows is like that.

HEYU - X10 Automation for Linux, Unix, and Mac OS X     http://www.heyu.org

Dan Lawrence

  • Hero Member
  • *****
  • Helpful Post Rating: 68
  • Posts: 3991
Re: Oddity in the Activty Monitor
« Reply #2 on: September 23, 2006, 11:13:15 PM »

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?
Logged
I don't SELL this stuff... BUT I sure do ENJOY using it!!!

Charles Sullivan

  • Hero Member
  • *****
  • Helpful Post Rating: 94
  • Posts: 1565
    • HEYU - X10 Automation for Linux, Unix, and Mac OSX
Re: Oddity in the Activty Monitor
« Reply #3 on: September 24, 2006, 12:23:53 AM »

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.



Logged
Yesterday it worked.
Today it doesn't work.
X10 on Windows is like that.

HEYU - X10 Automation for Linux, Unix, and Mac OS X     http://www.heyu.org

Dan Lawrence

  • Hero Member
  • *****
  • Helpful Post Rating: 68
  • Posts: 3991
Re: Oddity in the Activty Monitor
« Reply #4 on: September 24, 2006, 10:23:11 AM »

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.
Logged
I don't SELL this stuff... BUT I sure do ENJOY using it!!!

Charles Sullivan

  • Hero Member
  • *****
  • Helpful Post Rating: 94
  • Posts: 1565
    • HEYU - X10 Automation for Linux, Unix, and Mac OSX
Re: Oddity in the Activty Monitor
« Reply #5 on: September 24, 2006, 11:21:29 AM »

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.


Logged
Yesterday it worked.
Today it doesn't work.
X10 on Windows is like that.

HEYU - X10 Automation for Linux, Unix, and Mac OS X     http://www.heyu.org

marty619

  • Jr. Member
  • **
  • Helpful Post Rating: 3
  • Posts: 12
Re: Oddity in the Activty Monitor
« Reply #6 on: September 24, 2006, 01:58:19 PM »

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!!

Logged

Charles Sullivan

  • Hero Member
  • *****
  • Helpful Post Rating: 94
  • Posts: 1565
    • HEYU - X10 Automation for Linux, Unix, and Mac OSX
Re: Oddity in the Activty Monitor
« Reply #7 on: September 24, 2006, 07:27:07 PM »

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


Logged
Yesterday it worked.
Today it doesn't work.
X10 on Windows is like that.

HEYU - X10 Automation for Linux, Unix, and Mac OS X     http://www.heyu.org

TakeTheActive

  • Hero Member
  • *****
  • Helpful Post Rating: 126
  • Posts: 1047
  • Old !@#$% Tinkerer!
Re: Oddity in the Activty Monitor
« Reply #8 on: September 24, 2006, 08:23:14 PM »

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!  :o
Unit Code . . . Binary Code . . . Decimal Code
130 0 0 000
050 0 0 101
030 0 1 002
110 0 1 103
150 1 0 004
070 1 0 105
010 1 1 006
090 1 1 107
141 0 0 008
061 0 0 109
041 0 1 010
121 0 1 111
161 1 0 012
081 1 0 113
021 1 1 014
101 1 1 115

Reference:
« Last Edit: September 24, 2006, 08:41:12 PM by TakeTheActive »
Logged
Low Post Count != Low Knowledge - High Post Count != High Knowledge ;)

ADVICE TO X-10 NEWBIES FROM AN X-10 OLD-TIMER

Charles Sullivan

  • Hero Member
  • *****
  • Helpful Post Rating: 94
  • Posts: 1565
    • HEYU - X10 Automation for Linux, Unix, and Mac OSX
Re: Oddity in the Activty Monitor
« Reply #9 on: September 24, 2006, 09:42:54 PM »

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.

Logged
Yesterday it worked.
Today it doesn't work.
X10 on Windows is like that.

HEYU - X10 Automation for Linux, Unix, and Mac OS X     http://www.heyu.org

TakeTheActive

  • Hero Member
  • *****
  • Helpful Post Rating: 126
  • Posts: 1047
  • Old !@#$% Tinkerer!
Re: Oddity in the Activty Monitor
« Reply #10 on: September 25, 2006, 12:48:53 PM »

...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... ;) ]
Logged
Low Post Count != Low Knowledge - High Post Count != High Knowledge ;)

ADVICE TO X-10 NEWBIES FROM AN X-10 OLD-TIMER

Charles Sullivan

  • Hero Member
  • *****
  • Helpful Post Rating: 94
  • Posts: 1565
    • HEYU - X10 Automation for Linux, Unix, and Mac OSX
Re: Oddity in the Activty Monitor
« Reply #11 on: September 25, 2006, 05:52:09 PM »

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

Logged
Yesterday it worked.
Today it doesn't work.
X10 on Windows is like that.

HEYU - X10 Automation for Linux, Unix, and Mac OS X     http://www.heyu.org

-Bill- (of wgjohns.com)

  • Advanced Member
  • Hero Member
  • ******
  • Helpful Post Rating: 81
  • Posts: 1340
  • He's just this guy. You know?
    • wgjohns.com
Re: Oddity in the Activty Monitor
« Reply #12 on: September 26, 2006, 02:00:42 AM »

TTA,

Bet you're right!  I've seen similar things in all kinds of electronic design!   ;D
Logged
-Bill- (of wgjohns.com)
bill@wgjohns.com

In the real world, the only constant is change.

When I'm online you can find me in the Home Automation Chat Room!
 

X10.com | About X10 | X10 Security Systems | Cameras| Package Deals
© Copyright 2014-2016 X10.com All rights reserved.