VSCP is an open source standard protocol for Home Automation and other remote control applications. It enables simple, low-cost devices to be networked together with high-end computers, whatever the communication media used.

There are a lot of technologies and protocols that claims to be the perfect solution for home automation and SOHO (Small Office/Home Office) control. X10 is the most well known system using power line. More and more RF solutions are now available too: Bluetooth, Zigbee, Z-wave, Wifi, etc. Many systems use a dedicated bus based on RS485, CAN, LIN, LON, TCP/IP, etc. or can sometimes support different transport layers: CANopen, KNX (EIB), C-Bus, LonWorks, etc.

Most of them are proprietary, some are somehow “open”, meaning you can participate if you're part of the alliance and pay your yearly fees, or anything similar. Except the small companies that have their own proprietary and completely closed small and simple protocols, the more standard solutions are usually difficult to understand, implement and require quite a bit of ressources.

VSCP was designed with the following goals in mind:

• Free and Open. No usage, patent or other costs for its implementation and usage.
• Low cost.
• K.I.S.S. (Keep it simple stupid.) Simplicity usually rules.
• Flexibility and performance, we still want the system to do what we need, in any situation.

The VSCP Protocol was initially used in CAN networks. CAN is very reliable and cheap today and allow us to manufacture low cost nodes that can work reliably, efficiently and can be trusted in their day-to-day use. But VSCP can be used equally well in other environments than CAN.

To meet both low cost and performance, VSCP is divided into 2 levels. Level 1 is intended for low-end nodes (i.e. based on tiny microcontrollers) while Level 2 is intended for higher level and faster transport layers such as TCP/IP. All nodes can talk together but level 2 nodes achieve better performance when talking together, while level 1 nodes that don't require much processing can be implemented with very cheap technologies.

Furthermore, VSCP:

• uses standard components and cables;
• should be easy to configure.

This protocol is open and free in all aspects that are possible. We want you to contribute work back to the project if you do your own work based on our code but we also like to make as much of this work useful also in commercial projects. The tool we have chosen to do this is the GNU public license and the lesser GPL. For firmware code we use an even more open model so that there is no question that you are allowed to put the code in your own commercial projects if you feel to do that.

The GPL license and the LGPL license is included in the distribution of code in the file COPYING but can also be ordered from by writing to the Free Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

There is an exception in the license from GPL/LGPL that make the tools more useful for commercial use.

Full license is here vscp_license

Copyright © 200-2008 Ake Hedman, D of Scandinvia

Current information about canal, vscpd and VSCP (Very Simple Control Protocol) can be found at:

http://www.vscp.org
http://sourceforge.net/projects/m2m
http://sourceforge.net/projects/can
http://sourceforge.net/projects/ohas

There are two mailing lists available on Sourceforge https://sourceforge.net/mail/?group_id=53560 that is about canal (can_canal) and VSCP (can_vscp) topics.

• To subscribe to the canal list go to http://lists.sourceforge.net/lists/listinfo/can-canal
• To subscribe to the VSCP list go to https://lists.sourceforge.net/lists/listinfo/m2m-development

Many of the thoughts behind this protocol come from work done as early as 1986 but high node costs at the time made it impossible to do the things VSCP can do today. The official start date/time is 2000-08-28 14:07 CET when the EDA project (http://sourceforge.net/projects/eda) was registered at Sourceforge.

EDA stood for Event-Decision-Action and is still preserved in the decision matrix of VSCP.

Why is this the VSCP protocol needed?

Most people don't remember what the world looked like for PC developers before Windows was introduced. This was a time when the developer needed to ship a big bunch of floppy disks with his/her application. One big pile of floppies were for different printers. Another set of disk was for different graphical cards and yet another for different pointing devices etc. It was not uncommon to have one floppy for the application and fifteen to twenty for drivers.

Windows changed this. The OS introduced abstraction for devices and from that point drivers was something the OS dealt with and the application developer could concentrate on creating the application. This was the big reason behind the boom in software that made Microsoft and others successful.

VSCP does this for automation tasks. Look around and see how it looks today. We have applications that work for Zigbee, X10, KNX, LonWorks etc. Some try to combine them into one application like MrHouse and the like but still it's a different thing to turn on a lamp using Zigbee, X10, KNX or whatever. In the best case the same user interface component can be used but still there is a need to differentiate between the technologies use also at that level and most important the knowledge about the technology is needed on the top level.

VSCP try to hide this. Drivers implement the interface to the technology and they all talk to the system using the VSCP protocol and understand VSCP protocol events. Compare this with printing under a modern OS. It's no difference today if you print to a Laser printer or a ink jet printer. Also it all works the same if the printer use protocol x, y or z. You are also still able to configure and print with the printers. This is where the abstraction comes into place.

To switch on a lamp (or a group of lamps) in VSCP we send a

 CLASS1.CONTROL, Type=5, TurnOn

event.

A driver translates this event to its own format and does its specific work using its own protocol and returns a

 CLASS1.INFORMATION, Type=3, ON

event when its job is done as a confirmation for the rest of the system.

An application now does not need to bother how the actual control is done. On the application level it's enough to implement a button and some visual indication to indicate the outcome of the operation.

A system to present some measurement data is another example. Think of a system with temperature sensors. They all use different technologies but a driver for each translate the temperature readings to a common

CLASS1.MEASUREMENT, Type=6, Temperature measurement

event. This event is region independent and format independent. It is easy to create a driver that log this value into a database. Also here in a common format. You can now build a web applet that shows the temperature for every possible temperature sensor. As the format is common and easy to collect in a database in a common way you can also write a statistical application that show temperature data and work for any temperature sensor.

The above is the most important reason for VSCP but there is more.

Each VSCP device have a common way it can be configured by. This means one high level software can be used for all devices. Note that a device necessarily does not need to implement this. Instead a driver can do that and make it look like a VSCP device. Typically is a 1-wire sensor where the driver can implement the parameters for it and export it in a common way.

All VSCP devices is described in a common way. The device itself holds this information and therefore when a device is found all information about how it is configured and used is available. Again this information can be implemented in the driver.

VSCP defines a lot more functionality and can be used all the way out to the actual device. Still the most important part is the abstraction.