Category Archives: VSCP

#VSCP New Multicast and UDP interfaces

From version 1.12.26 the muticast channel interface is available. Also a new UDP interface is available.

With the multicast channel interface one can set up groups of Level II nodes that share a common channel for events. Much like a bus like CAN. Frames can be encrypted using AES128, AES192 or AES256.

With the new UDP interface one can set up a receiving interface and several sending interfaces which send UDP datagrams to remote nodes. Frames can be encrypted using AES128, AES192 or AES256.

The settings for the multicast channel interface is here http://www.vscp.org/docs/vscpd/doku.php?id=configuring_the_vscp_daemon#multicast_channel_interface

The settings for the UDP interface is here http://www.vscp.org/docs/vscpd/doku.php?id=configuring_the_vscp_daemon#udp_interface

The encryption key are under the <security> tag.

Some sample code can be found in the source tree under test/multicast and tests/udp. Not more documentation at the moment I am afraid but I work on that.

Well there are probably some bugs left…

Cheers
/Ake

State of things | #VSCP

I know when I have lost. The chance that VSCP will be adopted by the many is pretty small. One could be sad about that. It is so much work. So many hours. But if you want to be a success you need money and even more, devoted people around you that preferably are better than yourself.

So, bad days, and this is one of them, you think about giving it all up. Why bother?

Still, there is something in that vision of small systems talking to each other,  working together, that is hard to not make come true. Just out of curiosity, Is it possible to do this?

But on the other hand. Soon seventeen years of development.  It is crazy to walk this road.

Well I do any way. The development continue.

I have decided to skip built-in  MQTT support in the VSCP server. The Level II driver will give this support and will be extended with new functionality instead.

I am implementing new UDP functionality at the moment. This is an extended version of what was available before. One can set up a UDP port on the server that can receive UDP VSCP frames. Ack is available and the frames can be unencrypted or encrypted using AES128/AES192/AES256. The VSCP server can also connect to other nodes using UDP and send a filtered output stream to them.

I also work on the Multicast functionality as this is close to the UDP functionality. The same encryption options is available here but the multicast channels work a bit different to UDP in that one can set up as many multicast channels one like, have filters in them for both send and receive, and of course encrypted frames.  This is perfect for low-end autonomous systems.

I hope to have this is done and fully working this week.

The multicast announce channel by the way is already in place and has been for quite a while. I will document this to. Basically this channel is where a higher end device can listen to discover new nodes in a system. Likewise should level II nodes post their info here as well as heart beats.  The VSCP daemon will collect this info, a work that is up next, and make it available through its high end interfaces.

That’s it for now.  Keep your eyes open for documentation of the new features.

Cheers
/Ake

Effect of #VSCP package change

For those of you running head code of the VSCP & Friends package

Remember to build the full VSCP & Friends package after checking it out from git and then compile all files and do a “make install” as root. If you don’t do this drivers and the VSCP server (the daemon) may use different package formats which will   corrupt memory and probably make the VSCP server and the rest of the code unstable.

/Ake

IMPORTANT! #VSCP configuration change

From version 1.12.24.0 Magnesium the configuration file format has changed. A lot of things have moved out from the <general> section up to the top-level.  Refer to the distribution vscpd.conf for full info.

Configuration file reading order has changed as well. Now things work as the following

  1. Read the <general> tag information from the XML configuration.
  2. Read configuration from the database.
  3. Read the full XML configuration.

This change makes it easier to have a safe setting in the XML configuration file that can’t be overwritten by changes in the database. The importance of this will be more clear when settings can be changed in the administrative web interface.

REMEMBER TO DELETE DATABASE FILES AFTER A NEW BUILD.

Cheers
/Ake Hedman

ps There is a lot of bumblebees here on the VSCP hill right now, more than ever before. Must be a sign… 😉 ds

Is #VSCP dead? #IoT

Did it even got born?   Well don’t ask the European Commission. They have never heard of VSCP.

The list in the picture can also be thought of as “better alternatives” to strange things like VSCP.

But…

development continues also for a ‘non leading’ IoT platform that did IoT before anyone was talking about IoT. We will never die. Well, that was maybe an exaggeration, we will not die right now at least.  But we will also change the world before we do that.

