[Message Prev][Message
Next][Thread Prev][Thread Next][Message
Index][Thread Index]
Re: Addressing vs sub-adressing... and vendorid
- Subject: Re: Addressing vs sub-adressing... and vendorid
- From: "Kevin Hawkins" <yahoogroupskh@xxxxxxxxxxxxxx>
- Date: Sun, 25 Nov 2007 20:58:39 -0000
--- In xAP_developer@xxxxxxx, "Patrick Giasson"
<patrick.giasson.maillinglist@...> wrote:
>
> Also, can a single address have multiple subadresses of the same
> type? See page 4 of TSC Schema.
>
> I see that ID1 and ID2 are position outputs, but how are they to be
> addressed individually using xap addressing?
>
> acme.radiatorcontrol.instance1:position ??
acme.radiatorcontrol.instance:position.1
acme.radiatorcontrol.instance:position.2
acme.radiatorcontrol.instance:hall.radiator.left
acme.radiatorcontrol.instance:hall.radiator.right
acme.radiatorcontrol.instance:livingroom.radiator
acme.radiatorcontrol.instance:diningroom.radiator
whatever you like really as long as each address is unique.
NB you mustn't do this though
acme.radiatorcontrol.instance:livingroom.radiator
acme.radiatorcontrol.instance:livingroom.radiator.window
as the number of hierarchies are conflicting within an identical
leading portion of the address, you could have the latter above and
acme.radiatorcontrol.instance:kitchen.radiator
though
>
>
> If ID is mandatory in the cmd class, why do we use subadressing at
> all?
>
> ID = two last bytes of UID, right?
Sub addressing is a way of associating and grouping endpoints within
one device. ID= is part of the endpoint 'targeting' of the CMD at the
device. It is needed when the target address is wildcarded and used to
further refine which endpoint is being changed. Bear in mind you could
have several bodies attached to one xAP message that each was directed
at a different endpoint.
eg if we have the two endpoints from above as follows
acme.radiatorcontrol.instance:hall.radiator.right
UID=FF123401
acme.radiatorcontrol.instance:hall.radiator.left
UID=FF123402
Now with ONE xap message you send
xap-header
{
v=12
hop=1
UID=FF123400
class=TSC.cmd
source=acme.heatingcontroller.instance1
target=acme.radiatorcontrol.instance1:hall.radiator.*
}
cmd.position
{
ID=01
unit=Arb
value=50
}
cmd.position
{
ID=02
unit=Arb
value=90
}
You will see that in one xAP message radiator 'right' was set to
position 50 and radiator left to 90 ... the ID determined which
radiator was being addressed. You could do this with two separate
messages of course but the purpose of one message is twofold.
a) Both changes can be applied coincidently - there is no transient
state , even for a fraction of a second.
b) In the unlikly event that a message is lost then neither changes
are actioned - ie its both or neither. This is more important say when
you can open a valve and turn a pump on in one message
>
>
>
> And why aren't ID mandatory in the info and event classes? Am I
> mixing up things?
They serve no purpose there. An info or event only reports one single
endpoint and hence the UID is fixed and known from the UID header. An
info or event has a single body in the message.
>
>
> So many questions ;-)
A few answers... keep asking away though
>
>
> Thanks
>
> Patrick
PS Just as a precaution let me warn you that the imminent xAP v1.3
has changed the UID format from
UID=FF123401 to
UID=FF.1234:00 or indeed
UID=FFAB.123456:789A
You will see that the three portions of the UID can now be longer.
This was primarily done for the benefit of the latter segment - the
sub address which previously allowed 254 endpoints 01-FE. Having only
254 endpoints was found to be too restrictive so a 4 digit sub address
(65534 endpoints) or even longer can now be used .
Kevin
xAP_Development Main Index |
xAP_Development Thread Index |
xAP_Development Home |
Archives Home
|