Humidity and Temperature sensor on Cosm IoT

The trouble with geese is that they are waterfowl, ie used to hatching near water, unlike chickens, so you tend to have to control the humidity of the incubator as well as the temperature. Humidity is terribly counterintuitive – unlike temperature humans have no real sense for it. So I was looking at how to make a humidity and temperature sensor.

The problem starts with our cheap Chinese import incubator. There’s no real calibration on the temperature dial, and you know it’s a bad sign when the manual tells you ‘when your small poultry is ready’. I was really sceptical about how well this would stabilise the temperature. Quite unfairly as it happens.

It turns out that the accuracy of the temperature isn’t as good as it could be, but the precision is very good. That is, it holds temperature stable to within half  a degree. It’s just that the set point it stabilises at isn’t necessarily what it says on the dial.

But what can I say – it was cheap.

Design Brief

We’d like to know the temperature and humidity in there, to within a couple of degrees C and about 5% RH. In an ideal world it would be a data logger with a screen on it, with a display something like this

But I could settle for a regular LCD display if I have to. A two line LCD display would be fine, temp on the top and humidty on the bottom line. This is the story of how I got this running in a day, because we have some new eggs and we’re looking at a way of upping the hit rate.

Design approach

Now in days gone by I would have done this with a thermistor and a capacitive humidity sensor. The latter is quite a horrible interface – it is some sort of polymer that varies capacitance with humidity and temperature. They don’t tolerate DC across them, so you need to make an oscillator with them and determine the frequency. That’s easy enough to do with a PIC, but calibrating them is a bear. Thermistors aren’t great to calibrate either -they have a tolerance of 10% which means you can be off a few degrees unless you line the system on a known reference temperature first.

I nailed these two by using the popular Dallas 18B20 sensor, which has a library for the JAL language I write the PIC code in. That has a ±0.5°C tolerance, which saves faffing about calibrating and compensating thermistors. For humidity I selected the Honeywell HIH5031, which gives an analogue voltage out which is ratiometric with the supply voltage. That’s a great match for the ADC of the PIC – by using the supply voltage for the ADC reference any power supply voltage variations cancel out due to the ratiometric output. The sensor has signal conditioning on the chip, so I am not dealing with a finicky capacitive device. The downside here is that the sensor is relatively expensive from CPC at nearly £10. The DS18B20 is 83p from China on Ebay.

Alternatives considered

Sensors – The obvious alternative is the DHT22 digital temp and humidity sensor that is popular in the Arduino world, but it has a bizarre digital interface and doesn’t seem known for reliability. This runs about £3.60 from China on Ebay, £5.70 from the UK. I’m paying about three times over the odds for Honeywell and Dallas parts and the hope that I can service or substitute them in the future, because smallholders are hard on their equipment. They’ll hopefully stand up to the harsh incubator environment better. If I were mass-producing the system the difference in price would matter. However, going for the dearer parts makes life easier for myself, as the Dallas 18B20 has a JAL library and the ratiometric analogue interface of the Honeywell is easy to match. I get the PIC to do the temperature compensation of the RH value using the data from the Dallas chip and integer math on the PIC.

Platform – I constructed this over a couple of days using parts I already had to hand. If I were starting from scratch I’d probably move away from the discrete PIC/ERF combination to the Arduino all in one RFu/XinoRF devkit combination. Development on the Arduino is faster because the language is higher level and the Arduino is more powerful. The downside of that is a higher power consumption – 7mA for the RFu active processor radio down, compared to about half that for the PIC active, radio down. The PIC power usage could be reduced by using the WDT, and the same would work for the Arduino, but there seem to be some pain associated with using a WDT on the Arduino because you aren’t programming the processor at the bare metal level which I do with PICS (I don’t use a bootloader).

For this application the RFu would have scored massively, as power consumption isn’t an issue, it’s mains powered via a wall wart. I wouldn’t have needed the veroboard for the PIC – it could have been done wiring straight to the RFu. But I didn’t realise that when I started, and it would be hard to tell the geese to stop hatching for a couple of days…

Replacing local storage and display with the Internet of Things

Any instrumentation normally needs at least a display, and something tracking variation with time needs storage of some sort. That is a major pain, a graphical display is dear and and writing a shedload of software for the graphing bit is hassle for a one-off. However, these days we’re surrounded by graphical displays on our PCs and smartphones, and it seems a shame to have to do all this again, why not sweat the existing asset? Those nice people at Cosm (formerly known as pachube) have done a lot of the software for the graphing, and they store and marshal any readings you send their way. It’s like having a low-cost lab assistant to write it all down and graph the result!

