Monthly Archives: November 2017

Howto: Practical use of #VSCP Remote Variables @thingspeak

See The story about an old fridge and VSCP module setup – refrigirator control part 1 , part 2, part 3, part 4  for earlier parts about this setup.

You have a VSCP system (or other system) setup that control something. and now you want to share some of this information up to the cloud.  One typical problem that you will see when doing this in a VSCP system is that data (we call it events in VSCP) is coming in with a higher rate than the rate you would want to publish it to the selected cloud service.  To solve this VSCP remote variables are perfect helpers.

A stream from a VSCP interface can typically look like this.

There is a lot of events coming in and often the frequency is even much higher that it is here. All the data above comes from a refrigerator and a fridge that is controlled by two Paris and one Kelvin NTC10K modules. Kelvin modules publish temperatures from a fridge, the kitchen and the upper and lower part of a refrigerator. The Paris module controls the compressors from these temperature measurements (ON/OFF events). The Turn-ON/OFF events originate from the Kelvin modules.  So when a temperature goes above a set point Turn-On events are sent from the Kelvin module after each temperature read and similar a Turn-Off event is sent when the temperature goes below the low set point. Nothing fancy really there.

We will look at one specific temperature only here, the fridge temperature.

This temperature comes from a Kelvin NTC10K module with GUID=FF:FF:FF:FF FF:FF:FF:FE B8:27:EB:0A 00:02:00:01  We find this out with the  VSCP Works tool which always is our friend when diagnosing a VSCP system.

We also see that the sensor is at  index 1 for this particular temperature sensor on the Kelvin NTC10K and that the temperature is sent in Celsius (Unit=1), exactly as we want to present it. Thus no conversions is needed.

Now, one way of sending this data to the cloud is to have a DM (decision matrix ) entry that send the data to the cloud every time it is received.

For this we just add an entry in the DM that calls a script when the  temperature event is received. This DM row would look like this

<row enable="true" groupid="thingspeak" >

<comment>
  Send value for fridge temperature to 
  Thingsquare
</comment>

<mask priority="0" 
 class="65535" 
 type="65535" 
 GUID=
"FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF
/>

<filter priority="0" 
 class="10" 
 type="6" 
 GUID=
"FF:FF:FF:FF FF:FF:FF:FE B8:27:EB:0A 00:02:00:01" 
/>

 <action>0x10</action>
 <param>
/srv/vscp/scripts/thingspeak.sh XXEIAQWY1XXNU6XX 2 %measurement.string
 </parm>

<allowed_from>0000-01-01 00:00:00</allowed_from>
<allowed_to>9999-12-31 23:59:59</allowed_to>
<allowed_weekdays>mtwtfss</allowed_weekdays>
<allowed_time>*-*-* *:*:*</allowed_time>

<index measurementindex="true">1</index>

</row>

Here the mask says that all bits of the VSCP class is of interest, all bits of the VSCP type is of interest and all bits of the GUID is of interest.  This is basically to say that the event we enter in the filter is the one we are interested in. So what we had entered in the filter is VSCP Class = 10 for measurement, VSCP type=6 for temperature and the GUID of the Klevin NTC 10K sensor that send the fridge temperature value.

Action is set to 0x10 (16) which says we should execute an external script. The param is the argument to this script.  The first part of the param is the path to the script to execute (which must exist and be executable)  and the rest is parameters. So here we execute the script /srv/vscp/scripts/thingspeak.sh and send three parameters

XXEIAQWY1XXNU6XX    2    %measurement.string

to itThe first parameter is the publishing key to the thingspeak service, the second is the number of the Thingspeak field we want to upgrade. The last parameter is the current temperature in the fridge. The %measurement.string will be replaced by the actual temperature before the script is executed. There are plenty of escapes one can use in decision matrices. 

The script that is called is simple and looks like this

#!/bin/bash
 # Arguments
 # =========
 # 1 - Write key
 # 2 - Filed number 1 .. n
 # 3 - Value
 #echo() { :; } # comment line to enable debugging

