The VSCP developers blog

I thought I ought to do a short update of how things move forward.   Well, despite me working all time I possibly can find with the new version of VSCP & Friends I still just move very slowly forward. On the positive side is of course that I write “forward” and not “backward”, but I feel things are moving very slowly ahead right now.  But it is just a lot to do and I am only one person. You bet I have wet dreams about having a team of programmers working on this.

Tables

My current work is on the new “tables” that will use a database. Reachable from all interfaces (tcp/ip, mqtt, rest, websockets) they allow for a way to collect and fetch series of measurements as the old ones did. Different this time is that Sqlite3 is used as the storage engine and that they are a lot more flexible than they where before.

The goal with tables is to be able to drag a decision matrix element in place that collect the data form a device. You have to do that manually today. And on the other end drag a live diagram/table to a web page that display the content in the table.

Anyway if all goes well I hope the full table functionality is fully in place in two weeks or so.

Discovery

Discovery is the next task. Today one can listen on the multi-cast channel for new devices that are discovered. This will be developed further so that more information about a node is published. This means that with discovery the VSCP daemon itself will go out and fetch data from nodes that it discovers. The VSCP daemon will also download and cache MDF’s.

Also new is that discovery data will be stored in a database and this data can be fetched and investigated through the different interfaces (tcp/ip, mqtt, rest, websockets).  In this database it will be possible to assign a real text name to a node and this name will in the future be possible to use when one refer to a node instead of using it’s GUID.

Lastly I hope to make a push interface to this discovery mechanism so that a VSCP aware phone for example can start an app. when a new device is discovered.

Hopefully in place before the summer. But don’t hold your breath.

Next release

The reason why I hold the next release of VSCP & Friends is that I the database structures aren’t final yet, and they will not be final until the interfacing code is in place. That is mainly the web interface code as of today, but also VSCP Works. If I release before the database structures is final I have to write update code between releases and that takes time I don’t have. So this work has to take the time it takes.

For those of you that want to try the head code, please do. But be careful to delete database files when you rebuild the project (rm /srv/vscp/*sql3).  The VSCP UX code now have a session window and variable handling and a few other functions in place and may be worth a try.

Community

It saddens me of course that VSCP has not been successful in the forming of a development community.  Today we don’t even have an active test or discussion community. This is of course harder still from a developer perspective as endless hours of work from my end just appears to end up in /dev/null.  But I still strongly feel that I will try to make the vision of a uniting system set up for soon seventeen years ago come to reality  before I give this up.  This year has been the hardest yet on this journey. and without all your kind donations I would not have been able to proceed at all. Thanks!

If someone out there share this passion or a tiny little tiny bit  of it, take on some VSCP work.  Web ux interface and bindings to different languages is probably the most important tasks at hand.  But there are so much more.

Have fun!
/Ake

Sync

To ask for readings (measurements/sensor values) from nodes one can use CLASS1.CONTROL, Sync. One can use sensor index, zone, subzone as a way to tell which readings are of interest. A node should send the requested value immediately when it get a sync. For cashing, use tables or variables to store the readings.

The sync’s primary use is to synchronize sensor readings from multiple nodes in time but it can obviously also be used  just to request data.

You can see that modules from Grodans Paradis AB implement the sync but also have registers the data can be read from and automatically repetitive delivery of sensor data.

For the Kelvin 1-Wire module for example the sync has the following description

If a SYNC event is received by the module it will check the zone/subzone parameters of the event and send out temperature measurement event(s) for all sensors that match. This can be a handy feature to use of one want synchronized data from several sources.

But you can also instruct the module to output temperature sensor data with a set time interval (see report interval registers here) or read the temperature reading in a register (see temperature registers here).

Periodical events are perfect when the VSCP daemon is part of a system. Tables and remote variables is two features it have that is well suited for this type of sensor data.

Tables is being rewritten and extended from the functionality available in the last release at the moment and is mostly into place in the head code right now. There is a description here. One can do many things with sensor data in them and actually create user defined SQL databases if one like that which can have its data requested over REST/TCP/IP/websockets…

If one want the x last readings the static table is perfect as it works in a round robin fashion.

One can also use remote variables to store certain sensor data. In many of my setups I use them all the time. A typical sample is a sensor value that should be sent on specific intervals to a cloud service but where internal systems need this sensor value at a much higher rate than the cloud service need it. The easiest way to do this is to store the value in a variable with a DM entry when it is received. This way one have the sensor value accessible all the time and  request the latest value over any of the interfaces. To send the value to a cloud service one use one of the internal events for example the minute event and send the value there calling an external script or using one of the internal actions such as the http put/get/post action or even the run internal JavaScript action (soon LUA to).

Well that’s power for you!