VSCP, the Very Simple Control Protocol
Information has been moved to the wiki.
Go to http://www.vscp.org/wiki/doku.php?id= instead.
The VSCP project is nothing special. Its just a project that connect tiny little things and let them work together in a very easy way. Its use are intended for SOHO (Small Office Home automation) but it can be used in many other areas. It can have a central server but works well also without one.
The protocol is divided in two levels.
VSCP Level I
This is for tiny devices like a switch or a sensor. It allows for a maximum of 254 nodes working together on a segment. More segments can be used and they can be coupled together if more nodes are needed. CAN, RS-485 or RF are examples of carriers for the protocol. The initial work is around CAN (Controller Area Network) and TCP/IP for Level II events.
Each node is identified by a globally unique id which also can be used as a node serial number. On a segment this GUID is translated to a 8-bit “nickname-id” using a simple initialization phase. This nickname-id lives with the device as long as it is connected to the segment.
Devices that confirm to VSCP Level I can be of two types.
Full VSCP nodes
This type of node determine its nickname address when it is hooked to a segment. It can send out predefined events. It also have registers that can be modified to make it work in a different way then the default. It can have a decision matrix which makes the module react on incoming events.
Hard coded VSCP nodes.
The hard coded node is the simplest from. This type of node are only capable of sending out events. It is not possible to interact with the node in any way.
Typical examples of this type of nodes can be:
* A node that send out an event when a button is pressed ( typical example is a light switch ).
* A node that send out an event when a PIR detector is activated.
* A node that send out an event on an alarm condition.
The node can have its nickname-id set in hardware letting the installer manage possible address conflicts or it can implement the VSCP standard “find nickname” mechanism.
VSCP Level II
VSCP level II are much like level I except for a different event structure. A node is always addressed with the full global unique id. The data part in each event is extended to 487 bytes. All other parts of the event structure has been increased. The medium is TCP/IP.
Events
Everything in the VSCP world is based around events. Something happens and as a result an event is sent out on the VSCP segment.
A typical example of such an event is when you press the light switch in your home. The event that you carry out is to press the light switch. The light comes on as an effect of this. The “light on” is an action in VSCP terminology.
* Events have a priority. Very important event such as an alarm. Not so important such as a temperature reading. And some in between.
* Events belong to a class of events. Typical is the measurement class, alarm class and X10 class.
* Events also belong to a type. The type give more specific information about different events within a class.
* All events also originates from a node. The nickname-id for that node identifies it and is included in the event.
* Also each VSCP level I event can carry eight bytes of class/type specific data.
Complicated way to light a lamp...
Lets light a lamp in your home the VSCP way.
This requires two VSCP nodes.
* One node that can turn a lamp on/off.
* One node that can check if a switch is open or closed.
We install the node for the switch. When we press the switch it generates the on-event. When we press the switch again it generates the off-event. With the automated address assignment mechanism the node gets a nickname-address lets assume it is set to 43. This address is permanent from now on.
The node that can light the lamp also generates on/off events. An on-event is generated when the lamp is lit. and off-event is generated when the lamp is turned of. Les assume this node got nickname-id 57.
To get the functionality we expect from a light switch/lamp combination we need to program the decision matrix of the lamp node. We program it in the following way.
1.If a on-event is received from node 43 turn the lamp on.
2.If a off-event is received from node 43 turn the lamp off.
Looks like an expensive way to handle lamp switching... But even in this simple scenario there can be advantages with this set-up.
* The lamp node can have functionality to sense when the lamp is faulty and inform about this (send alarm-event) so that someone can change the lamp bulb.
* The lamp node can be controlled through its VSCP registers from a computer. The computer can turn the lamp on/off and check the state.
The “state” for a node is reported on the segment and can also any time be checked by reading the lamp nodes VSCP registers.
* To add on/off switches we only need to add switch nodes and elements for each switch to the lamp nodes decision matrix.
* A remote control node (IR/RF remote control) can control the lamp. Just add entries in the decision matrix for the buttons on the remote that should handle the lamps state.
* We can also add buttons that implement “all off “ or similar functionality.
There are many possibilities.... but they are all easy....
Registers
Each Level I node has a mandatory set of registers (not in hard coded nodes). The registers always contains the global unique id for the device, a manufacturer id that identifies the device, a user id that can be used for installation house keeping, an alarm register that can be checked for latched alarm status from the device. Also there are an URL stored which points to a server on the net which contains information about that specific node in a well specified XML format. So if you get a node in your hand there is always a way to get info on how to use it.
The node can also have user defined registers. This is registers that can be used to control the node. “Turn on a lamp by writing a one in register x” is a typical example. The decision matrix is also stored in this area.
Decision Matrix
The decision matrix is a powerful feature that some but not all nodes have. It contain elements that perform actions as a result of incoming events. This also make the nodes usable without a dedicated server.
An action can me a node predefined action such as turn on/off a lamp. It can also be to send out a new event or a combination of both.
Decision matrix content as well as all other register content are persistant and is stored after power failures and other events.
Where are we today?
The lower level drivers and services for CAN (CANAL) and VSCP is ready. This makes VSCP usable on the PC level both for UNIX/Linux type machines and on Windows. All source is freely available.
The first VSCP hardware node prototype is finished. It is a temp/humidity humidity module. The source is in MCC18 C and is freely available. PC's and ready made modules will be available.
The full specification and the source code is available on this site and at
http://sourceforge.net/project/showfiles.php?group_id=53560
All software released under Firmware License, GNU GPL and LGPL.
Last change: 2005-08-09
Copyright (c) 2005 the VSCP Team