update=$(curl --silent --request POST --header "X-THINGSPEAKAPIKEY: $1" --data "field$2=$3" "http://api.thingspeak.$

echo "Update #$update"

# Uncomment to get debug output
 #echo `date` - "$1 field$2=$3" >>debug

Pretty straight forward. Check the documentation up at Thingspeak for the full process.

So what we got now is a DM entry that will update the cloud data as soon as the measurement event comes in. If it, as in this case is received with a frequency less than ten seconds, this may be pretty wasteful of  server resources. Better to update the cloud data at even time intervals.  How do we do this using the VSCP server?

we use one of the built-in events of the VSCP server, the minute event which is feed to the DM exactly once every minute.

To do this we first write the fridge temperature to a variable every time the event is received. We select a non persistent variable as it is no use in saving this value between session. The DM entry for this looks like this

<row enable="true" groupid="fridge" >

<comment>
 Store current temperature for fridge in remote variable fridge_temp
 with typ float (5)
 </comment>

<mask priority="0" 
 class="0xffff" 
 type="0xffff" 
 GUID="FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:FF:Ff:FF:FF:FF:FF" />

<filter priority="0" 
 class="10" 
 type="6" 
 GUID="FF:FF:FF:FF:FF:FF:FF:FE:B8:27:EB:0A:00:02:00:01" />

<action>0x50</action>
 <param>fridge_temp;5;false;0;0x777;%measurement.string</param>

<allowed_from>0000-01-01 00:00:00</allowed_from>
 <allowed_to>9999-12-31 23:59:59</allowed_to>
 <allowed_weekdays>mtwtfss</allowed_weekdays>
 <allowed_time>*-*-* *:*:*</allowed_time>

<index measurementindex="true">1</index>

</row>

So now whenever the event that holds the fridge temperature comes in it is written to the VSCP remote variable fridge_temp .

With VSCP Works we can list check that the variable is available

and it is, fridge temperature is currently -19.43 degrees Celsius.  As you can see we have added the other measurements of the fridge and the refrigerator to variables as well.

Now with the fridge temperature in a variable we can easily access the fridge_temperature remotely  using websockets in a webpage or if we prefer the REST interface  better it can be used instead.  But also the TCP/IP interface or the MQTT interface of the VSCP server can be used. Actually display the fridge temperature in a widget on a web pages is just connecting it to the variable.

But here we want to send the value to Thingspeak every minute so we add another row in the DM that looks like this

<row enable="true" groupid="thingspeak" >

<comment>
 Send fridge temperature varible value to Thingspeak
 </comment>

<mask priority="0" 
 class="0xffff" 
 type="0xffff" 
 GUID="00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00" />

<filter priority="0" 
 class="65535" 
 type="6" 
 GUID="00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00" />

<action>0x10</action>
 <param>/srv/vscp/scripts/thingspeak.shXXEIAQWY1XXNU6XX 2 %variable:[fridge_temp]</param>

<allowed_from>0000-01-01 00:00:00</allowed_from>
 <allowed_to>9999-12-31 23:59:59</allowed_to>
 <allowed_weekdays>mtwtfss</allowed_weekdays>
 <allowed_time>*-*-* *:*:*</allowed_time>

 </row>

In this DM row we use the same script as above but now instead of triggering on the Class=10,Type=6 (A temperature measurement) we trigger on Class=65535, Type=6 which is the internal minute event. So now the fridge temperature will be sent up to the cloud server every minute instead of each time the measurement event is received. We can do this for all other fridge/refrigerator measurements also and send them all in one call up to the cloud server. Much more efficient.

You have the live result here.

Note the abstractions here. A driver on the VSCP server can collect data from a device of any type, transported over any net using any protocol  etc and it will end up well-defined here. This also works the other way around as the data can be sent out over any protocol, using any carrier and ending up on any device. One simple driver is all that distinguish one type from another and this driver can make everything look like it is a VSCP aware thingi from the VSCP servers point of view.

Task completed.

Hardware Setup: Here the VSCP Server is running on a Raspberry Pi. The fridge and the refrigerator and the modules is connected with CAN and the Pi uses the CAN4VSCP driver with the Frankfurt RS-232 module with a serial USB adapter to talk to the bus. Ethernet, Wifi, sub MHz RF, or whatever could have been used instead of CAN, but the powered CAN4VSCP bus is both low-cost, reliable and perfect in many other ways for a setup like this.

For the brave #VSCP

If you are a brave person please test the new deb packages for the VSCP server. More of them will follow. Please note that this is not release code. They are for test only.

There are three files for each binary

vscpd_12.29.2-20_amd64.deb for 64-bit base machines
vscpd_12.29.2-20_i386.deb for 32-bit  based machines
vscpd_12.29.2-20_armhf.deb for Raspberry Pi and the like

you find the files here under 12.29…   Use wget for example  to get them.

Installation process is

sudo dpkg -i vscpd_12.29.2_20…….

On a machine without wxWidgets installed it will complain about that, can be other dependencies also that fail. To fix that issue

sudo apt-get install -f

which will download and install the dependencies.

Remove the installed package with

sudo dpkg -r vscpd

Report problems on the VSCP list or  on Github.

I will try to set up a package repository later. Expect problems. But it currently at least appears to works on the machines I have here.

/Ake

W A R N I N G #VSCP #IoT

All drivers now have a common format

vscpl1drv-xxxxxxxxxxx

instead of

vscpl1-xxxxxxxxxxxdrv

Level II drivers are prefixed with

vscpl2-

Also note that the default installation folder is changed to the driver folder (with sub folders level 1 and level2) of the installation tree under (default) /srv/vscp

Also note that ‘-‘ is used instead of ‘_’

Before updating to >= 12 remove drivers from /usr/local/lib

State of #VSCP

So finally we are getting closer to a #13, Aluminium. It’s been over a year now since the last release. A lot, and I mean a lot has gone into VSCP & Friends since then, actually to much to list it here. But it is a better software package now than before and it was pretty good at that time to if I may say it myself.

For users maybe the deb packages will be the most notable thing. There will be a Debian package for the vscp server, vscp works and for the helper lib. Also all of the drivers will have debian packages.  But as drivers now are installed in the vscp folder structure (/srv/vscp/drivers/) they will be a bit special. This is a step against a web installable driver functionality I hope to have in place in the future.

Windows support for the VSCP server is now gone but it is possible to build and run it on a windows 10 machine in the bash mode. VSCP Works and the helper lib will be available as will the Level I (CANAL) drivers.If someone want to put down the work it should not be a big thing to get the VSCP server running on Windows either.

The last steps to work on before the release is here for those of you that are interested.

Last for you home automation freaks out there. Take a look at OpenHAB and Domoticz. One of them is probably what you are looking for, not VSCP & Friends, even if it to of course can be used for tasks like home control.

Cheers
Ake Hedman