All of a sudden I could see my way to losing the display entirely. That’s nice, it’s always a pain to cut out the rectangular slot for the LCD anyway. And of course you don’t have to sit and watch the LCD display. I believe cosm will even send alerts on triggers if the variables go out of the spec you set, but I haven’t got that far.

There has to be a downside, and the downside is you have to send the data to cosm over the internet. A PIC isn’t really man enough to run a TCP/IP stack and do anything useful as well. However, I am a great fan of Ciseco’s OpenKontrol Gateway, which uses an ATMega which is just about man enough to run a TCP/IP stack, and I have one next to my Ethernet switch, sending the odd bit of data up there. So getting the data from my sensor PIC to Cosm is simply a matter of buying a Ciseco ERF or XRF Xbee-like device, adding some extra code to the OKG and job done. The sensor can then send LLAP commands which are simple 12-byte serial strings, that are reasonably easy to send from a PIC.

Cost summary

Going radio and IoT has startup costs. The OKG kit and ancilliary bits to make it all go online is about £75 all in (the Wiznet 5200 ethernet card is dear) but it can serve any number of devices in radio range, so it is a shared cost hit. Mine serves a couple of other temperature sensors and my Geiger counter. Once I have it, adding new sensors doesn’t carry any extra incremental cost.

The humidity and temperature sensors and radio is about £26

Look ma, no wires!

One of the great things about the XRF radio series is it creates a virtual RF bus for all the devices to talk to. Oh yeah, and you don’t have serial cables snaking all over the place, which is nice as the OpenKontrol Gateway is on the top floor and the incubator is on the ground floor of the house. I take the hit of £16 for the ERF module which I already had – if I were starting over I’d save £4 and use the XRF and level shift to 3.3V.

Using RF I get no wires, I need no display and I need no storage. That’s worth something in terms of ease of use, less development time and less hassle

Software

I pinched this Arduino sketch from Ciseco and modded the code to adapt to my application. Unlike that application I detect an incoming message anod update only that value on Cosm. This is because I have 8 sensors spread across several feeds, two user accounts and three API keys. Some sensors update every minute, some every five minutes. Cosm is perfectly capable of maintaining state, so I didn’t want to maintain state locally, otherwise on startup I might upload a zero value to cosm from a sensor I haven’t received yet, which makes the charts look terrible.

Arduino lack of WDT woes…

I did try using the Cosm Arduino library and the Wiznet 5200 module (which it seems to need rather than the cheaper ENC device) but it gave me obscure memory leaks that would hang the Arduino. Since the Arduino doesn’t sit well with a watchdog timer that is bad. A WDT is a perfect solution to a hanging IoT Arduino, since the odd missing value is neither here nor there, Cosm interpolates fine. At one point I considered adding a self-oscillating CD4060, resetting it with the Arduino pin 3 which I can pick off the NRF socket that I don’t ever see myself using, and letting Q14 ground the Arduino reset pin via a transistor. Getting rid of the Cosm API was a better way, and getting rid of the Wiznet was also a good move. The Wiznet5200 is ratty – it works fine most of the time but does need a WDT in its own right, particularly when using DHCP. Mine was a lot more reliable using a fixed IP, but I still needed to detect a run of more than 5 -1 or -3 return codes and reboot the Wiznet with the Arduino.

Construction

I used DIN 5-pole plugs for the sensors. Years ago they were used for audio, but I haven’t seen a piece of audio gear using DIN plugs for a while. The plugs are multipole and reasonably reliable in operation.

Sticking the Honeywell sensor up above the metal allows it to be in the plastic grid of the cable grip. seen on the RHS

I used a 16F870 PIC because they were cheap from Crownhill, I am not using the full set of pins. I’d probably have run with a 16F88 if I were starting over.

It’s designed to be powered for a wall wart up 7 to 15V, the first resistor from the PSU is to provide a battery sensing facility, though it will be out by the forward drop of the fool’s diode on the input. I use a pin of the PIC to power up the radio via the PNP transistor to save a little bit of power.

Result

The result was a vote of confidence for the thermal stability of this fine Chinese product, and a greater awareness of what you have to do to change humidity. It isn’t enough to simply add water to the  reservoir, you need to increase the surface area by soaking a beer towel or something in water  to shift the needle on the dial. That was a revelation, and should improve our hit rate on the next bunch of eggs that are already loaded.

Goose egs have very thick shells,so raising the humidity towards the time of hatching presumably makes it easier for the hatchling to break out of the shell. This is where having a measurement of humidity really helps, because it informed us we had been way too low, but we can fix that now.

All in all this one has been successful from the rapid application development point of view – requirement to delivery in a day, and eggs installed the next. Thank you to cosm and Ciseco who made this a lot easier than it would otherwise have been.