The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Re: xAP over ethernet - device configuration


  • To: <ukha_d@xxxxxxx>
  • Subject: RE: Re: xAP over ethernet - device configuration
  • From: "Mark Harrison" <Mark.Harrison@xxxxxxx>
  • Date: Wed, 14 Aug 2002 19:31:15 +0100
  • Mailing-list: list ukha_d@xxxxxxx; contact ukha_d-owner@xxxxxxx
  • Reply-to: ukha_d@xxxxxxx

Patrick,

I think you're right, at least as it pertains to VFD outputs.

Since my "phase 1 outputs" are going to be 32bit Windows clients, I'm not thinking about that yet :-)

M.

-----Original Message-----
From: PatrickLidstone [mailto:patrickl@xxxxxxx]
Sent: 14 August 2002 19:02
To: ukha_d@xxxxxxx Subject: [ukha_d] Re: xAP over ethernet - device configuration


I think it makes sense to minimise the on-device configuration
requirements for the display/output devices. In the case of the
display, for example, there is no on-board input device, and although
it can be done through the web (my rabbit interface to the VFD has
the beginnings of web interface already), it's not reasonable to
expect every node to support a browser interface.

On cold startup: The minimum would be a "station name" (unique
identifier) and broadcast port number. The default station name could
be something like the last 4 digits of the MAC address by default, to
allow for out-of-box configuration for devices with no UI. Where the
MAC address or equivalent unique identifier is not available, then it
should default to a fixed name (any better solution?)

On cold start the device would then broadcast a config request at
(say) 10s intervals until it got a response. The response would come
>from case of the display, would define which xAP-source would be display
on which lines. Normally a device would store this config in non-
volatile memory of some description.

On warm start, the previous config is read from non-volatile RAM.

Devices should respond to config update messages at any time.

Devices which are listen only could also support this interface,
allowing manual configuration on demand from a PC by pressing a
button to generate the config broadcast.

Leads me to think we probably need to add a new tag to the message
structure xAP-msgtype, because the xAP-source is not really
sufficient in itself.

So a config message would look like:

xAP-source=autoconfig
xAP-instance=my_pc_name
xAP-msgtype=deviceconfig

station-name=SittingRoom
device-type=VFD-Display
device-version=1.2

line1-source=outlook
line1-field=unread

line2-source=netclock
line2-field=datetime

etc.

Is this a reasonable plan?

PS. Is it worth starting a spin-off list (much as I hate them), given
message volume?

PPS. Mark M., will try and take some pics tomorrow.

Patrick




For more information: http://www.automatedhome.co.uk
Post message: ukha_d@xxxxxxx
Subscribe:  ukha_d-subscribe@xxxxxxx
Unsubscribe:  ukha_d-unsubscribe@xxxxxxx
List owner:  ukha_d-owner@xxxxxxx

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/



________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs SkyScan
service. For more information on a proactive anti-virus service working
around the clock, around the globe, visit http://www.messagelabs.com
________________________________________________________________________


Yahoo! Groups Sponsor
ADVERTISEMENT

For more information: http://www.automatedhome.co.uk
Post message: ukha_d@xxxxxxx
Subscribe:  ukha_d-subscribe@xxxxxxx
Unsubscribe:  ukha_d-unsubscribe@xxxxxxx
List owner:  ukha_d-owner@xxxxxxx

Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

Home | Main Index | Thread Index

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.