Soil Moisture Sensor using Analog Input - Solved

[Deennoo]

Just recieve this :

http://www.google.fr/imgres?imgurl=http ... aCh1-oANDt]

Plug it on a ESP12 and on Gpio 13, but it on earth with meddium water looks to get good value on ADC :

[attachment=0]Capture.JPG[/attachment]

Create a dummy device on Domoticz, and want to update it via HTTP/json.

Device is update but with no value (stay on : 0)

Is there a way to see which json order is send from ESP ?

Thanks

[Deennoo]

After some test, value on Analog aren't good, put it on water or on Air will give the same value...

I test it on a anrduino skecth who ready analog value, and sensor looks good :

1024 : on dry sand
250 : on full water

Can you help ?

[Martinus]

[quote="Deennoo"]After some test, value on Analog aren't good, put it on water or on Air will give the same value...

I test it on a anrduino skecth who ready analog value, and sensor looks good :

1024 : on dry sand
250 : on full water

Can you help ?[/quote]
What's the sensor analog output range on your sensor?
Remember that the Arduino has analog input ranges from 0-5 volts.
The ESP range is 0-1.1 volts or different if they added some extra resistors.

[rtenklooster]

[quote="Martinus"]After some test, value on Analog aren't good, put it on water or on Air will give the same value...

I test it on a anrduino skecth who ready analog value, and sensor looks good :

1024 : on dry sand
250 : on full water

Can you help ?
What's the sensor analog output range on your sensor?
Remember that the Arduino has analog input ranges from 0-5 volts.
The ESP range is 0-1.1 volts or different if they added some extra resistors.[/quote]
Quote testje

[Deennoo]

Ok Thanks for this help, i just figure that ESP GPIO works like Arduino One...

When VCC on 3.3v this sensors return analog on 3.3v, i made a div bridge and now get 1.1v when sensor is on the air and 0.574v when is on water, is this more ESP8266 compiliant ?

[Deennoo]

finally got good analog value by plug the sensor to the good esp PIN (ADC).

Probleme is still the same, as i can choose which style of device to use for update sending.

[Deennoo]

Got a Good result ! and solve my probleme !

using Json to update Domoticz Humidity device must be :

http://ip:port/json.htm?type=command&param=udevice&idx=IDX&nvalue=HUMVALUE&svalue=HUM;HUM_STAT

http://ip:port/json.htm?type=command&param=udevice&idx=IDX&nvalue=HUMVALUE&svalue=0 is allowed too

my probleme was ESPEasy send :

http://ip:port/json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=HUMValue (the analogique value, saw this using Domoticz MQTT)

on R38 code i made this change on _C001

previous was :

case SENSOR_TYPE_SINGLE: // single value sensor, used for Dallas, BH1750, etc
url += F("&svalue="); //value from analogique was sending as the svalue
url += UserVar[event->BaseVarIndex];
break;

and now is :

case SENSOR_TYPE_SINGLE: // single value sensor, used for Dallas, BH1750, etc
url += F("&nvalue="); // now analogique value is send as the nvalue who has to been updated for a HUMDITY sensor
url += UserVar[event->BaseVarIndex];
break;

et voila :

[attachment=0]Capture.JPG[/attachment]

[maluko]

I have order one of that, i will try too, good job

[Deennoo]

Must admit that sending good % is not easy.

Actually can't get a good result because i'm missing 2 characters on formula place to provid a real number to place my formula who was give by a friend,

100-(%value%-66)*2 : must be 1024-((%value%-660)*2)/10

My tweak is to divid analogic input/10 (line 43 on _P002_ADC) :

i'm facing 2 problemes :

When sensor is on water he never goes to 0, but fluctate between 530 and 660 (this number is never stable) that why i decide that 660 is 0, but when outside of water 1024 give 25% instaed of 0%

When on water sometime it can give 102% or 103%.

I need help on this and on formula for more real accuracy.

[Drum]

Has anyone tried the capacitive I2C sensor fron the chirp? Temp/moist/light sensor, has arduino library and appears to have good documentation.
Also appears to have software assignable I2C address, so maybe multiple units on 1 esp8266.

Only issue I see so far is it may need some additional waterproofing as the standard varnish doesn't seem to be good for all soil types or is just not robust enough for this use.

https://www.tindie.com/products/miceuz/ ... re-sensor/

