linuxha-misc — General topics for Linux Home Automation

Re: [LHA-misc] Sample Commands (was Line parsing routine)

[Neil C. <nc...@ho...>]

Jay Hogg wrote:

> The same *exact* format carries to the ADICON RS-485 direct
> devices except that address 0 is actually on the network and
> not the Ocelot... or if they ever get the Ocelot to fully support
> RS-485 access then you could have a Leopard or Ocelot at an
> address on the ADICON RS-485 bus and all the X10/IR/KEYTOUCH
> domains are valid.
>
> >  Also I noticed that each
> >device has a seperate port are these seperate agents (daemons)?
>
> Yes. They can all be on one machine, separate machines, on
> remote networks through firewalls...  It also makes adding/
> changing or creating brand new interfaces real easy...

Good, that is very clear now, the ADICON device threw me, I had
considered it a subdevice of the Ocelot. I see that it is not in this
case.

Have you given any thoughts to the subdevices being described in XML?
It would probably cause some difficulty but it is what XML is made to
handle. 

BTW, I purchased a book on XML "Teach Yourself XML" by Sandra E.Eddy &
John E. Schnyder (IDG books). It was the only book on the shelves (that
I could find) on XML. I also found a student guide on XML from some
classes given in the building I'm in (at work).

> Always fun. I'm having to learn IE messages on ISDN PRI at the moment
> and doing some advance work on G729 channel banks over ATM without
> the hardware in hand. I can relate fully :)

AH! I actually understand all of that! Hey how about ATM over BiSync over
IP over frame over ATM (the first ATM being Automated Teller Machines at
1200 :-).

-- 
Linux Home Automation           Neil Cherry             nc...@ho...
http://members.home.net/ncherry                         (Text only)
http://meltingpot.fortunecity.com/lightsey/52           (Graphics)
http://linuxha.sourceforge.net/				(SourceForge)

Re: [LHA-misc] Sample Commands (was Line parsing routine)

[Jay H. <jh...@fa...>]

At 10:12 PM 11/28/00 -0500, Neil Cherry wrote:
>Jay Hogg wrote:
> >
> > Ok,
> >     This is from memory and reviewing code since I can't find
> > my paper copy of this and my HD died in March...
> >
> > I've included 2 things inline:
> > - Command/Response document
> > - Sample XML configuration for some of my devices. This is the
> >    "Master" defintion that controls the what/where of all devices
> >    that can be access by the control server.
> >    - Currently called '/usr/local/ha/conf/interface.conf'
> >    - Used by every agent. Start the agent with an 'id' code that is
> >      xrefed in this file to get port/address/device/password/etc.
> >    - The "id" is the prefix to addresses from the server application
> >       (ie  ADDR="napco9600:device.domain.point")
> >
> > Sorry it is so long...  I considered it as an attachment but I
> > know how this group likes to debate inline.  If you want it as
> > an attachment next time just say so.
>
>I think this is fine (but I have a cable modem).
>
>BTW, it is evident that you put a lot of thought into the entire doc.
>Good work! I have some questions (of course).

Thanks. It has been a long time in the works and coincides with stuff
at work that is unrelated except the need for a simple protocol,
*lots* of programs talking, and configs.


> >     <interface
> >        id="ocelot"
> >        desc="Ocelot #1 - Main"
> >        device="//1/dev/cti4"
> >        address="localhost:2004"
> >     />
>
>I noted that the ADICON relay device is seperate from the Ocelot. Is the
>relay controller controled by the Ocelot or is it seperate?
>  The reason I
>ask is that I was wondering about sub devices.

This is an *interface* level definition - specifically defined
by the fact that it is physical (not logical).

The addressing handles the sub-devices.
Ocelot axample:
Addr=0.*  is the Ocelot itself (sub unit); further subdefined by:
      0.0.*    is X10
      0.0.A1   is X10 device A1
      0.1.*    is IR
      0.1.1    is IR code 1 from the ocelot (xmit or recv)
      0.2.*    is Inputs (none on Ocelot)
      0.3.*    is Outputs (none on Ocelot)
      0.4.*    is Keytouches
      0.100.*  is Parameters
      0.101.*  is Timers
      0.102.*  is Variables
Now if I want the relay module off the Ocelot @ address 1:
      1.3.*    is Outputs
      1.100.*  is Parameters
or SECU16 @ 2
      2.2.*     is Inputs
      2.3.*     is Outputs
      2.100.*   is Parameters

The same *exact* format carries to the ADICON RS-485 direct
devices except that address 0 is actually on the network and
not the Ocelot... or if they ever get the Ocelot to fully support
RS-485 access then you could have a Leopard or Ocelot at an
address on the ADICON RS-485 bus and all the X10/IR/KEYTOUCH
domains are valid.

>  Also I noticed that each
>device has a seperate port are these seperate agents (daemons)?

Yes. They can all be on one machine, separate machines, on
remote networks through firewalls...  It also makes adding/
changing or creating brand new interfaces real easy...


>I'm working on an XML definition for the HCS and I need to get this
>straight in my head (this while learning about Frame Relay/ATM switches,
>hand off through online docs :-).

Always fun. I'm having to learn IE messages on ISDN PRI at the moment
and doing some advance work on G729 channel banks over ATM without
the hardware in hand. I can relate fully :)

Jay


>--
>Linux Home Automation           Neil Cherry             nc...@ho...
>http://members.home.net/ncherry                         (Text only)
>http://meltingpot.fortunecity.com/lightsey/52           (Graphics)
>http://linuxha.sourceforge.net/                         (SourceForge)
>_______________________________________________
>http://lists.sourceforge.net/mailman/listinfo/linuxha-misc
>To unsubscribe, send "unsubscribe Linuxha-misc"
>in the body of a message to  Lin...@li...

Re: [LHA-misc] Sample Commands (was Line parsing routine)

[Neil C. <nc...@ho...>]

Jay Hogg wrote:
> 
> Ok,
>     This is from memory and reviewing code since I can't find
> my paper copy of this and my HD died in March...
> 
> I've included 2 things inline:
> - Command/Response document
> - Sample XML configuration for some of my devices. This is the
>    "Master" defintion that controls the what/where of all devices
>    that can be access by the control server.
>    - Currently called '/usr/local/ha/conf/interface.conf'
>    - Used by every agent. Start the agent with an 'id' code that is
>      xrefed in this file to get port/address/device/password/etc.
>    - The "id" is the prefix to addresses from the server application
>       (ie  ADDR="napco9600:device.domain.point")
> 
> Sorry it is so long...  I considered it as an attachment but I
> know how this group likes to debate inline.  If you want it as
> an attachment next time just say so.

I think this is fine (but I have a cable modem).

BTW, it is evident that you put a lot of thought into the entire doc.
Good work! I have some questions (of course).

>     <interface
>        id="ocelot"
>        desc="Ocelot #1 - Main"
>        device="//1/dev/cti4"
>        address="localhost:2004"
>     />

I noted that the ADICON relay device is seperate from the Ocelot. Is the
relay controller controled by the Ocelot or is it seperate? The reason I
ask is that I was wondering about sub devices. Also I noticed that each
device has a seperate port are these seperate agents (daemons)?

I'm working on an XML definition for the HCS and I need to get this
straight in my head (this while learning about Frame Relay/ATM switches,
hand off through online docs :-).

-- 
Linux Home Automation           Neil Cherry             nc...@ho...
http://members.home.net/ncherry                         (Text only)
http://meltingpot.fortunecity.com/lightsey/52           (Graphics)
http://linuxha.sourceforge.net/				(SourceForge)

Re: [LHA-misc] Line parsing routine

[Paul F. <pg...@fo...>]

 > 
 > I wonder can we drop the addr= and value= ? If they're always in the
 > same position we can drop them. But if the addr= can be replaced with
 > something else then we'll need them (is this too short sighted?). Also

while it _can_ be typed by a user, i don't see this command set as
being something anyone would _want_ to type.  given that there will
probably always be some sort of UI in front of this, then requiring
the addr= and value= keywords is probably the right thing to do.  the
ambiguity you'll eliminate if you someday, say, decide to add "name=...",
will make it worth it.

 > we've planed for. Also can we have more than 1 value? Say we d/l some
 > code to the Ocelot, we can first send the size of the file (make
 > reserving memory easier) then the actual file, which can we a stream
 > of 8 bit characters (no null or <CR> to worry about or escape).

this is a good idea.  but don't require sending the size of the file
first.  or at least make it device-specific.  it's hard to do
on-the-fly compression if you need to know the final size up front.

