The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[Message Prev][Message Next][Thread Prev][Thread Next][Message Index][Thread Index]

Rules for Instance WAS PIC testing WAS OSD ALERT


  • Subject: Rules for Instance WAS PIC testing WAS OSD ALERT
  • From: Tony Tofts
  • Date: Wed, 10 Dec 2003 09:05:00 +0000

> and i assume a non configured device would have default....?

A non configured device can boot with an instance of 'default' initially,
but _must_ be capable of remembering it's newly configured instance (i.e.
must not loose it at reboot).

The xpl manager will _not_ allow a device to be configured with an instance
of 'default' as this is a reserved (the only one) instance name to aid
identification of a devices ability to remember it's instance.

The following might be a bit long winded, but explains it in more detail

There are basically 4 types of device/app (referred to as device only
hereon)

A) cannot remember an instance on reboot, cannot generate unique instance
B) cannot remember an instance on reboot, can generate unique instance
C) can remember an instance on reboot, cannot generate unique instance
D) can remember an instance on reboot, can generate a unique instance
(might
be supplied on command line prompt or similar)

Type 'a' is for the simplest of devices, as it cannot create a unique
instance, nor remember an assigned instance there can only be _one_ of
these
devices on a given xpl network (must never be 'default')

Type 'b' is for devices that can generate their own uniqe instance, but
cannot remember a change to the instance after a reboot. i.e. if it's
ethernet it might use it's ip address for it's instance (must never be
'default')

Type 'c' is for devices that don't generate a unique instance on startup,
but _can_ remember an assigned instance. It should always start with an
instance of 'default'

Type 'd' is for devices that can generate a unique instance and remember
it.
This applies to most current applications and various devices (e.g.
rioplayxpl)

All devices are assumed to be able to store a change to their instance once
running, even type 'a'. xPLHal config process tracks changes to the
instance, and if necessary, will reconfig the device multiple times to
restore it to the state it was in before being switched off, but this
always
must start from a unique instance (which is why a device cannot be
configured with an instance of 'default' as this is used by multiple
devices
for initial configuration).

So to sum up, where a device remembers it's last assigned instance, it will
receive a single config for xplhal to return it to it's required state.
Where it starts with a base unique instance it is configured thru all
cycles
to return it to it's last state.

All these devices would always start with a config.app or config.basic

Where a device wishes to remember it's own settings (e.g. pc registry or
non-volatile storage) it is free to start with a hbeat.app ot hbeat.basic,
and will not be configured unless manually sent a config from xpl manager.

Hope this clarifies things.

As a side note, when xplhal configures a device it then requests it's
current config. That way if any configured item was invalid or failed,
xplhal will always know the true config state of the device.

Regards
Tony










xPL Main Index | xPL Thread Index | xPL Home | Archives Home

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.