Category Archives: VSCP

Refrigerator control Part 3 #VSCP #IoT #m2m

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.

#VSCP Register Abstraction Model (VSCP-RAM)

The single most important part of a VSCP system is the Register Abstraction Model.  With it you can describe anything that are real (or even not real) in this universe.  Quite a piece of a powerful super tool to have in your arsenal.

In the IoT world people often say that MQTT,  CoAP,  etc is IoT servers/protocols. For me they are transport mechanisms. Good ones, at least in the case of MQTT.  Useful for IoT? Yes. But IoT severs no?

Now what!?

To explain my point. Look at a web server. It serve content using the HTTP protocol. Simple enough. Works good. Quite similar to MQTT in fact.

But…

this was not the reason the world-wide web was a success.  If everyone started to serve different non standardized content with the http protocol it would have been a mess of it all. Very hard to cope with for the web readers at least.  Yes, it would have been useless. Well this was more or less the case also pre HTML.  But what HTML did was to specify a common format for the content. That was the killer that made everything moving. Not the web server which is just the transport mechanism just as MQTT and others are in IoT.

VSCP try to be more than a transport mechanism for m2m and IoT. A common way to look at and handle “things”.  (yes MQTT can transport it just as CoAP and others can)

In the picture above is a view on how VSCP look at a “thing“.  A “thing“can be a TV,  a refrigerator,  a car,  a lamp,  a human or whatever. Everything can be described in this way. Yes, everything. Hardware as well as software or a some abstract non existing life form. ANYTHING is the world.

To describe anything is of course not a problem. One just describe the anything in a way that comes up in one’s mind. So if we ask 999 people to describe the anything object there will be 999 different descriptions. That is actually OK. The problem is rather that there will be 999 different ways to interpret the descriptions of the anything. Hard work.

If we instead came up with a common way to look at the anything,  an abstraction of it,  we could all use that abstraction to describe every the anything and after that we do not need to come up with so many new ways to interpret the descriptions nor ways to interact with the anythings of the world. We could even use this abstraction on top of any of the 999 description from above as it is useful for describing anything. Good if we love our “description” and don’t want to throw away our lovely description and interpretation of it.

Of course, the abstraction would be most useful if it was available for a high-end system or user as well as for low-end system or user.  Low end can actually be really  low-end.  So we better start there.  But a high-end user or system demands handling of great complex things so we need to take this into account as well.

VSCP solve this in the following way

  • Everything can be described by a collection of  8-bit registers.
  • To know whats inside an 8-bit register you need the ability to read it.
  • To change the content of an 8-bit register you need the ability to write it.

So VSCP can describe everything in the universe,  yes everything from a flower,  a person,  a car or anything else with a set of 8-bit registers. The only thing needed to interact with the resister set is that registers can be read and written.

So

  • Read a byte.
  • Write a byte.

is all that is needed for  VSCP to work with “anything” on its lowest level.

In VSCP this is called the Register Abstraction Model.

VSCP’s register abstraction model demands that all “anything” objects have a set of registers that contain specific information. Same on all. The two most important parts is GUID, ett globally unique id  a 16 byte world unique if for “the anything“,  and a 32-byte area which contains a pointer to a  Module Description File.  The GUID identifies “the anything” much the same way as an Ethernet MAC does for Ethernet device.  They can actually be coupled. The MDF pointer can point at a local location or to a file on the Internet. The content is a well-defined XML description of “the anything”.

One thing that is described is of course the registers of “the anything“.  But to handle things on a register level can be to hard sometimes. For instance is a floating point value stored in eight registers. If this floating point value for instance represent a temperature of “the anything”  and this is what the application or user is interested in there should be no need to know how it is actually stored on “the anything“.

So to make life easier for high-end systems or users the MDF often also contains abstractions. Abstractions specify higher end type such as strings, floats, integers, booleans and tell in what registers they are stored and also how many bytes they use.  So a high en user just handle these higher end objects, reading and writing them,  even if the system still only read and write bytes.

Both registers and abstractions describe the same “anything“,  just on different levels.

At this point it would be possible to build an application that can configure any device, “anything“,  just by read/write byte operations and by reading and interpreting the MDF of the unit. The user (or machine) just fill in the values. The same application can be used to configure a car,  a TV,  a clock radio etc.

The MDF can also contain wizards. A wizard can guide a human user, step by step through a specific setup of a device. They are also described in an abstract way and can be interpreted by C/C++, JavaScript and other higher end programing languages alike.  So it is as easy to make an app. that goes through the wizard steps as it is to make an HTML page that do the same.

It is of course possible to use XML/JSON on the higher level to “set register/abstractions”.  A read and a write byte operation is still all that is needed.

The fact is that the register abstraction model is so light weight that it easily can live alongside a more proprietary solution

But way?

That you have to think about yourself… ,-)

ps VSCP is of course a lot more than this. There are events, classes/types, bootloaders, decision matrices and a lot of other clever things. ds.

