The UK Home Automation Archive

Archive Home
Group Home
Search Archive


Advanced Search

The UKHA-ARCHIVE IS CEASING OPERATIONS 31 DEC 2024


[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

Comments to the Webmaster are always welcomed, please use this contact form . Note that as this site is a mailing list archive, the Webmaster has no control over the contents of the messages. Comments about message content should be directed to the relevant mailing list.