vscpworks is deprecated. But as it will still take some time before the ++ version is released some updates will be done to it to keep it usable by the community.
In the current release a Debian package is for example available for Debian/Ubuntu. A windows setup will also be available soon.
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
<driver enable="true"
name="driver-name"
path-driver="/usr/lib/x86_64-linux-gnu/vscpl2drv-driver-name1.so"
path-config="/var/lib/vscpl2drv-driver-name/drv.xml"
guid="FF:FF:FF:FF:FF:FF:FF:FC:88:99:AA:BB:CC:DD:EE:FF"
</driver>
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 vscpl2drv-automation1.so.1.1.1 but links will be created for vscpl2drv-automation1.so.1.1, vscpl2drv-automation1.so.1 and vscpl2drv-automation1.so 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.
VSCP is now part of the GitHub sponsor program. Under the first year GitHub will go in with the same amount as other go in for. So if you like VSCP this is a chance to show that you do that helping me to continue this project for another nineteen years.
At last, after a long time the PIR sensors and the door sensors start to deliver some VSCP events. This is something that should have been live this spring, but due to unforeseen events of life, it all has been delayed. But better late than never I guess.
This is nothing fancy of course but I will still describe the project here in detail later. For me it is important to get some real world data to work with. Using real world data always give more insight in how things should work than simulate things. Side-effects of this project is smart lights, lock control and some other things, for part of our house and my office.
Now some coffee, then it’s time to go on with other parts of this project.
VSCP is now part of the GitHub sponsor program. Under the first year GitHub will go in with the same amount as other go in for. So if you like VSCP this is a chance to show that you do that helping me to continue this project for another nineteen years.
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.
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.
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.
So
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.
Cheers
/Ake
Today it is 19 years since the VSCP project started. A long time. Many hours of work has gone into this project. But nineteen now. Time to grow up. This is the last year as a teenager. I think I have the path ready for this grow up phase. But more on that later. Today we celebrate.
Just a post to let you all know that VSCP is still alive even if not many things have happened for the last months.
As I wrote before I had some surgery in January this year and a follow up operation on that in June. Sadly I got a bad infection in the operation wound so I had to stay for some time at the hospital, but now I am home again eating tons of antibiotics.
Well things are pretty good now and I hope I am in working condition next month or so. But apparently one never know with deep infections, they often come back with full force. I, of course, hope it will not. 😉
I am sorry for all this talk about my health lately, everyone have enough with there own health and wellbeing, but this is my reality right know and I just want to indicate that VSCP is not dead. or even sick. It’s just me and I am in a good mode after all.
Have fun!
/Ake
It’s been many months. I have more or less been unable to do any serious VSCP development. All plans for the first half of 2019 just went out of the window. Even if that hurts, loosing such amounts of time, I had a second operation last week and the doctors says I am allowed to do some programming again from the end of the month. I look forward to that.
So hopefully “the state of VSCP” will be less about my scars and more about project progress after this summer. I have done quite a bit of the new VSCP works client during this slow time and hopefully some initial code will be available publically also very soon. JavaScript is still a little “strange” for me. But I like Electron and node.js more and more.
I hope everyone reading this will have a very nice summer. A Blackbird, named Pavarotti here on the hill, is singing for me and there is nothing in the world more beautiful than his song. Enjoy the summer my friends.