RE: Topic 1: Base Level Status Schema

[Kevin Hawkins]

I'm trying to nudge this topic up to the top again so we can decide
something for the developers looking at including xAP support in existing
controllers.

Are we happy with as previously stated..????

State as
ON  OFF  UNKNOWN  NA (not applicable)

And also for LEVEL expressed as a percentage eg 20% 88.3% or again UNKNOWN
or NA

Do we have a case for the relative percent support for level eg +20% ?

And re Stuarts comment below - any feedback ? - I personally am sort of
against having multiple bodies as the way to do this mainly because I am
considering the size of the packets but maybe it's correct ?? The
alternatives would be to either report all status info in one body or to
send separate messages and vary the UID.
I think generally when a status changes then a separate message is
essential
as the UID is vital but as a response to a status request maybe all in one
message is much better.

Kevin


> -----Original Message-----
> From: Stuart Booth [mailto:<a
href="/group/xAP_developer/post?postID=mEslWu_eU7Wj-Ls-RND47bnY8_4hUXCUtwsvn6SDZrSVI9cjFmlNTK7_R1XHC88F0jc6QpNNcb617SI4_htdgaQ">lists@x...</a>]
> Sent: 01 June 2003 18:22
> To: <a
href="/group/xAP_developer/post?postID=UdOzoLAc5r4wKVEDFH_rIwrS-5eSAyyFOPnWRVUaeqWH_TqBAElCVyI9ifCmpk4QvJYzWztSI_RGenoYg3h_V6mNVA">xAP_developer@xxxxxxx</a>
> Subject: Re: [xAP_developer] Topic 1: Base Level Status Schema
>
> On Wed, 28 May 2003 18:15:29 +0100, "Kevin Hawkins"
> <<a
href="/group/xAP_developer/post?postID=rq-av1dU2VaMm-xsUWj5orAAadlE5HPiNsxe4maqnM1jIY_pOqjw81QJAVrCIAYXcLvkLBxpU9wvbSP6heXmlqe3">lists@u...</a>>
wrote:
>
> > We must also address the issue of a Status response from a xAPp
> that
> >has several outputs - which should, if it adheres to the spec
contain
> >several hardware sub addresses and also alter it's UID for each
> separate I/O
> >end point (or terminal). It's clear that if we target a specific
> output end
> >point (which currently is only possible via addressing not UID)
then a
> >status response relates directly to one terminal and the above
> scenario
> >works - what should happen when a status request is sent to the
xAP
> itself -
> >one that may have several I/O ports that it services. Clearly I
think
> the
> >device should respond with the state of all of it's inputs and
outputs
> but
> >should it do this with one body or should it split each into a
> separate body
> >somehow identified through the header or perhaps issue multiple
xAP
> messages
> >one for each I/O ?? This has a ramification on how tidy and basic
we
> can
> >make a basic status schema.
>
> This reminds me of what I've been wondering about James' News feed. If
> you included data in the block name you can include the status of each
> port in a separate message block in the message body, and use the same
> format for each block.
>
> Is there any scope of including instance data in the block name format
> e.g. Block.Name:Instance ?
>
> I've preferred to have data variables inside the blocks though. It's
> data, not a type, after all.
>
> S
> --
> Stuart Booth
> xAPFramework.net - a reusable xAP framework for .net
>
> <a href="http://www.xapframework.net/";>http://www.xapframework.net/</a>
<a
href="/group/xAP_developer/post?postID=CP3F3nIyVSVKMeZ1So59dXttBP05Zltau0znD2nieefBl38mTonDHF2jnVX_b9OCBx8sIP5_tVoXgoRFp_Ff">stuart@x...</a>
>
> ------------------------ Yahoo! Groups Sponsor
---------------------~--
> >
> Get A Free Psychic Reading! Your Online Answer To Life's Important
> Questions.
> <a href="http://us.click.yahoo.com/Lj3uPC/Me7FAA/ySSFAA/dpFolB/TM";>http://us.click.yahoo.com/Lj3uPC/Me7FAA/ySSFAA/dpFolB/TM</a>
>
---------------------------------------------------------------------~-
> >
>
> To unsubscribe from this group, send an email to:
> <a
href="/group/xAP_developer/post?postID=wiKhCtLHDfrbARg4aPByzFVB0Np9vcq4WuNsfXpsEhR0nchVQdh_kYG10hm5w4xlPa8ZG5xJ7Q6n316i-pcLY7MMmyH_c0_yHKrkP6qrSQ">xAP_developer-unsubscribe@xxxxxxx</a>
>
>
>
> Your use of Yahoo! Groups is subject to
> <a href="http://docs.yahoo.com/info/terms/";>http://docs.yahoo.com/info/terms/</a>