Part 1
Demos VSCPWorks
Part 2
Category: HowTo’s
This article is based on this tutorial from AdaFruit. Read it before you continue. Here is an extended version. It explains how to connect 1-wire sensors to a Raspberry Pi system (Works on other Linux systems also of course).
As explained in the above article there is support for 1-wire in the Linux Kernel. You will get a folder for every each temperature sensor you attach to the system under /sys/bus/w1/devices
The script send_pi_onewire.py will read information from each on the attached sensors and send to a VSCP daemon for further processing. This script originally comes from Adafruit but has been extended and changed, see the original article.
The usage is
./send_pi_onewire.py host user password
The script will use the 1-wire sensor GUID to construct a valid unique VSCP GUID.
Only sensors that has been read correctly will be sent to the VSCP daemon.
The script can of course be added to cron if one for example want to have temperature reported every minute. There are other howto’s on this blog that explains how this is done.
note
A good reading of a sensor gives this data on the filesystem
2a 00 4b 46 ff ff 0f 10 40 : crc=40 YES
2a 00 4b 46 ff ff 0f 10 40 t=20812
May be worth checking that you have this content in the file(s) there before using the script.
If you want to know the GPU temperature of your Raspberry Pi you issue
/opt/vc/bin/vcgencmd measure_temp
and will get a response like
temp=45.5’C
form this command.
We will show a script here that send this temperature to a VSCP daemon so that you can handle, display, diagram, react on the measured value etc
The script to do this is here.
You use it like this
./send_pi_gpu_temp.py 192.168.1.6 admin secret –
First remember to make it executable (chmod a+x send_pi_gpu_temp.py ).
The parameters are.
- IP address to server (192.168.1.9) where VSCP daemon resides.
- User name for TCP/IP connection, obviously you should use anther user than the admin user in most cases.
- Passsword for TCP/IP connection.
- GUID to use for the temperature event. This is an optional parameter and if not given “-” wil be used which is the same as a GUID with all zeros and mans that the event will have the GUID of the interface. It is better to give an explicit GUID but this works for now.
So issuing this and watching it in VSCP Works
now we can add this to a cron script to get the temperature sent to the VSCP daemon every minute.
We add a script send_gpu_temp to /etc/cron.d looking like this
* * * * * root cd /root;./send_pi_gpu_temp.py 192.168.1.6 admin secret 00:00:00:00:00:00:00:00:00:00:00:00:00:01:00:03
Note that a GUID has been assigned here for the sensor. The
00:00:00:00:00:00:00:00:00:00:00:00:xx:xx:xx:xx
can be used for lab usage and I put a id for some hardware in byte 2/3 in this case 00:01 and index in byte 0/1 ( 00:03). We could have used the MAC address or the IP address of the Raspberry Pi as a base for this or a privately assigned GUID series. You can read more about the GUID’s here.
Thats it. You can now alarm yourself when the temperature reach critical levels or just diagram the data or collect it in a database.
The CPU temperature of a Raspberry Pi can be checked with
cat /sys/class/thermal/thermal_zone0/temp
what you get is the CPU temperature in degrees Celsius times 1000. A typical output would therefore be
44388
which is 44.388 degrees Celsius.
If we want to react on this temperature or collect it or diagram we need to send it to the VSCP daemon. There is many ways to do this but the probably easiest way is to send it to the VSCP daemon over the TCP/IP interface. If you like MQTT more or websocket or a REST interface you can choose any of them instead as they all are supported by the VSCP daemon.
On a Raspberry Pi we usually have Python so we do this with a Python script for simplicity. We can add this python script to cron and as we will see later get the CPU temperature every minute.
The script by the way is general. It can send any temperature times 1000 expressed in degrees Celsius and stored in a file to the VSCP daemon. It is possible to have the conversion as an input parameter but we skip that in this case.
The script is easy and looks like this
You use it like this
./send_pi_cpu_temp.py 192.168.1.6 admin secret –
First remember to make it executable (chmod a+x send_pi_cpu_temp.py ).
The parameters are.
- IP address to server (192.168.1.9) where VSCP daemon resides.
- User name for TCP/IP connection, obviously you should use anther user than the admin user in most cases.
- Passsword for TCP/IP connection.
- GUID to use for the temperature event. This is an optional parameter and if not given “-” wil be used which is the same as a GUID with all zeros and mans that the event will have the GUID of the interface. It is better to give an explicit GUID but this works for now.
So issuing this and watching it in VSCP Works
now we can add this to a cron script to get the temperature sent to the VSCP daemon every minute.
We add a script send_cpu_temp to /etc/cron.d looking like this
* * * * * root cd /root;./send_pi_cpu_temp.py 192.168.1.6 admin secret 00:00:00:00:00:00:00:00:00:00:00:00:00:01:00:02
Note that a GUID has been assigned here for the sensor. The
00:00:00:00:00:00:00:00:00:00:00:00:xx:xx:xx:xx
can be used for lab usage and I put a id for some hardware in byte 2/3 in this case 00:01 and index in byte 0/1 ( 00:02). We could have used the MAC address or the IP address of the Raspberry Pi as a base for this or a privately assigned GUID series. You can read more about the GUID’s here.
Thats it. You can now alarm yourself when the temperature reach critical levels or just diagram the data or collect it in a database.
A note
VSCP base measurements on the SI system. So a measurement has a base unit that is standardized and well specified. For convenience you can often use other units also. As an example, for temperature, the base unit (0) is Kelvin. But you can send the temperature data as degrees Celsius (unit=1) or degrees Fahrenheit (unit=2) also. The important thing is that it will always be well specified.
The format of the data is also well specified. In VSCP there is no questions raised about big/little endian or decimal point formats and such things. The number can come in many formats (string/integer/float…) but they are all well specified and have a clear conversion path between each other.
Well why? you may ask. What can we gain from this?
The thing is that as soon as we have the data in a common format routines for handling one type of measurement will work equally well for another type of measurements. Write once use many times. You can even see this in the above sample. Only the unit and the class type will have a new meaning if we wanted to send a sound level measurement instead of a temperature measurement to the VSCP daemon.
In this case all VSCP Level I is used. That means max. 8 bytes of data. Even the smallest device out there can handle this. It’s both practical and economical.
And all this is true for turning on/off things etc also of course.
The most important mission with a m2m/IoT/whatever framework like VSCP is to make the world simpler for the end-user. Yes for the “end-user”, NOT for the developer. That said it is of course good if things are as easy as possible for the developer to.
If you are new to VSCP the system is always overwhelming. It is a big system with many possibilities, but the event is central, VSCP is after all an event based system, and when your data is on the VSCP standardized event format you can present it, store it, react on it or calculate on it in a standardized way. Any solution you come up with that handles events will become a reusable component. For you and for others if you share your work. For instance. If you make a software that diagram measurement value and your intention is to show temperature changes this same piece of software will be useful for someone else to display concentration variations in a fluid of a process industry by just changing the description of the diagram labels.
VSCP events have a class and a type that specify what the event describes. This is typically a “measurement” or “info” or “control”. Samples are
Class=10, Type=6 – The event describes a temperature.
Class=30, Type=5 – Turn on “something”.
You can read all about them here
The measurement events are standardized around the SI units. So you will see all standardized units there but also some derived ones. If/when need arise more will follow. They all have a unit and a value.
For the unit there is the standardized unit, for example for temperature “degrees Kelvin” is used. But user want to work with Celsius or Fahrenheit so they are also available. Without going into details the end result is a unit of information (the VSCP event) that specify the measurement value fully and this information unit is usable by both low end and high end systems.
Why is this important you say.
First of all there will not be mistakes like sending a Mars sond past Mars because one developer thought the values where inches and another centimetres. Secondly you only need to write code once for each layer. An event, a measurement, a type of measurement and so on. If you think about it this is exactly what the web and web browsers is all about. A common format for the hypertext.
So to the point. To benefit from the above you have to translate world data into VSCP events.
In this sample a DS2490 one-wire adapter read an outside temperature and an inside temperature and send the sensor values to a VSCP daemon as VSCP events for further processing. A simple Python script is used which is added to the crontab on a Raspberry Pi to report the temperature every minute. ne wire id’s can be directly translated into a valid VSCP GUID (just as an Ethernet MAC etc can) so this is also taken care of in the script.
When the sensor values is sent to the daemon it can be collected or presented in a standardized way or another system can react on the data and as in this case turn on a heater when the temperature is to low or alarm via an SMS when the outside temperature is going below zero.
You can find more Python code here.
Salvo Musumeci started work to do VSCP Python bindings to the VSCP helper library but it appears that this project has stalled. I hope he or someone else will complete this project as it would benefit a lot.
VSCP MQTT Driver Simplify mode
Make measurement event come out as a plain number over the MQTT channel.
Sometimes, and especially if your device is a low end device, it can be nice to publish measurement events from the VSCP daemon to it as plain numbers. You can do this with the simplify feature.
First look at the driver entry in /etc/vscp/dm.xml
<!– Level II MQTT driver –>
<driver enable=”true” >
<name>MQTT2</name>
<path>/usr/local/lib/vscpl2drv_mqtt.so</path>
<config>session2;publish;vscp-pub;192.168.1.9:1883
<guid>00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00</guid>
</driver>
We see that this driver defines a publishing MQTT channel with
- topic = vscp_pub
- session id = session2
- broker is at address = 192.168.1.9
- broker use standard MQTT port = 1823
Nothing strange here. Normally VSCP events would be available if you subscribe to the topic vscp_pub on this broker. On the console typically like
mosquitto_sub -h 192.168.1.9 -v -t ‘vscp-pub’
This is just the same as we described above. But now lets define a simplify variable like (/srv/vscp/variables.xml or in the web interface of the VSCP daemon).
<variable type=”string”>
<name>MQTT2_SIMPLIFY</name>
<note>Feed temperature measurements to “the thing”</note>
<value>1040,6,0,1,0,0</value>
</variable>
When the MQTT driver loads it looks fore variables named like it’s name + “-” + keyword and configure itself from the variables. This configuration actually overrides the configuration done in the diver configuration string.
It also add extra configuration possibilities and SIMPLIFY is on of them so
MQTT2_SIMPLIFY
is a variable with name “SIMPLIFY” that is destined for the driver with name “MQTT2”.
The content of a simplify variable specify the event we want to send on the MQTT channel as a plain number. In our case we have
1040,6,0,1,0,0
which boils down to
- 1040 – This is the VSCP class. In this case CLASS2.MEASUREMENT_STR
- 6 – This is the VSCP Type and six is “temperature”.
- 0 – This is the sensor index. Only events with this sensor index will be published.
- 0 – This is the zone. Only events with this vallue will be published.
- 0 – This is the sub zone. Only events with this value will be published.
- 0 – This is the unit. Only events with this value will be published.
You can use CLASS1_MEASUREMENT and CLASS2_MEASUREMENT_FLOAT also if you which for this functionality and the format for them are here.
So now when you restart the VSCP daemon CLASS2.MEASUREMENT_STR events will come out as plain numbers on the MQTT channel. We can test this in the TCP/IP interface by sending
send 0,1040,6,0,0,-,0,0,0,1,0×35,0x35,0x35,0x2e,0x30,0x32
which will come out as
vscp-pub 555.02
if you subscribed using mosquitto_sub -h 192.168.1.9 -v -t ‘vscp-pub’
Send plain numbers over a MQTT channel and have them automatically translated into proper VSCP events.
You may just want to send plain numbers instead of a full VSCP event to the VSCP framework. Typically this can be some stupid device that just is capable of sending out plain numbers. The simplicity mode can make these kind of devices a bit more useful also. YES you want at least the unt of your measurement to come along with your data in a standardized way.
To use this feature we us the first driver entry we specified
<!– Level II MQTT Driver –>
<driver enable=”true” >
<name>MQTT1</name>
<path>/usr/local/lib/vscpl2drv_mqtt.so</path>
<config>session1;subscribe;vscp-sub;192.168.1.9:1883
<guid>00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00</guid>
</driver>
Here we subscribe to a MQTT channel vscp_sub on the broker located at 192.168.1.9 on port 1883. We name the session “session1”. Remember that all drivers MUST have a unique session name.
So things publishe form other devices on topic vscp_sub will be received by the driver and normally this is VSCP events on the standard string form
send head,class,type,obid,time-stamp,GUID,data1,data2,data3…
you can read mode here about this format used n the TCP/IP interface of the VSCP daemon among other places.
But now we want to send just a number and get a VSCP events. So for this we use the simplify feature again.
We start out just as above by specifying the SIMPLIFY variable. As you see we now referee to the first driver entry MQTT1
<variable type=”string”>
<name>MQTT1_SIMPLIFY</name>
<note>Allow for sending plain numbers </note>
<value>1060,6,0,1,0,0</value>
</variable>
Only 1060 is different than above, We could have used 1040 here alos to get CLASS2.MEASUREMENT_STR event but to be not to repetitive we use CLASS2.MEASUREMENT_FLOAT for this example.
And using VSCP Works to check the incoming event gives the expected result
If we set CLASS2.MEASUREMENT_STR (1040) instead we got the same end result
And you can use one of the other measurement types also of course. Read the docs.
Well that was it for this time. The full driver info is here.
Using
The MQTT driver for the VSCP Daemon is a way to connect VSCP to things communicating over MQTT. Well it’s just as easy as 1-2-3 to do so. Just follow this instruction.
Suppose that we want two MQTT channels. One that publish content to a broker and one that subscribe content from a broker channel. Of course we can have as many as we like. Just add more driver entries if you need more. There is no practical limit.
So for driver additions we add the following driver enteries to the vscpd.conf file (/etc/vscp/vscpd.conf on Linux and /programdata/vscp/vscpd.conf on windows).
<!– Level II MQTT driver –>
<driver enable=”true” >
<name>MQTT1</name>
<path>/usr/local/lib/vscpl2drv_mqtt.so</path>
<config>session1;subscribe;vscp-sub;192.168.1.9:1883
<guid>00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00</guid>
</driver>
<!– Level II MQTT driver –>
<driver enable=”true” >
<name>MQTT2</name>
<path>/usr/local/lib/vscpl2drv_mqtt.so</path>
<config>session2;publish;vscp-pub;192.168.1.9:1883
<guid>00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00</guid>
</driver>
Both have there own unique names, MQTT1 and MQTT2 as they should. Paths are set to the driver location. Windows user need to point this path to the installation folder. The GUID is set to all zeros meaning the driver will use the GUID of the interface. We are fine with that in this sample but for most cases it is better to set a unique GUID.
Then we have the configuration string and it is different for the two driver entries. We look at each driver on its own from here,
MQTT1
The configuration string looks like this
session1;subscribe;vscp-sub;192.168.1.9:1883
That is we create a subscription channel, that is a channel which subscribes on content from a MQTT broker, and in this case expects VSCP events on the standard text form coming in on the channel. The broker is at IP-address 192.168.1.9 and using the standard port 1883. The topic we are interested in is vscp_sub. That’s almost it. We need one more thing. We need to name the session for our communication with the MQTT broker. In this case we set the session name to session1. Remember that this session name must be unique in each driver entry.
Restating the daemon and we are ready to go
Using mosquitto_pub we can now send MQTT events to the VSCP system
mosquitto_pub -d -t vscp-sub -m “vscp-pub vscp-pub 0,10,6,0,0,-,0x88,0x82,0x0A,0x09”
which comes in as 25.68 degrees Celsius from sensor 1.
Data
This section can be skipped if your not interested in how the data is coed.
This format is fully described in the data coding section of the specification but we give a brief explanation of the event data here also (but you should read the spec. for a comprehensive understanding). The event is CLASS1. MEASUREMENT, Type=6, Temperature. So we have a temperature measurement. Good to know.
It is a VSCP level I events. We see that from CLASS1. in the class name. This is a low end measurement event used in VSCP that can handle all SI system defined types. VSCP level I event have a maximum of eight data bytes as it is defined to be possoble to be handled by the smallest devices out there. Eight byte is not much but you can tell what type of measurement it is, what sensor of eight possible on a board it comes from, and what unit the measurement is give in. Not bad. Compare that to just sensing 44.20 over the topic.
The data can be coded as a string or a floating point value or in something called a normalized integer as here. If your device can handle floating point you should use that. But many devices does not have resources to handle floating point data as it costs memory. They ned the memory for other tasks. And that is where the normalized integer comes in handy.
As you see the data for the measurement is
0x88, 0x82, 0x0A, 0x09
The first byte of this data is the coding byte, here 0x88. In this byte fits information about the index for the sensor (bits 0,1,2), the the unit for the measurement (bits 3,4) and the type of data that follows (bits 5,6,7).
So in binary 0x88 is
10001000
which if we break apart the different fields become
100 01 000
- Bits 0,1,2 is set to 000 so this is a measurement from sensor 0 of the board.
- Bits 3,4 is set to 01 so this is the second defined unit of the measurement. Unit zero is always the SI unit and as this is a temperature measurement (we got that information from the class and the type) the available units for temperatures are Kelvin (unit=0), Celsius (unit=1), Fahrenheit (unit=2). So our measurement is in degrees Celsius.
- Bit 5,6,7 Tells if the value is a string, a floating point value or any of the other defined types. In this case 100 tells us that it is a normalized integer.
OK We have a measurement value from sensor 0 that is expressed as degrees Celsius. Just need to know the value as well.
A normalized integer have a decimal point shift byte as its second byte and then the 1-6 bytes that follow are the actual integer value. So here the value is 0x0A09 (VSCP always store everything MSB first). Translated to decimal 0x0A09 is 2569.
The second data byte (0x82) says, if it has bit seven set, that the decimal point should be moved left in the number that follows with the amount told by the remaining bits. So in this case the decimal point should move two steps to the left which gives 25.62.
So the measurement value is a temperature measurement of 25.69 degrees Celsius.
Sending on/off
Everything is well specified in VSCP. So to turn something on or off is well specified of course.
To tun something ON one use the CLASS1.CONTROL, Type=5 in VSCP. To turn something off one use CLASS1.CONTROL, Type=6.
The event CLASS1.CONTROL is coded as 30.
Now to something that might look strange to VSCP newcomers at first. VSCP normally does not address things. WHAT!? you might scream out. Yes it does not. Instead it send a TurnOn event to devices in a zone/subzone. The sender does not know if the receiver is one or as man as hundred devices. It does not even care. It just send the event. It trust the transport mechanism to deliver the event to interested parties.
So for both TurnOn and TurnOff of the data format is
0x00, zone, subzone
So to turn something on in zone=1/subzone=2 we send
mosquitto_pub -d -t vscp-sub -m “vscp-pub vscp-pub 0,30,5,0,0,-,0,1,2”
and to turn something off we send
mosquitto_pub -d -t vscp-sub -m “vscp-pub vscp-pub 0,30,6,0,0,-,0,1,2”
Not to hard is it?
MQTT1
The configuration string looks like this
session2;publish;vscp-pub;192.168.1.9:1883
Well we recognize the confoguration string from above. The session name is “session2”. Remember it should be unique. and we publish to a broker instead of subscribing. The MQTT topic is set to vscp_pub.
So to if you subscribe to vscp_pub on the broker you get events from the VSCP system sent to you. You set filters to tell which events you want and do many other things.
Using the mosquitto_sub subscribing is
mosquitto_sub -h 192.168.1.9 -v -t ‘vscp-pub’
which you can use for testing. But Arduino or Raspberry Pi also have MQTT libraries so you can take in VSCP events to them to, well or sening giving you access to the VCSP framework with web interfaces, diagrams, message routing and a lot more.
It may be simpler to use just VSCP and get the same advantages but this write-up is for those of you that use MQTT today.
Another part will follow describing a way to simplify message handing over MQTT.
To get a XML file in JavaScript can be difficult due to the same origin policy. CORS is on solution but using JSONP is a much simpler solution also because JavaScript kind of like the JSON format.
The problem here for VSCP is that the MDF (Module Description File) is in XML format. We therefore need a conversion.
This PHP scripts will handle this and out put a local xml file in JSON/JSONP format
You can test the output for the Paris module
here.
In this case the local MDF file is paris_010.xml and we request JSONP output using the function “callback”.
If we skip the
&jsonp=callback
we get pure JSON output instead.
The script can be downloaded here.
By Ake Hedman
One day the fridge in our house died. Probably due to a recent thunderstorm. Panic of course and when I noticed that it was totally dead I bought a new one and saved the situation. The fridge was left in its location and later I realized that the control logic inside it was dead. I checked the obvious things but without a drawing it was not much I could do and buying a new board was in excess of EUR 250 so I decided to build my own control logic.
Well, I as most people, have a lot to do, so two years later I actually started the project. As my company build VSCP based modules I decided to use two of them for the project and by that way make it a reference project. I could have done this much easier probably with an Arduino or similar, after all it’s not a very complicated project, as a fridge is an easy thing to control. It is just basically turn on compressor when it’s to hot inside it and turn it off when the wanted temperature has been reached.
But as I said above my company makes control modules and I am the maintainer of the VSCP project so this could be a reference project for VSCP and our modules. That and to again to get a working fridge in the kitchen therefore became the goal of the project.
So that was the staring point. Join the journey.
Hardware assembly
Old control card
This picture shows the controller card after I removed it. A beeper, a transformer, a potentometer for the set temp, a boost button and some LEDs is all that it is.
As I am rather feed up with changing batteries in units all the time i prefer cables when ever possible. Therefore I decided to draw wires from my office up to the kitchen. I wanted an RJ-45 connector there anyway for Ethernet so I draw CAT-5 cables for that one, and another CAT-5 for the CAN4VSCP bus. Yes I could have used Ethernet for the fridge also of course. But I decided to use CAN4VSCP for demo/test purposes and because it have the advantage of having power included.
Office at the bottom floor and apartment at the top floor. in this old school house.
I live in an old school house (well this picture is old to) so putting in new cables is not a big deal. Just to make more holes in the walls and add more cables. It still is some work of course drilling in 30 cm solid wood walls but as I see it worth the effort it in the end and being an embedded programmer I need the exercise anyway.
Two modules from my company was the perfect choice for this job. The Paris relay controller that can control seven relays and the Kelvin NTC10K that can read six temperatures. Well it’s just one relay to control in this case and the relay I decided to use is a solid state relay that could have been used without the extra driving capabilities of the Paris module but it is really the functionality of the Paris module I am after. Same is true for the Kelvin NTC module. I don’t need the extra temperature measurements this module can offer but as it had the capabilities I decided to put a temperature sensor on the compressor of the fridge to check it for overheating as well and another sensor in the kitchen itself. It is also easy to connect more sensors if/when the need arise.
Testing the modules before mounting them.The Paris relay module to the left and the Kelvin NTC10K to the right with one NTC sensor connected.
All CAN4VSCP modules can be connected together (and be power) over the RJ-45 connector or over the daisy chain connector on the board. In a cabinet the daisy chaining is perfect and convinient. Here the CAN4VSCP cable is drawn from the office which is downstairs in our house. This cable also supply 24V power to the modules and is UPS protected at the source. The modules then are connected together using the daisy chain connector. For more boards one can use the CAN4VSCP power injector but that was not needed in this case with just two modules.
Paris in place and Kelvin NTC10K waiting to be mounted in the control logic part of the fridge.
Next step is t mount the boards in the control logic enclosure where the old control card where installed. I had to remove some plastic fittings for the old board but after that evrything was easy to mount.
Paris firmly mounted with the wall type mounting accessories for CAN4VSCP modules.
The boards my company sells have two mount options. Screw/wall mount or DIN rail mount. In this case I use the screw mount versions.
LED’s and solid state relay
Then it is time to mount the solid state really and some LED’s for status information. The LED’s show that the fridge is on, compressor status and a warning LED for low temperature. The solid state relay is a standard 230V/10A five volt controllable piece. Pretty standard gear.
LED’s, solid state relay and wall mounts for the two CAN4VSCP modules.
Then it was time to connect things together
Connecting things together
and mounting it all on the fridge
Time to drill a hole for the new fridge temperature sensor and mount it remembering to isolate well. The old sensor was mounted with some plastic stuff and I used it for the new one as well.
Then put back the plastic covers of the fridge and put it back in it’s place. Powering it. Yes dead so far. The boards has had not been configured yet so that was just what I expected. To be honest I would have need disappointed if the fridge started to work at this stage.
Connecting things
Drilling drilling drilling, cables, cables, cables till it all is down at the office.
A wall in the office used as test site.
So time to set things up down at the office. A power supply of course. 24V and connected to an UPS so things will work also if the power fails. Two CAN4VSCP modules and a Raspberry Pi is also mounter here on the DIN rail. As you see I expect more modules to be installed here later as the demo project goes on with other parts.
The modules I install here is another Paris relay controller module which I need for some light control. More about that in a later post.
The other module is Frankfurt RS-232 module which connects with the USB to serial converter that comes with it to a Raspberry Pi.
Note that the Raspberry Pi is powered from one of the CAN4VSCP modules. Plenty of juice for that in a CAN4VSCP module.
Software and configuration
On the Raspberry Pi is the VSCP Daemon installed. Instructions for setting it up on the Raspberry Pi is here. I use a read only file system to make things stable as documented on the linked page. The risk one face otherwise is a corrupted SD card when power fails which happens also when an UPS is used as in this case when disconnecting cables etc. I can really recommend that approach.
The Raspberry Pi is just used as a link between the CAN4VSCP bus and TCP/IP. But as documented later in this document it does some other work to. When the Frankfurt Eth board is available I will probably replace both the Raspberry Pi and the Frankfurt RS-232 with it. Time will tell.
The CAN4VSCP driver is used for the Frankfurt RS-232 module. The settings in the VSCP daemon configuration file looks like this
From the config string we can see that /dev/ttyUSB0 is the port used. This is what was assigned or the USB serial adapter. Use
ls /dev/ttyUSB*
to list available adapters. Normally the Frankfurt RS-232 adapter communicate using 11520 baud but the 5 in the configuration string tells that we here use 500000 baud in this setup. Speed is good.
The path to the driver is the standard place on a Linux box after installation of VSCP & Friends.
The flags value of 32 may need an explanation. This is a bit array so it may be easier to see it in binary form which is 0b00100000. That is bit 5 is set. Looking at the driver documentation CAN4VSCP driver we see that this means that hardware handshake should be enabled.
So nothing strange really. All we need to do to get things working is to restart the VSCP daemon with
/etc/initd/vscpd restart
whih will connect things to the world or to our local net.
But before doing that we can use the diagnostic feature of the Frankfurt RS-232 and see if we can see all modules on the bus. We can do this by using a terminal program on the Raspberry Pi. I use minicom (sudo apt-get install minicom) for my needs. Starting it with
minicom -b115200 -D/dev/ttyUSB0
will connect to the Frankfurt RS-232. If we issue
open
the connection to the CAN4VSCP bus will open. Issue
scan
to scan for available devices on the CAN4VSCP bus. In my case I got
I can see that I have the Kelvin NTC10K module at nickname = 1 and two Paris relay modules at nickname =2 and nickname = 3. The question is which module is which of the two Paris modules. The easiest way to determine this is to push the init. button on one of the devices which will make it go through the nickname discovery process and at the end show it’s discovered nickname. I used that method and found the the node with nickname=3 is the one installed in the fridge and the one with nickname=2 is the one installed in the office. I can change this of course but it really did not matter in this case.
A reader that is on his/hers toes notice that the GUID’s for two nodes are set to all FF’s which is wrong and not unique at all. I had to fix that at this stage. The reason was that I use nodes that are left overs from production and a GUID had never been set on these modules.
Knowing that the nodes are reachable and working makes things easier (and me happier). I restarted the VSCP daemon on the Raspberry Pi and could then do the rest of the configuration work on my desktop computer over TCP/IP and using VSCP works.
To setup VSCP for this task is easy. Use any Windows or Linux computer. I use Linux in this sample as that is my main working system.
Using VSCP Works t he first one has to do is to configure how we want to talk to the devices. There is two possible ways to do this. One is to talk directly to the driver. This means it must be connected to the computer on which you are located. So if we had the Frankfurt RS-232 connected to this computer we could have configured the CAN4VSCP driver in VSCP Works to connect to it and to the CAN4VSCP bus.
In this case the Frankfurt RS-232 is connected to a VSCP daemon on a remote device and this is the other way we can connect to it. So ee connect to it over TCP/IP and via the VSCP daemon on the Raspberry Pi. This works if the remote device is in another room as in my office or equally well if it where located on the other side of the earth. SSL is available for protection.
The configuration looks like this in VSCP Works
Basically the settings is the name we want to give this connection. The ip-address of the daemon and the port which usually is the VSCP assigned one (9598). Username and password and interface name. The interface name is important. You select it by choosing one of the available interfaces from the list you get when you click on the “Get Interface” button. This tells which interface you want to talk to on the remote daemon. After this is done you can connect to this location with all the tools available in VSCP Works.
The interface is important because we use nickname to talk to devices on a bus when usinge VSCP Level I. Many interfaces can be conected on a VSCP daemon and therefore the same nicknames will be present on multiple interfaces. In VSCP Level II where the full GUID is used this is no problem of course.
I can now use the configuration interface of VSCP Works and set register 3 to one. This will start the compressor of the fridge. And it did so it works. But we need to automate this. Making an autonomous system of it. This is one of the great advantages of VSCP. The possibility to leave out a central computer and by that a central point of failure. When things are configured a group of modules just work.
Configuring the Kelvin NTC10K
As the Paris relay module is dependent on the Kelvin NTC10K module for it’s work it was best to start to configure this module.
We want this module to send out temperature values with a certain interval so we can log temperature data. We also want it to send CLASS1.CONTROL, TurnOn events when the temperature is higher than a l high set point and CLASS1.CONTROL,TurnOff events when the temperature in the fridge is lower than a low set point.
Temperature sensors are connected like this
- Sensor 0: On board temperature.
- Sensor 1: Fridge temperature.
- Sensor 2: Compressor temperature.
- Sensor 3: Currently not used.
- Sensor 4: Temperature in kitchen.
- Sensor 5: Currently not used.
The compressor temperature should be reported with 10 second intervals. So we configure that by setting register 0x16 to 10 (0x0A). That is all we need to do for that sensor.
We do the same for the kitchen room temperature by writing 10 to register 0x18 so it also is reported every ten seconds.
And then we do the same thing for the fridge temperature by setting register 0x15 to 10.
This is all we have to do to get a system that report temperatures every ten seconds. In the picture above we see the sensor value for the fridge (-20.86 degrees Celsius). We can change the unit to Fahrenheit or Kelvin if we prefer that instead of the default degrees Celsius. For a logging system this is all we need to configure.
But this system should do more and for sensor 1, the fridge temperature sensor, we need to configure some more registers to get the functionality we wanted as of above.
We get the requested functionality by writing 0xB9 to register 3 which is the control register for sensor 1. 0xB9 is 0b10111001 in binary. An the functionality we set is
- 0b10111001 – Bit 0/1 – Report temperature in degrees Celsius.
- 0b10111001 – Bit 2 – Reserved not used.
- 0b10111001 – Bit 3 – Enable low alarm.
- 0b10111001 – Bit 4 – Enable high alarm.
- 0b10111001 – Bit 5 – Send TurnOn/TurnOff events instead of alarm.
- 0b10111001 – Bit 6 – Don’t invert meaning,
- 0b10111001 – Bit 7 – Continuous alarm.
The enable of alarms (Bit 3/4) makes it possible to get alarms when temperature goes over or below set points. Normally an alarm event is sent out and alarm bits set in the alarm register. It is however possible to get TurnOn/TurnOff events sent out instead at the alarm points. This is configured by setting Bit 5 to one.
Last Bit 7 is set to one which makes the alarm or in this case TurnOn/TurnOff being repeated very second as long as the condition is valid. This can be good to use as a precaution for communication errors.
There is no need with alarm points without setting them so we set the low alarm point by writing 0xff to register 0x34 and 0xFB to register 0x35 which is the 16-bit register for the low alarm point in degrees. This is equal to -21 degrees Celsius which is the lowest temperature we want the fridge to have.
We also write the high alarm point by writing 0xFF to register 0x40 and 0xED to register 0x41. This is equal to -19 degrees which then is the highest temperature we accept.
We should note here also that there is a hysteresis value for alarms that default to two degrees. That is an alarm condition is valid until the temperature goes either above the low set point with that amount or below the high set point with that amount. This is why the low and the high temperature set points are two degrees apart. It is possible to set them further apart but always equal to more the the configures hysteresis.
So what have we accomplished here now?
- If the temperature is higher than -21 degrees Celsius continuous TurnOn events (one very second) will be sent out until the temperature has reached -21 degrees Celsius.
- When the temperature goes below -21 degrees Celsius continuous TurnOff events (one every second) will be sent our until it goes up to -19 degrees Celsius.
- We get temperature events sent out every ten seconds telling the actual temperature for three sensors.
Before we start to configure the Paris relay module we need to configure one more thing.
When events are sent all of them except CLASS1.PROTOCOL is sent without a destination address. The receiver decides if it is interested in the event or not. As a means of grouping things together zones and subzones can be used. They are both 8-bit identifiers that define a zone and a subzone within that zone. Its good to set up a schema for a specific setup and here in my house I use the following
- The zone is divided into two 4-bit parts. The high part is the floor plane. 0=cellar, 1=office, 2=Apartment, 3=Attic, 4=Garage…
- The rooms is then coded into the lower four bits of the zone.
- A zone=255 always mean all zones.
- Subzone is used for specific group of things in a room that needs to be grouped or be identified. A sunzone=255 always mean all subzones.
So the fridge, which is at in the apartment, the zone is 0x22 as the kitchen is coded as 2 and the fridges s set to subzone=1.
So we program that in for the sensors as well. Register 0x4D holds the zone for sensor 1 and register 9x4D holds the subzone. We use the same setting for the other sensors as well but it really only matters at this point for sensor 1.
We used the default NTC 10K sensor with this setup so the B value for the sensors are already set. If we have used another sensor we needed to code this value for all sensors as well. For best precision we also could have programmed a calibration value but a fault of about one degree is OK in this setup. Information about all Kelvin NTC10K registers is available in the manual.
Configuring the Paris relay module
The Paris module has one task to perform. It should turn on the relay when told to do so and turn it of when told to do that. Simple enough. With a server in the system it could have written a one in register 3 of the module to turn on the compressor when the temperature was to high and turn it of by writing a zero into register 3 when the set temp is reached. But we want this to work in an autonomous way without a server so we need to set this up.
We again start with the control register for relay 1 which is connected to the solid state relay which driver the compressor. This is register 0x0B and the default value is actually OK here so it is no need to change it but we go through the bits and there meaning anyway. The full Paris relay controller manual is here.
The programmed byte is 0x98 which in binary is 0b10011000 and have the following meaning.
- 0b10011000Bit 0 – Set to zero no pulse output activated.
- 0b10011000 Bit 1 – Set to zero so no alarm. The protection timer is not used anyway in this sample.
- 0b10011000 Bit 2 – Set to zero meaning protection timer is disabled. This timer can be used to automatically turn of a relay after a configurable time and optionally send an alarm when doing so.
- 0b10011000 Bit 3 – Set to one so an CLASS1.INFORMATION, ON-event will be sent when the relay is activated.
- 0b10011000 Bit 4 – Set to one so an CLASS1.INFORMATION, OFF-event will be sent when the relay is deactivated.
- 0b10011000 Bit 5 – Set to zero no CLASS1.INFORMATION, Start-event is sent.
- 0b10011000 Bit 6 – Set to zero no CLASS1.INFORMATION, Stop-event is sent.
- 0b10011000 Bit 7 – Set to one which enables functionality.
The only interesting for us here is that we get confirmation events when relays are activated/deactivated.
We set zone/subzone info here also just as we did for the Kelvin NTC10K. Again we use zone=0x22 and subzone=1 which groups the two modules together, saying this is events belonging to the fridge in the kitchen on the apartment floor.
But still nothing happens. The Paris relay module will just disregard the TurnOn/TurnOff events sent out from the Kelvin NTC 10K.
The solution is to program the Decision Matrix (DM) of the Paris module. This matrix is a event-decision-action matrix. That is when an event is received, a decision is made if it is useful and if so a specified action is performed. Every VSCP module with a DM implemented have a series of well defined actions specified. So what we need to do is to program what should happen when the TurnOn event is received from the Kelvin NTC10K module and likewise what should happen when the TurnOff event is received.
In this case the task is straight forward.
- TurnOn received: We need to activate the relay.
- TurnOff received: We need to deactivate the relay.
The tool to use is as always VSCP Works and the configuration view and the Decision Matrix tab. Double clicking a row here makes it possible to edit the row
The first row is used to turn on the relay. We specify that the zone and the subzone should be the same as we programmed for both of the modules (zone=22/subzone=1) by selecting that zone and subzone should be checked. In the class mask and filter we set the class mask to 0xff meaning all bits of the class filter are valid. Then we set the class id for the TurnOn event into class filter which is 0x1E. This means that when a CLASS1.CONTROL(x1E), Type=TurnOn(0x05) event with zone=0x22 and subzone 0x01 is received the action we choose here will be performed. In this case we want it to activate relay one which is the second relay channel, that is bit 2. So we select “Activate relay(s)” for action and put 0x02 as action parameter meaning relay 1 (bit 1 is set) using zero offset.
We know do the same thing on the second DM row but now trigger on TurnOff which is CLASS1.CONTROL(0x1E), Type=TrunOff(0x06), And we select “Deactivate relays(s)” as action instead.
That’s it. We have now created our autonomous fridge control.
In the above picture we see how things looks like in the working system when the temperature inside the fridge is below -21 degrees Celsius. The Kelvin NTC 10K send the TurnOn event every second and the Paris relay node replies with an ON-event for all of them indicating it has done the requested relay activation. Most of the time the relay is already on but if it was not it would have been turned on. With ten second intervals temperature events for the sensor are sent and highlighted here is the fridge sensor which is at this point is about -20 degrees Celsius.
This picture show the events when the temperature has been reached. And this is therefore the message stream that will be visible until the high set point has been reached. Here TurnOff events are sent every second from the Kelvin NTC10K module and the Paris relay module respond with an OFF event when the relays has been turned off or is already off.
Extensions is alarms such as sounding an alarm when the fridge temperature goes above a certain value and/or sending an SMS informing of the condition. I will come back to these extensions later in another post.
If you want to look at the register content or copy it to your own modules the register files for the sample are here
The easiest way to view the files is to open an empty configuration session and load the file there.
Logging data
It may be useful to log data into a database or similar for later use. Here I use a MySQL database located in the cloud for this purpose. It can be a local database equally well of course.
One way to do this is to use the VSCP helper lib with your favourite programming language and write some code that performs this. It is usually just a few lines of code for a simple task like this.
Another way is to use the capabilities of the internal decision matrix of the VSCP daemon. This is a more powerful decision matrix than the simple one that is available on low end VSCP modules. It however works mostly the same as every event received by the VSCP daemon is feed through this matrix and is able to perform an action when it matches some criteria.
The decision matrix of the VSCP daemon can be edited in the configuration file/dm.xml file which resides in /srv/vscp on Linux (ProgramData\vscp on windows) or it can be edited in the web interface of the VSCP daemon which is at http://ip-address:8080/vscp. The web interface is the easiest way to use IMO. If you edit the dm.xml file directly remember to restart the VSCP daemon so that the new file is read.
This is how the DM row look like to log data to an external MySQL database with a database structure defined as below
The table definition can be downloaded here with 200 sample records.
The action used in this case is 0x10 which executes an external program on the machine where the VSCP Daemon is installed.
In the web interface the DM list looks like this
If we click on this we get the content for this DM row
If we walk through the parts of it
- groupid – This is any textual id you want to use to group a number of rows together. It is mainly intended for use by external applications that work with the DM.
- priority – Let you set a specific priority you are interested in. The left part is the priority and the right part (blue) is the mask. The mask tells what bits in the left column that is of interest. Set to zero (default) if non is interesting or 0xFF if all is interesting. Here we do not care about the priority and therefore set the mask to zero meaning events with all priorities will trigger this row condition.
- class we recognize from the DM in the decision matrix of the modules. Again the left part is the class and the right part (blue) is the mask. The main difference here is that the class is a 16-bit number. If you are interested in events of a specific class enter the class in the left field and set the mask to 0xFFFF (default). If you are interested in events of all classes set the mask to zero (don’t care). Here we are only interested in CLASS1.MEASUREMENT which is coded as 10.
- type we also recognize from the DM of the lower end modules. Again it is 16-bit here. If you are interested in events of a specific type enter the type in the left field and set the mask to 0xFFFF (default). If you are interested in events of all types set the mask to zero (don’t care). Here we are only interested in CLASS1.MEASUREMENT, Type=6, Temperature which is coded as 6.
- GUID – The nickname we saw earlier is just that, a nickname for a full GUID. The nickname is there to save bandwidth so the full GUID does not have to be used. Every node have a GUID and also every interface of the VSCP daemon gor one. In the case of an interface the nickname will be repeated in the LSB byte of the GUID and we see here that the GUID LSB is set to 1 which was the nickname for our Kelvin NTC 10K node and the corresponding mask is set to 0xFF with all other bytes set to zero. So all events from modules with nickname = 1 will be fulfilling this requirement. This is OK as we just have one interface on the test machine but we would have needed to check more bytes of the GUID in a real world scenario where there was more interfaces used.
- Index – Here we can check for the content of the first data byte of an event or check the measurement sensor index. In this case we don’t need this check. Corresponding control checkbox must be checked for the check to be performed.
- Zone – Here we can accept only events with zone set to a specific value. We don’t use this in this example. Corresponding control checkbox must be checked for the check to be performed.
- Subzone – Here we can accept only events with subzone set to a specific value. We don’t use this in this example. Corresponding control checkbox must be checked for the check to be performed.
- Control checkboxes – You can enable the DM row here, you can tell the parsing mechanism that this is the last row that should be checked which can be good for certain debugging. You can also enable check index, check zone and check subzone here. If check index is checked together with the “Use measurement index” to the right of the index input field the measurement index is used for the compare instead of the index byte (byte 0) of the data.
- Allowed from – is the time from which the action is allowed to occur. The format is YY-MM-DD HH:MM:SS. In the web interface ‘*’ can be entered to mean “beginning of time” or any date far back in time.
- Allowed to – This is the end time up to which the action is allowed to occur. The format is YY-MM-DD HH:MM:SS. In the web interface ‘*’ can be entered to mean “end of time” or any date far in the future.
- Allowed Time – This makes it possible to make actions happen every ten minutes etc etc. See the documentation for full info. All times is *-*-* *:*:* As an example *-*-* *:*:0/10/20/30/40/50 will allow he action to occur every ten seconds.
- Allowed day – Days when the action is allowed to occur. Here every day.
- Action – Is the action to perform. There are many available. See the documentation. Here we execute an external program.
- Action Parameter – What is entered in this fields depends on the chosen action. For execute external program the command to execute and parameters for that command is entered. Here we call the mysql client.
- Comment – Here a comment about the DM row can be entered.
Lets look a bit closer at the action parameter. Most of it is pure SQL and we will not go through that. But we have some items with a percent in front of them that are of interest. When action parameters are feed to the DM certain keywords (words starting with %) will be replaced by something else (they are escapes). In our expression we have
- %event.guid – Which will be replaced by the full GUID of the event that triggered this action.
- %measurement.index – Which will be replaced by the measurement index of the sensor that triggered this action.
- %isodate – Will be replaced by the current date on the form YY-MM_DD
- %isotime – Will be replaced by the current time on the form HH:MM:SS
- %measurement.float – Will be replaced by the measurement value as a floating point value.
There are of course a lot of other escapes available. The full list is here.
I think you understand what will happen. Real floating point values will be written into the database with real date/time stamps and GUID and sensor index to identify the sensor that originated the measurement.
I hope its also clear that if you have an executable that can control something you will be able to control that ‘thing’ with the VSCP daemon.
Sending data to the cloud – method one.
ThingSpeak is a popular and free cloud service for visualisation and handling of measurement data. There are probably about ten thousand more services like it. Search. You can use ThingSpeak to, among other things, show real time diagrams of your data.
This is how it looks for the sensors from the fridge. Lets go through each of them before we explain how to generate them
The first diagram is data from the Kitchen temperature sensor, that is temperature sensor 4 of the Kelvin NTC 10K board.
The second diagram is the fridge temperature. That is data from temperature sensor 1 of the Kelvin NTC10K. We see that it works as expected and stays in the interval -21 — -19 degrees Celsius.
The third diagram is the compressor temperature. That is temperature sensor 2 of the Kelvin NTC10K.
The fourth diagram just shows when the fridge compressor is on or off over time.
Sending data to ThingSpeak can be done using HTTP POST or HTTP GET. The syntax for GET’s are
GET https://api.thingspeak.com/update?api_key=xxxxxxxxxxxxxxxx&field1=0
and for POST’s
POST https://api.thingspeak.com/update.json api_key=xxxxxxxxxxxxxxxx field1=73
xxxxxxxxxxxxxxxx is a key you get from ThingSpeak when you create a channel.
We will use POST in this sample.
Curl is a program that can be used to send HTTP data and is which is quite easy to understand and use so I decided to use it for this demo.
To do what we need we issue a command like this in curl
curl –request POST –header “X-THINGSPEAKAPIKEY: xxxxxxxxxxxxxxxx” –data “field1=20.5” “http://api.thingspeak.com/update”
which will update field1 with the value 20.5 using the current date/time.
To be able to handle all sensors with one external command I made a script thingspeak.sh that looks like this
#!/bin/sh
# 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.com/update”)
echo “Update #$update”
You can download this script here. Remember to make the script runnable before using it (sudo chmod a+x thingspeak.sh).
The script takes three parameters
- $1 – This is the TingSpeak key.
- $2 – This is the field number to update. 1,2,3,4…
- $3 – This is the value to write into the field.
All we have to do now is to add the rows to the decision matrix of the VSCP daemon that call this scripts when temperature events are received.
<row enable=”true” groupid=”” >
<mask priority=”0″ class=”0″ type=”65535″ GUID=” 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:FF” > </mask>
<filter priority=”0″ class=”10″ type=”6″ GUID=” 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01″ > </filter>
<control>0x20</control>
<action>0x10</action>
<param>/srv/vscp/thingspeak.sh xxxxxxxxxxxxxxxxxxx 1 %measurement.string
<comment>Send value for Room temperature</comment>
<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 bMeasurement=”true” > 4</index>
<zone>0</zone>
<subzone>0</subzone>
</row>
This row update field1 and is thus the event from the sensor that measure the kitchen temperature.
<row enable=”true” groupid=”” >
<mask priority=”0″ class=”65535″ type=”65535″ GUID=” 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:FF” > </mask>
<filter priority=”0″ class=”10″ type=”6″ GUID=” 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01″ > </filter>
<control>0x20</control>
<action>0x10</action>
<param>/srv/vscp/thingspeak.sh xxxxxxxxxxxxxxxxxxx 2 %measurement.string
<comment>Send vaule for fridge temperature</comment>
<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 bMeasurement=”true” > 1</index>
<zone>0</zone>
<subzone>0</subzone>
</row>
This row update field2 and is thus the event from the sensor that measure the fridge temperature.
<row enable=”true” groupid=”” >
<mask priority=”0″ class=”0″ type=”65535″ GUID=” 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:FF” > </mask>
<filter priority=”0″ class=”10″ type=”6″ GUID=” 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01″ > </filter>
<control>0x20</control>
<action>0x10</action>
<param>/srv/vscp/thingspeak.sh xxxxxxxxxxxxxxxxx 1 %measurement.string
<comment>Send value for Room temperature</comment>
<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 bMeasurement=”true” > 4</index>
<zone>0</zone>
<subzone>0</subzone>
</row>
This row update field3 and is thus the event from the sensor that measure the compressor temperature.
For the compressor on/off diagram we need two Decision matrix rows.
<row enable=”true” groupid=”” >
<mask priority=”0″ class=”65535″ type=”65535″ GUID=” 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:FF” > </mask>
<filter priority=”0″ class=”20″ type=”3″ GUID=” 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:03″ > </filter>
<control>0x18</control>
<action>0x10</action>
<param>/srv/vscp/thingspeak.sh xxxxxxxxxxxxxxxxx 4 1</param>
<comment>Record compressor ON</comment>
<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 bMeasurement=”false” > 0</index>
<zone>34</zone>
<subzone>1</subzone>
</row>
The first row records ON events received from the Paris relay module and writes a one to filed4 when they are received. That is whene the compressor is active.
<row enable=”true” groupid=”” >
<mask priority=”0″ class=”65535″ type=”65535″ GUID=” 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:FF” > </mask>
<filter priority=”0″ class=”20″ type=”4″ GUID=” 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:03″ > </filter>
<control>0x18</control>
<action>0x10</action>
<param>/srv/vscp/thingspeak.sh xxxxxxxxxxxxxxxxx 4 0</param>
<comment>Record compressor OFF</comment>
<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 bMeasurement=”false” > 0</index>
<zone>34</zone>
<subzone>1</subzone>
</row>
The second row records OFF events received from the Paris relay module and writes a zero to filed4 when they are received. That is when the compressor is inactive.
That’s it. Not so complicated is it? You can use this method for most other cloud services as well.
Sending data to the cloud – method two.
As we wrote earlier the VSCP daemon have many more actions available than the execute external program we have used so far. One that is perfectly suited for sending data to a cloud service is the HTTP GET,POST,PUT action.
If you follow the link you will find two examples. The first use POST to update a field on ThingSpeak and the second use GET.
What method you chose is much a matter of preference.
Sending timed data using variables
If you look at the sample above you have learned that we can do timed actions as well using the VSCP daemon decision matrix. That is running an action every minute, very second or every hour or whatever. That is mor or less just like cron on a Unix/Linux system. This is possible using the internal events of the VSCP daemon. The events in this class is feed into the DM on regular intervals or when special things occurs.
So if we want to send data to a cloud service every minute we can trigger on the CLASS2.VSCPD, Type=6, Minute event. This event is generated once every minute. Now if we want to send updates to the cloud service every minute we have a problem if the sensor, as for the fridge in this example, updates every ten seconds.
The solution is to firts write the sensor value to a variable when the temperature event is received.
<row enable=”true” groupid=”” >
<mask priority=”0″ class=”65535″ type=”65535″ GUID=” 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:FF” > </mask>
<filter priority=”0″ class=”10″ type=”6″ GUID=” 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:01″ > </filter>
<control>0x20</control>
<action>0x50</action>
<param>fridgetemp;float;false;%meaurement.float</param>
<comment>Store fridge temperature in variable</comment>
<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 bMeasurement=”true” > 1</index>
<zone>0</zone>
<subzone>0</subzone>
</row>
This is how this looks for the fridge temperature sensor. Action is 0x50 which is “store in variable”. This action is documented here. According to the documentation the action parameter format is
name-of-variable;variable-type;persistence;value
So we can create/write a variable fridgetemp with
fridgetemp;FLOAT;false;%meaurement.float
That is the floating point measurement value is written to the non persistent floating point variable “fridgetemp” every time the temperature event from sensor 1 of the Kelvin NTC10K sensor in the fridge is received. We can use this variable from other programs.
Now all we have to do is to send this variable to the cloud service every minute.
<row enable="true" groupid="" > <mask priority="0" class="65535" type="65535" GUID=" 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00" > </mask> <filter priority="0" class="65535" type="6" GUID=" 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00" > </filter> <control>0x0</control> <action>0x75</action> <param>POST;http://api.thingspeak.com/update;field1=%variable:fridgetemp;X-THINGSPEAKAPIKEY: xxxxxxxxxxxxxxxx\n</param> <comment></comment> <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 bMeasurement="false" > 0</index> <zone>0</zone> <subzone>0</subzone> </row>
The new item here is the escape
field1=%variable:fridgetemp
where %variable:fridgetemp is replaced by the content in the variable fridgetemp.
VSCP has it’s own functionality for tables and diagrams. We will continue this demo with some samples of this functionality on a later time.
To be continued…
Hope you found this writeup useful.
/Ake
Paradise of the Frog AB