Written with a smile not a frown.

State of #VSCP May 2017

Well, it’s time for a new status update for the VSCP project.

I am still working with the tables interface on the VSCP daemon.  This has taken far more time then I ever expected it to take.  But I want to have it in place and will eventually. One of the reasons for it to take such a long time to implement is that I clean up code and document parts of the system at the same time.  Another reason is that I have some surgery for a bad shoulder last week and that also has slowed things down. Anyway. things move forward, be patient.

The helper lib

I discovered a bad thing I did not think of last week when I worked with the VSCP helper library.  A year ago or so I changed the communication motor from my own work to Mongoose mostly to quickly get SSL working. This was of course a big mistake. I want this code and the resulting library to be free to put in any project, also in commercial project where the source needs to be protected. Mongoose is released under GPL v2 so by using it in this case users of the helper library and helper/interface classes has to share their code.  This is no problem under the development stage of a project. But it is a problem for released works.  I will prioritize this change. Mongoose will be removed from this part.  The problem is not the same for the VSCP daemon and other tools in the package which can live with GPL’d code. Here Mongoose will still be used.

VSCP Classes

An easy way to build clients for the VSCP daemon is to use the some classes available in the VSCP &Friends package.  A sample project and some examples for this is now available here.  As always the other way to make clients for communication with the daemon is to use the VSCP helper library.  A C# library is on the way for this and hopefully we will see more bindings also in the near future.

OK – That was all for now.

Cheers & Have fun!
/Ake

ps My mascot, the frog, was destroyed when the roof fell in here last night, I hope that is not a bad omen…  😉 ds

python-can #VSCP #m2m #IoT #CAN

In a support question today I got to know the python-can package which I was not aware of. This is a package for Python developers python-can wanting to work with CAN. The package supports CANAL but unfortunately the CANAL interface is named “USB2CAN“, which disappoints me a bit,  but at least it’s there.

So all drivers here should work with Python now.

Interesting for VSCP‘ers can the remote interface of the package be. Here you can set up a lightweight connection to a CAN4VSCP bus (CAN bus) and feed it over TCP/IP to a VSCP daemon or some other thing. Perfect for use on small Linux boards where the full  VSCP daemon is too much.

Important change to the vscpEvent/vscpEventEx structures and timestamp #VSCP

New fields in vscp event structures (vscp.h)

From version 1.12.20.0 a date/time block of the following form

        // Time block - Always UTC time
        uint16_t year; 
        uint8_t month;    // 1-12
        uint8_t day;      // 1-31
        uint8_t hour;     // 0-23
        uint8_t minute;   // 0-59
        uint8_t second;   // 0-59

has been added to the vscpEvent/vscpEventEx structures

This will affect all interfaces that read and write VSCP events. So for the TCP/IP interface which previously used

send head,class,type,obid,time-stamp,GUID,data1,data2,data3....

will now have the form

send head,class,type,obid,datetime,time-stamp,GUID,data1,data2,data3....

where datetime is the UTC date/time in ISO standard form YYYY-MM-DDTHH:MM:SS

It is possible to let the interface set this time to the current UTC time by leaving the item blank.

So

send 0,20,3,0,,,-,0,1,35

will set the current UTC time (and timestamp) in the interface when the event is received.

But on the other hand

send 0,20,3,0,"2001-11_02T17:00:01",,-,0,1,35

will use a specific date and time. Note that timestamp is set by the interface in this case.

The change affect a lot of code. Expect some instability. The helper lib has been changed appropriately so if using it your code should be safe.

timestamp

It’s a bit of  confusion before if timestamp has been set in microseconds or milliseconds.  Now this is definitely fixed at microseconds.  An unsigned long is enough to keep track of about 71 minutes before it roll over. This was considered a bit low before the date/time structure was introduced but is more than enough now.

When timestamp previously was sent with a value of zero it was set to UTC microseconds of the interface. This is not the case anymore.  Leave the field blank instead if you want the interface to set the timestamp.

Resend to the VSCP mailing list

I have previously resent blog entries here to the mailing list when I though they could be of interest for the mailing list audience.  This will be the last one resent this way. If you are interested in blog posts about VSCP subscribe to this blog. An RSS reader is another option.