Print

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

[tom j]

...I still haven't figured out how to start one macro then maybe call up another one to follow which should theoretically give me another 4 1/2 hours. 
tomh 

In order to do this you (probably) need smart macros to prevent the timer from re-triggering.  You can call a macro from within a macro by creating a "dummy" switch and a macro at the same address.  The macro will be callable via the dummy switch on/off commands.

Main Macro
If trigger and flag1 off {is the macro already running}

Set Flag1 {prevent re-entrance}
Delay 4.5 hours
Turn dummy1 on

Dummy1 macro
Delay 4.5 hours
trigger your hardware events
Clear Flag1 {re-enable main macro}

I'm not hot the above will act without the flag to prevent re-entrance.  I could come up with about 5 different scenarios (and they'd probably all be wrong).  Probably best to actually test and observe activity monitor rather than second guessing the AHP operation.

Say Boiler, how could the software be improved so that you could accomplish the same thing without to use dummy switches? I want to submit some software improvements got a couple from flock like you this one looks interesting always hear about folks creating them seems like the software could be improved so that you could get around the use of them. Thanks

Tom j

[Boiler]

Say Boiler, how could the software be improved so that you could accomplish the same thing without to use dummy switches? I want to submit some software improvements got a couple from flock like you this one looks interesting always hear about folks creating them seems like the software could be improved so that you could get around the use of them. Thanks

Tom j

Tom,
The dummy module workaround is by no means my creation.  I believe it's been around since the CM11 days. 

Depending on what you're doing, the multiple macro call requires Smart macros (flags) to prevent re-entrance.  In the thread example this would equate to re-starting the main macro while Dummy1 macro is still executing.

I don't have many wishes for the AHP software, I use mainly the Smartmacros and timers.  The people using cameras and web features could probably come up with a long list.

Most of my wishes deal with the CM15a microcontroller itself.  This device has been around for quite some time and has some known hardware problems.  The RF and zero crossing inputs must be "polled" by the micro due to hardware interrupt problems.  This is very inefficient for a device that doesn't have a lot of power to begin with.  This is why I'm constantly harping about reducing the amount of RF/powerline activity to the CM15a.  It's got a lot to handle.

To be honest, X10 has done a fair job of using an old horse up to (and past) it's maximum potential.  There are newer microcontrollers out there.  Cypress makes a newer version of the controller currently used in the CM15a.  Benefits include -

• Onchip EEProm (ability to upgrade Firmware in the field)
• Additional Interrupt Inputs that actually function (much lower controller overhead - ability to process RF and powerline inputs without getting lost)
• Increased clock frequency (increased speed)

Unfortunately, this device is neither pin nor code compatible with the existing device.  It would take a fair amount of commitment on X10's part to incorporate.

I realize I haven't really answered your question.  In my mind, piling additional features into AHP is simply adding more burden to an already overworked interface.  I'm trying to keep my system as simple (KISS concept - Keep It Simple Stupid) as possible and I'm comfortable with the workarounds that I have in place.  Each time X10 rev's the AHP package to support a new feature, I risk having my workarounds "broken".  At my stage in life, I really don't need that.