I am going to order some, but I have no clue how to modify the code for this, but I will look into it..

[Bram81]

Hi,

Im using a soil moisture sensor on a nodemcu 0.9 running esp easy r48. Using the nvalue to get readings in domoticz as stated in this topic indeed sends info to domoticz. Now my problem is that I can't use those values in LUA or Blocky because it seems that the eventsystem is using svalues. An option to solve this problem could be to add a line to the sketch saying it has to update a custom user variable in Domoticz with the same nvalue as it is sending as a value for my soil moisture sensor. I've posted this question last week on the software part of this forum, but nobody seems to be able to help me out. Do you guys have a clue, or is it simply not possible? Maybe @Martinus has an idea?

[Deennoo]

Got a better solution :

1 create a counter device

counter.PNG (20.03 KiB) Viewed 41523 times

2 Update this device with ESPeasy analog Value
3 Create a leaf hum sensor

4 Use this lua script directly on Events domoticz page :

Code: Select all

commandArray = {}

   --print(otherdevices_svalues['cpt_Hum_ESP']) 
   val = tonumber(otherdevices_svalues['cpt_Hum_ESP'])
   val1 = math.floor(100-(100*(val/1024)))
   
   commandArray['UpdateDevice']='1380|'..val1..'|0'
   --print('Hum ESP - '..val1..' %'.."  "..val)
   
  
   
return commandArray

Where :
cpt_Hum_Esp is the counter
1380 is the dummy leaf sensor IDX

Source : http://domotique.web2diz.net/?p=629 & http://easydomoticz.com/forum/viewtopic ... 337#p17337

[staber]

finally got good analog value by plug the sensor to the good esp PIN (ADC).

Deennoo,

I'm using a Wemos D1. Is A0 is the good PIN ?

[Deennoo]

Yeap that the good one !

I discover a small probleme by using a GPIO and Deepsleep.

[jochem]

I don`t get it to work in easy esp.
I am using an wemos d1 mini with pin a0 but can`t get any value.

The sensor is working, because i tested it with another script:

void setup() {
Serial.begin(9600);
pinMode(A0, INPUT);
}

void loop() {
Serial.println(analogRead(A0));
delay(100);
}

with this script I get a value around 1000 when i put it in water en 200 outside the water.

any ideas on this?

[jochem]

solved,

it needed some time or so. suddenly it started working...

[toffel969]

solved,

it needed some time or so. suddenly it started working...

maybe sensor delay?

[Ton_vN]

@Deennoo

The 'fork'-moisture sensor is 'not the most accurate' device, and therefore the resulting values should be believed with "some" (=wide) margin.
Let's assume 1024 as 'bone dry'= 0% Humidity and approx. 550 as 'wet' = 100% humidity => range 0% to 100% is roughly equivalent to approx. 500 'units'.
IMHO then you can simplify the formula for the moisture sensor to (1024-%value%)/5
That formula easily fits in the calculation-field of ESPEasy.
You may 'improve' the division by 5 by giving the divider some more decimals:
- If you assume a 'wet'/bottom-value of 660, then the range would become 364 => more accurate divider of 3.64 => formula is (1024-%value%)/3.64
- If you assume a 'wet'/bottom-value of 550, then the range would become 475 => more accurate divider of 4.75 => formula is (1024-%value%)/4.75

Have the same experience with an ESP8266&ESPEasy: the reading from the sensor is not stable.
Looking in Domoticz (applying the formula above) one can recognize the average tendency, but the spread is considerable.
For a more stable display in Domoticz I implemented a lua-script with a simple alpha/kalman-filter with the following setup, to be run periodically:
a) read (previous_value) from the user values
b) (actual_value) = (1-alpha)*(previous_value) + (alpha)*(last_measured_value)
c) store (actual_value) as (previous_value)
d) display (actual value)
By variation of alpha, the filtered (actual_value) follows the measured values with a 'tail' of history:
usually alpha=0.1 is a good starting setting, while alpha > 0.1 makes the filter 'jumpier' and a lower setting of alpha means more 'laziness'.

[Ton_vN]

The concept with 'fork'-sensor is very cheap, but with short life-cycle.
Further search at this moment provides info on 'better' concepts: see http://www.domoticz.com/forum/viewtopic ... 39#p139039
The capacitive sensor with analogue output seems very promising.

[Shardan]

