Preliminary Level II configuration Do not use!!!

For the level II part of the protocol a higher level configuration model for nodes has been added. This is a complimentary way to configure a device besides the register model. The manufacturer define what the dataformat for a specifc node looks like and specify this in the settings section of the MDF file. Module Description File

XML format for configuration events (requests/responses)

   <?xml version = "1.0" encoding = "UTF-8" ?>
   <config xmlns:xs=http://www.w3.org/2001/XMLSchema>
      <name>20</name>
   </config>

Where name is taken either from name in

   <name type = "string" lang = "en" description = "Description of this particular device parameter"/>

or from the id value in

   <abstraction id="somename"
         type="bool"
         default="false" page = "0" offset = "1" bit="0" >
        <name lang="en">tttt</name>
    <description lang="en">yyy</description>
    <access>rw</access>
    </abstraction>

The type of the value is thus defined in the MDF.

Also the registeroffset implied names can be used. See Module Description File

The abstraction tag is also valid for Level I and maps registers and abstract types together. A higher level node can from this information decide if it wants to look at the data/parameters a node holds from the register perspective (which must be implemented for all VSCP nodes, both Level I and Level II) or from a higher level.

This can be used to specify a short which in register space is stored as a MSB byte and a LSB byte but which can be handled as the higher layer type short by all routines above the actual register read/write which use the information in the MDF to know how to store the abstract value.

A number of the methods below requires that the GUID of the target node is known beforehand.

This can be achieved by sending a “Segment Status Heartbeat” (CLASS1.PROTOCOL1, TYPE= 1).

Nodes respond to this message by sending a NodeHeartbeat (CLASS1.INFORMATION, TYPE=9).

The following is an example of how these messages can be used.

1. A ConfigReadRequest event is sent. Index set to 0. The target node is addressed with its GUID.
2. Node responds with one or several ConfigReadResponse with the code portion indicating the current page / total pages and data in byte 9 and onwards.
3. Requesting node receives all the ConfigReadResponse events togehter forming the configuration. Note that if a ConfigReadRequest is detected whilst compiling the ConfigReadResponse message then the process is abandoned.

1. The requesting node can edit the configuration for a node and then send out a ConfigChanged event to indicate that the config has changed for this node by supplying its GUID.
2. The node interested in this can now request the new configuration by issuing a ConfigUpdateRequest.
3. The node that changed the configuration will now notice this event and send out a series of ConfigUpdateResponse events.
4. The target node received the events.

Example of response or config send from/to node

<?xml version = "1.0" encoding = "UTF-8" ?>
   <settings>
      <MSensor1>20</MSensor1>
      <MSensor2>800</MSensor2>
   </settings>

is a response from a node