CBOR — Concise Binary Object Representation | Overview

Source: CBOR — Concise Binary Object Representation | Overview

Development General

How Safe is AES Encryption?

In the world of embedded and computer security, one of the often debated topics is whether a 128-bit symmetric key, used for AES (Advanced Encryption Standard) is computationally secure against brute-force attacks.

Source: How Safe is AES Encryption?

Development VSCP

#VSCP project autogenerated files with units

Units for all measurements and conversion between them is now included in the autogenerated databases and in autogenerated JSON and XML files. Also ASCII and UTF8 symbols are included for each measurement unit.

The unit definitions and formats relay on the mustche format with JavaScript (pseudo) code for the conversion. Simple tools can be used in a project handle this. For this the default unit always is defined as


That is the value (which is a floating point value) is always substituted on it’s own by mustache. For the other unit’s for a specific measurement there are mathematical expressions added to convert that unit to the default unit. With this schema all units can be converted to every other defined unit by first converting it to the default unit.

As an example, for temperature measurements this looks like this

  • unit = 0 (default) is Kelvin: {{val}}
  • unit = 1 is Celsius: {{val}} + 273.15
  • unit = 2 is Fahrenheit: ({{val}} – 273.15) * 1.8 + 32.0
  • unit = 3 is undefined.

A helper for event display is <b>render</b> which for the moment is only defined for vscpworks but can have formats defined for other presenter software as well. The definitions for measurement renderings as an example looks like this today

    <vscpworks template=" 
       {{lbl-start}}Unit: {{lbl-end}} = {{unitstr}} [{{unit}}]{{newline}} 
       {{lbl-start}}Sensorindex: {{lbl-end}} = {{sensorindex}}{{newline}} 
       {{lbl-start}}Value: {{lbl-end}} = {{val}}{{symbol}}{{newline}} " /> 

Mustache is also used here for variable substitution. More info is here.

You find the auto generated files here

Development VSCP

#VSCP Helper library 14.0.1 released

Full info and source and binary downloads can be found here

Development General VSCP

Change of #VSCP package header definition

The VSCP package header is a 16-bit code that give some information about a VSCP event. A change has been made to this header that is not binary backward compatible. Software relying on it must therefore be recompiled to be compatible with other software for the upcoming version 14.0 of VSCP & Friends.

The first change is that the dumb-node bit has been moved from bit 14 to bit 15. This bit is used to indicate that an event originate from a node that does not have a MDF, no registers, noting else than that it can send VSCP events and maybe receive VSCP events. Ignorant of any other rules. Applications that used the VSCP_HEADER16_DUMB define will handle this perfectly if recompiled.

The second change is the bit that tells that the GUID is an IPv6 address. This bit was previously in bit 15 but is now in bit 12. Furthermore a field of three bits (14/13/12) has been allocated for GUID types. Applications that want to be compatible with the upcoming 14.0 release must take care of this.

Two new GUID types are also introduced. RFC-4122 V1 and RFC-4122 V4. You can read more about the difference between them here. This make sit easier to take advantage of UUID generating tools like this one.

So the complete header is now defined as

            Bit 15 - This is a dumb node. No MDF, register, nothing.
            Bit 14 - GUID type 
            Bit 13 - GUID type
            Bit 12 - GUID type (GUID is IP v.6 address.)
            Bit 8-11 = Reserved
            Bit 765 =  priority, Priority 0-7 where 0 is highest.
            Bit 4 = hard coded, true for a hard coded device.
            Bit 3 = Don't calculate CRC, false for CRC usage.
                  Just checked when CRC is used.
                  If set the CRC should be set to 0xAA55 for
                  the event to be accepted without a CRC check.
            Bit 2 = Rolling index.
            Bit 1 = Rolling index.
            Bit 0 = Rolling index.

New and old/changed defines are

