Re: bsc questions

[Kevin Hawkins <lists@xxxxxxxxxxxxxxxxx>]

Ian Davidson wrote:
> Kevin,
>
> Thanks for the reply. I hadn't realised I could restrict the target
> length and still be compliant. I should have a little time again next
> week so I'll see how it goes coding again.
>
Actually xAP doesn't formally restrict the length to even 128 ..  all
that restricting it to very short addresses causes is the device not
being able to interact with (all) other devices - but if your device
isn't wanting to do this it's hardly a problem.
> When I mentioned targeting via UID I don't think I explained well
enough
> what I meant. If there was a UID target field, the device it was
> intended for could read this field and know to act on the message. The
> usual target line could still be populated with an address but the
small
> micro would not read it. However other devices on the network would be
> allowed to ignore the UID target field and otherwise treat the message
> as standard even though not directly targeted to them, such as a
display
> or speech type interface. Sorry for the confusion I should not have
used
> the word exclusive as I did realise all UID's must indeed be unique
>

Ahh - I see what you mean now.  Having an optional TargetUID field but a
mandatory (non wildcarded) target= line.  That's an interesting one...

Actually there are two ways you could do this within the current spec .
Firstly you could add the TargetUID= field as a parameter into a schema
body of a schema you defined (even a BSC one) or secondly & probably
better,  include it in the header where it sits more naturally.  We have
some experimental parameters already defined that you could use for
exactly this purpose - and all existing xAP applications should just
ignore them.    There is a rule in xAP that you should gracefully ignore
any unexpected name/parameter pairs, or blocks that you encounter whilst
parsing a message. Gracefully means just skip them basically (and
continue parsing). This allows for both later expansion of a schema and
your own customisation too. It can be done in the header too but as that
has such key and formal data we predefined the names of these parameters
for experimental use , of course 'any old name' shouldn't cause problems
but prefer to stick to the 100 reserved ones - which are Test00 to
Test99  - I believe in decimal sequence.  I am fairly sure all the
existing hubs pass these parameters although I have a feeling the very
rigid xFX based ones drop any other named parameters, and maybe
therefore even drop the whole message as being malformed  I'll try this
shortly and confirm. .  If the experimental usage has proven benefits
over time  then the TESTxx parameter can be given a more useful name eg
TargetUID and added to the xAP spec.  In order to test your parameter
with other people/devices then please choose a TestXX parameter name and
publicise exactly how you are using it and other people can then use it
in the same way. At this stage I am not aware of any of them being
(formally) in use already.

Just for interest - one other approach that was discussed  is to have a
helper PC application that mapped UID's to source addresses and listened
for messages resending them and replacing the target or source with
another mapped as Source=FF.1234.05 to match the UID for example.
Effectively then in your device you have both a source address and an
alias source which is your UID as above. This is not a workable (or
nice) solution however as it duplicates messages and if those messages
have say 'state=toggle' in them it is not predictable as to the result

Also a reminder that in xAP v1.3 the new UID format will almost
certainly be UID=NN.AAAA:SS    with a . and : delimiter for the various
component parts and additionally the size of the 3 fields is flexible eg
FF.123456:7890  .  We are likely to define some recommended patterns eg
NN as 2 chars ,   AA as 4 6 or 8 and SS as 2 4 6 8 or even more.  1-wire
devices for example need very long identifiers .    The main issue with
the UID so far has been the restriction to 254 sub addresses and I
expect most people that have hit this issue (eg X10, HomeSeer, Charmed
Quark, MisterHouse, HomeVision, 1-wire  etc) will move to a
UID=NN.AAAA:SSSS  ( or  even perhaps UID=NN.AAAA:SSSSSS if they have
more than 64K endpoints - somewhat unlikely).



Kevin