Introduction

The Voltcraft CO-100 displays temperature, relative humidity and CO2 levels in the house. It has adjustable alarm levels for CO2 which, when exceeded, illuminate an orange or red LED on the front and optionally a beep alarm. It also has a datalogger that keeps historic data for 24 hours.

But what's the use of a datalogger if you have to be near the device and press some buttons to see the values?

I decided to look into the possibilities of reading the data directly from the device and store it in my Domoticz home domotica system so that the history would be available online in graph form.

Some time ago I published about the old clock I have which uses the mains ('grid') frequency as its timebase. There were some timing issues which I though I had ironed out, but it's still running fast.

It is widely accepted that the mains frequency is not a very accurate timebase for synchronous clocks, but over a long period of time the average frequency is 50 Hz, and good enough for a coarse clock like this. However, it is a couple of minutes fast in a week, and that I am not willing to attribute to mains frequency fluctuations.

First I thought it might be interference from household appliances, so I put a ferrite core around the mains cable close to the electronics. Didn't work.

So I decided to start a small Arduino project to measure the grid frequency and calculate the lead/lag over a longer period of time, to prove that the problem is somewhere in the clock's electronics. I would need an application to show me:

the mains frequency over the 20 seconds

the uptime of the application (i.e. the number of hours/days/minutes it is running)

When I learned that the new heating appliance I had installed in my home communicates with the room thermostat using an actual protocol (as opposed to 'switch on'/'switch off' commands) I became very interested in finding out if it would be possible to listen in on those communications and do interesting stuff with it.

The protocol in question is called OpenTherm (TM). From the OpenTherm website: "OpenTherm is the name of a non-manufacturer-dependent system of communication between modulating HVAC heating appliances and room thermostats. The system consists of a communication protocol and an interface specification. OpenTherm is futuristic system, which combines simple installation techniques with high functionality and future expansion possibilities.".

It seemed that nobody in the Arduino community had tried to read it yet, so that made it an interesting challenge.

I bought a couple of cheap micro servos for a future Arduino project. They are impressively small (I think) whilst still delivering the torque that I require. Two are packaged in a blister pack, together with some extra servo arms and -screws.

They're called "Dynam 7g micro servo", model number DY-1002, and the specs are:

Servos are controlled using pulse width modulation. Others described very eloquently and in great detail how this works, so I won't go into that, except for one thing, which is the point of this article: you need to know the two pulse width values that correspond to the minimum and maximum angle that the servo can be set to.

I wanted to capture the splash that objects make the moment they fall into a liquid, but this is pretty hard to do if you have to operate the shutter release by yourself: you need a lot of luck to capture the right moment, and a lot of time trying to.

The drop from the point where the object is released till the surface of the liquid or the point where it has to cross the lens, is in this case about forty centimetres (16") and only takes a few hundred milliseconds. You'd have to take into account the delay of the camera, the available light, etcetera.

I figured I needed some electronic assistance. So I took to the drawing board and used a combination of hardware and software to help me out.