Magic Module
Back Home Up Next

SUMMARY

This technical note discusses some of the issues that you should be aware of when creating schedules and programs that you want to download to the Magic Module (MM).

What follows are some notes about various features and limitations of the MM and how they effect HCA.

Limitations on download to MM

When you select programs and schedules for download to the Magic Module, the download wizard prevents you from selecting some programs and some schedules.  This list describes what types of things that will prevent a program or schedule from being selected for download.   All of these limitations are directly related to the instruction set within the Magic Module and its memory.  It is a simple processor that exposes a simple interpreter with an instruction set created by Elk Products.  Some of these limitations are minor and some are major.

bulletThe download compiler checks for appropriate hardware options before downloading.  For example, things that use X10 can't be downloaded without an X10 interface, iButton triggers without an iButton interface, etc.
 
bulletAll triggers for programs, groups, device alternative triggers must all  be on a single house code per Magic Module.  This is a limitation of the Magic Module instruction set.  For example you could have two programs: one triggers on B1 and the other on G1.  You could select the B1 program for download, the G1 program for download, but not both.   If your application required that you respond to different housecodes, you can use more than one Magic Module.  More information on this technique is given later in this technical note.
 

Schedule downloads have these limitations:

  1. Schedule entries for programs not downloaded are dropped
  2. Schedule entries for groups are changed to schedule each member
  3. Any entries for a specific date (day-month-year) have the year part dropped
  4. All 'Vary by" part of schedule entries dropped
  5. All plus / minus from sunset / sunrise are changed to happen exactly at sunrise / sunset
  6. A maximum of 4 schedules can be selected for download
  7. Schedules can't be downloaded unless Magic Module has a clock or something on the 485 bus that transmits time data
     

Programs with these elements can't be downloaded

  1. Repeat
  2. WaitUntil
  3. RunProgram
  4. Suspend
  5. Resume
  6. Stop
  7. LynxRelay
  8. LynxInput
  9. LynxAnalog
  10. LynxADCTest
  11. LynxGroupAorB
  12. Compute
  13. ComputeTest
  14. Weather
  15. IR
  16. SendIR
  17. Speak
  18. PLCFirewall

