For me its always been a bit strange to dub MQTT as an IoT protocol.  Well noways it’s even a standard. Strange to. It just does not solve the ‘problem’ as VSCP (Very Simple Control Protocol) for instance (and others) do. But nevertheless, as a general transport protocol, it is VERY useful. There is tons of code out there making it even more interesting to use. Very useful. Love it.

I know. It is tempting to send “ON” and “OFF” or “23.789”  on a topic to a MQTT broker. Simple and easy to understand and handle. The one problem is that others solving problems like the one you solve will send  “AUF” and “AUS” and “74.8202” meaning the exact same thing. It is hard to write stuff that can be reused and even work with stuff from different vendors with that approach.

It’s better to standardize what is what and stick to that standard. In that case an “ON” from one vendor of a device is understood by another vendor with a different device. Same for measurements. There are just a few SI units. But many units derive from them. If standardized a temperature in degrees Celsius is equally understandable on the receiving side as a temperature in degrees Fahrenheit (or even Kelvin).

VSCP defined events and other solutions for this twenty years ago. Not many people use VSCP today and have ever been using it for that matter (or will use it) and hopefully one of the big companies make a similar solution – calling it a new invention and revolutionizing – so we get an adoption of a system that help us write thing once and use it many, many times. Move things forward instead of we doing the same thing over again and again. I will be the firsts to applause such a thing when it happens. Because it will. One day.

I will not go further into VSCP and what it is and what it can do here. You are probably not interested (if you are look here ) anyway. That is OK. But I will show how VSCP events are transferred over MQTT. Or rather, I will show one way to transfer VSCP events over MQTT (guess which one is the IoT protocol and which one that is the transport protocol).

VSCP events are more or less the same as messages.  But “event” better describe the asynchronicity of events,  a button is pressed – an event is sent. VSCP events have a source, a class, a type and some data. The source tells who sent it. The class what class of events (measurement/information/data…) it is. The type is more specific of the event type. Data holds the actual info of the event.

Depending on the medium that carry the event a VSCP event is packed in different formats. Ethernet and CAN, for example, use a binary format for efficiency. Higher level protocols like MQTT does not (normally) need this efficiency. So here a VSCP event is packed as either a XML or JSON formatted message.

We are just interested in JSON format here but you have both described in the VSCP specification.

A VSCP event looks like this in JSON format

   "note":"Some optional note about event",

There are some extra fields we did not explain above and you have to read the VSCP specification to get info about them. But you recognize vscpGuid which is the ‘source’, this is the id/address for the device that sent the event. vscpClass is the class, vscpType is the type. VscpData is the actual data. This data is always in bytes but very well specified in both format and such things as byte order. Usually on a higher level you can handle this data with higher level functions and don’t need to care about the actual format it have.

So when a VSCP event is sent over MQTT this is what is sent.

For “ON” this will look like


This is the  VSCP ON event.

Similar for a VSCP OFF event which looks like


or for a temperature measurement


In this case a temperature in degrees Celsius, coded as a 32-bit floating point value.

It is now possible to send VSCP events on any MQTT topic. But it is good to follow a specific scenario for the topics as well. Suggested for VSCP events is


prefix‘ can be ‘vscp‘ or ‘/aaa/bb/cc/tt/yy‘ or something else.

Using this schema we can subscribe to the MQTT topic


to see every event that is received from our setup.

If we just want all events from a specific remote node we can subscribe to


or if we want all all temperature events from a specific node


or temperature events from all VSCP nodes in the setup


It’s just as simple as that.

Don’t just send magic numbers or “ON” or “OFF” anymore. Please!

Arduino ESP8266 HowTo's VSCP wifi

Howto: Snailmail sensor

Mail delivery. That is the physical type. That land in a box. Outside. There is one problem with it. You don’t know when or if you get any. So quite often, especially when there is a blizzard, one walk out to the postbox to find that it is empty. And if you have mail almost every day like me one wounder. “Are they late or is there no post for me today?” This usually ends up in me taking another trip to the postbox later when the blizzard is even worse.

A flag – the American style – would be possible. Needing binoculars. The later a habit that also might disturb my neighbors. But now, after all I work with computer. Something more firmware + electronics is my way. A perfect topic for a VSCP howto.

So the problem is simple: I need a notification when mail arrives in my mailbox. It also need to be a VSCP based solution. After all, I came up with the damn protocol.

So I set out to do this.

I like to lean new things. I therefore decided to use Platformio and the esp8266 with the Arduino core for this project. En environment I have not been playing with before. For both there are plenty of “getting started” write-ups available on the net.

This was a design that needed a battery. I have previously noticed the deep sleep capabilities of the ESP8266 so it should work. The device should take only ~20uA when sleeping and about 70mA when doing it’s work. In this app, we talk about a device that just need to wake up for a short moment once (when mail arrives) or twice a day (when I collect the mail).

You have the different sleep modes for the ESP8266 in the table below.

For deep sleep RST and CH_PD on the ESP8266 should be connected together. RST needs a pull-up. Now when set to deep sleep a low pulse on RST will wake the device.

So I came up with this schematic

Nothing strange here. Notice that I added a 1-wire temperature sensor also to get the temperature reported also when the lid is opened. Eagle file are here.

There is suggestions around to use a one shoot at the input. I tested without and it looks like things work as expected so I skipped it. An input switch will bounce so the startup of the unit will probably be a bot chaotic. This will take more juice form the battery and I will change this later on if I find it to be a problem.

I also replaced the reed switch with a mechanical switch on the mailbox. I will probably change that back later on but it was a little harder to get the reed switch approach to fit mechanically and I did not have the time to fix it the way I wanted to when I mounted the hardware.

