Category Archives: Modules

Refrigerator project Part 4 #IoT #m2m #VSCP

CAN4VSCP Bejing, CAN4VSCP Kelvin NTC10KA, HowTo's

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.

 

Refrigerator control Part 3 #VSCP #IoT #m2m

CAN4VSCP Bejing, CAN4VSCP Kelvin NTC10KA, CAN4VSCP Paris, HowTo's, VSCP

The refrigerator again. It takes more time then expected of course. It always do. This time because I have a lot of other things to attend to at the moment.  I understand if you ask some questions about this project. So I answer them here (before you actually ask them)

Why this project?

Our refrigerator broke down two weeks ago. And we need one also in my family.  Of course we do, open source programmers may not afford much buying stuff but we also want our milk to be cold.  Luckily it is winter here now and we have some other storage that is at about four/five degrees so it is no immediate panic,  but as weather is getting better (the spring is coming)  this is not a good long-term solution.

When our fridge broke down some years ago I decided to try to rescue it and if it was possible I would take standard VSCP modules to do so.  The compressor was OK and if it is this is a simple  project mostly.  This project has worked perfectly well since then and became a nice VSCP demo project.

Yes, Yes, YES it’s an overkill using VSCP standard modules for this. An Arduino or some other simple board would have done the job. But I wanted to use the modules to see if they did their job also over time. The best way to actually see if things are working the way you thought is to put them in some critical system in your house (the heating in our house is already controlled this way). If there is some bugs or design problems things will be solved by necessity. To have them in a demo system on a workbench is just not the same thing.

So for the refrigerator the first question was to check if the compressor still worked. If it was dead it is just a pieces of junk and not a refrigerator.  But just as with the fridge it was the control logic that had broken also this time. Make me wonder how many perfectly fine refrigerators/fridges are thrown away out there that could have new  control added for a few bucks and do the job they were designed for for many years more.

How?

As with the fridge I decided to go for standard VSCP modules for the refrigerator project to make it a demo project.  It is easier this time as I have the CAN4VSCP bus connected to the fridge that stands next to the refrigerator. I just need to connect the two together.

So I put in a Kelvin NTC10K module and a Bejing I/O module in the refrigerator and hook it up to the CAN4VSCP bus so I am able to monitor temperatures and change temperature settings and get possible alarms from the unit.  As with all VSCP modules they form a self-contained unit.  There is actually no need for a server after they have been configured. The second video here show the configuration process and the first show how the modules are connected together.

The Kelvin NTC 10K module is a module that one can connect a couple of temperature sensors to.  It can be programmed to alarm at low and high temperatures and as in this case turn on and off things when certain temperature thresholds are reached.

In the fridge project a Paris module is used together with the Kelvin NTC module. The Paris module is constructed to control relays and have all the electronics on board to do that. It also include protection timers and a lot more.

In the refrigerator project I decided to use the Beijing module instead of the Paris module. Mostly because it did not matter to have standard I/O channels  as I use a solid state relay to switch on and off the compressor, but my main reason was that  I got a chance to use it in a real life demo system.

So the Kelvin NTC10K module sense the temperature in the refrigerator and the Beijing module is used to switch the compressor on or off and to sense if the refrigerator door is open or not and if it is light the lamp inside the box.

It is possible to  sound s siren if the door to the refrigerator is opened between midnight and six in the morning. But some things just hit you right in the face so I will not implement that functionality. At least not now.

Next?

Connect cables and putting it in the refrigerator where the old control logic was located. No programming is needed just configuration.  The second video above show a bit of this configuration but I will go through it in a more precise way in a future post. Hopefully things will work as thy should tomorrow. The VCSP modules are very flexible and can be used in most control situations to form self-contained systems that can be connected together and be connected to the world in a safe and secure way.

Brewing in the lab. #VSCP #M2M #IoT

CAN4VSCP Kelvin 1-Wire

IMG_1872

In the lab, brewing, the Kelvin 1-wire module.  Four channels times two sensors plus one on board sensor. That is 8 + 1 temperature channels with all the features on the Kelvin NTC10K.  Hopefully, if all goes well (yes it works already but manuals, mdf’s, testing is needed), it will be available in the FrogShop from next week.

I ordered the PCB’s for this module series for almost  1 1/2 years ago. Thinking to much of my ability to finish stuff. One learn. Hardware and firmware and software takes time when you are a small company. The Frankfurt BLE (bluetooth) and the San Francisco (barometer) module  is still left to do in that batch of PCB’s. And many other such as Frankfurt Eth is in the queue.

