Category: VSCP

When things are silent it means that things are brewing here at the Paradise of the frog. Currently the REST interface is getting some work.

This work is due to the user and access-right fields added to variables.  Yes there will be an owner of the variable, and there will be others that can or can not have access to it.  The access rights are the same as in Unix. RWX grouped in three pairs UGO where U=user, G=group and O=other. So 0x777 means everyone can read, write and execute the variable, 0x744 mean the owner can do everything with the variable but everyone else can only read it.

To execute a variable may sound strange. But as you are able to store LUA or JavaScript in a variable this definitely has its meaning. And yes JavaScript is available in the VSCP daemon now.

All main interfaces support variables so when the REST work is done (this week?) variables can be handled over the REST, TCP/IP and the websocket interfaces with the same ease.

The goal with the work at the moment is to have a working administrative web-based interface before the end of the year. This is hard work for me as I am a low-end and embedded programmer but as usual if no one else does it you have to do it yourself. Well very disappointed of course as this slow down things (and makes me poorer) but what the heck ” a man got to do what a man got to do” and I am sure that is true for woman to.

Have fun!
/Ake

Ripping things apart and building it together again is hard. We all know that. That is exactly what I am doing with the VSCP program suite at the moment. So messages as the one above, from the REST interface of the VSCP daemon is great happenings. Meaning things are coming into place again. Slowly.

Variables is a big thing in the VSCP daemon. You may wonder why? What the fuck, can a variable be sexy or even be an interesting feature. I would say yes. But don’t trust me. Read on.

In VSCP land two sorts of variables are known. Persistent and non persistent. This is all about sessions. A non persistent variable is fast but is sent to never never land after a power loss or a VSCP daemon restart. That is, they get lost  when a session ends. Still useful for many things. But never around for to long. A bit like money if you think of it. At least my money. Fun and useful when they are around.

The other type, the persistent one, lives also after a power drop and a VSCP server restart. They live and survive also over sessions. That is, works just as they where a database items. Tell you a secret? They are. They are just exposed to the word as a “variable”.

All VSCP variables have a type. The type tells what sort of value a variable holds. There are plenty of types. First there are types like a string, integer, long, double, boolean. A string just stores some sort of text, just as an integer type stores a number and so on. You have date, time and that kind of thing also of course.

Then there is VSCP relate types such as variables holding events or GUID’s etc. Not to unexpected to find in a VSCP related system. The rest of the types may be more surprising. JavaScript. HTML pages. LUA scripts. User interfaces… You have a full list here.

Well a short explanation may be in place.  The scripts can be executed by the daemon when an event is received. Yes you can program your advanced scenes with them. The HTML pages and user interface parts are holders for user interface elements for your particular setup.

The great things with variables is that they are remotely available. To write a variable from an Arudino or some other board  just log into the TCP/IP interface and issue

variable write current-temperature 13.31

to set an integer variable value to the value “13.31”. Or to read its value

variable readvalue current-temperature

which will return the variables current value.  You can do this from anywhere. From small things or from php scripts and from large things.

But…

it’s not just through the tcp/ip interface you can handle variables. You can reach them over all interfaces. The REST interface. The websocket interface. The MQTT interface. The CoAP interface. They are accessible from all parts of the system.

And more…

you have access to them in your LUA scripts, Javascripts, HTML pages and in the local decision matrix of the VSCP daemon.

So in their simplest form. Variables is just a storage position. You store something in them.  But once stored they can be displayed, calculated with, being the source for complex decisions or automatically be sent to other parts of a system for that part to carry out great things when they arrive.

And security…

which is state of the art of course.

Yes I definitely think that VSCP variables is a sexy thing.

I should work with hardware modules in Grodans Paradis AB because it is a much greater chance to get some money back from the work I do there. And sadly we all need money to survive.

But…

I work with the software at the moment. And I will continue to do so for some time. Neglecting my own hardware development then of course. Well I actually decided some month’s ago to do hardware some days each week and software the other. But (again) I need the changes and additions I am working on right now to go on. So it’s has been and will be still for some time only software work.

So what is it?

Many have heard me talking about databases in VSCP. At leat if you been around at all.  Not so hot and sexy you may say, but by adding them there is much easier to do a nice remote administrative interface. Also the discovery process becomes much simpler.

And yes I do plenty of Javascript now. UX work to. I am not the man to do this kind of work because I am really bad on it, but if no one else does it…

So expect an administrative interface where settings for the local/remote daemon can be changed in a secure way, where devices can be discovered, where data/measurements can be visualized, where drivers can be installed/uninstalled and much more.

And then there is variables. Variables will be the common interface to set all values. So users, driver, DM-rows, measurement values, tables, discoveries and all the rest of the functionality that is available in the VSCP daemon will be exposed as variables. Accessible through the tcp/ip interface, the REST-interface, the web socket interface , the MQTT inteface, the CoAP interface and from LUA, Javascript and with the helperlib from all local or remote applications.

