RE: xPL protocol questions

["Tony Tofts" <tony@xxxxxxxxxx>]

> 1) Unconfigurable Devices
> If a device just flat out cannot support configuration at
> all, how should it announce itself.  Should it just skip
> sending out the config.app/base and go straight to sending
> out heartbeat messages?

Yes it goes straight to heartbeat, and there can be only _one_ of the
devices present.

> 2) Timeout on Configuration
> If a device does support configuration, how long should it
> keep sending out config.app/base messages (in lieu of a
> heartbeat message) if it's not getting a reply?  For example,
> I start up and send a config.app out.  Lets say I send one
> out every 5 minutes, but I don't get any reply back.  Should
> I keep sending config.app out for eternity or wait X
> heartbeats before dropping back to any previously saved
> defaults and start sending normal heartbeat messages.

For eternity in theory

> 3) Can an app request configuration data (sending
> config.base/app) at any time or only during initial device
> identification/discovery?

It would normally be only during device startup, though there's nothing to
prevent it doing otherwise.

> 4) Handling Locally Saved config data
> The xPL docs suggest a device should try to save config
> settings, if possible, and restore them.  If I have a device
> capable of doing that, should I restore the config and then
> still broadcast config.app?  If I get a config.app reply,
> should I dump all my stored config data and use only what I
> get back in the reply (like when you get a group= and are
> supposed to dump all existing groups) or should data be
> merged (items supplied in the reply overwriting those
> previously loaded and items not in the reply remaining untouched)?

If you have locally stored config, then when you start again you woulf
heartbeat. If you receive a new config it should override the local
settings.

> 5) config.base vs config.app
> What is the difference between config.base and config.app?
> Should they just
>   be used with the same rules as hbeat.base and hbeat.app?

It's .basic rather than .base. Normally config.* would be at 1 minute
intervals, whereas the default for hbeat.* is 5 minutes.

There is also a hbeat.end that can be sent if a device knows it's going
down, to advise xplhal that the device is terminating.

> On non-configuration items
>
> 1) Are requests for status mandatory in xPL?

No

> 2) Is the key for asking for them that the message schema
> class unimportant, only that the type is ".request"?  Or
> should the schema class be checked as a valid schema class
> for this device and then the .request processed?  Are there
> any other required types of a schema class?

Well a non-x10 device should respond to an x10 status request, as a basic
example.

> 3) Can you send status requests out to target=* or must they
> always be directed?

Don't see why not, though targetted status requests are preferrable.

> 4) Do responses to a status request always have to have a
> target=* or can they choose to direct it at a certain target
> (presumably, the source)?

Optional

> 5) Is their some suggested time limit a client sending a
> status request should allow before assuming it's not going to
> get a request?  Or should such requests be consider async --
> you may not get a response, may get one response or many
> (i.e. responses are, at best, loosely coupled to requests for status)?

There is no I'll wait for this or that in xpl. Every message is considered
independent, and therefore never assume you'll get an answer. Messages are
processed on a first come first served basis and are totally independent
(so
to speak).

> 6) Can the target= on a trigger message ever be a specific
> target or must it always be a wildcard?

If the trigger isn't a wildcard then the device would need to know of the
existance of another device? Can't see this being of any use?

> Sorry for all the Qs -- I am reading the protocol docs, but
> these areas are either note covered or I'm missing them (my
> apologies -- I'm re-reading the docs over and over trying to
> see if I missed any of this).

No problem. Hope the above helps, and I'm sure someone will correct me if
I've got anything wrong.

Regards
Tony