Where is #VSCP heading? #Iot #m2m

 

vscp_new_v2

Where is VSCP heading? I have asked that question  to myself  from  time to time over the years. I can assure  you that this has happened many times  over the fifteen years VSCP has been around.  But the result is always the same. The only thing that changes is that technology moves forward and  VSCP moves forward with it.

The central points are

  • VSCP should work on low cost, low end hardware.
  • VSCP should function without a central server.
  • VSCP nodes should contain information on how they work and how they should be configured.
  • VSCP should work the same on different network topologies.

So today we have a server, a client, helper libs, a web socket interface and a lot of people building CAN based nodes for VSCP. For many people, VSCP == CAN, but for me this has always just been the starting point. A point I should have moved beyond now after so many years  but for a one man operation without money and resources things takes time. This is why it is so important to support this project by buying things from the FrogShop. The only source for income I have.

On the software side the main project at the moment is to build a web interface for configuration, control of nodes and visualization of data.  This is work in progress and if you are interested in taking part in this work please let me know.

On the hardware side I can only talk about what my company the Paradise of the Frog / Grodans Paradis AB  will do. Others may do other things and move in other directions.

The first hardware constructed and which we work on at the moment is the CAN4VSCP series. This is a wired series of nodes based on CAN. The can bus is secure and reliable and is a perfect match for VSCP as it easily work without a server. The nodes are low cost built to be mounted on a DIN rail.

VSCP_CAN4VSCP_node

Paradise of the Frog currently sell seven CAN4VSCP based nodes and some more are in the pipeline. Functionality range from temperature measurements, relay control, counters etc that can be put together to form autonomous groups of functionality or network controlled clusters.

Of the wired network modules some Ethernet based modules are in the working. The first dubbed Zeus.

vscp_Ethernet_nodes

We have this running in the lab at the moment and it’s only a financial matter to get them out on production.

Ethernet nodes can be powered over the bus or locally and in all other ways behaves like CAN4VSCP nodes. The main difference is that they use VSCP level II events and that VSCP multicast is used for communication with the world, other modules and a possible server.

Planed are also a series of RS-485 nodes.

vscp_RS-485_nodes

but this is low priority development mostly for reference. RS-485 nodes requires a VSCP daemon to work as they are not autonomous in functionality as the CAN4VSCP nodes. In most cases CAN4VSCP is superior to RS-485.

For the wireless part we currently work with is wifi based nodes.

vscp_Wifi_nodes

This is nodes that uses a current wifi infrastructure. VSCP communication is tcp/ip and VSCP multicast. A VSCP wifi nodes works the same way as a VSCP Ethernet node. On the downside the wifi nodes are designed to be powered. So this is not a technique for battery operated devices.

Bumblebeez on the other hand is designed for battery powered wireless VSCP setups. Keywords are secure, low cost, reliable, mesh.

VSCP_Bumblebeez_nodes

we will provide more information about this exciting technology this fall.

We also work on 433/868MHz things but mostly to interface existing things like the Nexa/Proove etc stuff.

Autonomous groups

CAN4VSCP forms autonomous groups when modules are coupled together.  It is very easy (and low cost) to construct systems for different control scenarios. Different groups can be connected with the upcoming Frankfurt gprs module.

VSCP_gprs_group

This means that some grouped functionality can be configured/controlled over SMS/Email and that a remote segment can be connected to a central service over gprs. All plug and play of course.

Another option is to use a wifi gateway to connect a CAN4VSCP segment group to a wifi infrastructure.

VSCP_wifi_group

or using Ethernet/tcp/ip

VSCP_ethernet_group

to connect a segment group to a server or to another group.

CAN4VSCP autonomous device groups are made to do there work hidden on DIN rails in control boxes and the like. For security reasons it can be good not to connect them to the world if they control sensitive systems.  To configure them one usually hook up to the CAN4VSCP bus and configure them there but an alternative is to use Bluetooth for the task

VSCP_ble_group

The module for this is called Frankfurt BLE and with this module it is easy to temporally connect to a CAN4VSCP group of nodes and configure them in a safe way using a phone/tablet or stationary.  One can also use this module to connect groups together or connect groups to a central server.  This make it easy to configure and diagnose things hidden away in a box without opening it.

Wires versus wireless

Some say IoT == wireless but that is just a foolish assumption. I have about twenty units on battery here in my house today. It’s a pain to change battery on them all. A real PAIN. If I had hundreds of them well it would not work. NO it would not.

Energy harvesting promises to solve this issue. But it does not deliver yet. Maybe in the future. I hope so.

So we will have devices for some time with wires and we will have devices without wires. VSCP is there and works for both.

Discovery

Node discovery is important.  This is true for all m2m/IoT products and especially for VSCP as there must be a way to fetch the MDF and thereby get information about the module and how to configure it.

For system that understand VSCP from the beginning the node heartbeat is the key tool for this. Listen for it and within a minute all nodes will be known and the MDF can be fetched from them.

For a higher end device this may not be as easy. It should not know anything about VSCP.  If it did RFID/NFC could be used to pick up mdf information.  But Google have Eddystone which can be used for this purpose and VSCP will support this technique for higher end devices.

VSCP Configuration

Security

We will work hard to provide top edge security for the solutions we work on. For CAN4VSCP/RS-485 there will never be any crypto protection. If you don’t want to be listened on or tampered with protect the cables or use some other more secure technique instead. Standard cable tampering protection have worked well for alarm systems for decades and work for other cable bases systems as well.

Use ssl for wifi/tcp/ip.  Use the provided encryption for other systems we provide.  Every setup has it’s own security concerns. We provide the tools to build secure systems.

So the work on VSCP continues. The idea for this system came in the beginning of 1980 and was first realized in the fall of 2000, the new millennium. So in a a couple of weeks we have been around for fifteen years, Dubbed the IoT protocol/framework that came about before IoT. I am proud of that and I am proud of what has been accomplished up to this point. But a lot is still left to do. I have set a side the next fifteen years for that work.

Ake Hedman
Maintainer of VSCP

IoT, M2M and VSCP talk from Grodans Paradis AB

%d bloggers like this: