The Very Simple Control Protocol (VSCP) is a free automation protocol suitable for all sorts of automation task where building- or home-automation is in the main focus. Its main advantage is that each VSCP-node can work completely autonomous, being part of distributed network of other nodes. VSCP is independent from the physical layer (e.g. CAN bus, Ethernet, RS-485, RS-232, MiWi) connecting the individual nodes to form the automation network bus. On the bus there can be nodes reading switches, controlling lighting, blinds, windows or information displays, broadcasting physical measurements (e.g. temperature, luminosity, power consumption, etc.), multimedia control, burglar- or fire-alarm, etc. There is a subset of the protocol (Level I) that is very much tailored to the CAN bus and resource restricted microcontrollers. Protocol Level II is designed for Ethernet (UDP, TCP and own Ethernet-type Raw-Ethernet) and wireless physical layers. All share the same common message fields and framework and can be connected through gateways.
Event VSCP is based on events. Each time an event occurs it is broadcast towards all other nodes. Each node on the network will receive the event and will decide if this event needs to be handled or not.
The example given in the diagram describes a button being pressed. This will result in node 1 sending an event message onto the bus informing all others the button is pressed. Node 2 receives the message but decides this button should not trigger an event for node 2. Node 3 receives the message and decides this button should trigger lamp 2 to turn on. There can be events for all sorts of things happening: an event can be a button pressed, a presence sensor being triggered, or the sun setting. Events can also be sent periodically, for instance a temperature reading every minute. VSCP predefines many events that could be happening. These events are defined into classes and types. Whether or not an event received should be handled is determined by the decision matrix or DM in short. Also the DM is explained further.
Event Class and Type Events are organized into Classes. A class is a collection of events that somehow belong together. There are classes for ALARM, MEASUREMENTS, CONTROL, INFORMATION, etc. Currently VSCP specifies about 25 classes, but has room for many more 1. Each class is on its turn subdivided into types. A type further specifies the event within the class. For instance, events of Class 20 (0x14) are INFORMATION events. In this class there is a subtype 1 (0x01) BUTTON signaling a button being pressed. In this same INFORMATION class there are also types to signal ON, OFF, BELOW LIMIT, etc. Likewise in class measurements there are types to signal temperature, current, voltage, etc. Having all these classes and types defined makes the nodes speak the same language. For a full list of pre-defines classes & types check the VSCP wiki.
VSCP event datagram structure Events that are broadcast contain a number of fields together forming one VSCP datagram. Exactly how these fields are mapped onto the physical layer is specified for a number of physical layer protocols such as CAN, Ethernet, TCP, etc. For others it is not yet defined, but it is in general not difficult to map these fields onto a physical layer protocol. There are 2 levels of the VSCP protocol called LEVEL I & LEVEL II. They are both basically the same protocol but differ in size of the different fields. Level I is intended to run on nodes with more constrained resources and fields are defined a bit more conservatively. Level I is in fact a subset of level II, and with an appropriate gateway events can transverse between a Level I & II network.
Level II is intended to be run on nodes that have little resource constraints and can easily cope with larger message sizes.
Decision matrix
When events are received by a node the node needs to determine if it needs to execute a task based on that event. This is done by evaluating the decision matrix or DM in short. The DM matrix is made of a number of IF ... THEN ... conditions. Each such IF/THEN condition is called a line and multiple lines make up the decision matrix. The Class and Type of the incoming message is always evaluated by a DM line. Evaluating Class & Type is done by passing the Class/Type through a mask first and then comparing with a filter. This method allows multiple class/Types to trigger a valid condition for 1 line of the DM. The other conditions for the DM line (SenderGUID, Zone, Subzone) are optionally evaluated. If the DM line is valid then the ACTION is executed. Together with the ACTION there is an ACTION parameters. An example ACTION would be: turn-on relay 6 with 6 being the action parameter. Exactly which ACTIONs are possible by the receiving node is determined by the design of the node itself. It is up to the firmware developer to define which actions can be executed. By then documenting the possible action in the MDF file (see later) the configuration SW will know how to select this action. The DM can be modified by setting the appropriate node configuration registers. A convenient way to do this is using the VSCPWorks configuration SW.
DataPayload An event being sent can also carry a data payload. The content & organization of this payload is depending on the class and type of the event. For example, an event of class 10 (measurement) and type 6 (temperature) will carry the temperature data (with coding determined by byte 0, degrees or Celsius) in its payload. A button event will carry information about the button & button zone/subzone in its datapayload. For each class/type the data formatting is determined in the spec, please consult the wiki for details.
Zone/subzone Some (quite some) events contain a field zone and a field subzone in their datapayload. This functionality is present to make grouping of nodes possible. For instance we could determine that all buttons controlling a certain lamp are part of the same group. This simplifies the DM for certain scenarios. Instead of having one DM line as the lamp node for each button (1 line per button: IF button x then turn-on lamp) we could have 1 DM line only saying IF (zone match) THEN turn-on lamp. Making multiple node switches part of a group is done by configuring the nodes, the firmware of the node will support this functionality.
… excerpt ends here. Continue reading the full article.