What the heck…. #VSCP #IoT #m2m

I will probably starve to death doing this but  the following hardware modules will be open source again.

can4vscp_accra – Counter module.
can4vscp_sanfrancisco_barometer  – Barometer module.
can4vscp_humidity – humidity and temperature
can4vscp_beijing – I/O- module.
can4vscp_vilnius – AD- module.
can4vscp_odessa – Expansion module.
can4vscp_kelvin_1wire – 1-wire temperature module.
can4vscp_frankfurt_rs232 – RS-232 interface to CAN4VSCP
can4vscp_frankfurt_gprs – GPRS interface to CAN4VSCÅ
can4vscp_newyork_lcd_display_controller – Display controller
can4vscp_frankfurt_eth – Ethernet <->CAN4VSCP
zeus_expansion_roma – Ethernet controller.
zeus_expansion_moscow
can4vscp_power_injector
zeus
zeus_expansion_napoli
zeus_expansion_leicester
zeus_expansion_kiev
zeus_expansion_budapest
zeus_expansion_brussels
blitz
thunder
can4vscp_frankfurt_ble
can4vscp_frankfurt_bridge CAN4VSCP <-> CAN4VSCP
can4vscp_frankfurt_rs485 RS485 <-> CAN4VSCP
can4vscp_frankfurt_usb  USB <-> CAN4VSCP
can4vscp_kelvin_9700
can4vscp_kelvin_multisensor
can4vscp_kelvin_smt160
can4vscp_kelvin_thermocouple
can4vscp_Loos_temp_control

 

Closing source for hardware modules ##VSCP #IoT #m2m

The following hardware modules will be closed source from today

can4vscp_accra – Counter module.
can4vscp_sanfrancisco_barometer  – Barometer module.
can4vscp_humidity – humidity and temperature module.can4vscp_beijing – I/O- module.
can4vscp_vilnius – AD- module.
can4vscp_odessa – Expansion module.
can4vscp_kelvin_1wire – 1-wire temperature module.
can4vscp_frankfurt_rs232 – RS-232 interface to CAN4VSCP
can4vscp_frankfurt_gprs – GPRS interface to CAN4VSCÅ
can4vscp_newyork_lcd_display_controller – Display controller
can4vscp_frankfurt_eth – Ethernet <->CAN4VSCP
zeus_expansion_roma – Ethernet controller.
zeus_expansion_moscow
can4vscp_power_injector
zeus
zeus_expansion_napoli
zeus_expansion_leicester
zeus_expansion_kiev
zeus_expansion_budapest
zeus_expansion_brussels
blitz
thunder
can4vscp_frankfurt_ble
can4vscp_frankfurt_bridge CAN4VSCP <-> CAN4VSCP
can4vscp_frankfurt_rs485 RS485 <-> CAN4VSCP
can4vscp_frankfurt_usb  USB <-> CAN4VSCP
can4vscp_kelvin_9700
can4vscp_kelvin_multisensor
can4vscp_kelvin_smt160
can4vscp_kelvin_thermocouple
can4vscp_Loos_temp_control

Paris and Kelvin NTC will be open and free as before for reference as will one or two RF modules resp.Ethernet modules.

Someone may ask why? The answer is that open source has not been working for these modules and I just don’t want to throw away the 1000h of work I put into them.

Next release of #VSCP #IoT #m2m

It’s been quite some time now since the last release of VSCP & Friends. Sorry to say it will be a few months more until the release is out. Why? Mostly because there is a lot to do and if Google and the likes can do a man year in a week a man year is a man year for someone working alone on a project as I am.  But there is a lot of nice functionality coming so it is hopefully worth the wait.

Of course you can use the head code. But beware that database structures will change still for some time and if you use head code please remove all configuration data including databases so it get built from scratch. This will of course be taken care of automatically when the release is out.

And again of course if someone want to take part in the project (there is many tasks) or sponsor it please let me know.

#JavaScript in decision matrix of #VSCP #IoT #m2m

Now it is possible to use execution of JavaScript as a result from a triggered action in the decision matrix of the VSCP Daemon.  Things that is triggering an action can typically be events from external nodes or internal VSCP daemon generated events.  For example a measurement value can be sent to a remote cloud service or an ON event can enable some special on-board functionality or just toggle a pin on some output. The possibilities are endless.

With the VSCP decision matrix escape functionality dynamic data can be written into the JavaScript before it is executed. This includes the triggering event data as well as environment information.

File, encryption and socket functionality is available from inside the script plus functions to send event, receive events, handle VSCP remote variables, handle measurements and more.

As a script can be stored in a VSCP remote variable it can be externally edited and functionality can therefore be dynamic.

The new functionality is described here.

Callback functions for VSCP functionality is described here.

LUA scripting will be added later making it possible to do slightly more complicated scripting.

Raspberry Pi and 1-wire temperature sensors to VSCP #rpi #iot #1wire

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.

Monitor GPU temp of a Raspberry Pi #rpi #vscp #iot

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.