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 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.
From version 18.104.22.168 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.
The work with the upcoming 13.0.0 Aluminium release is moving on. As usual a few surprises has turned up adding some weeks to the work but things move forward as expected. Instead of being released before X-mas I now expect it to be out sometime late January next year.
For those of you doing home automation project I can recommend Domoticz and OpenHAB (in that order). Both projects has a huge and active user base constantly adding support for new devices. Much better choices for HA freaks than VSCP will ever be.
I also want to take the opportunity to wish all of you a merry X-mas. This year has been a quite rough time here and that will continue for some time but with the support from many of you I have managed to keep servers active and also had a chance to get some new hardware to play with as well. Thanks for your generosity. I will never forget.
There are a few days more coding for me before I turn of my computer and rest for a couple of days. A good book, some movies and a lot of food is waiting for me and honestly I need the rest. I hope all of you enjoy a few days rest also.
Be hungry, stay foolish
If you are a brave person please test the new deb packages for the VSCP server. More of them will follow. Please note that this is not release code. They are for test only.
There are three files for each binary
vscpd_12.29.2-20_amd64.deb for 64-bit base machines
vscpd_12.29.2-20_i386.deb for 32-bit based machines
vscpd_12.29.2-20_armhf.deb for Raspberry Pi and the like
you find the files here under 12.29… Use wget for example to get them.
Installation process is
sudo dpkg -i vscpd_12.29.2_20…….
On a machine without wxWidgets installed it will complain about that, can be other dependencies also that fail. To fix that issue
sudo apt-get install -f
which will download and install the dependencies.
Remove the installed package with
sudo dpkg -r vscpd
I will try to set up a package repository later. Expect problems. But it currently at least appears to works on the machines I have here.
All drivers now have a common format
Level II drivers are prefixed with
Also note that the default installation folder is changed to the driver folder (with sub folders level 1 and level2) of the installation tree under (default) /srv/vscp
Also note that ‘-‘ is used instead of ‘_’
Before updating to >= 12 remove drivers from /usr/local/lib
So finally we are getting closer to a #13, Aluminium. It’s been over a year now since the last release. A lot, and I mean a lot has gone into VSCP & Friends since then, actually to much to list it here. But it is a better software package now than before and it was pretty good at that time to if I may say it myself.
For users maybe the deb packages will be the most notable thing. There will be a Debian package for the vscp server, vscp works and for the helper lib. Also all of the drivers will have debian packages. But as drivers now are installed in the vscp folder structure (/srv/vscp/drivers/) they will be a bit special. This is a step against a web installable driver functionality I hope to have in place in the future.
Windows support for the VSCP server is now gone but it is possible to build and run it on a windows 10 machine in the bash mode. VSCP Works and the helper lib will be available as will the Level I (CANAL) drivers.If someone want to put down the work it should not be a big thing to get the VSCP server running on Windows either.
The last steps to work on before the release is here for those of you that are interested.
Last for you home automation freaks out there. Take a look at OpenHAB and Domoticz. One of them is probably what you are looking for, not VSCP & Friends, even if it to of course can be used for tasks like home control.
Time for a status report again.
My hope was to have a LTS release ready before the summer but I never reached that point. But things are what they are. There are mainly two reasons for the delay. First I don’t want to rush some big changes in the core structure that force me to do incompatible updates later with code needed for update paths. This mostly relate to the database. Next I want to move as much of the code as possible to MIT licensed which means I have to remove and rewrite some stuff. Hopefully something will be available soon after the summer.
The multicast channel support is now fully implemented. This means one can set up groups on the VSCP multichannel group that act as subnets using a specific port. AES128/AES192/AES256 encryption is available. The multicast announce is also fully in place now. Python and c/c++ samples available.
A new UDP interface has been implemented. Also here are AES128/AES192 and AES256 encryption available. Python and c/c++ samples available.
Support classes for encryption and frame packaging has been added to the vscphelper lib to make it easier to handle this new functionality.
pyvscp is a pip installable Python module that add VSCP functionality to Python. The main interfaces is in place but more will come and also more documentation. It’s very easy to interface the VSCP server and VSCP with this module. I personally love it.
The libvscphelper library is now packaged as a deb as the first component that will be available on this form. It is needed to be installed to use most of the functionality of pyvscp. VSCP Works and the vscp server till also be packed in their own deb’s for easy installation.
node.js bindings installable with npm is next and I know there is c# bindings brewing also. Probably have to dig into Java soon also if someone does not volunteer for that job.
A lot of other this to have hap-end of course.
Now I will go on a four-week leave. I am not used to that long vacations and right now I don’t actually know how to survive such a long time without coding. But I have promised my wife to try to to be honest I probably need it. I will check mail occasionally though but wil probably not answer mails on a daily basis.
So all friends out there. Have fun!