paul
=---------------------
  paul fox, pg...@fo... (arlington, ma, where it's 40.6 degrees)

Re: [LHA-misc] Line parsing routine

[Jay H. <jh...@fa...>]

Not to get out-of-sync with the last posting (in response to another
request) you have some good points (Q's) in here that I think need to
be addressed:

At 12:14 AM 11/28/00 -0500, Neil Cherry wrote:
>I've looked over what you've posted so far and it looks good. Now I have
>few questions.
>
> >What I've got implemented as far as commands are:
> >USER <user id>
> >PASS <password>
>
>The login/password part is difficult, how does one let an LCD login?
>We can allow a default/guest id that is active when they connect. This
>would allow monitors to do their work.

LCD's/UI's fall in an interesting area (at least the way I think
about them) because (1) they generate events and have a proprietary
control interface (be it web, lcd, leopard, ...) but (2) they make use
of information from other "agents" for display purposes.

I see 3 ways to implement them. I have an LCD+ sitting here, still
waiting for an LCD-80 to appear (not holding my breath) so I am not
to biased towards either of these methods but the nature of the Leopard
being a primary agent interface (ADICON) and UI (or multiple UI) almost
forces both methods be available.

OSI Model (selected pieces):
~3 - Agents
~4 - Server that dispenses events and plays "traffic cop"
~6 - UI handling
~7 - Actual interface (web, ...)

Problem is #7 can be a real interface or #7 can be forced back through
layers 1-3 because it is a hardware device. With that in mind:

(1) Web/Program (non-hardware) UI devices sit at 6/7. They talk to
the server and display info. Login is easy to accomplish in this
picture.

(2) A UI interface "logic" sits at 6 for communications with the server
and agents and implements its own 1..3 for talking to an LCD/etc. Easiest
and the most flexible. This lets the UI app implement menus, receive
events from the server, and submit commands to the server. Problems are
(a) I don't see this working well for things like the Ocelot that support
both UI and sensors (we need a term for these!) and (b) it forces the
program providing the UI to be running on the system with the physical
hardware interface.

(3) A UI app that runs at layer 6 so it gets the benefit of sitting
"on top" of the server but it also opens "agents" directly, manages
it probably via module-specific commands (it means a UI app can't be
100% generic) and receives 8xxx/9xxx events as things happen. The
"UI" events probably need to be a different 8XXX code so they can be
filtered from the server (the UI app will interpert them, navigate
menus, then submit events to the server). This allows management of
the Ocelot via the normal agent commands for all the control and via
MODX commands for the display.

My preferred methods are (1) and (3) as appropriate.

The short version is *devices* don't log in - they are managed - they
may *implement* a login for user functions but that is at a higher
level.

>  But logins would have to be
>through a secure channel (no plain text). That one we can leave for
>a while.

If it is not over internal hard-wire (rs485, Ether inside a firewall)
then I agree 100%. Remember, most (all) of these logins will hopefully
be to a web/UI agent on the upper layers where security is already
defined. I realize sometimes *I* may want to log directly into an
agent (the wife complains that it is 45 degrees inside and the system
has her locked out) but I don't see that as a normal occurrance.

I'll leave off the rest of the comments and continue with the other
document after you've had time to absorb. A lot of it is addressed
in that document - note that some "commands" have different names -
the one I posted in the beginning was from a March email between us
and the full document was pulled from notes and running code (closer
to reality).

Jay

Re: [LHA-misc] Sample Commands (was Line parsing routine)

[Neil C. <nc...@ho...>]

Uhm, OK, was that a response to my question or a coincidence in timing?

Wow, that is great! I wasn't quite sure how I was going to work that into
the code base but the XML part is just UPnP. I'm not sure we're ready to
jump that far into it yet but if we plan it right it should fall right
into place.

Like I said, Wow!

I now need time to absorb.

Thanks

-- 
Linux Home Automation           Neil Cherry             nc...@ho...
http://members.home.net/ncherry                         (Text only)
http://meltingpot.fortunecity.com/lightsey/52           (Graphics)
http://linuxha.sourceforge.net/				(SourceForge)

[LHA-misc] Sample Commands (was Line parsing routine)

[Jay H. <jh...@fa...>]

Ok,
    This is from memory and reviewing code since I can't find
my paper copy of this and my HD died in March...

I've included 2 things inline:
- Command/Response document
- Sample XML configuration for some of my devices. This is the
   "Master" defintion that controls the what/where of all devices
   that can be access by the control server.
   - Currently called '/usr/local/ha/conf/interface.conf'
   - Used by every agent. Start the agent with an 'id' code that is
     xrefed in this file to get port/address/device/password/etc.
   - The "id" is the prefix to addresses from the server application
      (ie  ADDR="napco9600:device.domain.point")

Sorry it is so long...  I considered it as an attachment but I
know how this group likes to debate inline.  If you want it as
an attachment next time just say so.

Jay

----- Begin Command/Response Document ---------
Sample telnet protocol for HA interfaces

**************************************************************************
Commands and Syntax
**************************************************************************

All commands are case insensitive and are entered one-per-line
terminated by a CR or CR/LF.

----------------------------------------
Core "Agent-1.0" Commands
----------------------------------------

USER - Login Request

    Used to perform a basic login for control purposes.

    Format:
       USER <username>

    Expected Response(s):

    Notes:
       - The paramater of this command is case sensitive.

PASS - Provide a password

    Supply a password for the pending USER login request.

    Format:
       PASS <password>

    Expected Response(s):

    Notes:
       - The paramater of this command is case sensitive.


QUIT

    Terminate the management session.

    Format:
       QUIT

    Expected Response(s):

    Notes:
       - Allowed before User/Pass.


IDENT - Identifies the module you are talking to

    Used to provide an application a method to identify what it
    has attached to in order to validate configuration data (ie,
    make sure IP/Port and Module match)

    Format:
       IDENT

    Expected Response(s):
       1225 [Module Identifier]
       where [Module Identifier] could be:
          OCELOT-1.0, LEOPARD-1.0, ADICON-1.0, NAPCO9600, ...

    Notes:
       - Allowed before User/Pass.

LANG

    Provide identification of the language subset supported by
    the management module.

    Format:
       LANG

    Expected Response(s):
       1226 [Language Identifier]
       where [Language Identifier] can be one or more of the
       following separated by spaces:
          Agent-1.0 - Agent command syntax version 1.0
          ModX      - Module specific extensions

    Notes:
       - Login required.

HELP

    Provide some level of help for basic commands since all of
    us forget things. Some of us more than others these days.

    Format:
       HELP [command]

    Expected Response(s):

       1210-Supported commands:
       USER      PASS     LANG     QUIT    HELP
       SET       GET      DUMP     WDOG    EVENT
       1210 Supported commands:

       1211-Command help:
       HELP - Provide detailed information about commands

       If you need help this badly you shouldn't be playing with
       your home controls!

       1211 Command help:

    Notes:
       - Login required. (anti-hack)

SET

    Change the current values of controllable information.

    Format:
       SET ADDR="..." VALUE="..."

    Expected Response(s):
       TBD - Need Good/Bad. Probably also need to echo ADDR, VALUE
       in response to handle things like relative adjustments well.

       1310  Invalid address.
       1311  Invalid value.

    Notes:
       - Login required (obviously)

GET

    Retrieve the current value of controllable information.

    Format:
       GET ADDR="..."

    Expected Response(s):
       TBD - Need Good/Bad. Needs to include ADDR and VALUE.

    Notes:
       - Login required (obviously)


DUMP

    Used for dumping large amounts of information. This is designed
    primarily for manual command interface assitance but can be
    used by a program to enumerate supported addresses.

    Format:
       DUMP ADDR="<wildcard address>"
       where <wildcard address> can be in the format of:
          *, device.*, device.domain.*, *.*.*.*

    Expected Response(s):
       1250-Configuration dump:
       Addr="..." Value="..." Desc="..." Range="#,#" Unit="..."
         ValueTypes="Absolute,Relative"
       1250 Configuration dump:

    Notes:
       - Login required (obviously)


WDOG

    Format:
       WDOG <timeout>
       where <timeout> is time in seconds with no response before
       a session is declared "dead" and the agent can take appropriate
       action to cleanup as necessary.

    Expected Response(s):
       1222 Watchdog set.
       1312 Invalid timeout.

    Notes:
       - An event 8010 will be generated at 1/2 the time to
       the timeout. ie, a 120 watchdog will generate an
       event at 60 seconds.

       - Any command will reset the watchdog.

EVENT

    Sets the mask for events to be received.

    Format:
       EVENT [CLEAR|8XXX|9XXX|WDOG]

    Expected Response(s):
       1213  Event mask set (Current mask is xxxxx)
       1313  Unrecognized event mask.

    Response on expiration of timer:
       1513  Watchdog timeout. Session closed.

    Notes:
       - This controls whether 8xxx/9xxx events are to be sent to
       this session. If WDOG events are not enabled you will not
       receive the WDOG timeout event at the midpoint but you will
       receive the 15xx code on expiration.

----------------------------------------
Module Specific "ModX" Commands
----------------------------------------

MODX - Module Specific implementation

    Used to provide special interfaces to modules. This is designed to
    be a "catch all" and the paramaters are defined as-needed on a
    module implementation basis.

    Purpose of this command include:
    - Firmware Download        - Direct memory access
    - IR Download              - Direct Serial command/response
    - Speech Download

**************************************************************************
Standard Data Identifiers
**************************************************************************

ADDR - Address
    device.domain.point -or-
    device.domain.group.point

    Note: The discussion of numeric vs text addresses is valid. I have
    considered the validity of the following (and plan on implementing):
       For an Ocelot:
          Addr="0.x10.A1"
          Addr="0.timer.0"

TS - Timestamp
    YYYYMMDDHHMMSS

VALUE - New value to assign

    This must cover a wide variety of options so ideas are:
       Value="100"  - Absolute value (scaling based on device)
       Value="+1" "-1" - Relative scaling
       Value="On" "Off" - Textual names depending on device

    On receipt of events/commands you would get something like:
       Addr="0.x10.A1" Value="On"  (Received X10 A1 On)
       Addr="0.IR.27" Value="On"   (Received IR slot 27)


**************************************************************************
Responses/Error Codes
**************************************************************************

All responses follow the standard FTP/SMTP response format of
a number, continuation identifer, and text.

Responses are broken down into the following classes:
1XXX = Standard Command/Response
12XX   Success
13xx   Temp Failure (login password required)
15xx   Perm Failure

8XXX   Status Messages (events received)

9XXX   Alarms (failures) in a form similar to 8XXX but not fully
        thought through.

1XXX response are generated in response to a command presented.

8XXX and 9XXX are unique in they can be generated at any point
in time (including while waiting for a command response) to
signal a significant event. These events can be, but not limited
to, receipt of a command (IR/X10), expiration of the watchdog,
change in status of a sensor (Alarm, temperature), or what would
be considered a "management" alarm condition (9XXX) where contact
is lost with a device.

During the processing of command/response any 8XXX or 9XXX event
received needs to be queued and handled after the command/response.
On a multi-part received (XXXX-, data, XXXX) tbe events will not
arrive within the message-enclosed data.

1XXX Series responses
----------------------------------------
1210  Supported commands:
1211  Command help:
1213  Event mask set (Current mask is xxxxx)
1220  Initial logon message (Welcome to the CPUXA daemon v1.00)
1221  Goodbye.
1222  Watchdog set.
1225  [Module Identifier]
1226  [Language Identifiers]
1230  Login successful.
1250  Configuration dump:
1310  Invalid address.
1311  Invalid value.
1312  Invalid timeout.
1313  Unrecognized event mask.
1331  Password required.(response to USER when password required)
1513  Watchdog timeout. Session closed.
1530  Login failed.

8XXX Series responses
----------------------------------------
8000  Generic event message. Contains at least the following data:
          YYYYMMDDHHMMSS.SSS TZ SEQ Addr=... Value=...
8010  Watchdog event. TS/TZ/Seq as 8000 but no data.

9XXX Series responses
----------------------------------------
9000  Generic alarm event. Similar to 8000 but more thought is
       needed and probably really need to identify each error
       as an independant 9xxx series number to keep it easy.

----- End Command/Response Document ---------

----- Begin XML interface.conf ---------
<!--- ***************************************************************** --->
<!---                                                                   --->
<!--- $HA/etc/interface.conf - Interface Definitions                    --->
<!---                                                                   --->
<!--- 02Jul00 Written.                                         Jay Hogg --->
<!---                                                                   --->
<!---                                                                   --->
<!---                                                                   --->
<!---                                                                   --->
<!--- ***************************************************************** --->

<Interfaces>

    <!--- **************************************************** --->
    <!---                                                      --->
    <!--- Device Interfaces with fixed physical interfaces     --->
    <!---                                                      --->
    <!--- **************************************************** --->

    <interface
       id="napco9600"
       desc="Napco P9600 Security Panel"
       device="//1/dev/cti1"
       mastercode="123456"
       address="localhost:2001"
    />

    <interface
       id="hvac1"
       desc="RCS HVAC/Front"
       device="//1/dev/cti2"
       address="localhost:2002"
    />

    <interface
       id="hvac2"
       desc="RCS HVAC/Rear"
       device="//1/dev/cti3"
       address="localhost:2003"
    />

    <interface
       id="ocelot"
       desc="Ocelot #1 - Main"
       device="//1/dev/cti4"
       address="localhost:2004"
    />

    <interface
       id="adicon1"
       desc="ADICON RS485 Network #1 (relays)"
       device="//1/dev/cti5"
       address="localhost:2005"
    />

    <interface
       id="lcd-keypad"
       desc="LCD+ w/keypad for testing"
       device="//1/dev/cti8"
       address="localhost:2008"
    />

    <!--- **************************************************** --->
    <!---                                                      --->
    <!--- Device Interfaces located on the network             --->
    <!---                                                      --->
    <!--- **************************************************** --->

    <interface
       id="tini1"
       desc="Dallas Semi TINI #1"
       address="172.31.1.241:1200"
    />

    <interface
       id="tini2"
       desc="Dallas Semi TINI #2"
       address="172.31.1.242:1200"
    />

    <!--- **************************************************** --->
    <!---                                                      --->
    <!--- Special Device Interfaces/Gateways                   --->
    <!---                                                      --->
    <!--- **************************************************** --->

    <interface
       id="weather"
       desc="Dallas Semi to UDP Gateway (arne)"
       address="localhost:2100"
       sourceaddr="0.0.0.0:8890"
    />

</Interfaces>


----- End XML interface.conf ---------

Re: [LHA-misc] Line parsing routine

[Neil C. <nc...@ho...>]

I've looked over what you've posted so far and it looks good. Now I have
few questions.

>What I've got implemented as far as commands are:
>USER <user id>
>PASS <password>

The login/password part is difficult, how does one let an LCD login?
We can allow a default/guest id that is active when they connect. This
would allow monitors to do their work. But logins would have to be
through a secure channel (no plain text). That one we can leave for
a while.

>QUIT
>HELP  (displays allowed commands)
>LANG  (tells language variants - AGENT-1.0 MCUSTOM)

I understand, yet I don't.

>SET <>
>GET <>

SET X10:FF ON

or
SET addr=1:FF value=ON

(should be case insensitive, yes?)

>NOTIFY <>  (Sets notification events to be received)

I've been calling the monitor, I think NOTIFY is part of one protocols
so the use notify is a good idea.

>Mxxx <>    (Module specific for "playing", dlding code/IR on ocelot

Sort of a raw command, like !12000200.

I'd like to see an example of this.

>General format of addresses is:
>[device name:]device.domain.point
>[device name:]device.domain.group.point

ad infinitum (SP?)

I wonder can we drop the addr= and value= ? If they're always in the
same position we can drop them. But if the addr= can be replaced with
something else then we'll need them (is this too short sighted?). Also
if it's device name can we drop the ':'? The x.y.z.aa.bb. .... should
stay, that way we can grow if the devices begin to expand beyond what
we've planed for. Also can we have more than 1 value? Say we d/l some
code to the Ocelot, we can first send the size of the file (make
reserving memory easier) then the actual file, which can we a stream
of 8 bit characters (no null or <CR> to worry about or escape).

-- 
Linux Home Automation           Neil Cherry             nc...@ho...
http://members.home.net/ncherry                         (Text only)
http://meltingpot.fortunecity.com/lightsey/52           (Graphics)
http://linuxha.sourceforge.net/				(SourceForge)

Re: [LHA-misc] Line parsing routine

[Neil C. <nc...@ho...>]

HGu...@ao... wrote:
> 
> Ok,
> 
> This helps a little, Jay have you documented the commands and the correct
> syntax?
> 
> I have added networking support to the HEYU program. Currently you can telnet
> in via a socket interface to the heyu program to status and issue basic
> commands (ie, on/off/dim).
> 
> The new HEYU actually supports and handles two types of services: the
> origional X10D (on the hamx10 service port) and a new format on the heyu
> service port. so you can telnet into either port and get the correct
> communicatios format.
> 
> I need some feedback from the list, first is this a useful  program (the idea
> is to use HEYU to handle CM11A stuff instead on X10D).
> 
> Second, is there a need for the X10D emulation, do many programs use it? And
> if so is the interface documented (i've been reading the source, but I'm
> missing a lot of information about the interface).
> 
> Then lastly, the heyu service (if  you telnet or connect to the heyu port)
> I'm planning on making this new format Jay and Neil are talking about, but I
> need more  information on the proposed syntax to finish up .
> 
> If anyone is interested in trying out this new version of heyu, let me know
> an I will post it, but it's still pretty preliminary (needs a little more
> work) and a lot of documentation.
> 
> Thanks everyone,

I think we're looking at a 50-50 mix (well maybe a slight bit more towards
the HeyU side). I've not seen docs on the X10d interface though I've also
read the source code. I know HeyU has Xtend (x 10 d) and X10d has HomeDaemon.

I'd be interested in looking at the code. :-) If you post it let me know
and I'll add it to my general HA page.

The interface to lhad (I've gotta bet a cute name for this) will be
documented. We're working through that now. I need to reread Jay's message
again to make sure I understand. I think I know what he means as I also
have controllers that support multiple devices. But I need to get a firm
grasp on it. There are going to be I/O commands (set/get type commands),
controller related commands (such as load firmware, not set/get commands
etc), and monitoring commands (monitor this device but not this one). I
currently haven't come up with any others.

-- 
Linux Home Automation           Neil Cherry             nc...@ho...
http://members.home.net/ncherry                         (Text only)
http://meltingpot.fortunecity.com/lightsey/52           (Graphics)
http://linuxha.sourceforge.net/				(SourceForge)

Re: [LHA-misc] Line parsing routine

[<HGu...@ao...>]

Ok,

This helps a little, Jay have you documented the commands and the correct 
syntax?

I have added networking support to the HEYU program. Currently you can telnet 
in via a socket interface to the heyu program to status and issue basic 
commands (ie, on/off/dim).

The new HEYU actually supports and handles two types of services: the 
origional X10D (on the hamx10 service port) and a new format on the heyu 
service port. so you can telnet into either port and get the correct 
communicatios format.

I need some feedback from the list, first is this a useful  program (the idea 
is to use HEYU to handle CM11A stuff instead on X10D). 

Second, is there a need for the X10D emulation, do many programs use it? And 
if so is the interface documented (i've been reading the source, but I'm 
missing a lot of information about the interface).

Then lastly, the heyu service (if  you telnet or connect to the heyu port)  
I'm planning on making this new format Jay and Neil are talking about, but I 
need more  information on the proposed syntax to finish up .

If anyone is interested in trying out this new version of heyu, let me know 
an I will post it, but it's still pretty preliminary (needs a little more 
work) and a lot of documentation.

Thanks everyone,

H. Gunner




In a message dated 11/26/00 7:39:23 PM Eastern Standard Time, jh...@fa... 
writes:

> At 04:37 PM 11/26/00 -0500, you wrote:
>  >Quoting Neil Cherry <nc...@ho...>:
>  >
>  > >
>  > > This was taken from Jay Hogg's recommendation, I hate it because
>  > > it's
>  > > hard to remember (and !12000200 is?) but it is simple and I
>  > > think it
>  > > covers all types of commands that can be sent. Maybe instead of
>  > > value
>  > > we can change that to num= , str=, hex=, oct=, etc?
>  > >
>  > > Hey this is becoming more object oriented!
>  > >
>  >
>  >TO save bandwidth, but make it somewhat readable for debugging, perhaps
>  >you should use single or double char commands.
>  >
>  >Stuff like N=, etc.  But that kinda limits you.  But keeping things 3
>  >chars or less would do fine.
>  
>  Hey Neil, If you don't like it I'm game for changes...
>  
>  What I've got implemented as far as commands are:
>  USER <user id>
>  PASS <password>
>  QUIT
>  HELP  (displays allowed commands)
>  LANG  (tells language variants - AGENT-1.0 MCUSTOM)
>  SET <>
>  GET <>
>  NOTIFY <>  (Sets notification events to be received)
>  Mxxx <>    (Module specific for "playing", dlding code/IR on ocelot
>  
>  General format of addresses is:
>  [device name:]device.domain.point
>  [device name:]device.domain.group.point
>  
>  Where:
>  [device name:] is used from the server side to identify an agent
>  device is the particular address within an agent
>      Ocelots: 0=Ocelot, 1..N=Adicon Bus
>      ADICON:  0..N=Bus
>      RCS Themostats 0..N = Controller # (rs485) or 0 for Serial
>      Napco P9600 0=Main Unit (no others)
>  domain is the area within the device:
>      Ocelot & ADICON:
>        0=X10, 1=IR, 2=Inputs, 3=Outputs, 100=Parms, 101=Timers, 102=Vars
>      RCS Themostats
>        Domain = Zone
>      Napco
>        0=Areas, 1=Keypads, 2=Sensors, 3=Relays
>  item is the particular variable within the domain
>  
>  group was in because some devices have more nesting layers and I
>  needed it when I first layed out the RCS Thems but can't remember
>  why at the moment.
>  
>  Regarding the 1/2/3 character variable names - it doesn't make any
>  difference on the packets if it is <42 bytes because it will be
>  padded. I'd rather use descriptive names plus it make the
>  transition to XML and no-brainer because we just change the format
>  and not the content.
>  
>  Jay
>  
>  _______________________________________________
>  http://lists.sourceforge.net/mailman/listinfo/linuxha-misc
>  To unsubscribe, send "unsubscribe Linuxha-misc"
>  in the body of a message to  Lin...@li...
>  
>  
>  ----------------------- Headers --------------------------------
>  Return-Path: <lin...@li...>
>  Received: from  rly-yd05.mx.aol.com (rly-yd05.mail.aol.com [172.18.150.5]) 
> by air-yd05.mail.aol.com (v77.14) with ESMTP; Sun, 26 Nov 2000 19:39:23 
-0500
>  Received: from  lists.sourceforge.net (mail1.sourceforge.net 
[198.186.203.35]
> ) by rly-yd05.mx.aol.com (v76_r1.19) with ESMTP; Sun, 26 Nov 2000 19:39:03 -
> 0500
>  Received: from mail1.sourceforge.net (localhost [127.0.0.1])
>   by lists.sourceforge.net (8.11.1/8.11.1) with ESMTP id eAR0c2u26703;
>   Sun, 26 Nov 2000 16:38:02 -0800
>  Received: from fastlane.net (fastlane.net [209.197.224.10])
>   by lists.sourceforge.net (8.11.1/8.11.1) with ESMTP id eAR0bSu26681
>   for <lin...@li...>; Sun, 26 Nov 2000 16:37:28 -0800
>  Received: from j_hogg1.fastlane.net (jh.fastlane.net [209.197.226.71])
>   (authenticated)
>   by fastlane.net (8.10.2/8.10.2) with ESMTP id eAR0bQ215022
>   for <lin...@li...>; Sun, 26 Nov 2000 18:37:26 -0600 
(
> CST)
>  Message-Id: <4.3...@ma...>
>  X-Sender: jh...@ma...
>  X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
>  Date: Sun, 26 Nov 2000 18:57:12 -0600
>  To: lin...@li...
>  From: Jay Hogg <jh...@fa...>
>  Subject: Re: [LHA-misc] Line parsing routine
>  In-Reply-To: <975...@ww...>
>  References: <3A2...@ho...>
>   <3A1...@ho...>
>   <3A2...@ks...>
>   <3A2...@ho...>
>  Mime-Version: 1.0
>  Content-Type: text/plain; charset="us-ascii"; format=flowed
>  Sender: lin...@li...
>  Errors-To: lin...@li...
>  X-BeenThere: lin...@li...
>  X-Mailman-Version: 2.0beta5
>  Precedence: bulk
>  Reply-To: lin...@li...
>  List-Id: Linux Home Automation - Misc. Discussions <linuxha-misc.lists.
> sourceforge.net>
>  
>  

Re: [LHA-misc] Line parsing routine

[Jay H. <jh...@fa...>]

At 04:37 PM 11/26/00 -0500, you wrote:
>Quoting Neil Cherry <nc...@ho...>:
>
> >
> > This was taken from Jay Hogg's recommendation, I hate it because
> > it's
> > hard to remember (and !12000200 is?) but it is simple and I
> > think it
> > covers all types of commands that can be sent. Maybe instead of
> > value
> > we can change that to num= , str=, hex=, oct=, etc?
> >
> > Hey this is becoming more object oriented!
> >
>
>TO save bandwidth, but make it somewhat readable for debugging, perhaps
>you should use single or double char commands.
>
>Stuff like N=, etc.  But that kinda limits you.  But keeping things 3
>chars or less would do fine.

Hey Neil, If you don't like it I'm game for changes...

What I've got implemented as far as commands are:
USER <user id>
PASS <password>
QUIT
HELP  (displays allowed commands)
LANG  (tells language variants - AGENT-1.0 MCUSTOM)
SET <>
GET <>
NOTIFY <>  (Sets notification events to be received)
Mxxx <>    (Module specific for "playing", dlding code/IR on ocelot

General format of addresses is:
[device name:]device.domain.point
[device name:]device.domain.group.point

Where:
[device name:] is used from the server side to identify an agent
device is the particular address within an agent
    Ocelots: 0=Ocelot, 1..N=Adicon Bus
    ADICON:  0..N=Bus
    RCS Themostats 0..N = Controller # (rs485) or 0 for Serial
    Napco P9600 0=Main Unit (no others)
domain is the area within the device:
    Ocelot & ADICON:
      0=X10, 1=IR, 2=Inputs, 3=Outputs, 100=Parms, 101=Timers, 102=Vars
    RCS Themostats
      Domain = Zone
    Napco
      0=Areas, 1=Keypads, 2=Sensors, 3=Relays
item is the particular variable within the domain

group was in because some devices have more nesting layers and I
needed it when I first layed out the RCS Thems but can't remember
why at the moment.

Regarding the 1/2/3 character variable names - it doesn't make any
difference on the packets if it is <42 bytes because it will be
padded. I'd rather use descriptive names plus it make the
transition to XML and no-brainer because we just change the format
and not the content.

Jay

Re: [LHA-misc] Line parsing routine

[<bap...@cc...>]

Quoting Neil Cherry <nc...@ho...>:

> 
> This was taken from Jay Hogg's recommendation, I hate it because
> it's
> hard to remember (and !12000200 is?) but it is simple and I
> think it
> covers all types of commands that can be sent. Maybe instead of
> value
> we can change that to num= , str=, hex=, oct=, etc?
> 
> Hey this is becoming more object oriented!
> 

TO save bandwidth, but make it somewhat readable for debugging, perhaps 
you should use single or double char commands.

Stuff like N=, etc.  But that kinda limits you.  But keeping things 3 
chars or less would do fine.

On that note (Neil already knows what I'm about to type) I've got some 
news that may interest you, especiall the HCS users out there.  Any of 
you with an HCS looking to interface it with Linux or whatever....

I've got a prototype Ethernet interface going on an HCS-II system 
here.  It is based on the Dallas Semi TINI board (A SIMM sized board)  
It is running a webserver for serving HTML documents and applets which 
can communicate directly with the HCS.  

Its pretty 'alpha' right now.  But it works!  It sends all HCS status 
data on port 5050 and can handle up to 24 simultaneous connections.  
The data protocol is the same as the normal HCS serial protocol which 
is outlined in Appendix D of the XPRESS manual (online at http://www.cc-
concepts.com/)

The beauty of this is anyone can write Applets or applications to 
communicate with teh HCS.  All I/O and states can be read and changed 
via this socket.  Eventually I plan to add ftp and email functionality 
to the gateway so you can send emails from the HCS and also upload log 
data to remote servers, etc.

TO check it out, go to http://64.40.83.12/  The web pages are served 
directly from teh gateway as are the applets.  Right now I only have an 
applet which will show all console messages.  Right now the test bonard 
is cycl.ing through 8 relays and everytime they change states a console 
msg is sent.

If you play around with the socket (Port 5050) and an applet, make sure 
you use DataInputStream and DataOutputStream objects when talking on 
the socket.  If you use any other language, the data will be regular 
bytes.

Mike

Re: [LHA-misc] Line parsing routine

[Neil C. <nc...@ho...>]

Tom Hull wrote:
> 
> Neil Cherry wrote:
> >
> > I need a line parsing routine, the one I'm currently using is Dan
> > Lanciaci's and his Licensing differs from the GPL. Besides we will be
> > going with Jay's suggestion of set addr=<BLAH> value=<yadayada>. The
> > format is not exactly worked out at this time. So does anyone have any
> > code?
> 
> I have lots of command line scanning code -- split string into argc/argv,
> various quoting, escape sequences, up through substitutions, expression
> evaluation, full-bore scripting languages. What do you want?

Sorry it took so long I've been hack a bunch of code.

I need something that will take a line and determine what command the
user want to attempt. I will guess there are only 2 commands a set and
a get (If anyone can think of others let me know).

The next part is the addr= and the last part is the value=.

The addr= has format of <interface>.<point>[.<item>[.<item> ...]
Each entry will be ascii numbers (literals 0-9 n amount of times up to
the '.') so it can be typed in from a telnet.

The value= has a string format terminated by a null (the null will not
need to be sent). The string may need to be converted into a number or
stored as a string. This way we can send strings with escape sequences,
hmm we may need to support being able to send \xxx sequences. Should we
translate them of just accept the 8 bit character? I know there are some
8 bit characters I can't send from telnet. So I guess we need escape
character support.

This was taken from Jay Hogg's recommendation, I hate it because it's
hard to remember (and !12000200 is?) but it is simple and I think it
covers all types of commands that can be sent. Maybe instead of value
we can change that to num= , str=, hex=, oct=, etc?

Hey this is becoming more object oriented!

-- 
Linux Home Automation           Neil Cherry             nc...@ho...
http://members.home.net/ncherry                         (Text only)
http://meltingpot.fortunecity.com/lightsey/52           (Graphics)
http://linuxha.sourceforge.net/				(SourceForge)

Re: [LHA-misc] Line parsing routine

[Tom H. <th...@ks...>]

Neil Cherry wrote:
> 
> I need a line parsing routine, the one I'm currently using is Dan
> Lanciaci's and his Licensing differs from the GPL. Besides we will be
> going with Jay's suggestion of set addr=<BLAH> value=<yadayada>. The
> format is not exactly worked out at this time. So does anyone have any
> code?

I have lots of command line scanning code -- split string into argc/argv,
various quoting, escape sequences, up through substitutions, expression
evaluation, full-bore scripting languages. What do you want?

-- 
/*
 *  Tom Hull * th...@ks... * http://www.ocston.org/~thull/
 */

[LHA-misc] Linux PDA w/RS-485 & Wireless < $50

[<bap...@cc...>]

Found an interesting thread in Slashdot today talking about a project 
at MIT called Project Pengachu

They are working towards a PDA with Linux OS, 900MHz wireless (200kbps) 
to peers or Internet gateways, and RS-485 hardwire networking with 
software that fits in 1MB.  All for $50 or less.

Very intersting if it pans out.  Would make a REALLY cool HA gadget for 
all sorts of things!

See http://slashdot.org/article.pl?
sid=00/11/24/2010245&mode=thread&threshold=-1

or just go to slashdot.org and scroll down.

Mike

Re: [LHA-misc] Line parsing routine

[<HGu...@ao...>]

Have you looked at the XTend stuff. It have some code written in C that may 
be able to be reused. Looks GPL too.

Do you have an interface specification for the interface ??? For example to 
command X10 would it be:

A10 ON
or,
set addr=A10 value=ON

or currently using x10d,
A10AON

Are you planning on changing x10d for the new interface protocol? How about 
changing the program HEYU instead to handle networking (that does not seam to 
be too hard)?

Just got heyu and Xtend to talk together. They look like good programs but 
need a networking layers added on. Heyu looks a little more functional and 
commented then X10D.



hg.

In a message dated 11/23/00 11:19:34 AM Eastern Standard Time, 
nc...@ho... writes:

> I need a line parsing routine, the one I'm currently using is Dan
>  Lanciaci's and his Licensing differs from the GPL. Besides we will be
>  going with Jay's suggestion of set addr=<BLAH> value=<yadayada>. The
>  format is not exactly worked out at this time. So does anyone have any
>  code?
>  
>  -- 
>  Linux Home Automation           Neil Cherry             nc...@ho...
>  http://members.home.net/ncherry                         (Text only)
>  http://meltingpot.fortunecity.com/lightsey/52           (Graphics)
>  http://linuxha.sourceforge.net/              (SourceForge)
>  _______________________________________________
>  http://lists.sourceforge.net/mailman/listinfo/linuxha-misc
>  To unsubscribe, send "unsubscribe Linuxha-misc"
>  in the body of a message to  Lin...@li...
>  

[LHA-misc] Line parsing routine

[Neil C. <nc...@ho...>]

I need a line parsing routine, the one I'm currently using is Dan
Lanciaci's and his Licensing differs from the GPL. Besides we will be
going with Jay's suggestion of set addr=<BLAH> value=<yadayada>. The
format is not exactly worked out at this time. So does anyone have any
code?

-- 
Linux Home Automation           Neil Cherry             nc...@ho...
http://members.home.net/ncherry                         (Text only)
http://meltingpot.fortunecity.com/lightsey/52           (Graphics)
http://linuxha.sourceforge.net/				(SourceForge)

Re: [LHA-misc] RE: HCS Web Pages

[Neil C. <nc...@ho...>]

Mike Baptiste wrote:
> 
> Neil Cherry wrote:
> 
> >
> > Dave Houston has an interesting project using a Scenix chip and wireless
> > to interface to X10 that sounds great! Give you any ideas Mike? :-)
> 
> Bluetooth has a lot of folks excited, but it is starting to look like
> CeBus.  Lots of promise but taking forever.  But I expect Bluetooth will
> reach store shelves soon.
 
Dave's stuff is a replacement for the TM705 (modification and upgrade
to support most of the X10 wireless stuff).

> One very bad thing about Bluetooth is it kills 802.11 wireless
> networking.  They interfere with each other in a huge way.

This is very bad, IMNSHO Bluetooth will fall. The 802.11 is going to be
too good a thing to pass up (I'm already looking forward to it :-).
 
> Just something to ponder.  Bluetooth could do amazing things for HA.
> But if they can't get Bluetooth and 802.11 to get along, it will be a
> Major problem.  Only time will tell.  I know they are working on it.

Everytime I hear about Bluetooth I hear about some modification to it. First
1 meter range then it was increased, then something else. A moving target,
at least 802.11b is real and here.

>  > BTW how was the show(s)?
> 
> Excellent!  I was really happy to see the variety of HA stuff out there.
>   RS-485 based HA is alive and well, but there are lots of alternatives
> too.  Microsoft wasn't even there (booths were too small I guess!)  The
> interesting thing is I was just as excited in the contacts I made with
> other vendors and talk of collaboration as I was with the customer
> contacts.  The idea of an RS-485 HA network standard protocol has me
> really excited.  We'll see how things go.

Very cool!

To those in the US Happy Thanksgiving to those else where, have a nice
day!

-- 
Linux Home Automation           Neil Cherry             nc...@ho...
http://members.home.net/ncherry                         (Text only)
http://meltingpot.fortunecity.com/lightsey/52           (Graphics)
http://linuxha.sourceforge.net/				(SourceForge)

Re: [LHA-misc] RE: HCS Web Pages

[Mike B. <bap...@cc...>]

Neil Cherry wrote:

> 
> Dave Houston has an interesting project using a Scenix chip and wireless
> to interface to X10 that sounds great! Give you any ideas Mike? :-)

Bluetooth has a lot of folks excited, but it is starting to look like 
CeBus.  Lots of promise but taking forever.  But I expect Bluetooth will 
reach store shelves soon.

Unfortunately, Bluetooth won't ever make it into my house :(  I'm 
working on my March 2001 column and it will cover wireless networking 
for the home.

One very bad thing about Bluetooth is it kills 802.11 wireless 
networking.  They interfere with each other in a huge way.

Bluetooth is exciting because UART to wireless is a default mode for it 
which makes it ideal for making some RS-485 nodes wireless.  But I also 
expect 802.11 networking will start making a huge dent in home 
networking now that access points are just over $200 and cards are < $100.

Just something to ponder.  Bluetooth could do amazing things for HA. 
But if they can't get Bluetooth and 802.11 to get along, it will be a 
Major problem.  Only time will tell.  I know they are working on it.

 > BTW how was the show(s)?

Excellent!  I was really happy to see the variety of HA stuff out there. 
  RS-485 based HA is alive and well, but there are lots of alternatives 
too.  Microsoft wasn't even there (booths were too small I guess!)  The 
interesting thing is I was just as excited in the contacts I made with 
other vendors and talk of collaboration as I was with the customer 
contacts.  The idea of an RS-485 HA network standard protocol has me 
really excited.  We'll see how things go.

Happy Thanksgiving everyone!
Here's to family, football and FOOD!

Mike



-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mike Baptiste                    bap...@cc...
Creative Control Concepts     http://www.cc-concepts.com/
** Home Automation Products for the Serious Enthusiast **
Check out the new HA FAQ http://www.automationfaq.com/
Our Home Renovation http://www.baptistefamily.net/remodel
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Re: [LHA-misc] RE: HCS Web Pages

[Neil C. <nc...@ho...>]

"Van Tassel, Bob" wrote:
> 
> Thanks Neil, that was very helpful.  I'm now thinking along the lines of
> buying a board from Lineo for $300 that has Linux and Ethernet already on
> board with 21 I/O pins.  Check them out
> http://www.lineo.com/products/ucsimm/index.html.

I answered this part in another reply, like I said before, don't take my word
as discouragement towards such a project.

> I realize there is a lot of support and info for the HCS board, but the
> hardware is using five year old technology and costs $500.  Seems like all
> that is missing from the lineo solution is an XJ11 connector to talk to a
> Two-way Powerline Interface (TW523) from X10.com.  Am I missing something?

Mike correct the cost issue and new/old technology is a funny thing. BTW the
HCS now uses a S180 which is 2 year old technology. :-) The uCsimm is using
5 year old technology (maybe a bit older, it's based on the 68K chip, right?).
In reality both are based on 20+ year old technology (68K ~78, Z80 ~77).
Be wary of technology as is often nothing more than marketing hype. After all
shouldn't we replace the TCP/IP (30+ years), ethernet (20+), cellular (30+)
and wireless networks (30+). :-)

> I'm starting from a clean slate, so I'm trying not to just blindly follow
> what most people are doing.  Which is why I'm thinking about CeBus.  Are
> X-10 commands simply a subset of CeBus?  Do you know of a TW523 like device
> for the CeBus?

This is a good thing, new ideas are always good. I've seen a power line CeBus
modem for ~$350 (US) but I haven't been able to find the link again. X10 and
CeBus (and LONWorks) are not compatible in any way.

-- 
Linux Home Automation           Neil Cherry             nc...@ho...
http://members.home.net/ncherry                         (Text only)
http://meltingpot.fortunecity.com/lightsey/52           (Graphics)
http://linuxha.sourceforge.net/				(SourceForge)

Re: [LHA-misc] RE: HCS Web Pages

[Neil C. <nc...@ho...>]

Mike Baptiste wrote:
> 
> Bob,
> 
> I was just about to reply to your email when I saw your post here.  I
> figured I reply here too.

Actually I was hoping you would respond here, you are best qualified to
defend your product (but I wasn't trying to start a war, not implying that
you are either). I just felt that this forum was the appropriate place
for the discussion.

> Yes, it uses and 'old' design, but not necessarily 'old' technology.  We
> upgraded the CPU used in the HCS-II, giving it a performance boost of
> 2.5.  Not bad for an older design.  The key is, it still gets the job
> done with room to spare and it is a VERY stable and reliable platform.
> My telephone is based on 50 year old technology and still works as
> designed :)

Funny thing about 'old' technology is that it becomes the 'new thing'
every once in a while. The PIC chips were designed in the 60's. The
technology used in the Intel x86 family is derived from 70's mainframes.
And the Z80 is back again as the EZ80. Of course all have been updated
a bit to take advantage of new methods of integration and construction.
I seem to recall that the Lineo board is based on the 68K processor
(1979). 
 
> However, I have no plans to create a system that uses Ethernet as the
> core communications media.

Ooops, I didn't mean to imply that the ethernet should be used to talk
to controllers. I hope nobody gets that impression. I'd like to also
clarify my past thoughts on the HCS. It can be purchased as a kit or
ready assembled.

> Now, I agree that using an embedded Linux solution sounds appealing and
> it has advantages.  But don't mix apples and oranges.  The HCS-II is not
> just hardware.  It uses an advanced firmware program that provides for
> an easy to use control langauage called XPRESS (included in the $299 you
> pay for an HCS-II board)  You simply write a program to control your
> house, compile it, and upload it to the HCS-II.   There is 200 pages of
> code behind all that functionality.

Yes this is very important, the Lineo board may be less expensive at
first blush but it doesn't come with HA software, the I/O still has to
be buffered (you need hardware) and it still needs a HA control software.
For some people this may be fine as it what they like to do (I not trying
to discourage you and neither is Mike).

> Sure, you can use perl in Linux to control your house, but this means
> you have to worry about control AND the interfaces to the various I/O
> you might have.
	<SNIP>
>                                                            But realize
> that $300 for an HA controller is more than just hardware, regardless of
> the age.
> 
> Neil's project aims to provide a generic interface to the existing HA
> hardware (and any new stuff that comes out).  Its a great idea since it
> lets you take basic HA controllers and add even more intelligence to
> them.  But don't forget the above controller were designed as stand
> alone devices that don't require a PC to be on non stop.

The last sentence is very important! One thing I've learned form my work
and experience is that eventually things fail. With the the LHA project
I intend to make the failure of the Linux box a smaller issue. The HA
controller can run independent of the Linux box and do what it's
programmed to do. The Linux box mainly gives you access to the status of
everything. But it also allows you to 'influence' the controllers
behaviour. And lastly it allows you to integrate dissimilar systems. By
using Perl and shell you can often create 'quick', 'dirty' little hacks
that let the HCS, the Ocelot, the CM11A, the CM17A, a weather station
and whatever else I have work together.

> Now regarding CeBus...  I personally wonder about its future.  It has
> been around for some time.  The parts and interfaces are VERY expensive,
> but that may change.
	<SNIP>
> The problem with CeBus is it requires a LOT of overhead.

Many of us beleive that X10 as a protocol will go away (BTW: A10 sounds
interesting). I have no idea what will replace it. I've heard of CeBUS
and LonWorks but I've yet to see much in the way of products and what I
have seen is very expensive (you want me to replace my $2 light switch
(hey, I only buy the best :-) with a $150 switch?).

Dave Houston has an interesting project using a Scenix chip and wireless
to interface to X10 that sounds great! Give you any ideas Mike? :-)