I never reached 20uA in deep sleep. Rather 200 uA but that is OK for this test (theoretically 260 days or ~8 months on two AAA cells). I will investigate this further when I get more time. But apart from that everything works as expected.

For the firmware you can find it here. It is written so it can be used both with VSCP and MQTT (JSON VSCP events is sent). There are switches at the top of the file to select the version to build. With large EEPROM both can be used simultaneously.

I wrote a general library for VSCP and Arduino with the thought that it can be useful for somebody. Full info is here.

The sample code connects to wifi, then it connects to a VSCP remote host or a MQTT broker. Then it sends five events and then go to deep sleep again. The events that is sent are

The two versions of temperature events should be considered as a demo of level I and level II events.

So time to test. Put everything in a box and mount it in the postbox. Our postbox is located a bit from my house

I have a directional wifi antenna in that direction for some stuff in our garage so wifi is OK (-85 dBm) at the location.

I mounted everything a bit after midnight last night.

And now this morning

VSCP Works tells that something has happened at 05:14:44

And yes there is a small package in the mail. Demo accomplished. Might even be useful when connected to node-red so I can get a notification on my phone using Telegram. There may be a short write-up about that also later.

This same setup can of course be used for PIR sensors, window sensors and similar. One can even change the data sent from VSCP to some format. It’s a free world.



Please support our sponsors

Supporting the VSCP project right now is probably more important than ever. This is the only financing we have to keep servers running and make it possible to buy hardware to do even more releases and provide demos. Currently Github boost community funding so any sponsoring amount actually doubles on our side.

We are VERY grateful to our current sponsors. Please support them.


New version of #Arduino VscpTcpClient available

A new version of the package VscpTcpClient (1.1) was published at 2020-09-01 13:53:17

  • The sendEventRemote method was broken. Fixed.
  • Response check is now returning VSCP_ERROR_TIMOUT instead of VSCP_ERROR_ERROR when a command fails with a timeout.

node-js node-red VSCP

New version of node-red-contrib-vscp-tcp

A new version of the package node-red-contrib-vscp-tcp (1.2.2) was published at 2020-08-31T09:20:38.185Z

Fixes problem with transmit of events to VSCP host.


#VSCP turns 20

birthday wallpaper
Photo by Ylanite Koppens on

Today VSCP turns 20. Not a teenager anymore. So many hours. A game of fools. There will be no party. stop.


Initial release of VscpTcpClient library for #Arduino #esp8266 #esp32 #platformio

The initial release (1.0.0) of the VscpTcpClient library is now available. The VscpTcpClient library can be used to communicate with a VSCP remote host in an easy and intuitive way. The library supports all Arduino Ethernet Client compatible hardware (atmelavr,espressif8266,espressif32).

Repository is here:

Documentation is here:


Don’t Use Arduino (For Professional Work) — Embedded

Arduino is an excellent prototyping platform. It is wonderful for its ease of use and speed with which to get started. I’m happy to say lots of good, heartfelt things about the whole Arduino ecosystem. But don’t ask me to use it in products.

Source: Don’t Use Arduino (For Professional Work) — Embedded


Not easy

It’s not an easy job to take on the job as a sensor in our house.


Power #Raspberry Pi Zero (W) from a #CAN4VSCP module. #VSCP #iot #m2m

In remote automation setups it can be very inconvenient to use a Raspberry Pi because of the need for a USB power supply. In a current setup of mine I have a bunch of CAN4VSCP boards and want to link them from a remote location to my central system. The Raspberry Pi Zero (W) is low cost, easy to work with and could serve as a good way to accomplish this.

In the official docs the recommendation for powering a Raspberry Pi Zero is 5V at 1.2 A power adapter. This is at first very disappointing for my project as a CAN4VSCP board only can deliver a maximum of one amp from +5V and the board itself takes about 100 mA of this.

But looking further reveals that the needed power is much less that the official requirements if just using WiFi and BT. 120mA is mentioned. Testing this I can verify this value but with some peaks up to 300 mA. Powering a Raspberry Pi Zero W from a CAN4VSCP board would therefore be possible.

I test this with a Vilnius A/D module that is feed with 24V from the CAN4VSCP bus and I experience no problems. The Vilnius A/D module have GND on pin 1 and +5V on pin 12 of the termination block and this can be a good place to get the power for the Raspberry Pi Zero. All 5V CAN4VSCP modules have +5V and GND somewhere on the termination block. Another possible location to get the power from is using the programming header, which also is available on all CAN4VSCP modules. This connector have +5V on pin 2 and GND on pin 3.

To reduce the power need I turn of HDMI on the board as discussed here and here. One can also turn of the LED’s to reduce power consumption even more. There is actually no need for this in my case.

To turnoff HDMI on startup add

@reboot /usr/bin/tvservice -o

to the root crontab job using

sudo crontab -e

This will turn of HDMI on startup. To put the same in /etc/rc.local is another option.

I will use a 3.3V TTL Frankfurt RS-232 module to connect to the CAN bus directly from the Raspberry Pi. Allowing a connection directly from the RX/TX GPIO pins. But more on this later in a separate howto.

I will try to use node-red together with the node-red-contrib-socketcan to connect this module with the main system. I can then choose to connect over MQTT or VSCP tcp/ip, websocket or whatever. It is mostly plug and play to set this up. I will do a separate howto about it to later. My concerns is that there may be a risk that this will be to slow for my needs and in that case I will do a separated link between socketcan and MQTT coded in C. But I will use node-red anyhow so it is still needed.

Installing node-red on a Raspberry Pi system (any Debian derived system) is very easy. Use the script at which looks like this

bash <(curl -sL

and after that everything is installed issue

sudo systemctl enable nodered


suso systemctl start nodered

to install node-red as an auto staring service.

Thats it.