Oh well, somewhere further ahead at least.

Again I would like to thank you guys again for support for the project. You all know who you are. VSCP have no angel investors or big institution founders and it can be hard to stand independent during long coding runs as we are in now. Still with the support from the community we will, in the end,  deliver the IoT solution that unite them all.  I promise you that.

Working with a new administrative interface for the VSCP daemon.  One must think that by taking one step at the time, one will eventually reach the top, or at least, by continue digging, even on your own, it will eventually, at last,  be a big hole.

224.0.23.158

Yes VSCP has a multicast channel assigned. The above is the assigned IPv4 address for it.

Announcements

All higher level IP equipment should send announcements  on this multicast address. The port used is 9598, the registered VSCP port.

This means that if you want to know what units are on a multicast segment you just listen on this channel.

Announcements can be of three different types

• VSCP daemon announcements. Announce the availability of a VSCP daemon (or other server with exported interfaces) and tell its capabilities.
• High end device announce. Announce the availability of the device and its capability. All Level II nodes should have this functionality. At the bottom line they just look to the system as a VSCP daemon with fewer capabilities.
• Heart beats: Heart beats come in the form of heartbeats from VSCP daemons and from high-end nodes. Both send them out each minute. Also heartbeats are available form devices connected to a daemon or through a high-end node.

• CLASS2.Protocol Type=20 is used for announcements.
• CLASS1.INFORMATION Type=9 is used for heartbeats

User multicast channels

Users can set up proprietary multicast channels  using some other port than the VSCP assigned 9598. This makes it easy to create groups of VSCP nodes that can communicate with each other in much the same way as on a CAN bus.

Two factors that must be taken into account is the unsecured nature of this type of communication. Delivery is never guaranteed. But most of the time this is not a problem in VSCP if one design the event exchange around it. That is that a node that digest an event also send some sort of confirm/information event when doing so. The other problem is that it is easy to go in a mess about with the traffic for a user that is not allowed to do that.  Something that is  easily solved with cryptographic routines. Some VSCP standardization (and samples)  will come here in the future.

You can read more here.

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

Every VSCP device have registers. Registers abstract the settings for any device. Actually a non VSCP device can have a driver that abstract the devices actual setup, whatever it is, into registers.

So what is a register? In VSCP it’s just a byte wide position that can be read or written. Hence to configure a device one simply write registers, to find out the configuration of a device one simply read registers. Two simple operations. Read and write a byte.

Registers is divided in two types. User registers and standard registers. The standard registers is you will find at the same location on every device, that is  in position 80-255 on level I devices and at 0xffffff80 – 0xffffffff on Level II devices.

Standard registers contain information about a device.  The most important information you can find here is the 16-byte GUID which is a globally unique id for the device and the MDF URL which locates the Module description file. You can find firmware version, alarm status and a lot of other information here as well (more info here) .

As the standard registers is at the same location on every device and they always have the same type of content they are easy to use without any more information. The user registers on the other hand can contain anything the maker of the device want them to contain. Actually we call the registers a register abstraction model as they often model a more complex setup that may look like it needs more than just a bunch of 8-bit registers.

For a level I device there are 128 user registers available in the range 0-127. But this register space is also paged into 65535 pages.  Level II device use 0-0xffffff80 for user registers.

As the standard registers can contain anything there is a need for a description on their content. This information is available in the MDF (Module Description File). This XML files location is pointed out in the standard register space and can be fetched by software that need to configure the device. The pointer is a standard URL so the file usually is located on a standard web server.

You can read about the full content of the MDF here.  An example real life MDF is here.

The register content of a device is specified in the MDF. Typically a record looks like this

<reg page="0" offset="11" bgcolor="0xFFFFCC">
<name lang="en">Relay 1 control register</nam>      <description lang="en">The relay control bits enable/disable intelligent relay functionality:\n
Bit 0 - Enable pulse.\n
Bit 1 - If set: Alarm sent when protection timer triggers.\n
Bit 2 - Protection timer enable.\n
Bit 3 - Send On event when relay goes to active state.\n
Bit 4 - Send Off event when relay goes to inactive state.\n
Bit 5 - Send Started event when relay goes to active state.\n
Bit 6 - Send Stopped event when relay goes to active state.\n
Bit 7 - If set to one the relay is enabled.\n
</description><access>rw</access><bit pos="0" default="false"><name lang="en">Reserved</name><description lang="en">This bit is reserved</description></bit><bit pos="1" default="false"><name lang="en">Protection alarm</name><description lang="en">If set: Alarm sent when protection timer triggers.</description></bit><bit pos="2" default="false"><name lang="en">Protection timer enable</name><description lang="en">
If set: Protection timer is enabled and will deactivate relay channel when the timer times out.
</description></bit><bit pos="3" default="false"><name lang="en">On event on activate enable</name><description lang="en">
If set: An on event will be sent when the relay is turned on.
</description></bit><bit pos="4" default="false"><name lang="en">Off event on deactivate enable</name><description lang="en">
If set: An off event will be sent when the relay is turned off.
</description></bit><bit pos="5" default="false"><name lang="en">Started event on activate enable</name><description lang="en">
If set: A started event will be sent when the relay is turned on.
</description></bit><bit pos="6" default="false"><name lang="en">Stopped event on deactivate enable</name><description lang="en">
If set: A stopped event will be sent when the relay is turned off.
</description></bit><bit pos="7" default="false"><name lang="en">Enable relay</name><description lang="en">
Set this bit to make the relay controlable.
</description></bit></reg>

