This (upper cabinet of refrigerator)

and this (lower cabinet of refrigerator)

 

is live data from the refrigerator project described here,  here and here.

First of all, this is quite a complex way to do this, it could have been solved in an easier way. But I wanted to test the modules Grodans Paradis AB made and put them to work.

Two CAN4VSCP based modules has been use for this project. The Kelvin NTC10K module is used to sense temperatures and the Beijing I/O module is  used to turn /on/off the compressor.

Configuration

Kelvin NTC10K

The module is fully describe here.

The Kelvin NTC10K (on nickname = 5) have one thermistor connected to input one which is located in the upper cabinet of the refrigerator and the one thermistor connected to input two which is connected to a sensor that is located in the lower cabinet.  Both has been set to send out temperature every ten seconds

As noted also the on-board sensor send out temperature data, It sends out the data with a longer interval (0x3C = 60) which is once a minute.  This value can be used to sense the room temperature but is always a bit high as the sensor is placed on the pcb. One can adjust this in the sensor calibration registers

Most thermistor needs a calibration and here it can be set with a two complement number that can calibrate a temperature with an accuracy of  two decimals.

If you want temperatures sent to some sort of central server this is actually all you need to configure.  The values will be sent with the set interval. The default unit is degrees Celsius but this can be changed. In our case we also need some other features enabled. This configuration we do in the control registers for each sensor

Temperature Sensor 0 and temperature sensor 2 just send out the temperature with the set interval. They are set to 1 which means they send the temperature in degrees Celsius.

For temperature sensor 1 more features has been enabled. It is configured with 0xB9 which is 10111001 in binary.

As Bit 0/Bit 1 forms 1 the temperature will be presented in degrees Celsius as for the other sensors.

Bit 3 is set so low alarm is enables.

Bit 4 is set so high alarm is enabled.

Bit 5 is set which means that CLASS1.CONTROL, TurnOff events and CLASS1.CONTROL, TurnOn events will be sent instead off CLASS1.ALARM,  Alarm occurred. So an OFF event will be sent when the temperature goes below the low alarm level and an ON event will be sent then the temperature goes above the high alarm level.

Bit 7 is set which means alarm events will be sent continuously, not just when a limit is passed.

For this to work we need to set the low alarm level

which is set to four degrees Celsius. And also the high alarm value

which is set to six degrees.

The hysteresis value is set to two as default and we leave it at that.

So what will happen here?

If the temperature is below four degrees Celsius CLASS1.CONTROL, TurnOff events will be sent out every second. This will continue until the temperature is above the low alarm temperature + the hysteresis, that means at 6 degrees.  When the temperature go over 6 degrees Celsius CLASS1.CONTROL, TurnOn events will be sent out every second until the temperature goes below the set high alarm point minus hysteresis, that means 4 degrees Celsius.

In addition to the TurnOn/TurnOff events the temperatures will also be sent out for us to diagram or collect in a database or do other things with.

Before we setup the Beijing module to handle the TurnOn/TurnOff events we need to mark out TurnOn/TurnOff events so they can be identified to the refrigerator. We can do this with the nickname id (node id) which in this case is set to 5. But this value could be changed if a module is replaced but it can also be good not to use this id for other purposes as well.  So instead we use the zone/subzone. For the Kelvin NTC10K we can set a zone/subzone for each sensor.  And we set

the zone to hex 23 (35 decimal) and the subzone for each temperature sensor to it’s index. So temperature sensor 0 get subzone= 0, sensor 1 get subzone=1 and so on.

There is no magic here. One can set up any number schema one likes.

This is how a temperature event looks like for sensor 1

And this is how a CLASS1.CONTROL, TurnOn event  looks like

Beijing I/O module

The module is fully described here.

The Beijing module can do many things. But as we have a relay that control the compressor of the refrigerator connected to I/O channel we are only interested in configuration of this channel.

The I/O channels of the Beijing module is set as outputs by defaults

We have set bit 1 as an input here for a task we want to go through in this write-up (refrigerator door sensor).

Note also that the nickname (node id) is set to 4.

We also need to match the zone with the one we set for the Kelvin NTC10K (0x23) and also the subzone (0x01) for I/O channel 0 .

That is all we need to configure.

To complete the  task we also need to program the decision matrix of the Beijing module. In this matrix we program what the Beijing should do when certain events is received by the module.

In our case there is the two events from the Kelvin NTC 10K module we are interested in.

If CLASS1.CONTROL, TurnOn is received we want I/O to be turned on or stay on, that is the compressor of the refrigerator should be turned on.

If CLASS1.CONTROL, TurnOff is received we want I/O zero to be turned off or stay off, that is the compressor of the refrigerator should be turned off.

The decision matrix have actions it can perform when an event matches a selection criteria. For us the SET and CLR actions is what we need.

The rest of the actions are described here.

We program the decision matrix like this. One row for each action we want to be carried out

In the first row, which looks like this

we enable the row,  don’t check the originating address as we discussed above, and the originating address is not hardcoded, the zone of the received event should match the zone of the our module (0x23) and the subzone should match that for the channel set in the action parameter (I/O 0 = 0) or the module subzone depending on chosen action.

the class mask tells which bits of the class filter that is of interest. Here all is of interest (0x1FF) and the class filter is set to 0x1E which is 30 and is the code for CLASS1.CONTROL

The type mask tells which bits of the type filter is of interest. Here all is of interest (0xFF) and the type is set to 0x05 which is the code for CLASS1.CONTROL, TurnOn

So if a CLASS1.CONTROL, TurnOn event is received with zone=0x23 and subzone=0x01 the Beijing module will carry out the chosen action. We want I/O 0 to be turned on so the compressor is turned on and the action set output of I/O channel high will do that for us.  This action expects the I/O channel as action parameter so we set it to x00.

So now out CLASS1.CONTROL, TurnON events will turn on the compressor.  The Beijing will confirm the I/O change with a CLASS1.INFORMATION, On event.

The DM row for the CLASS1.CONTROL, TurnOff is then setup in  the same way.

Thats it. We have now made a self contained unit consisting of two modules that can work autonomously.

The cloud

The  fridge project explains how to share the generated data to the cloud.  I will do another write-up about this later. But it’s not more to it then to program the decision matrix of the VSCP daemon to send data to the cloud.  You have live data for this setup here as a sample. This data is on a CAN4VSCP bus in this house and is collected by a Raspberry Pi and is sent up to ThingsSpeak.

VSCP have other means of displaying data and more will come in the next version.