A new version of the package node-vscp (1.0.14) was published at 2020-02-11T15:19:43.097Z from 87.249.187.214. The shasum of this package was f5ac0f87bf0f7844d47abd274ac71c523d57ae1c.
Categories
Category: VSCP
Categories
node-vscp (1.0.13)
A new version of the package node-vscp (1.0.13) was published at 2020-02-11T14:37:12.767Z from 87.249.187.214. The shasum of this package was 62eb7d3e752576d8335dfd201b275a47524a55af.
Categories
node-vscp (1.0.12)
A new version of the package node-vscp (1.0.12) was published at 2020-02-11T13:53:10.719Z from 87.249.187.214. The shasum of this package was 8bd859405c9a27145158bf237800882f17f044ca.
Categories
#VSCP wiki
I have closed down the VSCP wiki because we have had unwanted visitors on it several times during the last year and it’s to hard to keep up with that junk. Will do a new try later when time permits.
/Ake
Categories
Fresh data for free
VSCP events are probably the most important part of VSCP. They make it possible for different type of hardware and different types of systems to talk to each other and they also makes it possible to write one application to solve many problems in one shot. A typical examples is a logger for measurement data or a presentation system for the same. They abstract things that happens in the world and they abstract how we can interact with the world.
Everyone that knows a bit about VSCP use the specification to search for events or to read more about them. But what everyone is not aware of is that they are also available here in a multiple of formats that are suited for a machines, always up to date. Just check the version.json file to see if the docs you have downloaded is the latest. Otherwise fetch the updated version.
In the docs folder you even find the full documentation for all VSCP events in markdown format. You can do your own documentation from it if you want.
And best of all. Maybe. Is that is all is free. Just as everything else is with VSCP & Friends.
And of course. If you are missing an event, tell us, and we will add it if it’s not there already.
The VSCP package header is a 16-bit code that give some information about a VSCP event. A change has been made to this header that is not binary backward compatible. Software relying on it must therefore be recompiled to be compatible with other software for the upcoming version 14.0 of VSCP & Friends.
The first change is that the dumb-node bit has been moved from bit 14 to bit 15. This bit is used to indicate that an event originate from a node that does not have a MDF, no registers, noting else than that it can send VSCP events and maybe receive VSCP events. Ignorant of any other rules. Applications that used the VSCP_HEADER16_DUMB define will handle this perfectly if recompiled.
The second change is the bit that tells that the GUID is an IPv6 address. This bit was previously in bit 15 but is now in bit 12. Furthermore a field of three bits (14/13/12) has been allocated for GUID types. Applications that want to be compatible with the upcoming 14.0 release must take care of this.
Two new GUID types are also introduced. RFC-4122 V1 and RFC-4122 V4. You can read more about the difference between them here. This make sit easier to take advantage of UUID generating tools like this one.
So the complete header is now defined as
/*
Bit 15 - This is a dumb node. No MDF, register, nothing.
Bit 14 - GUID type
Bit 13 - GUID type
Bit 12 - GUID type (GUID is IP v.6 address.)
Bit 8-11 = Reserved
Bit 765 = priority, Priority 0-7 where 0 is highest.
Bit 4 = hard coded, true for a hard coded device.
Bit 3 = Don't calculate CRC, false for CRC usage.
Just checked when CRC is used.
If set the CRC should be set to 0xAA55 for
the event to be accepted without a CRC check.
Bit 2 = Rolling index.
Bit 1 = Rolling index.
Bit 0 = Rolling index.
*/
New and old/changed defines are
#define VSCP_HEADER16_IPV6_GUID 0x1000 /* GUID is IPv6 address */ #define VSCP_HEADER16_DUMB 0x8000 /* This node is dumb */ /* Bits 14/13/12 for GUID type */ #define VSCP_HEADER16_GUID_TYPE_STANDARD 0x0000 /* VSCP standard GUID */ #define VSCP_HEADER16_GUID_TYPE_IPV6 0x1000 /* GUID is IPv6 address */ /* https://www.sohamkamani.com/blog/2016/10/05/uuid1-vs-uuid4/ */ #define VSCP_HEADER16_GUID_TYPE_RFC4122V1 0x2000 /* GUID is RFC 4122 Version 1 */ #define VSCP_HEADER16_GUID_TYPE_RFC4122V4 0x3000 /* GUID is RFC 4122 Version 4 */
Categories
New #VSCP documentation site
The VSCP project will move away from Gitbook (with all it’s problem and slow/no support) in favor of Docsify deployed on one of our own servers. This will make it easier to add versioned documentation, among many other things.
At the moment only the VSCP spec. is available but other documentation will follow.
The VSCP documentation site is located at http://docs.vscp.org
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.
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.