On the subject of a lot of overhead, that goes for LONWorks and UPnP.
They both sound great but require lots of overhead. I know that CPU are
getting faster, more powerful and cheaper but the resources required for
these tecnologies is bordering on Bloat! When I design networks for my
customers I try to keep it as simple as possible to meet the customers
needs. The best designs are simple. This makes installation, maintenance,
and debugging quick and easy.

> Sorry for the long post, just had a lot to cover and I haven't posted in
> a while! :)

BTW how was the show(s)?

-- 
Linux Home Automation           Neil Cherry             nc...@ho...
http://members.home.net/ncherry                         (Text only)
http://meltingpot.fortunecity.com/lightsey/52           (Graphics)
http://linuxha.sourceforge.net/				(SourceForge)

Re: [LHA-misc] RE: HCS Web Pages

[Mike B. <bap...@cc...>]

Bob,

I was just about to reply to your email when I saw your post here.  I 
figured I reply here too.

First, the HCS itself is not $500.  The controller board sells for $299 
and includes the XPRESS HA software (more on that later)  $495 gets you 
teh controller, an 8 relay, 16 buffered input board, heavy duty metal 
enclosure, and an X-10 gateway/coprocessor board.

Yes, it uses and 'old' design, but not necessarily 'old' technology.  We 
upgraded the CPU used in the HCS-II, giving it a performance boost of 
2.5.  Not bad for an older design.  The key is, it still gets the job 
done with room to spare and it is a VERY stable and reliable platform. 
My telephone is based on 50 year old technology and still works as 
designed :)

