Re: Proposal for VSCP schema

[YAP <x112358@xxxxxxxxx>]

Hi Gregg and thanks for your comments

>
>  1) Your "received message" (re:
> http://www.vscp.org/vscp/proposals/VSCP%20xAP%20Schema%20examples.html)
>  does not contain a nickname field---which your schema (re:
> http://www.vscp.org/vscp/proposals/VSCP%20xAP%20Schema.html)
> claims is
>  mandatory

Hmm... Must set this "optional". Its a bit tricky as it will
always be
there on a received message but makes no sense for a sent message.


>
>  2) I am confused by the statement "6789 is an optional interface
channel
>  on the daemon" w/i your first example.  Is "interface
channel" the same
>  as the actual device or is it some transport/medium for gaining
access
>  to the device?  If the latter, then (AFAIK) the xAP subaddress needs
to
>  be fully qualified (i.e., include the device reference).

The daemon can have many interfaces which in turn can have up to 254
nodes.  The "nickname" just have meaning on an interface and is
an
abrevation for the nodes full GUID which is 128 bits.

All interfaces also have a GUID and can act as a proxy for the nodes
on the interface. So if I want to talk to a specific interface I can
use the full GUID of the interface or an interface ordinal
("6789").

Allmost all events in VSCP have no target adress with a few
exceptions. To read/write a register in a node and to bootload that is
update the firmware in the device, needs a target adress.

>
>  3) It is not clear to me the relationship/mapping between VSCP level
1
>  nicknames and your xAP subaddress.  Logically, they might be
identical.

See above.

>
>  4) The selection of "1234" in your UID is probably a bad
default value.
>  I'm assuming that your daemon will have some ability to permit the
user
>  to init this portion of the UID to something else.

Yes you are right. I just used Patricks example.

>  5) The LSBs "00" in your UID need to be changed to the
mapped subaddress
>  UID values that correspond to your "6789" subaddress.

OK Another map.

>  6) From my limited reading of the VSCP spec, a level 1 VSCP segment
can
>  support up to 256 level 1 devices.  The maximum xAP subaddress range
is
>  254.  This means that a base xAP address of eurosrc.vscp.zeus could
map
>  to at most a single level 1 VSCP segment--excepting 2 of the possible
>  256 devices.  The implication is that you will need more xAP base
>  addresses to map to other segments (if that's needed) and groupings
of
>  level 2 VSCP devices.
>
>  This limitation is (IMO) very limiting to those of us creating xAP
>  gateways for systems that have many more than 254 devices and
inevitably
>  causes "hacks" to be required to handle the mappings.  I'm
personally
>  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
>  "virtual" subaddresses that nominally map to semi-natural
groupings of
>  devices.  Even this technique, however, doesn't scale well and will
>  break if pushed.

Actually it is 254 devices as 0 is reserved for a possible segment
controller (which most often is not needed) and 0xff is for an
uninitialized node. That is a node that does not have a nickname yet.

Every VSCP daemon can have CAN, RF, PLC, TCP/IP devices connected to
it.  Other interfaces like LIRC etc are also possible (and available
:-) ) So there can be a lot of nodes or logical endpoints.


>
>  7) Your BSC example
> (http://www.vscp.org/vscp/proposals/VSCP%20xAP%20mapping.html)
> shows an
>  xAP address of eurosrc.vscp.bsc.idx.zone.subzone*.*  I
> would have
>  expected use of xAP subaddressing syntax instead like:
>
>  eurosrc.vscp.bsc:idx.zone.subzone
>
>  Admittedly, I'm still confused by the use of idx and the absence of a
>  device reference following subzone.  Also, is "bsc"
useful/appropriate
>  in an address (it's obvious that bsc is being used based on the xAP
>  class value)?

The mapping was harder then I first expected.  This is beacuse VSCP
devices themselves are intelligent and can be configured to understand
things like "God Morning", "ON" or "ALARM"
and do there stuff without
any further addressing.

The idx and zone,subzone pair looks strange I admit. This is because
some events have an optional index parameter and some have optional
zone,subzone pairs.

When I look at this now it would probably be better to do a full
mapping with the idx,zone,subzone in the map with some symbolic id
visible to xAP.  I will revise this example.


/Ake