The VSCP developers blog

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.