I hope to add an Ethernet interface to the HCS-II using the Dallas TINI 
board Neil talked about earlier.  It will use web pages and Java applets 
to display system information and also allow you to control things.  It 
will allow the HCS to send email and can also FTP event logs from the 
HCS to servers or email them as well.

However, I have no plans to create a system that uses Ethernet as the 
core communications media.  The added expensive in hardware and overhead 
for the core processor are simply not worth it.  Plus Ethernet is NOT an 
ideal transport for 'control'  It is limited in distance (about 300'), 
requires 4 to 8 wires, and generally is not justified for things like 
controlling relays or reading analog values.  Someone may make a light 
switch with an Ethernet port, but it'll never succeed due to price and I 
doubt it'll pass code.  Now bluetooth or some other wireless varient 
might be a different story.  We'll see.

This is why RS-485 is so much better.  1 twisted pair can go 4000' and 
the tiniest processor can communicate with it.  So the ideal setup 
(IMHO) is a controller with Ethernet capability and RS-485 or wireless 
as the backend control network to talk with the end nodes used for 
control and monitoring.  That's why RS-485 is used almost exclusively 
for industrial and factory control.  It is easy to run, easy to wire, 
has excellent noise immunity and can approach speeds of 10MBps.

By having the main controller Ethernet capable, you can access your HA 
setup from anywhere, regardless of the backend network in use.  That's 
why I prefer and will stick with the 'gateway' concept for Ethernet at 
the controller.

As for the RS-485 hub, you don't 'need' it.  If you wire your modules in 
the proper 'daisy chain' fashion, its not required.  But many people 
like to wire their RS_485 devices in a star configuration which RS-485 
was not designed for.  But the RS-485 hub allows you to use stars in 
your RS-485 network.  That's another advantage of RS-485 in control, it 
is a multi-drop network that does not require the use of hubs like Ethernet.

Now, I agree that using an embedded Linux solution sounds appealing and 
it has advantages.  But don't mix apples and oranges.  The HCS-II is not 
just hardware.  It uses an advanced firmware program that provides for 
an easy to use control langauage called XPRESS (included in the $299 you 
pay for an HCS-II board)  You simply write a program to control your 
house, compile it, and upload it to the HCS-II.   There is 200 pages of 
code behind all that functionality.

Sure, you can use perl in Linux to control your house, but this means 
you have to worry about control AND the interfaces to the various I/O 
you might have.  Plus you have to write the low level drivers for things 
like X-10, analog conversions, timers, etc.  With the HCS-II (or other 
controllers like the Stargate, Ocelot, Magic Module, etc), you program 
at a higher level.  Its designed for folks that may not have in depth 
knowledge of C or perl or python, etc.

For example, to monitor a remote sensor and take action in XPRESS (or 
the language used in other HA controllers), you'd do something like:

IF Drivewaysensor = ON THEN
    FrontFloods = ON  ! X-10 modules
    FrontPorchLight = ON
END

With a Linux setup you talk about you'd have to write all the low level 
stuff.  Don't get me wrong, it can be done and many folks would enjoy 
doing it (myself included - a certified perl & Linux nut)  But realize 
that $300 for an HA controller is more than just hardware, regardless of 
the age.

Neil's project aims to provide a generic interface to the existing HA 
hardware (and any new stuff that comes out).  Its a great idea since it 
lets you take basic HA controllers and add even more intelligence to 
them.  But don't forget the above controller were designed as stand 
alone devices that don't require a PC to be on non stop.

Now regarding CeBus...  I personally wonder about its future.  It has 
been around for some time.  The parts and interfaces are VERY expensive, 
but that may change.  Microsoft has adopted CeBus which may give it 
life, but Microsoft is not a major palyer in home automation (yet)  I do 
know of one company getting ready to mass product light switches, 
outlets, etc based on CeBus.

The problem with CeBus is it requires a LOT of overhead.  Most of todays 
HA controllers are simple in that they use 8-bit or 16-bit embedded 
controllers which keeps thing ssimple (ie stable) and also keeps costs 
low.  I'll never forget an article I read in Circuit Cellar that 
outlined how to turn a RELAY on and off using CeBus.  It took up 5 pages 
and they provided no code, just high level outlines of objects and stuff 
that were very involved.

X-10 is popular with customers because it is inexpensive.  X-10 is 
popular with HA manufacturers because it is simple to implement.  CeBus 
is not and the chipsets are still really pricey.  CeBus is touted as a 
great thing because it is plug and play.  Who cares?  Do you REALLY need 
a light switch that auto sets itself?  Is it THAT hard to set an X-10 
address?

The second benefit I've heard is reliability.  Yes, X-10 has reliability 
issues.  But companies are working on improving X-10s problems.  The 
folks at ACT have come up with 'A-10' which is compatible with X-10, but 
it is MUCH more robust when it comes to powerline noise.  Yet it still 
uses the simple X-10 protocol.  But it also handles the extended data 
aspect of X-10 which until now has not been used due to the TW-523's 
limits.  Now there are new interfaces coming to market from ACT and 
SmartLinc which support extended codes.

So CeBus may take the HA industry by storm, but I doubt it.  But then 
maybe I'm just in denial. ;)

Sorry for the long post, just had a lot to cover and I haven't posted in 
a while! :)

