RE: xPL protocol questions

["John B" <home-automation@xxxxxxxxxxxxxxxx>]

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

Why only one? I thought that only applied to devices that supported remote
config, but that couldn't store their instance.
If a device doesn't support remote config (e.g. my Winamp plug-in) but can
store it's instance elsewhere (e.g. in an INI file) there is no reason why
you can't have multiple instances of the device.

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

Indeed - this is really up to the developer.

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

Yep, we need to clarify that this could be requested at any time - in fact,
xPLHal requests config data from devices when they appear for the first
time, whether they're configured or not.

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

I'll check that this is mentioned in the protocol spec.
Note that hbeat.end can also be used to signal a local hub that a 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

I thought it always had to be target=*?

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

Agreed - it should really always be target=*.

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

It's probably more a case of the protocol document not being as specific as
it should be - I'll see about amending it when I get chance.

Regards,

John