Category: VSCP

Good people. Join us U2.

http://www.vscp.org/wiki/doku.php/who_why_where/the_vscp_team

 

We today got a  EUR 50 donation from Henk Hofstra, Alkmaar, Holland to the project.  Thank you Henk!

Besides the money, which is  very much-needed to keep this project going, with servers and all other stuff that need to be held active, the belief in the project, from an other human being far away, which a contribution like this is a proof of, is worth thousand and thousands  times more than the actual money.  So this is big.

I thank you Henk, and all other people around the world, that decided to support the project. I do this  from the deepest rooms of my heart. You will never be forgotten and for me your unselfish action is the proof that there actually is good in the world after all.

Ake Hedman
Maintainer of the free and open VSCP project.

 

For people who want to keep track of the TODO’s of VSCP (OR help out by taking on one of the points)  the (ever-growing) list is here.

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.