The World of Computer Software/World_Of_Computer_Software-02-385-Vol-1of3.iso/x/x10ctl21.zip/X10CTL21.TX_

Text File | 1992-12-25 | 21KB | 458 lines

X-10 Control Program for Windows (X10CTL)  Ver. 2.1


**** NOTICE

This program is available at no cost from the Author, Larry E. Fosdick
[CIS 70105,1142].  No warranty, either expressed or implied, covers
losses of data, fingernails, or hair from the use or abuse of this
software.  This program may be freely distributed.  No money is to
be collected for this software, especially by the author, who did this
for recreation. The source code is NOT available.


INTRODUCTION

This program, written in Microsoft Visual BASIC, provides complete access
and control for the X-10 Powerhouse Interface (X-10 USA Inc.).  Features
include:

   - True multiple window application
   - X-10 clock can be automatically synchronized to computer system clock
   - Console window for immediate control
   - Descriptive unit definitions entered by user
   - Timed events are easily added, deleted, or modified, with
     changes downloaded    automatically to the interface
   - Timed event sets can be saved to and restored from disk files
   - Timed events can be set to
      Today, Tomorrow, Everyday, Weekdays, Weekends, or Specific Days
   - Event list can be printed for reference
   - 16-position dimmer function for lamp units or light switches
   - Powerful Batch facility added (new in Version 2)

X10CTL requires the X-10 Powerhouse interface from X-10 (USA), Model CP290.
It can be purchased from DAK Industries (at times), Radio Shack, CompUSA,
and probably others.

I do not endorse any equipment vendor.  This information is provided
to answer queries Revision 1.00 generated.  There may be other vendors.
I bought my X-10 Powerhouse from DAK in 1986, and it works very well.

I recently added a 486 motherboard to my computer system.  The DOS software
supplied by X-10 USA no longer functions.  I'm contacting them to see if they
provide technical support.  For you, this means I can no longer test my
software side-by-side with the original.  The last time I tried, it worked
well (with one exception, described in the Technical Section).


PROGRAM INSTALLATION

The following files, included with the X10CTL package, are
installed in the Windows SYSTEM directory:
     spin.vbx
    cmdialog.vbx
     gauge.vbx

These files are part of the Microsoft Professional Toolkit.

The following files are not included in this package to
conserve download time, and are available separately on
CompuServe:
    VBRUN200.DLL
    COMMDLG.DLL

No changes are made to WIN.INI or SYSTEM.INI.  A private .INI file,
X10CTL.INI is created in the Windows directory.


PROGRAM OPERATION

The first time the program is started, X10CTL.INI is created in your
Windows directory.  This file maintains initialization parameters for
X10CTL, including the COM port number, window positions, and unit
descriptions.  You will be required to enter the COM port for the
X-10 Interface the first time the program is run.  If you change the
port in the future, you will have to edit X10CTL.INI, since the program
will not operate without the Interface active.


Main Window

The Main window provides access to the other windows in the application.
Access can be gained by double-clicking the appropriate icon, or through
the menu system.  The Unit, Event, Batch, and Console windows can be open
concurrently, with free movement between these windows.


Unit Window

This window allows the user to describe up to 256 units (A1 - P16).  The
descriptions are stored in X10CTL.INI in the format

        HUU=Description String

where H is the House Code (A-P) and UU is the unit number (01-16).  The
leading zero is required.  Unit descriptions are added by first selecting
House and Unit codes, then clicking the Add/Edit button.  A dialog box is
opened, allowing the user to enter a series of characters describing the
function of the unit.  Changes are saved when the application is terminated.

Unit descriptions can be edited by first selecting the unit to be edited,
either using the House and Unit buttons, or by clicking the entry directly
on the list, followed by clicking the Add/Edit button.

Unit descriptions can be deleted by selecting the unit of interest, followed
by clicking the Delete button.

In Version 1.2 and later, unit number 17 (which does not exist physically)
is predefined as "All Lights On/Units Off".  This function was added at the
request of users, who wished to be able to program "All Off" functions as
events.  Note that any "On" events are translated automatically to "Dim00"
(Highest lamp unit output) so that "On" functions will only work on lights
connected to lamp or wall switch modules.  The "Off" functions will work
with all units assigned to the given House Code.

Event Window