In this case a description of the bits in a register and how they make the device behave as they are set or cleared.  This register is at location 11 on page 0, usually written as 0:11.

Note that we can reach this level of abstraction with a protocol that have only two operations, read and write, it’s hard to think of a simpler protocol than that.

The intended user of the MDF is a configuration software. This piece of software read the MDF location from the device, download it from the server, parse it, and can then help a user to set up a device. Good thing is that one piece of software works for all devices. Later we will explain the wizards that are available in the MDF which makes this even more useful.

Abstractions

A register is an 8-bit location as we said. Now how about storing things, like floating point value, that does not fit in an 8-bit location. Well the answer is simple of course. Store them in multiple 8-bit locations.

To describe this abstractions are used. Abstractions sit on top of registers and specify how higher end types such as integers, strings, floating point values are stored in register space. So a higher end software usually does not bother with registers it instead  work with the high level types it usually deal with.

An example from the same MDF we sampled before

<abstraction type="short" default="0" page="0" offset="18" bgcolor="0xCCFFFF"><name lang="en">Relay pulse time register for relay 0</name><description lang="en">
This is the pulse time for the each relay expressed in seconds.
This can be used to have a relay turn on and off with a certain
preset interval. The min pulse time is 1 second and the max time
is 65535 seconds which is about 18 hours. Set to zero (default)
for no pulse time i.e. the relay will be steady on/off.\n\n
To start a pulse sequence first write the pulse time to this
register and then write 2 to the relay status register to start
the output. The pulse train is terminated by writing on or off
(1 or 0) to the relay status register.\n
</description><access>rw</access></abstraction>


show an integer that has its MSB at pos 0:18 and it’s LSB at 0:19 (Everything in register space is stored MSB first)

Software tools  like VSCP Works (available in the  VSCP & friends package) can handle configuration of any device. Some web-based tools is on the way to do the same.

There is no need for things to be more complicated.

Yes I know. It’s all about the cloud nowadays. Every device should post their data up to the cloud and allow themselves to be controlled from the cloud. So I will talk about autonomy of a VSCP setup today. Well I know. It’s kind of the opposite to the cloud model as no cloud is needed. But wait, don’t go away, you can have the cloud and autonomy at the same time. Promise.

VSCP is an event bases system. Events are sent by nodes when things happen. The node that originates the event does not care if there is one or two or three receivers. It just originate the event for anyone to receive (must-be-in-the-cloud people: yes the event can be sent up into the cloud).

So another node receive this events, find it interesting, and do something with it. For example if the event sent was CLASS1.CONTROL, Type=TURN-ON (the standard event to turn things on) the receiving node will turn the thing(s) it is supposed to turn on and send CLASS1.INFORMATION, Type=ON (the standard event to tell that something has been  turned on) to tell interested parties that it has turned on a device.

This is typically how the VSCP event system work. An event is sent out and if something happens at a point and a receiving device  take interest in the event, this device also sending out an event telling the system it did something.

The ping-pong mechanism described above where a reply is sent when something is turned on can be used to validate that the expected operation actually has been carried out.

(Must-be-in-the-cloud people: yes the event can come from the cloud and the “response” can go to the cloud).

Well most systems around typically have a server in the system (or a server in the cloud). VSCP does not need one (but CAN have one). Because when a VSCP system is configured it behaves like an autonomous system. All this is possible because of the decision matrix (DM) that can be implemented  in a VSCP node..

The decision matrix

We will only discuss the Level I decision matrix here.  Made for low-end devices, The Level II works mostly the same.

The decision matrix is a 8-byte entity and a device can have zero or more rows in its matrix.  The purpose of the DM is to say

When an event of a certain kind comes in do something.

And the “do something” part of a decision matrix row is called an action. Take a look at the Paris Relay module for some action samples. This is typical for all modules. It has a few well-defined things it can carry out. In the case of the Paris relay module  turn on a relay, turn of a relay and so on.

As the DM looks the same on all VSCP devices it is easy to make a user interface that configures it

1. Let the user decide which event(s) should trigger the action.
2. Select from where the event should come.
3. Select what action should be performed.

Same for every device.

When this is configured  for a devices it will work  autonomous from that point on. Incoming event’s will be feed through the DM of the device and if a match is found the action will be performed.

No server needed.