Print

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

[Noam]

What I was looking to do was:

Condition [Security Is Not Disarmed]

Trigger [Basement Door Sensor Triggered] OR [Basement Motion Sensor Motion Detected]

It appears that there is only one trigger allowed.

It looks like you can have multiple conditions, but the IR modules are unavailable for conditions.

Yes, a macro can only have one trigger (that's what kicks off the macro). You would need to create a second macro that would be triggered by the other sensor.
You can have multiple conditions (up to three, but some condition types use of two of the condition "slots") in a single macro.

If you create the macro with the one condition (not disarmed), and trigger it with the one motion sensor, does it work properly?
You MUST test it using the motion sensor (or some other device that can trigger it). clicking on the macro within AHP will ignore the conditions, and ALWAYS run the commands.

[m82a1pa]

I did create a second macro triggered by the other sensor.  I was just musing about wanting to have a single macro for both.

But - in screwing around with the macros, the [Not Disarmed] wasn't the problem.  I somehow started video recoding manually apparently and thought the motion detector had triggered the recording.

I now have another problem (which may be a bug or I'm simply misunderstanding macros).

While the macros work fine when I manually trigger them from AHP, they do not work after arming my system and tripping a trigger.  I can watch the activity log and see the log entry for the trigger, and the [All Lights On] [All Lights Off] log entries repeating.  However, the macros do not fire.

Shouldn't the CM15A communicate with my PC and AHP to fire off the macro?  Or is there something else I should be doing?

Or the 'Run from PC' not capable of doing this?

[Noam]

I did create a second macro triggered by the other sensor.  I was just musing about wanting to have a single macro for both.

So you'd like to be able to assign multiple triggers to the same macro. Yeah, that might be a nice feature. (you can do it by assigning a "simple" macro to each motion sensor, that just calls a third one - using a "dummy" appliance module).

But - in screwing around with the macros, the [Not Disarmed] wasn't the problem.  I somehow started video recoding manually apparently and thought the motion detector had triggered the recording.

Okay, so it isn't a bug I need to add. Thanks for confirming that.

I now have another problem (which may be a bug or I'm simply misunderstanding macros).
While the macros work fine when I manually trigger them from AHP, they do not work after arming my system and tripping a trigger.  I can watch the activity log and see the log entry for the trigger, and the [All Lights On] [All Lights Off] log entries repeating.  However, the macros do not fire.

That's probably not a bug. Macros ignore conditions if you trigger them from within AHP (by clicking on them). More than likely, your conditions aren't being evaluated as "true." Check them carefully, you might have an error in the conditions somewhere.

Shouldn't the CM15A communicate with my PC and AHP to fire off the macro?  Or is there something else I should be doing?
Or the 'Run from PC' not capable of doing this?

That's EXACTLY what it *should* be doing, as long as the PC is on, and the cable is connected, it should run those macros when triggered by the CM15A.

[m82a1pa]

I think I'm out of the woods, Noam.  When I changed out the batteries in my two alarm remotes, they still worked fine with the security box.  I had to reinstall them both in AHP though.  Once done, I believe it works as it should now.

[Noam]

I think I'm out of the woods, Noam.  When I changed out the batteries in my two alarm remotes, they still worked fine with the security box.  I had to reinstall them both in AHP though.  Once done, I believe it works as it should now.

So perhaps the problems were simply caused by weak batteries. It wouldn't be the first time we've seen that happen.
Glad to hear you got it working.

[Noam]

I added a new bug:


* User is prompted to choose a file location and name when saving their AHX file, if they used the "browse" function during their session in AHP (such as when adding a Windows command to a macro). The folder defaults to the last-used folder, not the one from which the AHX file was loaded.
   (added 2/6/2012 by Noam, but I think it has been around a long time. Confirmed still present in 3.318)

[Tuicemen]

Moved the AHP fails to load bug to the top of the list.
I don't often open AHP any more but with some users reporting this after a resent Windows 7 update.
I opened AHP and it worked. I then noticed I hadn't installed some security patches so I updated windows.
I then tested AHP again and it failed to open. Removed the XML file and reinstalled to fix the issue.
This is no Longer a rare bug as X10 programmers had reported if a windows update will cause this.
Note: This has occurred for me with all reported ways known to cause the corruption.
This time I didn't waste my time submitting a xml file.(However I did rename the corrupt file and kept it)
The last time I submitted files I submitted my whole setup(all files).
Comparing my corrupt XML file with the new good one I find some noticeable differences.
There are multiple Dusk/Dawn entries now right after the entry
<ahphwconfig command="replace">
        <HWConfigData WorldTime="129732228138710000" InterfaceTime="129732048030000000" BatteryTime="0" BatteryState="7012461823655937" FirmwareRev="2" MacroMemory="446" TimerMemory="130" TransceivedHouseCodes="37029" TransHCAuto="0" TransHCMode="2" ts="129732228122480468"/>
    </ahphwconfig>
    <ahpduskdawn command="replace">the good XML but at the first part of the corrupt file

note: the good file states a firmware rev = 0  
WorldTime="0"  
InterfaceTime="0"
ts= entry is different as well
How can a newer file report an older firmware revision?

[Tuicemen]

Update: after adding registration codes I decided to recheck the XML file.
Seems the firmware rev is related to registration as is the dusk dawn and other entries.
but these stay at the end of the xml and are not moved to the first part of the XML.
Seems everything after the entry
(<ahphwconfig command="replace">
        <HWConfigData WorldTime="......) is move to the first part of the xml in the corrupt version.

[ps653]

I originally posted this in smart macros - but it seems that it fits better here.  This (hopefully) provides some more details on the bug that says macros run twice when triggered by security events
---
Just an FYI - what I see is not necessarily the macros being run twice, but each command in the macro executing twice in a row. i.e. macro is set to turn a light on and off 3 times and send an email when a sensor is triggered.  Used to result in
transmit J7
transmit on
transmit j7
transmit off
3 times
-> and then the email was sent

now I get
transmit J7
transmit on
transmit J7
transmit on
transmit j7
transmit off
transmit j7
transmit off
3 times - the lights only flash 3 times because it is sending on - on - off - off
-> and then the email is sent twice - 1 to 4 seconds apart

Hence, if the macro itself is executing twice, it is doing it virtually simultaneously, or each macro command is being executed twice.

You would think that this bug added by the latest code revision 5+ months ago would have been able to be fixed by now - especially since there is no work around.  

[Tuicemen]

You would think that this bug added by the latest code revision 5+ months ago would have been able to be fixed by now - especially since there is no work around.  

Saddly many of the programers X10 had working on this have left.
Those still with the company are most likely working on ICS builds for the AirPads.
Hopefully they'll get back to AHP issues soon.

[ps653]

Sadly many of the programers X10 had working on this have left

Unfortunately I see no evidence that AHP will be moving forward at all - with the last update being 5+ months ago, the CM15a gone and replaced by older less capable devices, silence from X10 in these forums - and just lip service on the facebook page - it looks to me like they have changed the company focus to just resell airpads and security systems with dismal customer support and forget about the product suite built the company. 

[Dan Lawrence]

Sadly many of the programers X10 had working on this have left

Unfortunately I see no evidence that AHP will be moving forward at all - with the last update being 5+ months ago, the CM15a gone and replaced by older less capable devices, silence from X10 in these forums - and just lip service on the facebook page - it looks to me like they have changed the company focus to just resell airpads and security systems with dismal customer support and forget about the product suite built the company.  

Sorry, you are 100% wrong there is X10 Repair Depot who is an X10 employee who has a constant presence here.   He keeps us posted as to what the company is doing and X10USA is fine and a new interface are coming, possibly by July.

[ps653]

You are 100% wrong there is X10 Repair Depot who is an X10 employee who has a constant presence here.   He keeps us posted as to what the company is doing and X10USA is fine and a new interface are coming, possibly by July.

I hope this ends up being correct, but in all honestly just the input from one x10 employee (no offense to X10 Repair Depot) still leaves me very skeptical with zero bug fixes since October '11.  I have my fingers crossed that you are correct but I will believe it when I see it.

[dave w]

You are 100% wrong there is X10 Repair Depot who is an X10 employee who has a constant presence here.   He keeps us posted as to what the company is doing and X10USA is fine and a new interface are coming, possibly by July.

I hope this ends up being correct, but in all honestly just the input from one x10 employee (no offense to X10 Repair Depot) still leaves me very skeptical with zero bug fixes since October '11.  I have my fingers crossed that you are correct but I will believe it when I see it.

Keep your fingers crossed but do not hold your breath. X10 is on the road to recovery but I think the "July" release date for either new hardware or software is wildly optomistic.

[Dan Lawrence]

I've found X10 Repair Depot to be very truthful in his posts considering he is an X10 employee. He would be the first person to post if that July date turned out to be false.