When the Event window is first opened, the events stored in the X-10
Interface are uploaded to the computer, then displayed. Events can be
added, updated (modified), or deleted.  All changes to the event list
are sent to the X-10 Interface immediately.  The Event window thus always
represents the current action list in the X-10 Interface.  The Event List
can be printed for reference or easy review.

Events are added by selecting the following components in any sequence:
   - Unit
   - Mode (Today, Tomorrow, Everyday, Weekdays, Weekends, or Specific Days)
   - Action (On, Off, or Dim)
   - Time (24-hour format)
   - Security (Checked or Unchecked)

The Unit and Mode are selected from drop-down lists.  The Unit list is
constantly updated from the Unit window.  If a desired unit is not defined,
simply switch to the Unit window, add the unit description needed, then
switch back to the Event window.

Remember that both windows can be open concurrently.  I tried to
make it possible to view both windows without overlap, but there
is simply too much information needed for full functionality.

If Mode is Specific Days, a Day Selection control box is displayed.  Check
the days you wish to have the action take place.  The box is not displayed
in the other modes, since the days are implicit in the mode definition.

If Action is Dim, a Dim Level control is displayed.  Use the spin buttons to
select the dim level between 0 (full bright) to 15 (full dim).

To change the Time, click on the hours or minutes areas, then use the spin
buttons to change the selected value.

Events can be updated by first clicking on the line describing the event,
then changing controls as needed, followed by clicking on the Update button.
When an event is selected by clicking on it, all controls are updated to
match.  This simplifies changes, since most controls will be correct.
Note that the days in the Specific Days mode appear gray to differentiate
the days selected in the interface from those being changed.

Events can be deleted by clicking on the event, followed by clicking the
Delete button.  There is no undelete function.

Event files are accessed through the Event window by clicking on
Save or Load.  The current list of events can be saved to disk (default
extension is .X10).  Events loaded from a disk file will completely replace
the events in the interface, i.e., any events in the interface are erased
when an event file is loaded.


Batch Window

The Batch window contains commands you can send to the X-10 whenever you
want.  The batch sequences can be stored on disk, and there are no limits
to the number of batch files you can have.  Starting with Version 2.1, if
batch commands are in the list box, they are automatically saved to the
most recently accessed batch file when the program ends.  If no file was
specified, the commands are stored in AutoLoad.X1b.  When the Batch window
is opened during a subsequent program run, the most recent file is loaded
automatically.

Each line in the Batch window is a separate batch sequence having the form

    H:OP.U1.U2.U3/

where     H is the House Code
    OP is the operation (on, off, dim)
    U1 is a unit descriptor

Examples

L:ON.1.2.3.4/L:D4.5.6/
turns on units 1,2,3 and 4, then dims units 5 and 6 to Dim04 (D0 is full
bright, D15 is full dim).

L:OFF.1.2.4/L:ON.6/L:D9.11.13/
turns 1,2, and 4 off; turns 6 on; dims 11 and 13 to Dim09.

Batch sequences are defined in a separate window, using simple point and
click operation.  Note that multiple units can be selected in batch mode.
Units having letters large and bold will be included in the batch sequence.

The batch files are stored as simple ASCII files.  You can create batch
files with a text editor.  If you do, any typos are your responsibility.
The BatchAdd function is easy to use, and it ensures proper syntax.


GENERAL COMMENTS

Thanks to all the folks that provided feedback.  Without it, the bugs
couldn't have been swatted as fast.  There may still be more, so be
careful until you are satisfied.  I used the DOS-based software to
save my event list before using this program at first, since you can
easily restore any errors that way.  All you have to do is unplug the
interface and remove the battery for a few seconds.  DON'T use the
change base code function, since your unit descriptions get lost as
well in the DOS-based version supplied with the interface.


TECHNICAL ISSUES

1.  To all of you claiming that your fast CPU was messing up the program:
NO WAY!  I upgraded to a 486/33 motherboard, and all versions back to 1.01
worked as well as they did on my 386SX system.  The DOS software from
X-10 USA no longer works with my 486.


