|
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
|
|