Category: General

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 it.  The 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.