2.  COMM ports, the X-10, and Windows:  This is a little tougher, but you
must understand that the DOS X-10 software supplied with the X-10 console
does not use interrupts when communicating with the X-10 interface (this is
true for Version 1.00 2/86, and probably for newer versions). Windows does,
so all the limitations of sharing IRQ's applies.  In the IBM PC and AT
world (any ISA bus system), COM1 and COM3 share IRQ4, while COM2 and COM4
share IRQ3.  COM1 and COM3 can NOT be used at the same time, nor can COM2
and COM4 be used at the same time, PROVIDED that the software is using
interrupts.  All COMM programs, mouse drivers, and Windows applications
use IRQs, while the DOS-based X-10 software does not.

My system can serve as an example:
    COM1     X-10 interface using IRQ4
    COM2    internal modem using IRQ3
    COM3    not attached at the moment, using IRQ4
    COM4    not installed
    MOUSE    InPort (bus) mouse, using IRQ5

You can see that my modem, mouse, and X-10 all have separate interrupts
assigned to them.  If I connect anything to COM3, then I can only use it
when I am not accessing the X-10 interface.

If you have a serial mouse, modem, and X-10 interface, then you should have
at least three COM ports(maybe four). My suggestion for configuring this
system is:
    COM1    X-10 interface     (IRQ4)
    COM2    mouse         (IRQ3)
    COM3    modem         (IRQ4)

Note you can't use the modem and X-10 at the same time.  If you have
nothing using IRQ5, then you might want to reconfigure one of your ports
to use IRQ5.  Most mouse drivers and Windows 3.1 will accept a nonstandard
setup (provided you tell the software what you've done).

The last thing you want to do is try to share an interrupt between the mouse
and the X-10.  It just can't work with X10CTL.


3.  A user recently sent me a dump file of the commands in his X-10 unit.
It reminded me that a command and an event are two different things.  A
command is "turn unit L01 on", while an event is "turn these units on house
code L on".  X10CTL assigns one command to one event, which simplifies
bookeeping, but wastes the limited memory of the CP290 (only 128 events can
be stored).

The DOS-based software from X-10 (his version, anyway) automatically
combined commands having the same operation, house code, and time, thus
producing commands with two or three units.  This has the benefit of
conserving event memory.

X10CTL cannot work this way without major revisions and fundamental
changes in its operation.  Right now, the events listed in the window
constantly reflect the X-10 CP290 memory, so you know what is going on.
If you turn off the computer, you won't have any surprises (at least
from the X-10).  To combine commands into events, the software would
have to increase greatly in complexity to remain matched to the
interface memory, or the exact tracking would have to be sacrificed.

I have used the interface since 1986, and have used X-10 modules since
1980.  The largest event list I ever created had about 60 events.  I
can't see the need to modify the code to the extent needed for commands
combined into single events.

X10CTL 2.1 will look for these events, and will let you know when it
runs into one.  It will display ?? instead of a unit number, and I
strongly advise against updating or deleting these events from within
X10CTL.

You can force the DOS version to separate the commands by changing the
times by as little as one minute.  If you plan to use the DOS version
alongside X10CTL, just remember to avoid having two identical commands
and times.  When used in this way, one command = one event, and both
programs should be happy.

If there is sufficient interest, I could write a utility to grab the
event memory, massage it into shape, then dump it back out to the
interface.  This would probably be a separate program, minus all the
fluff needed in the user interface.  I estimate that it would require
1-2 minutes to execute, depending on the number of events in the
interface.  Interested parties can send me mail messages with
their opinions.

If this seems inelegant to you, or if you feel that wasting event memory
is not possible, then let me point out that X10CTL is free, and you may
use it or not as you see fit.  I appreciate the interest that many of you
have expressed, but I wrote this for fun, and this change won't be fun.


4.  Additional features: The original program improved in robustness,
performance, and features due to the interest and ideas I received from
users.  The Batch facility and "All Lights On/Units Off" function were
ideas I got from you.  I will still entertain ideas, since this can lead
to uses that I would never conceive.

Another idea I received was to match events to sunset or sunrise.  A
program called X10Win by Tenholder does this already.  I could do this,
but the typing for geographic locations is not trivial.  Also, I never
located an algorithm for calculating sunsets and sunrises (I could have
looked, I suppose).  Right now, there are no plans to implement this.


ERROR MESSAGES AND THEIR CAUSES

Error Opening Port
Either some other program, such as a comm program or mouse driver, is using
the port, or the X10CTL application suffered an uncontrolled crash.  If the
former, adjust the port assignments in your computer (see Tech Section,
above).  If the X10CTL has crashed, you must restart Windows, since the port
was not closed, and access is cut off.  If X10CTL crashes, record as much
information concerning your actions at that point, then e-mail a summary
to me.

