Today I am writing about the globally unique identification code (GUID). Can it be more boring than that? Well maybe not, but it is needed in VSCP, and it is important for any VSCP system to work.
Lets get started.
First the VSCP GUID is 16-bytes and looks something like this
FF:60:83:12:111:49:A0:1C:00:97:97:C8:CC:02:01:42
Sixteen hex bytes forming a globally unique id. MSB is to the left. An empty or unassigned GUID is represented by all nills
00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
you can see this in many configuration files where the GUID is expected to come from some other place. This unassigned GUID should never be used on a working system.
By writing to guid@vscp.org and request a GUID series you can get a series of GUID’s for your own project. Doing so you will get something like
27:00:00:00:00:00:00:00:00:00:00:00:XX:XX:XX:XX
(this GUID btw belongs to Grodans Paradis AB).
The XX:XX:XX:XX part is what we have for our own devices. So with it we can start out and set
00:aa:bb:cc
for product series 00 (aa:bb:cc is increased for every built unit) and products series 01 get
01:aa:bb:cc
etc. Or we just have a number that is increase for every product made. Or we request a new series of GUID’s for each product series. The important thing is that no other device on earth (or in the universe for that matter) should have the same GUID.
Requesting GUID’s is btw free of charge. After all VSCP IS free, will be free and is proud to be free and open forever. We may starve to death in the process of keeping it that way though. I can promise GUID’s (and VSCP) will still be free.
You can find current assigned GUID’s here.
But wait now, with VSCP being the protocol of the world, the IoT framework that unite them all, every IoT makers first choice etc, should it not be a lot more people requesting GUID’s. (Note: Joking here (Note: At least try to. ) )
Well one of the reasons is that you actually do not need to request a GUID, you probably have one already, or more precise you can form one.
For example if you have a machine that have an Ethernet MAC address you are in the free. Using it you also have a series of GUID’s you can use. The reason is that some GUID series has been set aside for other id series. You can find them all here.
FF:FF:FF:FF:FF:FF:FF:FE:YY:YY:YY:YY:YY:YY:XX:XX
The series
FF:FF:FF:FF:FF:FF:FF:FE:00:00:00:00:00:00:00:00
is set aside for Ethernet MAC range. The
YY:YY:YY:YY:YY:YY
is the MAC address (MSB left, first), and
XX:XX
is the part you can assign to your own devices.
There is also a range set aside for IPv4 addresses
FF:FF:FF:FF:FF:FF:FF:FD:YY:YY:YY:YY:XX:XX:XX:XX
where again
YY:YY:YY:YY
is the IPv4 address and
XX:XX:XX:XX
is the bytes you can use for your own devices.
If you look at the list there are many other possibilities to form GUID’s from other unique ID’s.
Where is it stored?
Every device have a GUID and it is stored in the standard register space from where you can read it. You find it at address 208/0xD0-223/0xDF for a Level I device and on address 0xffffffd0 – 0xffffffdf on a Level II device.
Proxy GUID’s
When a device send you an event in higher level software the GUID is usually part of the message. For instance you can get a temperature sent to you from a device with GUID
FF:FF:FF:FF:FF:FF:FF:FD:C0:A8:01:33:01:02:00:04
and then when you read the GUID from the actual device you get
32:00:00:00:00:00:00:00:00:00:00:00:20:13:02:88
which appears to be wrong. But it isn’t actually wrong, the temperature event from the device have just probably passed another interface which acted like a proxy for the actual device.
This is not as hard to understand as it sound. GUID’s are 16 bytes and therefore far to big to use in many low-end transmission media. On the CAN bus for example VSCP uses only one byte for its id. This byte is called a nickname id as it is a nickname, a simpler version, of the full GUID. Other systems may have 16-bit nicknames and even other formats.
The thing with VSCP nicknames is that when they pass an interface they wil take the interfaces GUID and place the nickname in the LSB. So the GUID
FF:FF:FF:FF:FF:FF:FF:FD:C0:A8:01:33:01:02:00:04
comes from an interface
FF:FF:FF:FF:FF:FF:FF:FD:C0:A8:01:33:01:02:00:00
on a machine with IP address 192.168.1.51 (C0:A8:01:33:01) . On that interface a node has reported a temperature and that node use the nickname 04 or 0004 on the subsystem connected to the interface. I can now communicate with that device on this GUID as it was the GUID of the device itself and actually it is in a way.
GUID’s are used for everything in VSCP. Locations also have GUID’s. Servers have them. The principle is simple. Very simple indeed.
That was all for this week. Enjoy your weekend. I will work with a new admin interface for the VSCP daemon this weekend.
Cheers
/Ake