These sensors will never be highly accurate due to basic physics.

No matter if resistance or capacitance, there is another factor, the soil density.
If the soil density changes the dielectric constant (capacitive) and also the conductance (resistive) changes.
So if someone puts a stone on the soil near sensor thus densifying it, values may change.
I'm not sure if there is a workaround for this.

Capacitive and resistive sensors have one advantage: a quick response time.
If a slow response is allowed a humidity sensor encapsuled in a sintered metal case might work better.
The slow response might be risky when watering plants as the response might arrive when your plants are already "submarine"
This must be solved by the firmware or rules.

Roughly this might be something like: If too dry, watering for x minutes, then stop for y minutes awaiting response, then check again.

The concept with 'fork'-sensor is very cheap, but with short life-cycle.

Dunno for soil sensors. For "fork type" rain sensors this is said too.
But why is the rain sensor at my parents home working reliable for more then two decades then?

Regards
Shardan

[Ton_vN]

But why is the rain sensor at my parents home working reliable for more then two decades then?

Speculation, but probably that rain-sensor is a capacitive sensor with r.f.-variation as measuring principle, and furthermore most of the time the probe-surface of such rain-sensor is dry (contrary to soil-sensors) .

If the same circuit would be applied with a 'fork'-sensor, my guess is that then also much longer lifetime can be expected for a 'fork'-probe.
That circuit is very simple, but unfortunately all 'forks' are sold in combination with a DC-measuring circuit.

The capacitive sensors mentioned in my earlier post are 'significantly' more expensive than the DC-sensors (but building a circuit such as applied for the rain-sensor is more expensive), and accuracy will always be questionable, but performance vs price seems OK for an experimental setup: now waiting till AliExpress delivers .......

[Shardan]

Nope, that sensor works very simple and resistive, but with AC, not DC on the sensor.
I think the problem is far more in the "concept of cheap" then within the "concept of fork".

Most of the cheap sensors are blank copper or tinned copper.
This alone will definitely run into problem quickly as even rain nowadays has a pH below 7 (--> acidic).
This together with oxygene from air will destroy tinning and copper.
The more the cheap sensors use DC for the sensor which speeds up the corrosion to the maximum.

What i'm using for experimenting atm is an AC driven sensor (using both effects,
capacitive and resistive) with gold-plated fork sensor as the ols sensor uses.
The circuit i've deveoloped is far more complex then a DC-sensor,
the gold plated sensor fork alone is around 15€...
It's a fork sensor, but not cheap.... We'll see.

Anyways.... i have ordered some sintered metal cases for SHT1x sensors a while ago
and of course the sensors so i mght soon be able to check wether the idea using this
as completely contactless soil humidity sensor works or not.
Would be nice as I just feel better if the sensor and the electronic circuit can be apart at least 1..2 meters.
That will be at least very difficult with a capacitive sensor.

Regards
Shardan

[Ton_vN]

Based on your reported experience that AC-application seems to make the difference.
Apparently further thinking along the same lines.

After the (negative) experience with the 'Fork+DC'-sensor planned to have an experimental setup with a capacitive sensor and an SHT-sensor running in parallel on a Wemos_D1 with ESPEasy:
- the capacitive sensor to measure humidity at the surface of the soil (because it cannot go deeper due to the hardware-configuration of the sensor).
To replace the 'Fork+DC'-hum_sensor. Temperature in the top-layer is already (reasonably accurately) measured by a waterproof DS18B20-sensor.
- the SHT-sensor at -10cm from the surface of the soil, to really measure the combination of temperature&humidity in the soil , not in the layer just above the surface.
Run that setup for some time to get experience, and to see what configuration offers best/enough value for money, before next steps.
If the 2 sensorsets report values which are reasonably close (or explainably different), then choice will the obvious.

Meanwhile the challenge to invent how to recyle/adapt the 'Fork+DC'-sensor in a dirt-cheap DIY-way into a 'Fork+AC'-sensor which does not 'eat' the fork ......
Also considering the aspect you mention, which is an advantage of the present setup: very simple sensor (which can be immersed) on a long cable to the processor.
The location of my experimental measuring setup is under my house with no disturbances to be expected to/at the surface to be measured and only slow & limited changes for temperature and humidity.

[Ton_vN]