Mike


Van Tassel, Bob wrote:

> Thanks Neil, that was very helpful.  I'm now thinking along the lines of
> buying a board from Lineo for $300 that has Linux and Ethernet already on
> board with 21 I/O pins.  Check them out
> http://www.lineo.com/products/ucsimm/index.html.
> 
> I realize there is a lot of support and info for the HCS board, but the
> hardware is using five year old technology and costs $500.  Seems like all
> that is missing from the lineo solution is an XJ11 connector to talk to a
> Two-way Powerline Interface (TW523) from X10.com.  Am I missing something?
> 
> I'm starting from a clean slate, so I'm trying not to just blindly follow
> what most people are doing.  Which is why I'm thinking about CeBus.  Are
> X-10 commands simply a subset of CeBus?  Do you know of a TW523 like device
> for the CeBus?
> 
> Thanks again, Bob.
> 
> -----Original Message-----
> From: Neil Cherry [mailto:nc...@ho...]
> Sent: Wednesday, November 22, 2000 10:56 AM
> To: Van Tassel, Bob
> Cc: Wedekind, Jeffrey; Nguyen, Hai; Fleming, Kevin; LHA-misc
> Subject: Re: HCS Web Pages
> 
> 
> 
>> "Van Tassel, Bob" wrote:
>> 
>> http://members.home.net/ncherry/common/hcs/index.html
>> 
>> Great site!  I realize that the HCS-II is made from an old Circuit Cellar
>> design, but are there plans to upgrade this puppy with an Ethernet
>> controller?  I think it sucks big time to have to buy an RS-485 hub for
> 
> $139
> 
>> to do networking, when Linux is so rich with a built in TCP stack.  Does
> 
> your
> 
>> code use PPP over the RS-485 bus?  I'd like to be able to use a HA system
> 
> from
> 
>> any computer in the house.
>> 
>> Thanks, Bob.
> 
> 
> I've included everyone, I hope you don't mind. The HCS II will probably
> not get an ethernet controller. But it is possible to hook up a Dallas
> Tini board to the ether' and the serial port the HCS II so that can
> provide an ethernet interface. The Dallas software would be written in
> Java, there is code to allow a CM11A to Dallas to ethernet. This should
> hackable to permit other devices to communicate between the serial and
> ether.
> 
> Having said all that, there is also plans for an HCS III and that may
> have an ethernet as it's based on the EZ80 by Zilog and Rabbit Semi.
> They have a version with an ethernet and since the HCS II is based on
> the Z80/180/S180 it seems like a logical path. Check out:
> 
> http://www.cc-concepts.com/opensource/
> 
> Now onto your other questions. There is no need for an RS485 hub you
> can simply string (daisy chain) them up to each other (a star config
> requires a hub). The total max devices: 32, the total length of cable:
> 4000 feet.
> 
> My HCSd code has the HCS II directly connected to the serial port (no
> TCP/IP or ppp, just straight 8 bit ASCII [0-255]) but it allows you to
> telnet from anywhere on the network to the port (assuming you have the
> routing working if it's a big network like the internet).  The telnet
> session is standard 7 bit ASCII, commands are "!12000200" (literally
> you type everything between the double quotes). That command is Set
> X10 A1 on. It will respond back with "$12" saying that it exec'd the
> command. I also wrote a perl program which runs under Linux and W95 to
> download the program to the HCS. Other commands will also be written
> in perl (for proof of concept) to turn things on, off, get status,
> what ever is appropriate. Multiple computers can attach to HCSd at the
> same time. I make no attempts to keep 2 users from issue dueling
> commands. There is also no security (I have TCPD compiled in by
> default, but that's not security). I expect security to be handled via
> outside programs, SSH, IPFilters, Net filters, IP table, etc. Here's
> an ASCII picture:
> 
>                          +-------+
>                          | Other |
>                          +---+---+
>            Ethernet          |
>  ]----------+-------SS-------+---------[
>             |
>      +------+----+
>      | Linux Box |---------> Internet Access (PPP/Slip/Cable/DSL/ISDN/AX25)
>      +----+------+
>           |
>           | RS232 Serial port
>           |
>        +--+--+
>        | HCS |------> RS485 network
>        +-----|
>         | | |
>         O O O (Digital/Analog I/O)
> 
> In the above diagram (fix font), SS means that those 2 parts of the
> network may not be on the same net. If not, they'll depend on normal
> TCP/IP routing. Technically they could be across the internet. There
> doesn't have to be a network card either, just as long as the
> interface looopback or dummy network is up. This will allow people
> with just a serial dial up to use the program. The daemon depends on
> TCP/IP doing it's thing correctly. The picture doesn't include a
> firewall but if you try to access from outside the safety of your home
> I recommend a seperate firewall box. I know this isn't practicle for
> dial up users, I still recommend using a firewall! The "Other" box can
> be anything, DOS, WinX, a MAC, another *nix box, a Dallas TINI board
> with keyboard and LCD (or just touch screen), or even CP/M. :-)
> 
> I hope that answers your questions.
> 
> BTW: You won't be able to post directly to the LHA project list, it will
> be sent to me and I'll have to approve it. Only members of the list are
> permitted to post to the list because of SPAM problems.


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mike Baptiste                    bap...@cc...
Creative Control Concepts     http://www.cc-concepts.com/
** Home Automation Products for the Serious Enthusiast **
Check out the new HA FAQ http://www.automationfaq.com/
Our Home Renovation http://www.baptistefamily.net/remodel
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

[LHA-misc] RE: HCS Web Pages

[Van T. B. <Bob...@me...>]

Thanks Neil, that was very helpful.  I'm now thinking along the lines of
buying a board from Lineo for $300 that has Linux and Ethernet already on
board with 21 I/O pins.  Check them out
http://www.lineo.com/products/ucsimm/index.html.

I realize there is a lot of support and info for the HCS board, but the
hardware is using five year old technology and costs $500.  Seems like all
that is missing from the lineo solution is an XJ11 connector to talk to a
Two-way Powerline Interface (TW523) from X10.com.  Am I missing something?

I'm starting from a clean slate, so I'm trying not to just blindly follow
what most people are doing.  Which is why I'm thinking about CeBus.  Are
X-10 commands simply a subset of CeBus?  Do you know of a TW523 like device
for the CeBus?

Thanks again, Bob.

-----Original Message-----
From: Neil Cherry [mailto:nc...@ho...]
Sent: Wednesday, November 22, 2000 10:56 AM
To: Van Tassel, Bob
Cc: Wedekind, Jeffrey; Nguyen, Hai; Fleming, Kevin; LHA-misc
Subject: Re: HCS Web Pages


> "Van Tassel, Bob" wrote:
> 
> http://members.home.net/ncherry/common/hcs/index.html
> 
> Great site!  I realize that the HCS-II is made from an old Circuit Cellar
> design, but are there plans to upgrade this puppy with an Ethernet
> controller?  I think it sucks big time to have to buy an RS-485 hub for
$139
> to do networking, when Linux is so rich with a built in TCP stack.  Does
your
> code use PPP over the RS-485 bus?  I'd like to be able to use a HA system
from
> any computer in the house.
> 
> Thanks, Bob.

I've included everyone, I hope you don't mind. The HCS II will probably
not get an ethernet controller. But it is possible to hook up a Dallas
Tini board to the ether' and the serial port the HCS II so that can
provide an ethernet interface. The Dallas software would be written in
Java, there is code to allow a CM11A to Dallas to ethernet. This should
hackable to permit other devices to communicate between the serial and
ether.

Having said all that, there is also plans for an HCS III and that may
have an ethernet as it's based on the EZ80 by Zilog and Rabbit Semi.
They have a version with an ethernet and since the HCS II is based on
the Z80/180/S180 it seems like a logical path. Check out:

http://www.cc-concepts.com/opensource/

Now onto your other questions. There is no need for an RS485 hub you
can simply string (daisy chain) them up to each other (a star config
requires a hub). The total max devices: 32, the total length of cable:
4000 feet.

My HCSd code has the HCS II directly connected to the serial port (no
TCP/IP or ppp, just straight 8 bit ASCII [0-255]) but it allows you to
telnet from anywhere on the network to the port (assuming you have the
routing working if it's a big network like the internet).  The telnet
session is standard 7 bit ASCII, commands are "!12000200" (literally
you type everything between the double quotes). That command is Set
X10 A1 on. It will respond back with "$12" saying that it exec'd the
command. I also wrote a perl program which runs under Linux and W95 to
download the program to the HCS. Other commands will also be written
in perl (for proof of concept) to turn things on, off, get status,
what ever is appropriate. Multiple computers can attach to HCSd at the
same time. I make no attempts to keep 2 users from issue dueling
commands. There is also no security (I have TCPD compiled in by
default, but that's not security). I expect security to be handled via
outside programs, SSH, IPFilters, Net filters, IP table, etc. Here's
an ASCII picture:

                         +-------+
                         | Other |
                         +---+---+
           Ethernet          |
 ]----------+-------SS-------+---------[
            |
     +------+----+
     | Linux Box |---------> Internet Access (PPP/Slip/Cable/DSL/ISDN/AX25)
     +----+------+
          |
          | RS232 Serial port
          |
       +--+--+
       | HCS |------> RS485 network
       +-----|
        | | |
        O O O (Digital/Analog I/O)

In the above diagram (fix font), SS means that those 2 parts of the
network may not be on the same net. If not, they'll depend on normal
TCP/IP routing. Technically they could be across the internet. There
doesn't have to be a network card either, just as long as the
interface looopback or dummy network is up. This will allow people
with just a serial dial up to use the program. The daemon depends on
TCP/IP doing it's thing correctly. The picture doesn't include a
firewall but if you try to access from outside the safety of your home
I recommend a seperate firewall box. I know this isn't practicle for
dial up users, I still recommend using a firewall! The "Other" box can
be anything, DOS, WinX, a MAC, another *nix box, a Dallas TINI board
with keyboard and LCD (or just touch screen), or even CP/M. :-)

I hope that answers your questions.

BTW: You won't be able to post directly to the LHA project list, it will
be sent to me and I'll have to approve it. Only members of the list are
permitted to post to the list because of SPAM problems.

-- 
Linux Home Automation           Neil Cherry             nc...@ho...
http://members.home.net/ncherry                         (Text only)
http://meltingpot.fortunecity.com/lightsey/52           (Graphics)
http://linuxha.sourceforge.net/				(SourceForge)

[LHA-misc] Re: HCS Web Pages

[Neil C. <nc...@ho...>]

> "Van Tassel, Bob" wrote:
> 
> http://members.home.net/ncherry/common/hcs/index.html
> 
> Great site!  I realize that the HCS-II is made from an old Circuit Cellar
> design, but are there plans to upgrade this puppy with an Ethernet
> controller?  I think it sucks big time to have to buy an RS-485 hub for $139
> to do networking, when Linux is so rich with a built in TCP stack.  Does your
> code use PPP over the RS-485 bus?  I'd like to be able to use a HA system from
> any computer in the house.
> 
> Thanks, Bob.

I've included everyone, I hope you don't mind. The HCS II will probably
not get an ethernet controller. But it is possible to hook up a Dallas
Tini board to the ether' and the serial port the HCS II so that can
provide an ethernet interface. The Dallas software would be written in
Java, there is code to allow a CM11A to Dallas to ethernet. This should
hackable to permit other devices to communicate between the serial and
ether.

Having said all that, there is also plans for an HCS III and that may
have an ethernet as it's based on the EZ80 by Zilog and Rabbit Semi.
They have a version with an ethernet and since the HCS II is based on
the Z80/180/S180 it seems like a logical path. Check out:

http://www.cc-concepts.com/opensource/

Now onto your other questions. There is no need for an RS485 hub you
can simply string (daisy chain) them up to each other (a star config
requires a hub). The total max devices: 32, the total length of cable:
4000 feet.

My HCSd code has the HCS II directly connected to the serial port (no
TCP/IP or ppp, just straight 8 bit ASCII [0-255]) but it allows you to
telnet from anywhere on the network to the port (assuming you have the
routing working if it's a big network like the internet).  The telnet
session is standard 7 bit ASCII, commands are "!12000200" (literally
you type everything between the double quotes). That command is Set
X10 A1 on. It will respond back with "$12" saying that it exec'd the
command. I also wrote a perl program which runs under Linux and W95 to
download the program to the HCS. Other commands will also be written
in perl (for proof of concept) to turn things on, off, get status,
what ever is appropriate. Multiple computers can attach to HCSd at the
same time. I make no attempts to keep 2 users from issue dueling
commands. There is also no security (I have TCPD compiled in by
default, but that's not security). I expect security to be handled via
outside programs, SSH, IPFilters, Net filters, IP table, etc. Here's
an ASCII picture:

                         +-------+
                         | Other |
                         +---+---+
           Ethernet          |
 ]----------+-------SS-------+---------[
            |
     +------+----+
     | Linux Box |---------> Internet Access (PPP/Slip/Cable/DSL/ISDN/AX25)
     +----+------+
          |
          | RS232 Serial port
          |
       +--+--+
       | HCS |------> RS485 network
       +-----|
        | | |
        O O O (Digital/Analog I/O)

In the above diagram (fix font), SS means that those 2 parts of the
network may not be on the same net. If not, they'll depend on normal
TCP/IP routing. Technically they could be across the internet. There
doesn't have to be a network card either, just as long as the
interface looopback or dummy network is up. This will allow people
with just a serial dial up to use the program. The daemon depends on
TCP/IP doing it's thing correctly. The picture doesn't include a
firewall but if you try to access from outside the safety of your home
I recommend a seperate firewall box. I know this isn't practicle for
dial up users, I still recommend using a firewall! The "Other" box can
be anything, DOS, WinX, a MAC, another *nix box, a Dallas TINI board
with keyboard and LCD (or just touch screen), or even CP/M. :-)

I hope that answers your questions.

BTW: You won't be able to post directly to the LHA project list, it will
be sent to me and I'll have to approve it. Only members of the list are
permitted to post to the list because of SPAM problems.

-- 
Linux Home Automation           Neil Cherry             nc...@ho...
http://members.home.net/ncherry                         (Text only)
http://meltingpot.fortunecity.com/lightsey/52           (Graphics)
http://linuxha.sourceforge.net/				(SourceForge)

Re: [LHA-misc] Which Open Source License?

[John <jk...@pr...>]

On Sun, 22 Oct 2000, Neil Cherry wrote:

> OK, I know this is going to be a painful subject but it's one that needs
> to be fully resolved (that right it's not). The subject is: which Open
> Source License?
> 
> Initially I intended this to be an FSF/GNU GPL. But with so many available
> I want to hear others opinions.

To reopen a painful topic...

I've been researching the OpenSSL project for use in a project at work and
I tripped over a licensing question in their mailing list:

http://marc.theaimsgroup.com/?t=97415736500005&w=2&r=1

Summary: The FSF will not allow GPL'd software to be linked with OpenSSL
Summary: (reason: advertising clause)

John