fHelper - capacitive humidity sensor

Time ago I did use a traditional humidity soil sensor (from the Grove family) for the fHelper project and it ended up very badly.


After some search I decided to try a capacitive sensor.
There are many on the market, so I just did pick up one of the cheapest
and easy to have one, from Amazon.


This is a brief review of this sensor.

The sensor, one of the many available on Amazon, is unbranded and it has just a laconic Vs. 1.2.
It can be powered with 3.3V (apparently, no datasheet received) and is basically returning an analog value depending the amount of humidity on the soil.
Like many similar sensors, the electronic on the top is exposed, so it is necessary to pay attention when watering the plant to don't wet the electronic !

The sensor returns the maximum reading (around 3500) when totally dry and the lowest when wet.

Test environment

To test the sensor I did set up a MQTT based system.
A Raspberry Pi is running a MQTT broker and a Node-Red website and a Huzzah32 interface the sensor.
Every 25 seconds the Huzzah32 is going to read the sensor, reading it 10 times and then calculating an average and sending it to the broker via MQTT.
There the reading is saved on two graphs : a 3 hours and 24 hours graph.

As first tests I did just let the sensor on the table, untouched.
The measurements were quite stables, at the maximum levels as expected.
Touching the sensor caused a drop of the readings.
More area covered of the sensor, less the read values.

But placing the sensor in the real environment, a vase with a plant, did show up a really different scenario, where the reading oscillate a lot.

Results

After running the system for a while in the real environment, i.e. the sensor in the vase, it was clear that the reading is quite unstable and unpredictable.
Unless the sensor is actually touched by the water, the readings vary as much as 80% !
One reading could be almost to the maximum (dry condition) to the middle or lower values !
This with a single reading every 5 seconds.

So as second tests I decided to change the way to read the sensor.
I did increase the reading time at 25 seconds and then read the sensor 10 times, with 100 ms delay between every reading, calculating the average (reading / 10).
That improved little bit the measurement but is still unstable.

The graph above shows the collected results for 12 hours (from Node-Red).
On the graph above note how the readings improved after switching from a single read every 5 seconds to 10 reads every 25 seconds.
The gauge value is the last reading.

In order to have a usable value to decide when is time to water the plant, the latest algorithm does :

• On the IoT client
• every 25 seconds, the controller read the sensor 10 times, with 50 ms delay between each reading
• the readings are summed then divided by 10
• the result is sent out as payload
• On the IoT server side
• every 25 seconds a value is received
• the value is put on an average block of 30 readings, i.e. the value of the last 30 readings contribute to generate the average value
• it is assumed the plant need water if the reading remains above 2500 for 30 consecutive times
• if the reading is below 2500 the counter is reset

This is a graph showing the results from this algorithm.
Note the drop around 11 am, is when water was added in the vase.

The linearization of the readings (graph in the middle) is much more clean and usable even if still varying a lot.
The graph on the top shows the payload received every 25 seconds.

Update - April 2019

After stopping to use a breadboard and long wiring to connect the sensor to the Huzzah32, I did notice a huge improvement in the readings !
More tests are required in the next weeks but I can already say that the sensor can behave much better with a clean connection (see the article Set up a Huzzah32 IoT client - testing).
Note here how much less noise is read from the sensor !

The drop of the values read is when I did add water to the plant.

Conclusion

This kind of sensor works but it requires a lot of analysis and signal processing to extract some useful information.

Pro :

• is cheap
• is simple
• it doesn't require special libraries

Cons :

• reading highly fluctuating
• requires lot of signal clean up and elaboration of the result to obtain something useful