#define VSCP_HEADER16_IPV6_GUID 0x1000 /* GUID is IPv6 address */
#define VSCP_HEADER16_DUMB 0x8000      /* This node is dumb */

/* Bits 14/13/12 for GUID type */
#define VSCP_HEADER16_GUID_TYPE_STANDARD  0x0000 /* VSCP standard GUID */
#define VSCP_HEADER16_GUID_TYPE_IPV6  0x1000     /* GUID is IPv6 address */
/* */
#define VSCP_HEADER16_GUID_TYPE_RFC4122V1  0x2000 /* GUID is RFC 4122 Version 1 */
#define VSCP_HEADER16_GUID_TYPE_RFC4122V4  0x3000 /* GUID is RFC 4122 Version 4 */

Development General VSCP

New #VSCP documentation site

The VSCP project will move away from Gitbook (with all it’s problem and slow/no support) in favor of Docsify deployed on one of our own servers. This will make it easier to add versioned documentation, among many other things.

At the moment only the VSCP spec. is available but other documentation will follow.

The VSCP documentation site is located at

Development General VSCP

New #VSCP Level II driver interface

The driver interface for Level II drivers will change for the upcoming 14.0.0 release. In previous versions the message passing has been done through the tcp/ip interface. This is no longer used (will still be used by Level III drivers).

The interface a driver maker has to implement is very simple and looks like this

// Open connection
long VSCPOpen( const char *pPathConfig, const unsigned char*pguid );

// Close connection
int VSCPClose( long handle );

// Write event
int VSCPWrite( long handle, const vscpEvent *pEvent, long timeout );

// Read event
int VSCPRead( long handle, vscpEvent *pEvent, unsigned long timeout );

// Get driver version MSB = major, LSB = build with minor/release in between
unsigned long VSCPGetVersion(  void );

// Get vendor string describing driver maker
const char *VSCPGetVendorString( void );

I think it is pretty selfexplanatory.

All Level II driver now must have a unique GUID assign to them. Configuration is

&lt;driver enable="true"     

Worth to note here is that driver now by default will be installed to /usr/lib/x86_64-linux-gnu/ and /usr/lib/x86_32-linux-gnu/ so one can have 32-bit and 64-bit drivers installed on a system at the same time. We by this adopt to Debian roles used in deb packages.

Also driver names will end with the major version. So a a level II driver “automation” will be vscpl2drv-automation1. Also, drivers will comply to the Linux library installation schema used on Linux so they will be installed with the full version for example but links will be created for, and so drivers can be addressed as before.

If you make driver please use this schema. In the same way use vscpl1drv- as prefix for level I driver.

name is a system unique name for the driver.

path-driver gives the path to the driver as expected.

path-config is a path to a configuration file for a driver. Normally this file should be in xml format. The location for the configuration file can be anywhere but recommended is /var/lib/vscpl2drv-driver-name/ for a driver that can be configured on the fly and /etc/vscp for a driver that are static. The later being the safest place.

guid is a system unique GUID for the driver. This GUID must be set and it must be valid.

New for level II drivers is that they will be able to be configured on the fly and be interacted with through the web interface, websockets and tcp/ip interface. One can therefore easily set up configuration pages etc. More on that later.

For a sample of the new futures and a base for your own projects check the vscpl2drv-automation driver. This driver implements the automation functionality that was previously integrated into the VSCP daemon. Tables, DM, remote variables, udp, multicast are other functionality that is moved out to drivers with the upcoming 14.0.0 version.

A lot of new functionality is demonstrated in the vscpl2drv-automation. Save and load for example that save/load the current configuration. Also all parameters are possible to edit/change when the driver is loaded and alive in a system.

Some parameters may still be changed so look at tis as somewhat preliminary information.

Development VSCP

C# expert needed

We need someone with C# knowledge to take over the vscp-helper-charp project which Bas Bongenaar. The design goal is to make the VSCP helper lib functionality easy to use for C# developers.

Development 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.

Development VSCP

#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.