Error with X-10 Interface
The port has been opened and configured.  The initial attempt to communicate
with the X-10 Interface has failed.  Possible causes include:
    1.  Wrong com port selected
    2.  X-10 Interface not connected
    3.  X-10 Interface unplugged

Correct the cause(s), if found, and try again.  If everything seems normal,
then it may be an unknown bug in X10CTL.  If you can, try using a different
program to access the interface to make sure the X-10 itself is OK.


Please forward comments, compliments, complaints, bug reports,
or suggestions to

    Larry E. Fosdick  [70105,1142]


REVISION HISTORY

*** Changes in Version 2.1

Automatic save and load for batch files added (see Batch Mode, above).

The Main Window position can be changed and remembered from run to
run (an oversight.  I saved the position on exit, but never read it
when starting up again).

Multi-command events are recognized and brought to your attention,
but not dealt with further (see Technical Issues, above).

Text and stuff are adjusted when in 1024x768 (or higher) video mode.

Several minor tweaks and adjustments which I can't recall and you
probably wouldn't notice (unless you were the one that found the bugs).

*** Changes in Version 2.0

Batch command processing has been added, where you can predefine a series
of commands and send them whenever your little heart desires.

Now that Windows has a common dialog function, I am using it.  You will see
minor changes in file handling for event files.

I also experimented with gauges to show dim level and spin buttons instead
of scroll bars where appropriate.

*** Changes in Version 1.4

A very helpful user determined that X10CTL crashed when first
accessing an X-10 system with a clean memory, such as that caused
by a power failure without battery backup.  This problem has been
fixed.  The startup sequence has also been altered so that the
Main window has the focus on startup.  On some systems, the
program lost the focus after the startup screen was removed.


*** Changes in Version 1.3

Corrected some problems with the file handler.  It seems that
events were uploaded to the Interface faster than it could accept
them, resulting in garbage.  Also corrected some strange things
that crept into Version 1.2 somehow that affected the appearance
but not the performance.


*** Changes in Version 1.2

The ability to print the event list has been added.

A unit description of "All Lights On/Units Off" has been added to the
Unit Window.  This was primarily added for those who wish to send
"All Off" commands while away from home.  I have no idea who will
use it to turn lights on.  Please note that the code uses DIM00
instead of ON, so that this control will only turn on lights that
are connected to lamp modules or wall switches.  The off function
affects all units on the selected house code.  The unit number for
this function is 17, which is not real, but gives the software a hook.

*** Changes in Version 1.1

First of all, version numbers became two digits.

The event upload has been changed again.  It should now work for any
speed CPU, without adding silly delays.  If you have trouble with this
version, please retest the program with a slower cpu speed, if your
computer allows cpu speed switching, then report the results to me.

The intro window was added once I saw how long the screen went blank
while initializing the program.  An odd quirk of Windows causes the
focus to go to a window other than the Main window on my system, so
I tried to incorporate a work-around using the timer.  It caused more
problems than it solved, so I took it back out.  If the Main window
doesn't have the focus when it first comes up, sorry.

It turns out that if you terminate a multiple window Visual BASIC
program (like this one), the Form Unload subprogram is only executed
on the primary window unless you unload explicitly the other
windows.  This "feature" caused problems with saving changes to the
Unit Decription List.  This has now been fixed.

*** Changes in Version 1.01

Three changes were made.  The first addresses an "Illegal Function
Call" error when first starting the program and setting the COM port
for the X-10.  This was a silly oversight.  I use the timer function
to ensure that the Main window gets the focus after the intro window
is removed (normally, the focus goes to some other window).  I now start
the timer after the port configuration window is closed.

The second fix deals with Event updates not working properly in 1.00.
It was simply a bookeeping error.

The third fix deals with uploading events from the interface.  The X-10
Powerhouse does not support any form of handshaking, and so the event
uploading has to be handled by a combination of timing and waiting for
the right number of characters in the buffer.  There are actually two
wait periods.  I have tried to improve the robustness of the routines,
and have added message boxes to help determine where the errors lie.  If
you get an error message box, please record the message and let me know.
CPU's faster than my 16 MHz 386SX may be too fast for my algorithm.  I am
trying to avoid making it too conservative, as this slows event uploads.