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: Proposal for VSCP schema



Mark Harrison (Groups) wrote:

>On Mon, 2005-08-08 at 08:14 -0400, Gregg Liming wrote:
>=20=20
>
>>This limitation is (IMO) very limiting to those of us creating
xAP=20
>>gateways for systems that have many more than 254 devices and
>>inevitably=20
>>causes "hacks" to be required to handle the mappings. 
I'm personally=20
>>hoping that the xAP spec will be revised soon to support a much
larger
>>number of subaddresses.  In the mean time, I've had to resort to=20
>>"virtual" subaddresses that nominally map to semi-natural
groupings of
>>devices.  Even this technique, however, doesn't scale well and
will=20
>>break if pushed.
>>=20=20=20=20
>>
>
>We discussed this at xAPCon04, and ISTR that everyone was in favour of
>extending the size of UID.
>
>I note that Kevin is going to push this forward, though for the record,
>my preference is for 2N8A8S
>=20=20
>

and mine....  :-)      although I sort of like including the delimiters=20
- but no-one else did so I'll surrender !

>That having been said, I'm in favour of the "majority
decision" on which
>length they should be because a quick decision is more important to me
>than the difference between 2N8A8S and 2N6A6S - either is enough for
the
>immediate requirements.
>
>If nothing else, it would make the BSC handling in xAPHomeVision _much_
>easier - at the moment, we map each house code on to a different xAP
>Device, to allow the full 256 X-10 devices - the 254 limit was terribly
>annoying. (I realise that xAPHomeSeer has a different set of
>constraints, because of the way that HomeSeer allows virtual X-10
>devices.)
>
>If truth be told, the BSC Support in xAPHomeVision is good, but the
X-10
>Schema support is fairly flakey. I'd be in favour of getting the UID
>issue resolved ASAP, so we can rewrite the X-10 stuff cleanly!
>
>One key question though - will extended UID be enough to push v=3D12 up
to
>v=3D13? I think, realistically, yes, in which case we may want to
consider
>message fragmentation at the same time - though the "get it
done" rule
>is again more important to me.
>=20=20
>
I think I would like to formally agree the format of the new UID and=20
release it asap so that people can use it from effectively xAP 1.21=20
onwards.  I would very much like to get the message sequencing ironed=20
out (and those couple of other things that build on this that we=20
discussed at xAPCon) but I think there's still a bit of work to do here=20
and I wouldn't want to delay the UID adoption as it's impacting lots of=20
applications and even causing 'abuse' of the UID as there isn't an=20
alternative.  AFAIK the UID change is the only aspect that could cause=20
incompatability with existing applications - the other changes are all=20
really enhancements that work as higher level policies and so should be=20
transparent.  (remember "gracefully ignore any unexpected parameters
you=20
don't recognise/expect whilst parsing", including within the
header).=20=20
BTW Gracefully means "don't throw a wobbly" and don't drop
subseqent=20
parsing.

>M.
>
>=20=20
>
K





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.