Category Archives: VSCP

State of #VSCP (#nodered #raspberrypi)

Not much has happend in the VSCP world this year (hopefully it have in other places then in my location) but now it is time to do some serious stuff again.

Big changes are coming for VSCP.

One thing that happend the last years is that MQTT has become an IoT standard. Personally I have not been so keen to go this way because it really did not solve the issues of a fragmented IoT message community. Rather it encourage fragmentation.

The fact however is that MQTT became a standard and VSCP has a driver for it since it became available and people seems to prefer it so there is no other option really than to jump on this movement. The gain is massive software support and understanding of course. In VSCP case this means VSCP events will be pushed on a MQTT server on the JSON format as of the specification. Published on a channel /vscp/class/type/guid/index/zone/subzone it is easy to do some filtering also as MQTT allow for wildcards on each level. As an example subscribing to /vscp/10/6/* will get all temperature events. Details will follow.

Another thing I kept an eye on for many years is node-red. Up until recently this has been more of a toy but lately it has matured and now solve many of the things I have planned for vscpd. I therefore have decided to use node-red for higher level VSCP stuff in the future instead of doing this development on a parallel track. The coupling between vscp and node-red is easy. A node-red module that feed events form vscpd and a node-red module that send events to vscpd. Add some filtering and other stuff to this and we have a real winner IMHO. Expect a package soon.

Wo what does this mean for the vscp software suite?

Well, a new version of vscpworks is in development built on node.js and electron. Much nicer and faster development. It just needs to add MQTT interfacing to the tcp/ip and websocket interface that is available today. Also there is a node.js module available already.

vscpd will take a new development path and be a hub/relay or what it should be called, against lower level VSCP stuff such as can4vscp(bluetooth/etc drivers. It will do two tings.

  • Interface higher level stuff through it’s tcp/ip and websocket interface.
  • Interface lower level stuff through its level I/II/III drivers.

The rest of the functionality will go away. Most will be moved to Level II drivers wherever possible. MQTT interfacing is done with the MQTT driver available today.


  • The DM (decision matrix) of vscpd will be removed. Handled instead by node-red or other high end app. Will possibly be moved to a Level II driver.
  • The webserver of vscpd will be removed – Handled by standard web browser, node-red or other high end app.
  • The REST i/f of vscpd will be removed – Handled by higher end app such as node-red. Will possibly be moved to a Level II driver.
  • The sqlite3 database will be removed. Configurations will be all XML again.
  • The Javascript engine will be removed.
  • The LUA engine will be removed.
  • The UDP interface will be moved to a level II driver
  • The multicast i/f will be moved to a Level II driver
  • The discovery functionality will be removed. Yhis functionality will be built as a node-red module.
  • The automation functionality will be moved to a level II driver. Functionality is available in node-red already.
  • VSPC table functionality will be removed. (Will possibly be moved to driver). Handled in node-red or other high end app.
  • VSCP variables will go back to the original simple form – Handled better in node-red or other high end app. Variable types will be the same as VSCP abstractions. Deprecating the rest.
  • Not fully decided yet: Level II events will get JSON payloads. If so the current defined Level II events will be deprecated but available for a long long time. I welcome a discussion on this.

So vscpd will be a server that handles drivers and interface the higher level world through a tcp/ip and websocket interface. Nothing more. Nothing less.

Another important change that will come is to separate drivers from the software three. This lowers the dependencies to build the vscp tools a lot. Especially now when the dependency on wxwidgets is gone. The goal is to make things very easy to instal and use on devices such as Raspberry Pi and the likes.

So the roadmap for the near future is to implement this. As much of the work is to take a step back it is not expected to be a long runner.

As you all know I have been hospitalized under a long period this year due to an infection I got from a surgery. This is not fully cured and even when it is I have to redo the full operation sequence that started all of this. This mean I will be off for more time, not being able to do any development. But hopefully this will be a shorter time then the current disaster and mess.

I am very excited about all this and is confident that this is the way to go. Please let me now if you have questions or concerns about this.


This is a setup I have for my heating system. All VSCP of course, with a Raspberry Pi as a relay node and using node-red for higher level work.

State of #VSCP

Just a post to let you all know that VSCP is still alive even if not many things have happened for the last months.

As I wrote before I had some surgery in January this year and a follow up operation on that in June. Sadly I got a bad infection in the operation wound so I had to stay for some time at the hospital, but now I am home again eating tons of antibiotics.

Well things are pretty good now and I hope I am in working condition next month or so. But apparently one never know with deep infections, they often come back with full force. I, of course, hope it will not. 😉

I am sorry for all this talk about my health lately, everyone have enough with there own health and wellbeing, but this is my reality right know and I just want to indicate that VSCP is not dead. or even sick. It’s just me and I am in a good mode after all.

Have fun!

State of #VSCP

It’s been many months. I have more or less been unable to do any serious VSCP development. All plans for the first half of 2019 just went out of the window. Even if that hurts, loosing such amounts of time, I had a second operation last week and the doctors says I am allowed to do some programming again from the end of the month. I look forward to that.

So hopefully “the state of VSCP” will be less about my scars and more about project progress after this summer. I have done quite a bit of the new VSCP works client during this slow time and hopefully some initial code will be available publically also very soon. JavaScript is still a little “strange” for me. But I like Electron and node.js more and more.

I hope everyone reading this will have a very nice summer. A Blackbird, named Pavarotti here on the hill, is singing for me and there is nothing in the world more beautiful than his song. Enjoy the summer my friends.

Howto: Read a #VSCP mdf file with node.js

The Module Description file is a XML file that all VSCP devices must have and which describe the device. It can either be stored on the device itself or more common linked by the device and stored on some external server storage. Software that wants to configure a device can fetch this file to get the knowledge to do so. Typically a user interface use this file to guide a user through device configuration. A good thing is that one software can handle and configure any device.

A sample MDF file is here an here.

Read a mdf file from a device, parse it and display the module name. A device can consist of several modules, there will always be one and result.vscp.module[0] will always refer to the first. Most devices contains only one module. You can get the number of modules with result.vscp.module.length

Below are some Javascript examples on how to get information from the MDF-file.

Display the module name

const axios = require('axios');
const xml2js = require('xml2js');

let parser = new xml2js.Parser();

  .then((response) => {
                         (err, result) => {
  .catch((err) => {    

Similar to above sample get a link to the manual for a device


List all registers with


Iterate through all registers an display there names

  .then((response) => {
    parser.parseString(, (err, result) => {
      for (let reg of result.vscp.module[0].registers[0].reg) {

  .catch((err) => {

List register descriptions with


You get the language code for a register name or a register description with


List abstractions with

  .then((response) => {
    parser.parseString(, (err, result) => {
      for (let reg of result.vscp.module[0].registers[0].reg) {

  .catch((err) => {

List number of events the module can generate and the events

console.dir('# events: ' + result.vscp.module[0].events[0].event.length);

If you want an url to a picture of the module


If you want the manual


or a firmware image


The number of firmware images available

  .then((response) => {
    parser.parseString(, (err, result) => {
  .catch((err) => {

The release date for a specific firmware


The way this works should be obvious by now. Enjoy!

State of VSCP

Just a short info about what is brewing in the VSCP world.

Over the years that VSCP has existed it has been times with pretty good interest and times with very low-interest.  This comes and goes and have done so many times.  At the moment we are in a  low period.  Contributions to the project has never been very high even in periods of high interest,  almost non existing in fact, and of course that is not better during a low period like this.

I have been working with this for so long now and coded a lot of code with other people’s needs in mind. Mostly broadcasting free stuff with a lot of effort behind it out in an empty space. It feels a bit awkward to continue that road ahead forever. As it feels now I will switch to do more “fun stuff” for my own needs instead of doing a general package for m2m/IoT in the future.

New drivers on the way

For my own projects I need some drivers for the Raspberry Pi and  I therefore is building three Raspberry Pi specific drivers at the moment

vscpl2drv-rpigpio and vscpl2drv-rpigpio-if2

This is a driver that handle general GPIO on the Raspberry Pi (used pigpio/pigpiod). It can be programmed with a decision matrix so you can send for example CLASS1.CONTROL, TurnON/TurnOff event(s) to control specific I/O, PWM, Servo and frequency support is there. Also input monitoring. Event based and periodic. It comes in two versions one that uses thew pigpio lib and one that use the pigpiod server.


With this driver you can control a LCD connected to the Raspberry Pi by sending/trigger on VSCP events. parallel mode and I2C supported.


Interface a MAX6675 for K thermocoupole temperature measurements.

The driver is build if –enable-rpi is used in the configure script.  It will be a month or so before they is officially released.

Abandon wxWidgets

I have decided to leave wxWidgets for future work. This affects all components except VSCP works. Expect this to take a year or two before it is completed. The new drivers mentioned above already have this change in them.

XML configuration

For the future all Level II drivers will use a XML variable for configuration.  This is true for the drivers mentioned above and will be for all current drivers as well. The old variable model will still be there for backward compatibility.

Bluetooth mesh

I have used a lot of money to collect Bluetooth mesh capable hardware for some time. And this winter will be used for work with these. VSCP is very well suited for Bluetooth mesh. I can’t almost wait before I can start this work.  Excited!

OK that’s all for now folks.




#VSCP: New client id assignment

From version a new more deterministic way is used to generate automatic client id’s. VSCP daemon internal events will use id’s from the high part of the client id that will always be the same.

Client id’s for drivers and other configuration parts that before was generated from the order the item was loaded  also now work that way If the client id part of a GUID is zero (byte 12/13). If however it is not AND the client id is not already used in the system the VSCP daemon will use the set client id for the item.

This means that drivers with set GUID’s will always have the same interface GUID being more deterministic. tcp/op connections, websocket connections rest i/f connections will be assigned client id’s on the go as before.

It is recommended to use the Ethernet/IP GUID series as a basis for interfaces.

HowTo: SMS Alarms

The problem

Just last week a house burned down to the ground here in my hometown. The family of two adults and three kids just made it out. This reminded me of the importance of alarms. My family as any family I guess have had some incidents over the year. In our case with a four floor building, cellar, office, apartment where we live and the attic it can be hard to, despite alarm equipment, to recognize what is happening in the cellar when your are in the apartment watching a film or even worse, sleeping. We have had our incident over the years as most people do. I use VSCP here of course. This system is intelligent enough to close down functionality  when things get bad. But a few weeks ago I had a bad incident. I have a VSCP node that control the water boiler in the cellar for warm water. This is a very simple setup. A relay, a sensor and a control node. I can thus remotely control sense and control the temperature of the hot water in the house. Sitting in the office I noticed a strange sound. I usually play music loud so it had been going on for some time I guess. I went around the house investigating the sound and when I came down to the cellar I heard that the boiler literally boiled hard. Not a good thing. There is a risk for a steam explosion from this so I got really worried. I turned of the power. Opened valves for hot water in the office and got steam and boiling water coming out. I checked the control unit and it had turned of the relay. Still the temperature was way over the limit. There is an independent security unit inside the boiler that should turn off power when it get over a certain temperature. Apparently this mechanism had not done it’s job. Also the security valve that prevent to hot water from going out in the system also malfunctioned otherwise I should not have got steam hot water out of the office valve. Two faults. The pressure security mechanism on the other side worked. But the boiler never got up to the 10 bar needed to release it. So things were actually not to bad. Bit could gone worse if I had been away for example. I later checked the cause and detected that the relays had gone stuck in the on position.  Something that happen to relays some times when load is heavy or control is a bit jumpy.  I also tested the overheat protection and it worked as it should, probably it would have just needed a bit more time to cut the power. The blender protecting the water line from to hot water was the only faulty component. Still this was a bit scary. I need to be alarmed if this happen again.

GSM Modem

I previously sold professional GPRS modems in the FrogShop from Caimore. Still have some around so I decided to put one to work. You can find may similar on Aliexpress or ebay. and even lower cost modules intended for Arduino or similar as the one below. They all have there pros and cons.

SIM Card

Next thing is to find a SIM card. In Sweden this is not a simple thing if you just want a module that sends a few SMS’s per year. The solutions available are highly overpriced. I know there are other and better options available in other countries. I just select a cash card to get started.


Initially I thought about writing a driver for the VSCP daemon and this may still be an option, we will see. I have for a long time used Smstools a wonderful package for uses like this. With the help of the decision matrix of the VSCP daemon it will be possible to do plenty without a driver. So this is the solution I go for. There is a nice getting started tutorial for smstools here. Thus no need for me to write one again. The only thing i ned to do to get things working is to set the device and the baudrate lines in /etc/smsd.conf file
device = /dev/ttyUSB0
as I use an USB adapter for serial communication. And
baudrate = 115200
as i use that higher speed. Then I just restart the smsd daemon with
sudo service smsd restart
and everything is working.

Sending SMS’s

We are just interested in sending SMS’s here so we stick to that. But receiving SMS’s (we look at that in a later post) is also equally simple. To send a SMS one just copy a formated file into the folder /var/spool/smsd/outgoing. So to send an SMS to +467012345678 one send a file
To: 467012345678
ALARM: The water in the boiler is way to hot!
Write this to a file and copy it to /var/spool/smsd/outgoing and the SMS will be delivered to the set recipient. You can set the header to
To: 467012345678
Flash: yes

ALARM: The water in the boiler is way to hot!
to send a flash SMS (is displayed on the users screen directly but not saved). It can hardly be simpler.


Another possibility is to make a call to a receiver instead. Add Voicecall to the header like this
To: 46730533146
Voicecall: yes
TONE: 5 #,#,#
Here the mentioned precipitant will receive a call and when answered five groups of three “#” DTMF tons will be sounded. Tones that can be used to tell the recipient about the cause of the alarm. I will for instance use the number of “#” sounds as an indication of what floor the alarm happened. Possible with different tones for different alarms.

vscpd and smstools

So now lets put this to work for our VSCP based system. Alarm related events is collected in the class CLASS1.ALARM. The CLASS1.ALARM, Type=2, Alarm occurred is intended for alarm conditions.  So if we let sensors that generate alarms send this event and trigger on it in the decision matrix of the VSCP daemon we can send our SMS and voicecalls from there. The zone and subzone can be used as markers for where the alarm occurred. The originating GUID can also be used to identify this.
<row enable="true" groupid="alarm" >

	<comment>Send alarm.</comment>
	<mask priority="0" class="65535" type="65535" guid="00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00" >
	<filter priority="0" class="1" type="2" guid="00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00" > 
	<param >/home/vscp/ %zone %subzone event.guid %isodate %isotime "Current boiler temp is %vardecode:[boiler-temp]"</param>
	<allowed_from>0000-01-01 00:00:00</allowed_from>
	<allowed_to>9999-12-31 23:59:59</allowed_to>
	<allowed_time>*-*-* *:*:*</allowed_time>
So what do we have here? We trigger on any alarm occurred event regardless of priority and from which originating GUID (which unit) it comes from. It would have been possible to do several DM rows for different GUID’s (originating nodes) of course to handle alarms from them different. The time block (form <allowed from> to the end) just say that this can happen anytime. Leaving this block out has the same meaning. And last the important action.  In this case, execute external program (0x10) and in the parameter for the action the actual program to execute is specified with the path to it (/home/vscp/ is given. The rest of the action parameter line is arguments to this external program.
  • – Zone for alarm event.
  • %event.subzone – Subzone for alarm event.
  • %event.guid – GUID for alarm event.
  • %isodate – Date on ISO format for alarm.
  • %isotime – Time on ISO format for alarm.
  • %vardecode:[//alarmtext//] – Specific text for alarm.
The description of the decision matrix is here. Zone and subzone is numericals that can be used to specify the place and equipment that generated the alarm. I have floor plan in zone and a room on that floor plan in subzone. The vardecode writes out the content of the given variable if it is present. We will come back to it later. When this row is added the external script will be executed when CLASS1.ALARM, TYPE=2 is generated by a node and received by the VSCP daemon. It is good if the script can do both voice calls and SMS sends and that both can be sent to a list of numbers.

The script

import sys
import uuid

filename_voice = str(uuid.uuid4())
filename_sms = str(uuid.uuid4())

# Dir that holds outgoing SMS messages

# Voicel recipients (comma separated list, empty for non)

# Set to true for flash SMS
bflash = False

# SMS recipients (comma eparated list, empty for non )

SMS_TEXT="An alarm condition has occured!"

# -----------------------------------------------------------------------------

voicetone="5 "
for x in range(0, int( sys.argv[1] ) ):
	voicetone = voicetone + "1,"

voiceRcvList = VOICE_RECEIVERS.split(",")

	for receiver in voiceRcvList:
		print( OUTDIR + "/" + filename_voice + str(cnt) )
		with open( OUTDIR + "/" + filename_voice + str(cnt), "w") as text_file:
			text_file.write( "To: {0}\n".format(receiver) )
			text_file.write( "Voicecall: yes\n\n" )
			text_file.write( voicetone )
		cnt = cnt + 1

SMSRcvList = SMS_RECEIVERS.split(",")

if SMS_RECEIVERS != "" :
	for receiver in SMSRcvList:
		print( OUTDIR + "/" + filename_voice + str(cnt) )
		with open( OUTDIR + "/" + filename_voice + str(cnt), "w") as text_file:
			text_file.write( "To: {0}\n".format(receiver) )
			if bflash:
				text_file.write( "Flash: yes\n" )
			text_file.write( "\n\n" )
			text_file.write( SMS_TEXT+"\n" )
			text_file.write( "Zone={0} SubZone={1} Time={2} Date={3}\n".format(sys.argv[1],sys.argv[2],sys.argv[3],sys.argv[4] ) )
			text_file.write( "{0}".format(sys.argv[5]) )        
		cnt = cnt + 1
This is the script. It is written i Python to make things simple to edit and/or change. You can find the script in the VSCP repository. Just edit the variables in the beginning of the script to fit your setup and you are set to go. Note that the voice call will do five groups of a series of “1”-press DTMF where the count is the same as the supplied zone parameter. In my case this is the floor plan so I know instantly where something happened and runa way and fix it. The SMS also give me more info.

The variable

To come back to the variable that is sent as a parameter. Perfect is to save a  measurement value in another part of the DM. Like this
<row enable="true" groupid="temperature" >
    <mask priority="0" class="65535" type="65535" GUID="FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF" > </mask>
    <filter priority="0" class="10" type="6" GUID="FF:FF:FF:FF:FF:FF:FF:FF:3C:00:08:01:92:9D:3D:10" > </filter>
    <comment>Store boiler temperature in variable</comment>
    <allowed_from>0000-01-01 00:00:00</allowed_from>
    <allowed_to>9999-12-31 23:59:59</allowed_to>
    <allowed_time>*-*-* *:*:*</allowed_time>

An alternative way to do it

Another way is to do measurement compares, as in this case check the boiler temperature, you can read more about this method here and it is in many ways the same as the one we described above but more specific for boiler temp alarm.

And next?

Now you should be able to add your own alarms to your VSCP setup. Maybe something that will do good work in your remote cottage, alarming  freezing conditions before bad and costly things happens. In my house we will now sleep much better knowing that we will get alarms when things go wrong. I promised to continue with a follow up on how to react on incoming SMS mesages. This makes it possible to remotely control things as well such as turning on the heat in that remote cottage I mentioned above. I will try to write that story up soon. Time is my enemy, or rather lack of it. Cheers /Ake