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
- Let the user decide which event(s) should trigger the action.
- Select from where the event should come.
- 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.