For the 'recycling' just wondering whether to revisit this theremin-setup.
Within a simple rigid & waterproof holder going into the soil, Pin1 of the fork as Antenna, Pin2 of the fork as Reference/GND.
The oscillator located as close as possible near the fork, with it's own simple&robust power supply, because any variation in power supply is expected to be seen in the frequency.
Shielded cable from oscillator to an ESP8266 applied as counter on the output of the oscillator.
For the ESP8266&ESPEasy software required to act as frequency-meter and a rule to translate the measured frequency-variation into a humidity-indication:
what is the max. frequency that the ESP8266 can handle in that role? Perhaps a small change to have the oscillator running at lower frequencies.
Such setup will only provide very rough info, but in a quiet & stable environment that may be sufficient to get a feeling of humidity-changes in the soil.
In an environment with frequent changes of temperature and/or humidity this concept may be less stable.

[Shardan]

I could give you the schematic of my rain sensor, but...
The circuit i use for my rain sensor will be far too sensitive for that.
It responses even if i put a 2mm glass plate on the sensor and put my hand on it as it is resistive and capacitive.

It might be possible to get it to work but it will need some effort and revamping a lot of the circuit.
Even worse i think a long cable between sensor end circuit will not work nicely, at least the oscillator
used for AC generation should be near the sensor. The cable has too much effect on the resonance point.

The following might be possible: Use a oscillator of some KHz and use the fork as part of a voltage divider.
De-couple the output from the voltage divider with a high impedance OpAmp like a TL081 and use the output
as analog value for moisture.
This might even work as a capacitive sensor, depending on the dimensions of the fork part.
The bad part: to get this working well it will need a symmetric power supply.

I've added a "first idea" schematic.
Please be aware this schematic is in no way tested, most values are made by "thumbs of rule" and might work or not.
I think it needs a lot of optimizing, so it's just a point to start from.

Regards
Shardan

[Ton_vN]

Simpler (and less effort&cost) to wait for arrival of the capacitive sensor plus SHT11 from China.
After activation of those 2 sensors then 'Fork+DC'-sensor just for experiments & fun.

[Shardan]

Yep... just for being a bit interested in those things - what size has the sensor fork for soil humidity?
I might play around a bit with those things on a breadboard as i have the electronic parts on stock.

Besides that i'm waiting for the sintered metal cases, i should have SHT11 in my shelf... then i'll see
if that works for soil humidity. Besides that being a solution with slow response time I suspect
it might drown the sensor... some things to do and to test as usual

[LisaM]

I've ordered this one: https://www.aliexpress.com/item/Soil-te ... 0.0.3mmJqW
I2C sensor, easy to connect...

[Ton_vN]

@shardan

For dimensional comparison of 'fork'-sensors (purchased vs. DIY) see the pictures and text at the bottom of http://www.vannwnhzn.nl/esp8266a3_humtemp01.html
'Legs' of all sensors shown are approx. 5cm long.

[Ton_vN]

@LisaM
SH1x is not really I2C: hardware interface yes, but protocol no.
See https://cdn.sparkfun.com/datasheets/Sen ... eet_V5.pdf
See also https://www.letscontrolit.com/wiki/index.php/SHT1X, although not clear what wire to be connected to what GPIO.
In that perspective also curious which colourcoding the chinese manufactureres apply for the interface-wiring.
Somebody with experience and hints on that aspect?

[LisaM]

@LisaM
SH1x is not really I2C: hardware interface yes, but protocol no.
See https://cdn.sparkfun.com/datasheets/Sen ... eet_V5.pdf
See also https://www.letscontrolit.com/wiki/index.php/SHT1X, although not clear what wire to be connected to what GPIO.
In that perspective also curious which colourcoding the chinese manufactureres apply for the interface-wiring.
Somebody with experience and hints on that aspect?

https://www.letscontrolit.com/wiki/index.php/SHT1X
https://www.adafruit.com/product/1298
http://blogs.helsinki.fi/greenhouseproj ... wiring.png
If nothing works, i'll adapt the code...

[Shardan]

You may also use newer generations of the SHT. SHT2X uses I2C.
The sensor itself is the same as with SHT1x, but with a I2C interface.
For a programmer It shouldn't be too difficult to adapt code of one of the existing Hum/Temp sensors.
I'd try the SI7021 - it uses a SHT21........

Shardan

[Ton_vN]

Received an SHT11 in watertight enslosure, with 4 wires peeping out (without any documentation).

