Re: Proposal for VSCP schema

[YAP <x112358@xxxxxxxxx>]

Kevin,

thanks for your comments and suggestions. Pling was new to me and I
will add it. How long can such a line be?

For the seperation of the classes for cmd and event I think its
perfect. Will change that to.

Will do the BCS mappings on a higer level and not expose zone, subzone
and index and instead use "logical names".  Will be much better
and it
would be possible to build a logical device from one or several real
world VSCP nodes that can be controlled rith BCS. Much better solution
then the one I originally suggested thanks to Greggs input.

>PS Are there any level2 VSCP devices about yet ??
I know our dear Charles Tewiah, London have someting running on a
Modtronix sbc65 board. I don't know if it is in a state that it can be
released. As of me I have about thirty Level I modules to do before I
can do any serious Level II stuff. Upcoming things are the Leicester
*very* low cost Ethernet board
(http://www.vscp.org/vscp/modules/leicester/images/main001.jpg,
http://www.vscp.org/vscp/modules/leicester/images/main_brd007.jpg)
and
the Milano wireless mains lamp dimmer
(http://www.vscp.org/vscp/modules/milano/images/milano_sch002.jpg,
http://www.vscp.org/vscp/modules/milano/images/milano_brd002.jpg
)
And many many other fun gadgets.

/Ake

On 8/8/05, Kevin Hawkins <lists@xxxxxxx> wrote:
>
>  YAP wrote:
>
>  >Hi,
>  >
>  >This is a RFC as I have written up a first proposal for a VSCP
schema
>  >and some initial VSCP-xAP mapping thoughts. It is available on
this
>  >page http://www.vscp.org/vscp/proposals
>  >
>  >Suggestions, thoughts, directions are all welcome.
>  >
>  >/Ake
>  >
>  >
>  >
>  Hi Ake
>
>      Just read your RFC on the train, good stuff,  and I have just
been
>  beaten to the post via Greg who has raised a lot of the points (and
many
>  others) that I was going to make.
>
>      Just recapping on a couple of the key ones. A xAP longform
address (
>  source= ) is made up of two parts , the application/device address
and
>  then a ':' and then a sub address which is intended for further
>  segmented endpoints within that one device.   The whole address must
>  uniquely map to a UID of the form  NNAAAASS   where NN is the network
>  (usualy FF), AAA is the application/device ie the main address to the
>  left of the : in the source= part and the SS is the sub address.  00
and
>  FF are reserved for SS and so you have 254 possible sub addresses to
>  play with.   00 is used to identify the complete device rather than
any
>  individual enpoint and FF is reserved for future use.  What is
important
>  is that any source address must map to a specific and unique UID and
>  each possible sub address (the part after the : ) must map to 01-FE
as
>  the last two digits of a UID   Hence no soure addresses with a : in
them
>  can have a UID that ends in 00.
>
>      This 254 limit on sub addresses is restrictive, we are aware of
that
>  and will be expanding the UID soon, indeed I will again canvas the
>  steering group to get this formalised & released ASAP.  It is
likley to
>  move to the form NNAAAAAASSSSSS or NNAAAAAAAASSSSSSSS  which will be
a
>  vast improvement. People writing current applications should make
>  provision for this.  If anyone has any comments on this sizing please
>  let me know. We are potentially interested in how this might be used
to
>  map to other specific unique identifiers eg MAC addresses, IP or
>  GUID's.     We have also considered but dismissed a separator in the
UID
>  as a delimiter ie UID=NN-AAAA-SSSS  to allow variable length
allocations.
>
>     In your VSCP class within xAP I think you should have a different
>  class or block identifier for a received VSCP compared with  a
command
>  to send one, otherwise they can't be differentiated (except by teh
>  inference that there is a target line present).  So I would suggest
>  something like
>
>  Class=VSCP with a block of level1.event  and level1.cmd or perhaps
>  Class=VSCP.event / Class=VSCP.cmd  with a  block name of just level1
>  perhaps
>
>  (duplicating VSCP and the level1 in both the class and section name
>  isn't necessary and uses space.   The Class should identify the types
of
>  possible messages (blocks) that you might expect (ie the schema) and
the
>  blocknames define the actual type of data content to be expected
within
>  the block so perhaps level1 and later level2 are both subsets of a
>  VSCP.cmd or VSCP.event
>
>
>    Where you are using ASCII coded hex data - if it really is binary
data
>  (and I think it is from the VSCP spec) then you should use the !
(pling)
>  delimiter instead of the =
>     ie data!010701  rather than data=010701 - its is then known it can
be
>  stored in 3 bytes.
>
>  I am confused by the source/target address formation in the BSC
mapping
>  but I need to refer back to the VSCP to better understand this I
>  think....  basically I think it's a way of mapping an address of teh
>  form 0-255 on VSCP to a longform address in xAP.   Certainly they map
>  well if you can avoid the 00 and FF addresses on level1 VSCP - but
you
>  may need to handle wildcarding with some care (or ignore it) , by
>  generating multiple messages on VSCP possibly.
>
>  More thoughts poss later... looks a good basis to work from though
>
>     Kevin
>
>  PS Are there any level2 VSCP devices about yet ??
>
>
>
>
>
>
>
>  ________________________________
>  YAHOO! GROUPS LINKS
>
>
>  Visit your group "xAP_developer" on the web.
>
>  To unsubscribe from this group, send an email to:
>  xAP_developer-unsubscribe@xxxxxxx
>
>  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
>
>  ________________________________
>