These elements are dropped from download programs.  They are considered minor:

  1. ChangeIcon
  2. DailyMessage
  3. ShowMessage
  4. PlaySound (Note: This element is for playing sound files through the computer sound system and shouldn't be confused with the support for the Elk Products Voice Module, which is fully supported for download)
  5. AddToLog
     

These elements have limitations:

  1. On and Off
    Error occurs if the element references a program.  It can reference a group but not a group containing a program.
  2. Dim
    Can't use any devices or group members that use extended commands to dim.
  3. Test: Testing for On/Off
    The test is made based upon the current state recorded in the Magic Module.  Even if the device supports status requests, no status poll is sent.  Only devices, and not programs or controllers can be used
  4. Test: Testing for dim
    Testing for dim is changed to a test for On
  5. Test: Testing for suspend
    Testing for suspend not supported
  6. Test: Time tests
    Testing for the current time between two times - including sun times -  is supported but with a restriction.  The Magic Module does not have any direct support for this and the solution that is used may not work correctly until the download has been running for 24 hours.
  7. Test: Date tests
    Testing for weekday sequence (1st Monday, 3rd Tuesday, etc) not supported.
    Testing for specific dates month-day-year, the year is not used.
    Testing for the current date between two dates is not supported
  8. Test: Started By
    When HCA executes a program, its starting trigger is always available for testing.  When downloaded to the interface the starting trigger  may be lost soon after the program starts.  Testing the start condition,  unless right after the program starts, may be unreliable.
  9. Send X10
    The milliseconds delay between each command is ignored
  10. StartProgram
    Error if the referenced program not selected for download
  11. Thermostat
    Supported for the MTHT and RCS thermostats.  No special communications modes are supported for RCS thermostats.
  12. Thermostat Test
    Not supported for RCS thermostats.  Testing for the MTHT setpoint is not supported.
  13. ChangeSchedule
    Must reference a schedule marked for download
  14. MakeFlagYes / MakeFlagNo / NotFlag
    A maximum of 41 yes/no flags can be downloaded
  15. MMCounter
    Can only be used with inputs on the Magic Module being downloaded into and not another MM on the 485 bus.
  16. No element can control a UPB or Insteon device or controller

These are several other limitations:

bulletProgram triggers on inputs can only reference the inputs on the Magic Module being downloaded into
bulletProgram X10 Alternative triggers can't use Preset Dim commands
bulletThere can be at most 4 delay elements active simultaneously. 
bulletThere can be at most 3 MM Counter elements downloaded.
 

 

More information on how HCA programs handle their triggers

As part of the program properties you can specify what happens when the trigger for a program is received when the program is already running.  In HCA you have three options:
1. Ignore it
2. Restart the program from the Begin Here element
3. Run a second copy of the program concurrently.

When downloaded to the MM, all programs act as if they had option #2, that is, they restart from the Begin Here.  You have no option on this.

There is a second related complication of this that is a bit technical when Delay elements are added to the mix.

Suppose a program looks like this:
On Lamp
Delay 1 minute
Off Lamp

Suppose this program is triggered on an A1 ON.  If an A1 ON arrives the program starts.  If during the delay another A1 ON arrives, the "ON Lamp" is done and then the delay restarts from 1 minute.  This should be clear.

Now, suppose you have this program
On Lamp
If Flag1 is No
  Set Flag1 to Yes
  Delay 1 minute
  Off Lamp
End if

Again assume that the an A1 triggers this program.  An A1 ON happens and the Lamp goes on.  Then let's assume that Flag1 is No, so the test succeeds and Flag1 is set to True, then the delay starts.

Now assume another A1 ON happens during that delay.  The program starts again: It does the On Lamp.  Since Flag1 is Yes, the failure path of the test happens and the program exits.

But what about that unexpired delay from the first invocation of the program?  When the minute is up the Off of Lamp will still happen !

This is because of how HCA has used the MM event facilities - how the MM responds to various events like a clock tick, an X10 reception, or a change in input voltage - in assembling programs for download.  Take note if you care about this sort of thing.

 

Downloading programs that don't have triggers

Select a program and go look at the advanced properties.  In the group labeled "Start", focus your attention on the option labeled "When HCA is started normally".

If this option is checked for a program that is selected for download, that program will start running immediately after the download completes. That is, it does not need to be triggered.  Also, if the MM is powered off, then powered on again the program will start at its beginning.

Why would you use this?

In the MM all flags start off as "No".  If you wanted to set up the state of the flags to some special values or you wanted to select a schedule, you can create a program that does this.  The program would run, do what it needs to do and exit.  This program would complete before the MM starts fielding program triggers or time based events.

For really sophisticated folks who wanted to use the MM more as a tool dedicated to one task rather than an automation controller this is useful!

You could write a single program that gets downloaded that has a forever loop in it - perhaps with some delays.  All that the Magic Module would do is in this program and it is marked to start right after download.

As an example, I used the Magic Module to build a solution for a friend of mine who needed to cure some material in a temperature controlled box for a few days.  I used the MM and the MM temperature sensor to turn on and off light bulbs using the MM relays.  Once downloaded the program started.  It checks the temperature and if it's too low, it turns on the lights.  If it's too high then it turns the lights off.  This program delays for a bit and loops back to test the temperature again.

I created this program in HCA and downloaded it to the MM which was then disconnected from the PC and given to him.  Now when he needs to run the temperature controlled box he just powers up the MM and lets it go.  When he is done he powers it down.  Nothing needs to start the program - it starts when the MM is powered on.

 

Magic Module Network

One of the nice features of the Magic Module is that you can use more than one and, if connected to the same 485 bus, they can operate as a network.  This has several advantages.  You can use it to expand the number of housecodes responded to (the housecode limitation described earlier), one MM can offer it's X10 interface or iButton reader for use by other Magic Modules,

Each MM can have it's own programs and schedules downloaded to it.  For example, suppose you have two programs.  One responds to A1 the other to B1.  Clearly both can't be downloaded into the same MM. But you could download one program to one MM and the other program to the other MM.

Only one of the MMs needs to have a X10 interface.  The other MM gets its X10 services from the MM with the X10 interface.  So back to the example.  MM one has the X10 interface and in its memory resides the program that triggers on A1.  MM two has the program that triggers on B1.  Even though MM two doesn't have an X10 interface it still gets the B1 trigger and starts the program running.  That program could also send X10 commands using the interface on MM one.  It is important that MM one be programmed to broadcast X10 receptions on the 485 bus.  This is done in step 2 of the download wizard.

The same facilities are available for an access device reader (IButtons, etc) attached to a MM.  All MMs will receive the scans from it.

In addition to sharing the X10 interfaces, a network of MMs can:

bulletMM one can test the state of any of its relays and also the state of any of the relays on MM two.
bulletMM one can control any of its own relays and any of the relays on MM two.
bulletMM one can test the input voltage on any of its own inputs and any of the inputs on MM two.
bulletIf MM one has a MT100 temperature sensor, MM two can test the temperature of that sensor.

In the above this we talk about two Magic Modules, one and two.  But don't forget that you can have as many as 31 MMs connected on the same network.

But there are a few limitations

bulletA change to one of MM one's inputs can only trigger a program downloaded into MM one.  That is, not a program downloaded into MM two.
bulletThe MM Counter element can only be used to count input voltage changes on the MM downloaded into it and not for input changes on another MM on the network.
bulletDue to a limitation of the MM facilities, preset dim commands can only be sent using an X10 interface attached to the MM doing the send and not using a X10 interface attached to another MM.

Finally, remember it is up to you to fashion your download into the various MMs on the network.  You need to decide what goes where.