-
The chkconfig: line in the init script needs tuning, it should start last
so user macros get a working system to play in.

-
Support A:ALL_LIGHTS_ON macro triggers.  The 'A' part isn't handled
currently.


-
Add an optional name to the DEFINE command.  Eg, DEFINE A2 LIGHT light1. 
ALIAS functions to group things, not provide names for the actual device.
This makes much more sense.


-
What about modes?  We could have user-defined mode names like 'night',
'home', 'away', etc...  More than one can be set at the same time.  These
can then be used in the conditional statements like IF.  We could simplify
this by just calling them variables.  Add a 'SET' command to the conf file
and the commandline to set them.  If a value to test it against isn't
specified, it checks for 1 and 0 to mean on or off.  IF would be able to take
either a device:status combo or a variable=value.  So for instance:

VARIABLE "mode" "home", "away"

MACRO (motion1:ON) {
	
	IF (mode="away") {
		RUN "play welcome-home.au"
		COMMAND lights:ON
		SET mode="home"
	}
}


-
Variables should be expandable in strings.  Example: RUN "echo $mode".


-
It would be nice to have variables for the trigger so we don't have to build
similar macros for each thing.


-
Show the base names of devices in monitor messages.  This is much easier if
we have the name-on-DEVICE thing added.  ALIAS should be used only for
groups now.


-
Need to check date setting on powerfail.


-
DAEMON_COMMAND_TIMEOUT and HOUSECODE need to be used.


-
IF, ELSE, variables, SET, COMMAND, --set, --value.


-
The configuration file isn't documented.  This is probably a good thing
right now, as it's very subject to change.


-
Do something about those address/function mismatch errors.  They should be
expected.  We know the cm11a is braindead.  Also, read timeouts should be
expected also.  This seems to happen a lot in practice, I guess it just
misses the poll received byte.

NOTE: Does this still happen with the signal corrections?


-
Cure memory leaks so refreshing the conf file many times doesn't drive us
into the ground.


-
Need to maintain the status info in the device structure.  Have a call to
process an Event and update the device structures.  The daemon and client
can use the same code.  Might want to add a hook for the client so that when
it is in 'status' mode, these changes are displayed.


-
Documentation should be in texinfo for the most part, man pages only for
ussage of the programs, not to document the conf file.


-
Client commands need to be repackaged as events and sent to the event
handler.

The COMMAND command should send the event but not allow macro execution for
it, if we want that use RUN "ppower ...".  That will get around problems
with infinite macro loops.


-
To get around the weird use of DIM/BRIGHT by the x10 stuff, we can have a
lock on the address buffer.  When we get a command, we lock the address
buffer.  If we get another command, we assume it is going to the same
addresses.  If we get an address when the buffer is locked, we flush it
before adding the new one.


-
IF is too simplified.  Just having states isn't as good as allowing full
expressions.  We should allow using && and ||.  I don't think we need
anything else.  Eg:

IF (light1,light2:ON && fan:OFF) {
	COMMAND fan:ON
}

Note that the light1,light2:ON is interpreted as light1:ON || light2:ON.

Compound names are also treated as ORs between each element.


-
Need to check for conflicting definitions when we define devices, aliases,
and named macros.  Note that we can have two macros that have the same
accepting events.  Both will be called when the matching event comes in.


-
Probably the easiest way of implementing EEPROM and hardware macros is to
write a decompiler for EEPROMs so we know all the oddities we'll need to
handle.  That will let windows users use their EEPROMs too (assuming their
software saves a data file).  We'd have ppower understand --dump-eeprom=FILE
so you could write your config stuff into a windows-usable file too..  A
--write command would take care of writing the EEPROM.

The EEPROM is built by the conf file reader from HMACRO tags.


-
The pid file writing allows people to clobber files via symlinks.  Probably
isn't a problem as you shouldn't be creating sockets and pid files in
world-writable directories and the example conf file warns about this, but I
still don't like it.


-
DIM and BRIGHT values in percentages.  Warns if it rounds to zero.


-
I'm not sure how extended transmissions should be implemented as I don't
know of anything that uses them.


-
Need to manage UUCP-style locking on the tty.


-
Make sure that the socket creation isn't giving it extra modes.  If so,
we'll need to tweak the umask to prevent permission races.


-
Features of the CM11A not yet supported:

EEPROM data transfer and hardware macros.

Enable ring.

Disable ring.

EEPROM address transmissions.

Time update request. - possibly implemented, need to test it. ;)

Get time and other status stuff.