Conclusion, life is to short…

/Ake

New version 1.2.6 for Kelvin NTC10K

CAN4VSCP Kelvin NTC10KA

kelvin11-500x500

A new version, 1.2.6 of the firmware for Kelvin NTC10K has been released.

2016-03-30 AKHE – Made code work for PIC18F26K80
2016-03-29 AKHE – Raw A/D register values was displayed in wrong order. Fixed.

In the manual the sensor calibration part has been corrected and extended. It previously described the indexed calibration value  version which was present in the first version of the module.

CAN4VSCP module firmware upgrades

CAN4VSCP Accra, CAN4VSCP Bejing, CAN4VSCP Kelvin NTC10KA, CAN4VSCP Odessa, CAN4VSCP Paris, CAN4VSCP Vilnius

power_injector5

Please update your module.

Instructions on how to update the firmware is available in the modules manual.

How to schedule events/schemas with the daemon #Iot #m2m #vscp

CAN4VSCP Paris, the VSCP Daemon

I got the following question from a VSCP users

  • How to turn on lights at sunset.
  • How to turn off the lights at a specified time (either sunset + x hrs, or for example at YY:ZZ).
  • How to turn on at a certain time.
  • How to turn off at sunrise.

So the easiest way to demonstrate this capability of the VSCP daemon  is to show the setup I have here in our house for this. Oh well part of it of course, we should not go to far away from the topic.

Some background

Yes I use VSCP based devices for some things here in the house but just as the shoemakers children have holes in there shoes I am often stuck at fixing things for others before I can do something for myself.  So here it is a lot of  my setups are test setups that are replaced by other test setups that are replaced by even other test setups  etc in a never ending story. Its the just the way it is  for makers I guess.

But some things I use here at least and that is I schedule the lamps in the house so they turn on at sunset and turn off at sunrise and some other things. So the questions above is easily by explaining my own setup.

Now I could have used a Paris module to control lamps and I actually do here in the office but just in a test setup . In our house and for lamps on the  outside I use low cost wireless modules from Nexa and Proove

large

nexa-infalld-fjarrstrombrytare-1000-w

Well you all recognize them. Low cost single way communication modules working over 433 MHz.  Reliable enough for lights IMO. But they could of course equally well have been Z-Wave, KNX, X10 or some other solution.

The CAN4VSCP Roma module will control these things and it sits on my desk at the moment working pretty well. It will be available in the store also one day I hope.

At the moment I us a Tellstick  from Telldus AB to control  lights connected this way. There are other similar products available and Arduino solutions that can do it as well

TellStick_1-600x600_0

Well this solution just let me execute a binary on a Linux machine to turn on/off a group of lamps.  There are similar devices available for all other vertical solutions. So to control KNX units with the VSCP daemon find an executable that can do that and the same for Z-Wave (OpenZwave) or whatever solution you want to integrate. Or write your own script or executable that does it. It is usually not a big deal.

But it of course does not end with an executable. The VSCP daemon can do many other things. Call an URL/send events/start timers etc etc. You can add anything and you should be able to add everything because the world consist and will consist of many different things,

Turn on lights at sunset

So lets look at the first point. This can be done in many ways of course but if you enter the coordinates for your location in the VSCP daemon configuration file  (dm.xml) in the Automation section  the decision matrix will be feed with two events that are of interest for this  type of control

CLASS1.INFORMATION, Type=45, Sunset

Sent when astronomical sunset happens at the location set by the coordinates.

CLASS1.INFORMATION, Type=35, Sunset-Twilight

Sent when astronomical sunset-twilight happens at the location set by the coordinates. The definition of twilight is

Nautical twilight is the period when the center of the Sun is between 6 and 12 degrees below the horizon, when bright stars are still visible in clear weather and the horizon is becoming visible. It is too dark to do outdoor activities without additional lighting.

You have to enable the events also if they are disabled in the configuration file.

Restating the VSCP daemon with

/etc/init.d/vscpd restart

and then opening

http://192.168.1.6:8080/vscp/configure

in your web browser (replacing 192.168.1.6 with your server ip) will show you the calculated times

Screenshot from 2016-01-31 16:17:53

We see that today when this is written the sunset is at 15:57 and the sunset twilight is at 16:44 two times one can use to turn on lights because it’s getting dark outside.

