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



>(1) I notice that you don't align VSCP classes

My thinking was that they are so different that it would not make any
sense. for incoming VSCP events. But sure a construct like

vscp.event."vscp-class"."vscp.type"

would work equally well. Would this be acceptable and prefered?

>(2) Will you be supporting VSCP class=0 messages?
Class=0 is the only class that have some events that address nodes.
The current version of the daemon interfaces does not support this and
the upcoming release will not either but the release after that will.

To do this the Interfaces that the device is at has to be known. So
the magic number form my previous post "6789" is the interface id
and
would address the correct interface.

This is just a problem for Level I devices which use the nickname id
instead of the bandwidth wasting full GUID used on Level II.

>VSCP daemon hearbeats...
VSCP nodes can send heartbeats but normally they want do that. Instead
a temperature node sends out the temperature and so on. So any
heartbeats from VSCP nodes will come out to xAP just as a any standard
VSCP event. I will however implement the standard hearbeat in the xAP
VSCP daemon driver and allow for mapping if someone wants this.

Some qustions coming up on my side.

For UID=FF123400

how are the 1234 assigned uniquely. Manually or through some automatic
process?

For the xAP hubs that are available today is there a standard way to
detect that a HUB is already there so my code can select if it should
be a client or start its own HUB functionality?

/Ake


On 8/8/05, Gregg Liming <gregg@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,
>
>      A couple of additional comments:
>
>  (1) I notice that you don't align VSCP classes w/ xAP classes. 
Instead,
>  the VSCP class is a field in a body block.  Is there a reason that
you
>  didn't align VSCP classes w/ xAP classes?  I'm asking because
>  misterhouse (mh) uses the class and source fields to quickly filter
or
>  route messages based on mh object registrations (which specify source
>  and/or class w/ wildcarding).  I don't know if other xAP applications
>  utilize a similar approach to more quickly "triage"
messages (and better
>  handle message "floods").  I'm not suggesting that you
change your
>  schema based purely on mh desires; however, it would seem more
intuitive
>  that VSCP classes align w/ xAP classes (of your choosing/creation).
>
>  (2) Will you be supporting VSCP class=0 messages?  Specifically, I'm
>  wondering about how you might handle/address VSCP daemon and device
>  heartbeats.  The VSCP spec suggests a VSCP heartbeat rate of 1 per
>  second.  That's a bit more rapid than typical xAP apps (which I
believe
>  normally report 1 per minute).  I'm wondering whether it might be
more
>  useful to accumulate all of a VSCP segment's hearbeats into a single
xAP
>  message (schema TBD).
>
>  Regards,
>
>  Gregg
>
>
>
>
>  ________________________________
>  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.
>
>  ________________________________
>





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.