GUID’s
A GUID is the one and only id for all VSCP devices, It is globally unique, 16-byte, and will never change. It can be derived from some common id’s like MAC addresses or come from a user/company assigned “namespace” which can be requested for free.
At the application level this is the id “that should” be used if one want to have an id that absolutely does not change over the life of a device.
The problem with 16-byte id’s is obvious and specially clear on CAN devices. There is no room for it in the payload. One see this in wireless payloads also. VSCP therefore uses “nicknames” for devices to identify a unit on a local segment/bus. A nickname is a number (any) that directly translate to a GUID. For CAN this nickname is a 8-bit number that is not zero (reserved for a possible master) and not 0xff (reserved for an uninitialized node).
On CAN a nickname can be assigned using the automated nickname discovery or be hard assigned. In the case of nickname discovery a possible master is search first and if there this device is supposed to assign a node id to the node. This is NOT implemented in the VSCP daemon (but may be) and must be handled in user land. That is one listen for CLASS1.PROTOCOL, New node online/probe to node zero and respond to it if it is detected and after that assign a nickname.
The nickname will normally not change on a bus. And one can make sure it does not by assigning the old nickname to a node that for example is replaced. But it can not be guaranteed so it is better to use zone/subzone’s as a way to connect “groups” together. That way when a node is replaced one only need to load it’s registers with the original nodes content and it is a replacement that is a real copy of the old device.
So at this point one have a one to one mapping between the GUID of the node stored in standard registers 0xD0-0xDF an the nickname. A table than must be added to/changed when a CLASS1.PROTOCOL, New node online/probe comes in by reading the GUID of that node.
One can easily do a REST i/f <-> CAN4VSCP interface app here if one want that. For example is a uvscpd planed that only have a driver interface and a link to a tcp/ip interface on a remote VSCP daemon.
Back to the uniqueness of the GUID. The VSCP daemon confuses things. This is because the fact that VSCP actually only identify things with VSCP GUID’s. So a Level I driver that implements the CANAL interface will receive and send using nicknames on the lower part but will use gull GUID’s on the higher part. This means that a device with GUID-A pass an interface (VSCP Level I in this case) and the will look as if it comes from GUID-B. Well one also send events to GUID-B.
The thing here s that the interface also is identified by a GUID. Either server assigned or user assigned. This is true for all interfaces on the VSCP daemon. It is important to note that this GUID can change when a daemon is restarted because the interface becomes another one.
Interface GUID’s of the VSCP daemon is built like this
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:aa:aa:bb:bb
0xaaaa form a server assigned id for the interface. 0xbbbb form the nickname and is actually 00bb for a Level I driver where bb is the nickname.
So for a user sitting on the REST/TCP/IP/websocket/mqtt interface a node that has a GUID YY:YY:YY:YY:YY:YY:YY:YY:YY:YY:YY:YY:YY:YY:YY:YY may look like it is XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:aa:aa:bb:bb. The only way to know the real GUID of a node is to read its GUID with CLASS1.PROTOCOL, Extended read register for example.
Again it is a one to one relationship and a CLASS1.PROTOCOL, New Node online from that interface may changed things so the table needs to be updated.
Not hard to implement on the application level.
That said the next version of VSCP & Friends will have a new function called node discovery. This is partly in place today also as new nodes are announced on the VSCP multicast channel. But this will be extended so nodes can have a unique name instead of the GUID and also the daemon will keep an internal table of “real GUID’s” one can query. Also MDF’s will be cashed by the server. This is what I will take on next after the new tables functionality I work on now is finished. Hopefully released before the summer.
In the meanwhile if one assign a GUID to a driver. And make sure that nodes use the same id, that is is initialized only once, the interface GUID is fine as a node identifier if one skip the 0xaaaa interface part of
XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:aa:aa:bb:bb
and just compare the rest. Also the one to one relationship works then to the “real GUID”.
VSCP and unique id’s.
A node’s assigned nickname id will be retained after a reboot on a CAN4VSCP bus device (or should). It is only changed (or can be) if the configure buttons is pressed. The first free id will be used in the nickname discovery process. In practice I see that this always turn out to be the same id in a real system but if one has removed other nodes in between one can never be certain. But it still is not a big problem for a service person. He/she in the first place press the configure button so it should not be a big problem to check that the id turned out to be the same and manually change it if not. The only time the configuration is done is during install and replacement of a node anyway. Another schema than the nickname discovery is to preferred for nodes that are going in and out on a CAV4VSCP bus.