For indoor light I use sunset and for outdoor light I use twilight sunset for this.  It all of course depends on how dark one want it to be before lights are turned on.

So setting this up in the web interface

Screenshot from 2016-01-31 16:25:23

Priority has flags set to zero so we don’t care about it.

Class is set to 20 which is CLASS1.INFORMATION and corresponding  flags are set to 0xFFFF meaning all bits should be checked.

Type is set to 45 which is Sunset and corresponding  flags are set to 0xFFFF meaning all bits should be checked.

GUID has mask all set to zero so we don’t check it.

On control we see that we don’t check index/zone/subzone but that we enable this row.

So at this point we say that events of type   CLASS1.INFORMATION, Type=45, Sunset  will perform what ever action we choose.

Screenshot from 2016-01-31 16:25:37

In the “when-section” we select when the action should happen. Her from the beginning of time to the the end of time and all weekdays and all times.  As you see it is possible to have different schemas for different weekdays and for different time of year.

Screenshot from 2016-01-31 16:25:48

And then we have the action to perform. In my case I execute an external file and turn on lamps in section 1. But there are many actions to choose from and Send Event is one. Typically used in his case to send to a group of Paris modules to instruct them to switch some relays on.

You can have many rows that trigger on the same event and therefore easily mix technology and control KNX, Z-wave, VSCP and other alongside each other.

The XML row for this scenario looks like this

<row enable=”true” groupid=”Tellstick” >
<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=”20″
type=”45″
GUID=” 00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00″ >
</filter>
<control>0x0</control>
<action>0x10</action>
<param>/usr/local/bin/tdtool –on 1
<comment>Turn on window ligts when sun goes down</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>

Turn off at sunrise

To turn off lights at sunrise just trigger on CLASS1.INFORMATION, Type=44, Sunrise or  CLASS1.INFORMATION, Type=52, sunrise twilight time.  The rest is the same as the above case.

Turn off the lights at a specified time

Here in this house I turn of some lights for the night at 02:00 regardless. This is how that is done

Screenshot from 2016-01-31 16:55:11

Priority is not used and therefore it’s corresponding  flags are set to zero.

Class is set t 65535 which is CLASS2.VSCP. The corresponding flags are set to all ones or 0xffff.

Type is set to 6 and that means we will trigger on CLASS2.VSCP, Type=6, Minute events. This event is feed through the matrix every minute. The corresponding flags are set to all ones or 0xffff.

GUID has mask all set to zero so we don’t check it.

On control we see that we don’t check index/zone/subzone but that we enable this row.

Screenshot from 2016-01-31 16:55:30

Again in the “when-section” we select when the action should happen. Her from the beginning of time to the the end of time and all weekdays.  The difference here frm the previous example is the

*-*-* 02:00:00/10/20/30/4/50

The

*-*-*

says the action will be triggered on every date.  If we want a specific thing to happen just on x-as eve we enter that here.

02:00:00/10/20/30/4/50

This part could have just been

02:00:00

meaning trigger at that time. But here we added some more times we now trigger on

02:00:00
02:00:10
02:00:20
02:00:30
02:00:40
02:00:50

that is on several times ten second apart.  A way to enter this without having a new DM row for each. This is possible on all fields in allowed time. So it is easy to do things at certain days of the month etc.

For the curious I did this so lights definitely will be turned off as I had some interference with the radio signal some times.

Screenshot from 2016-01-31 17:12:19

And then again we have the action which in this case turn off section 1 instead of on.

And yes turning on something at a certain time is just the same but with another action and also here one can send events or do other things.

The xml line looks like this

<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>0x10</action>
<param>/usr/local/bin/tdtool –off 1;
<comment>Turn off window lights @ 02:00</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>*-*-* 02:00:00/10/20/30/40/50</allowed_time>
<index  bMeasurement=”false”  > 0</index>
<zone>0</zone>
<subzone>0</subzone>
</row>

 

The future

Time time is a resource that is limited.  When I did the DM of the VSCP daemon a long time ago an external nice and user friendly interface to edit it was planed. Not the web based interface that is available to day which is targeting a technical user.  Actually editing is possible remotely also today so it is only the UX code missing.  That will probably come in place one day. Giving this functionality the attention and usability it deserves.

An even more exciting feature that will come to this functionality, probably in the next release, is scripting right inside the VSCP daemon. That will make this an extremely cool cat.

Hopefully this gave some lights of the magic’s of the VSCP daemon DM.