Something that may confuse new users of VSCP is the GUID of interfaces. Looking at the interface above the CAN4VSCP driver have GUID set to

FF:FF:FF:FF:FF:FF:FF:FE:B8:27:EB:0A:00:02:00:00

which means nodes connected to this interface will come in with GUID’s

FF:FF:FF:FF:FF:FF:FF:FE:B8:27:EB:0A:00:02:00:01
FF:FF:FF:FF:FF:FF:FF:FE:B8:27:EB:0A:00:02:00:02
FF:FF:FF:FF:FF:FF:FF:FE:B8:27:EB:0A:00:02:00:03
FF:FF:FF:FF:FF:FF:FF:FE:B8:27:EB:0A:00:02:00:04
....

If we look at the GUID’s if this machine we see that they all start with

FF:FF:FF:FF:FF:FF:FF:FE

As of  the spec we know that this is a GUID constructed from an Ethernet address. In this case only four of the six MAC digits is used. The

00:02

is the interface id as set by the VSCP daemon and the last two digits are the nickname id for a connected node.

The problem that can occur here is that the interface digits can be different at different runs of the VSCP daemon. The number is just set when the interface is set up and from time to time this setup can happen in different order. So sometime

00:02

can be

00:03

or even

00:11

One can’t tell beforehand.

This is a problem if one want to use the GUID to identify a node. Problematic as this is just what we want in most cases. To trigger on an event from a specific node in a decision matrix the GUID is the item to filter on. Just as in this case

Here we store a temperature measurement in a variable if it comes from a node with GUID

FF:FF:FF:FF:FF:FF:FF:FE:B8:27:EB:0A:00:02:00:01

and measurement index = 1

If the interface ordinal  becomes something else like

00:03

we are in trouble here as the action (store measurement value in variable) will not be triggered.

If we look at the current driver for this setup it is set to

 

<!-- The can4vscp driver -->
<driver enable="false" >
    <name>can4vscp</name>
    <config>/dev/ttyUSB1</config>
    <path>/srv/vscp/drivers/level1/vscpl1drv-can4vscp.so</path>
 <guid>00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00</guid>
    <flag>>0</flags>
</driver>

The “problem” is solved by changing the <guid> tag from an all zero value (or not defined) to a valid GUID.  If not defined or all zero the VSCP daemon will assign a GUID as of above. But if a valid GUID is set this value will always be used.

In my case I can use

01:00:00:00:00:00:00:00:00:00:00:00:01:02:00:00

as I have some assigned GUIDs.  The two LSB’s is still used for the nicknames.

After that change the “problem” is no more and I can filter on the new GUID instead which alway will be the same.