SHT11_sensor

SHT11.png (218.87 KiB) Viewed 39348 times

From descriptions at AliExpress I deduct that following colourcoding might apply:

• brown = VCC
  black = GND
  yellow = Data
  blue = CLK

Viewing the 'standard' I2C-interface at ESP(Easy) I deduct that following data-interface applies:

• yellow to GPIO4/SDA
  blue to GPIO5/SCL

Wire-coding confirmed by the results as described in my message of 21 August, but not the assumption for the application of GPIO!

[Ton_vN]

This message just demonstrates how much time you can spend by a wrong starting assumption and/or wrong information .......

Found time to connect the received SHT11.
To avoid conflicts with the OLED on 'real' I2C (and in fact no choice, because then GPIO4+GPIO5 not made available for selection), similar to I2C at GPIO04 and GPIO05, start with SCL/SCK= D6/GPIO12 at 1st GPIO and SDA = D7/GPIO13 at 2ndGPIO
Under tab 'Devices/Edit' selected SHT1X, set PullUp and set Enabled, and then the 'Devices'-display shows values.
So far OK, but apparently missmatch with the 'standard' driver-software for SHT1X, because I get the display below, while I expect something like (at this moment) approx. 24 degreesC and 55%RH. The displayed values remain fixed regardless of changes in the environment.
In hindsight, these values are displayed if no sensor is connected and ESPEasy has the settings mentioned above ..........

ESP8266+ESPEAsyMega+SHT11+GPIOSet

Knipsel_ESP8266F_170821.JPG (66.39 KiB) Viewed 39352 times

If the result is not as expected, you look in detail & experiment ......
Putting the device-data&clock on GPIO04+GPIO05 and performing I2C-scan does not yield results => device is not I2C [as to be expected]
Opening the sensor-head does not help to get info, because the sensor-pcb is nicely shielded&coated.

SHT11_opened

IMG_SHT11_Open.jpg (33.87 KiB) Viewed 39335 times

Looking at the interface-side, I left the SHT-device hardware connected to D6 and D7, but did not set the GPIOs in ESPEasy:
then you get the result below (again with 'frozen' values).

ESP8266+ESPEasyMega+SHT11+GPIOnotSet

Knipsel_ESP8266F_170821A.JPG (61.31 KiB) Viewed 39341 times

Exchanging the wires on D6 and D7 has no results, hence certainly not the remedy .......

Then another idea popped-up ......
Switch SDA = yellow = D7/GPIO13 to 1st GPIO and SCL= blue = D6/GPIO12 to 2nd GPIO
That is the correct/working setting!
But the opposite of the information in the Wiki!
=> Careful conclusions
1) lack of colourcoding for the cable => a lot of effort to find out the operational configuration
2) WEMOS & SHT11 can accept/survive quite a lot of molesting .....

ESP8266+ESPEasyMega+SHT11+reversedGPIO

Knipsel_ESP8266F_170821B.JPG (63.65 KiB) Viewed 39324 times

[karmacoma]

Got a Good result ! and solve my probleme !

using Json to update Domoticz Humidity device must be :

http://ip:port/json.htm?type=command&param=udevice&idx=IDX&nvalue=HUMVALUE&svalue=HUM;HUM_STAT

http://ip:port/json.htm?type=command&param=udevice&idx=IDX&nvalue=HUMVALUE&svalue=0 is allowed too

my probleme was ESPEasy send :

http://ip:port/json.htm?type=command&param=udevice&idx=IDX&nvalue=0&svalue=HUMValue (the analogique value, saw this using Domoticz MQTT)

on R38 code i made this change on _C001

previous was :

case SENSOR_TYPE_SINGLE: // single value sensor, used for Dallas, BH1750, etc
url += F("&svalue="); //value from analogique was sending as the svalue
url += UserVar[event->BaseVarIndex];
break;

and now is :

case SENSOR_TYPE_SINGLE: // single value sensor, used for Dallas, BH1750, etc
url += F("&nvalue="); // now analogique value is send as the nvalue who has to been updated for a HUMDITY sensor
url += UserVar[event->BaseVarIndex];
break;

et voila :

Capture.JPG

ATTACHMENTS
Capture.JPG

Hi There,

I wonder where were you placing the script, and since I'm a newbie, I would like to have more details about this

Thaks a lot!
Oscar