Re: Format of xap packet

["drodegeb" <drodegeb@xxxxxxxxx>]

Kevin,

Very good explanation.  I will keep the bodies as part of the same
message object and have the primary application process them.

Thanks,

Dave



--- In xap_automation@xxxxxxx, Kevin Hawkins <lists@...> wrote:
>
> Hi Dave,
>
>     I think the main purpose of including multiple bodies is to tie
the
> context of the blocks together and to ensure everything within one
> message is processed . That's not to say that this always happens
but if
> it isn't necessary then the blocks could have been originated as
> separate messages.    The context could be important in that the
> information in one block , for example say a list of temperatures (min
> max average) could only be valid in the 'context' of the other block
> which might have some data relating to measured  time periods or
> something. Perhaps the same could happen with TV listings (I haven't
> looked at that schema) with recording information related to program
> descriptions/schedules in another block perhaps. I'm thinking this is
> probably a bad way to design a schema with this contextual
relationship
> between blocks but it surely happens.  If you effectively break the
> blocks back out into separate messages you would lose this.
>
> In typical usages the purpose is very much to cause the blocks to be
> processed as one message, for example using the BSC 1.3 schema..  Here
> is a 'cmd' message (from the BSC spec doc) that turns one device ON
and
> another OFF . The idea here is to process the message as one such that
> the changes are always synchronised, ideally the state changes within
> the device should be coincident. Certainly there should never be the
> possibility that only one of the state changes happens.
>
> {
>     v=12
>     hop=1
>     uid=FF123400
>     class=xAPBSC.cmd
>     source=ACME.Controller.Central
>     target=ACME.Lighting.apartment:>
> }
> output.state.1
> {
>    ID=03
>    State=ON
>    Level=50%
> }
> output.state.2
> {
>    ID=1B
>    State=OFF
> }
>
> Having said that I suspect that most people would still process this
> sequentially/as two messages , changing the '03' output to ON followed
> immediately by changing the '1B' output to OFF. The key aspect is that
> both changes happen, or neither (should the packet not be received).
If
> the device does support a mechanism for presetting it's outputs , say
> with a latch, and then actioning all changes coincidentally then
> technically that would be the correct way. Then there couldn't be a
> glitch time during which both could be ON for example.
>
> One thing that you will read in the xAP v1.2 spec is that it is
> allowable to include within each body a target= line which effectively
> combines with the main message target= line in teh header to further
> restrict which devices action each individual body part. Often the
> target in the header would have some wildcard construct and the one
> within the body would be more focussed, but could again use wildcards.
> Although powerful this in practice is complex to implement and has
> limited application , indeed as far as I'm aware no-one has used that
> feature . As such it is proposed in the xAP v1.3 specification that it
> be deprecated - which you'll be pleased to hear.
>
>     Kevin
>
>
>
>
>
>
> drodegeb wrote:
> > I am developing a DLL in vb.net to be used in a couple of my
future
> > projects.  I am hoping to have this dll do most of the work and
make
> > it simple to integrate into other applications.  I understand
that the
> > packet can have multiple bodies.  Is it likely that the bodies
are
> > actually tied to each other and need to be processed together, or
just
> > based on the same header?
> >
> > The reason is that I want to pass the messages to the primary
> > application calling the DLL, and I don't mind repeating the
header
> > over for each part of the body to make it easier in the parent
> > application.
> >
> > Thanks,
> >
> > Dave Rodegeb
> >
> >
> >
> >
> >
> >
>