The MQTT driver is next i line in the major rewrite of the VSCP software that is going on. Currently MQTT publishing works. As before the “simple” method is available so that one can publish the value for an event on a MQTT topic. But now it is also possible to publish VSCP events on string form, XML form and JSON form. The same functions will work for subscribing. It is therefore very easy to interface for example node-red and others. But for node-red more support functionality will come.
Also new in the next release is that Level II drivers use a totally new interface. You may now also (re)configure them on the fly if you need and enable that functionality.
But still some code to go through before the 12.0.0 release.
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
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.
Copperhill’s third-gen, $65 “PiCAN3” HAT features Raspberry Pi 4 support and a SocketCAN-ready CAN-Bus 2.0B port. The HAT has an RTC and is powered by a 3A, 6-20V Switch Mode Power Supply that can also power the Pi.