Just to summarize since the thread is becoming a bit confusing.

The sensor shown in the example and the shopping guide is no more than a device that measures the resistance between the two pins of the fork. That is done by the boards, which includes an analog output and a digital output.

Should you just need to know when moisture is over or below a certain degree, just connect the digital output to a digital pin in the Arduino. Then use the potentiometer in the board to decide the switching point. In a battery powered node, this could be connected to an interrupt pin so the node sleeps and is only waken up when the moisture falls under the predetermined level to send an alert to the controller. But if you want to know track how moisture evolves, you may connect the analog output of the board to an analog pin in the arduino, which will provide a numerical value. Then the sensor needs to be calibrated; there are several forms but one involves measuring the output when the fork is submerged in water (which would be 100% moisture) and then when it's in air (that would be 0%). You can then map this scale to a moisture scale, typically a cb scale.

The negative side of using that board is that the current always flows in the same direction through the fork. The same occurs with another similar type of sensor like the sparkfun here. This will lead in some time to corrosion of the fork, even if it's one of the latest nickeled ones. Reports in the internet vary from weeks to months, but in any case the form will corrode and as a result the measurement will drift slowly.

The alternating polarization strategy tries to overcome this problem. To do so, the board is removed and only the fork is used. Instead of connecting it to Vcc and GND, the two terminals are connected so that the fork is actually one of the resistors in a voltage divider. The other resistor is usually a 10k resistor. In this setup, one of the digital pins is connected to one leg of the resistor, the other resistor leg is connected to one side of the fork, and the other side of the fork is connected to the other digital pin on the Arduino. Another wire needs then to be connected between the connection between the resistor and the fork, to an analog pin of the Arduino, which will read a value that will be proportional to the resistance of the fork, therefore to the moisture level. Then, by switching the pins from INPUT to OUTPUT, and from HIGH to LOW, you can have the current flow in one direction or the opposite one, which significantly delays the corrosion. In my case, the forks still look like new after months of use. Corrosion speed will still obviously depend by time between readings, reading time, soil type and other factors. I've never experimented with this sensor but with a rain sensor I could see corrosion symptoms after some minutes of continuous readings. This sensor also needs to be calibrated in a similar way as the former one. This setup makes the sketch a bit more complex but there are multiple examples here and in the internet.

There are also variations on the measurement strategy within this approach. For example, you may just take a reading in one direction, another reading in the other direction, convert them to moisture level, and average them. Other people take several readings and average them all. I realized that if the reading is repeated, the value increases with each reading until it stabilizes at a certain value, so I decided to have the sketch iterate until two consecutive readings get the same result. The measuring time also needs to be asessed; in my investigation, the shorter the time, the less battery consumption, but at some point around 5ms the readings started to be unreliable. On the other hand, the longer the measurement the more realiable, but the span of the measurements in analog pin where closer and closer which led to loss of accuracy, and of course higher battery consumption. I decided 10ms was a good balance but others' milage may vary.

Finally, there are other completely types of moisture sensor that measure the soil dielectric constant instead of its resistance. They are said to be more reliable, and additionally they do not suffer from corrosion since they do not need to be conductive, hence they are covered by a layer of non-metal material (probably epoxy?). This makes them more durable but also more expensive. I have no experience with those.

I hope this contributes to clarify this topic a little bit. This thread contains additional information on the same topic.

I went through a lot of problems when trying to build my network using the nrf24 modules. I jept using more and more powerful modules but never really managed to get a robust connection at all nodes.

The nrf24L01 do not provide signal level reporting capabilities, so it's not easy to imagine what's oging on when communication fails.

I finally understood by using the connection quality meter here. BY using I found that:

• Increasing the power is sometimes a problem instead of a solution, since the nrf24L01 tend to overload at some point.
• In my home there where "shadow" areas where the 2.4GHz simply didn't reach at a good enough level. I then checked the 2.4GHz signal from my router and found that it was also weak (not as weak as the nrf24L01, of course, but you could see the decrease).
• Isolating the nrf24L01 by wrapping them on a plastic film foil and then another later of tin foil helped a litlle.

From the results of my investigation I decided to move to using rfm69 modules, which have a better penetration power. They are working quite well, and certainly much better than the nrf24's.

Maybe in your case it might be worth using a similar tool to understand what is going on.

The sketch does not correspond to the sensor shown in the images. It is much better to use the 2-pin sensors and drive them directly using digital outputs. Search for FC28 (better) or YL-69 in ebay or amazon. I use a voltage divider with a 10k resistor

I've been using the alternating polarity approach on about 20 sensors, with perfect results and no signs of corrosion after around 6 months. I run some tests to determine the effect of measuring time and finally came up with 5ms with no averaging. The batteries last for months; I'm not sure how many since I haven't yet had to replace any (status led removed from 3.3v arduino mini pro board).

As a reference, I tested a rain sensor (same principle) with no alternating current and as soon as a drop of water touched the tracks, small bubbles were produced with indicated that electrolysis was taking place. The effect could be seen on the tracks after just a couple of minutes.

I'm attaching my sketch below. It reports battery level in addition to moisture. It uses the development branch of the mysensors library in order to use the new version of the rfm69 drivers with RSSI ATC - which btw works more than perfect.

I'm using Domoticz which includes a predefined device for moisture. This device uses the centibar scale, so I calibrated my sensors in % moisture and then convert to cb.

#define MY_RADIO_RFM69
#define MY_RFM69_NEW_DRIVER   // ATC on RFM69 works only with the new driver (not compatible with old=default driver)
#define MY_IS_RFM69HW
#define MY_RFM69_FREQUENCY RFM69_868MHZ
#define MY_RFM69_ATC_TARGET_RSSI_DBM (-70)
#define MY_RFM69_NETWORKID  100

#define MY_PARENT_NODE_ID 0
#define MY_PARENT_NODE_IS_STATIC
#define MY_TRANSPORT_MAX_TX_FAILURES 3

#define MY_DEBUG 

#include <MySensors.h>
#include <SPI.h>
#include <Vcc.h>
#include <Streaming.h>
#include <math.h>

#define VERSION "1.1"
/* Measurement probe connected to pins shown below
I avoided using pins 2 and 3 because they are reserved for IRQ (potential future use) - 2 is also used by the RFM69 module.
Although this may not actually have a noticeable effect, I also avoided 5 and 6 because they support PWM and hence are a bit slower.
*/
#define PIN_ALIM1 4                                   // Connect to input of resistor
#define PIN_ALIM2 7                                   // Connect to input of measuring probe
#define PIN_LECTURA A0

#define AGUA_DIR 780.0
#define AGUA_INV 160.0
#define AIRE_DIR 0.0
#define AIRE_INV 1023.0
#define TIEMPO_LECTURA 5
#define SLEEP_TIME_1h 3132000 // 1 h = 1*60*60000 = 3600000 ms -13% = 3132000 ms(my arduinos show a delay of 8s/min = 13%)
#define SLEEP_TIME_2h 6264000 // 2 h = 2*60*60000 = 7200000 ms -13% = 6264000 ms
#define SLEEP_TIME_3h 9396000 // 3 h = 3*60*60000 = 10800000 ms -13% = 9396000 ms

// Battery calibration (Li-ion)
const float VccMin   = 3.0;                         // Minimum expected Vcc level, in Volts.
const float VccMax   = 4.2;                         // Maximum expected Vcc level, in Volts.
const float VccCorrection = 3.82/3.74;              // Measured Vcc by multimeter divided by reported Vcc

#define CHILD_MOIST_ID 1
MyMessage msgmoist(CHILD_MOIST_ID, V_LEVEL);
Vcc vcc(VccCorrection);

float oldresultcb=0;
int oldbat=0, count=0;

void presentation(){
  Serial.begin(115200);
  sendSketchInfo("Sensor de humedad", VERSION);
  present(CHILD_MOIST_ID, S_MOISTURE, "Humedad suelo");
  analogReference(DEFAULT);
  pinMode(PIN_LECTURA, INPUT);
  pinMode(PIN_ALIM1, OUTPUT);
  pinMode(PIN_ALIM2, OUTPUT);
}

void loop()
{
  unsigned int value1, value2;
  float result1, result2, resultp, resultcb;

//Measurement of moisture
  wait(TIEMPO_LECTURA);
  digitalWrite(PIN_ALIM1, HIGH);
  digitalWrite(PIN_ALIM2, LOW);
  wait(TIEMPO_LECTURA);
  value1=analogRead(PIN_LECTURA);
  result1=constrain(value1/(AGUA_DIR-AIRE_DIR)*100.0, 1, 100);

  digitalWrite(PIN_ALIM1, LOW);
  digitalWrite(PIN_ALIM2, HIGH);
  wait(TIEMPO_LECTURA);
  value2=analogRead(PIN_LECTURA);
  digitalWrite(PIN_ALIM1, LOW);
  digitalWrite(PIN_ALIM2, LOW);
  result2=constrain(100-(value2-AGUA_INV)/(AIRE_INV-AGUA_INV)*100.0,1,100);

/*Conversion from % moisture to cb taken from http://lieth.ucdavis.edu/Research/tens/98/SmtPub.htm
Another option https://www.researchgate.net/figure/260321179_fig1_Fig-1-Relation-curve-between-water-tension-cb-and-soil-moisture-percentage
The scale used in Domoticz is explained here http://www.irrometer.com/basics.html and can be checked in file domoticz/main/RFXNames.cpp
  0-10 Saturated Soil. Occurs for a day or two after irrigation 
  10-20 Soil is adequately wet (except coarse sands which are drying out at this range) 
  20-60 Usual range to irrigate or water (most soils except heavy clay soils). 
  60-100 Usual range to irrigate heavy clay soils 
  100-200 Soil is becoming dangerously dry
*/
  resultp=(result1+result2)/2.0;
  resultcb=constrain(square((-2.96699+351.395/resultp)),0,200);                           //Equation fit using stat software
  count++;
  
//Send the data
  if ((oldresultcb!=resultcb) || (count==4)) send(msgmoist.set((unsigned int)resultcb));

//Measure battery voltage here since it has been under change recently (more reliable)
  float v = vcc.Read_Volts();  
  int p = vcc.Read_Perc(VccMin, VccMax);
  p=constrain(p,0,100);
  if ((p!=oldbat) || (count==4)) sendBatteryLevel(p);

//Save the last values and reset the counter
  oldresultcb=resultcb;
  oldbat=p;
  if (count==4) count=0;

#ifdef MY_DEBUG
  Serial << "Value1=" << value1 << " " << result1 << endl << "Value2=" << value2 << " " << result2 << endl << "Result = " << resultp << "% (" << resultcb << "cb)" << endl;
  Serial << "VCC = " << v << " Volts" << endl << "VCC% = " << p << " %" << endl;
#endif

  sleep(SLEEP_TIME_2h, true);  
  }

And this is how it looks in Domoticz:

I hope this helps.

@SquareKinematics If everything was working well before changing fom MQTT to TCP, and the flag was introduced together with that change, then you most likely have a non hw rfm69 module. That flag is only needed when the rfm69 module is hw type.

You can see in this image the differences between the two boards so you can check.

I would not expect anyone to put or take responsability on anyone for a piece of advice. I think we are here to help each other by sharing information and our own experiences.

The full picture should be more than clear at this point for anyone reading this and other threads, but I will clarify once more. Best practice is using the rfm69 family with a logic level converter when connected with a 5v arduino, given that as of today the manufacturer's datasheet is not 100% clear on this area. From a problem solving perspective, keep in mind, however, that should a converter not be in place for any reason, the setup might or might not work, so if it doesn't don't discard it as a cause but don't take it for granted at 100%. And even if it works, do plan for adding a converter.

@tekka Tested the new library and both issues seem to be gone now, great job !

I have one more question though

During testing I treid to put things difficult for my radios and move them until reception started to be bad. At some point the FOTA process gave up with a FW UPD FAIL message (line 41146 in attached log). So the node gave up and went to sleep. I was expecting it to try again after wake-up, but it didn't (see lines after 43589).

36734 !RFM69:SWR:NACK
36737 RFM69:PTX:NO ADJ
36771 RFM69:SWR:SEND,TO=0,RETRY=5
36966 RFM69:SWR:ACK,FROM=0,SEQ=119,RSSI=-55
36972 RFM69:ATC:ADJ TXL,cR=-55,tR=-80,TXL=12
36976 RFM69:PTX:LEVEL=12 dBm
36978 TSF:MSG:SEND,22-22-0-0,s=255,c=4,t=2,pt=6,l=6,sg=0,ft=0,st=OK:010001002005
36988 OTA:FRQ:FW REQ,T=0001,V=0001,B=0520
36993 RFM69:SWR:SEND,TO=0,RETRY=0
37203 !RFM69:SWR:NACK
37206 RFM69:PTX:LEVEL=13 dBm
37216 RFM69:SWR:SEND,TO=0,RETRY=1
37423 !RFM69:SWR:NACK
37425 RFM69:PTX:NO ADJ
37459 RFM69:SWR:SEND,TO=0,RETRY=2
37666 !RFM69:SWR:NACK
37668 RFM69:PTX:NO ADJ
37679 RFM69:SWR:SEND,TO=0,RETRY=3
37885 !RFM69:SWR:NACK
37888 RFM69:PTX:NO ADJ
37922 RFM69:SWR:SEND,TO=0,RETRY=4
38129 !RFM69:SWR:NACK
38131 RFM69:PTX:NO ADJ
38174 RFM69:SWR:SEND,TO=0,RETRY=5
38313 RFM69:SWR:ACK,FROM=0,SEQ=120,RSSI=-56
38318 RFM69:ATC:ADJ TXL,cR=-56,tR=-80,TXL=12
38322 RFM69:PTX:LEVEL=12 dBm
38326 TSF:MSG:SEND,22-22-0-0,s=255,c=4,t=2,pt=6,l=6,sg=0,ft=0,st=OK:010001002005
38334 OTA:FRQ:FW REQ,T=0001,V=0001,B=0520
38338 RFM69:SWR:SEND,TO=0,RETRY=0
38547 !RFM69:SWR:NACK
38549 RFM69:PTX:LEVEL=13 dBm
38559 RFM69:SWR:SEND,TO=0,RETRY=1
38768 !RFM69:SWR:NACK
38770 RFM69:PTX:NO ADJ
38805 RFM69:SWR:SEND,TO=0,RETRY=2
39012 !RFM69:SWR:NACK
39014 RFM69:PTX:NO ADJ
39024 RFM69:SWR:SEND,TO=0,RETRY=3
39231 !RFM69:SWR:NACK
39233 RFM69:PTX:NO ADJ
39268 RFM69:SWR:SEND,TO=0,RETRY=4
39475 !RFM69:SWR:NACK
39477 RFM69:PTX:NO ADJ
39520 RFM69:SWR:SEND,TO=0,RETRY=5
39702 RFM69:SWR:ACK,FROM=0,SEQ=121,RSSI=-54
39706 RFM69:ATC:ADJ TXL,cR=-54,tR=-80,TXL=12
39712 RFM69:PTX:LEVEL=12 dBm
39714 TSF:MSG:SEND,22-22-0-0,s=255,c=4,t=2,pt=6,l=6,sg=0,ft=0,st=OK:010001002005
39723 OTA:FRQ:FW REQ,T=0001,V=0001,B=0520
39729 RFM69:SWR:SEND,TO=0,RETRY=0
39938 !RFM69:SWR:NACK
39940 RFM69:PTX:LEVEL=13 dBm
39983 RFM69:SWR:SEND,TO=0,RETRY=1
40192 !RFM69:SWR:NACK
40194 RFM69:PTX:NO ADJ
40228 RFM69:SWR:SEND,TO=0,RETRY=2
40435 !RFM69:SWR:NACK
40437 RFM69:PTX:NO ADJ
40480 RFM69:SWR:SEND,TO=0,RETRY=3
40687 !RFM69:SWR:NACK
40689 RFM69:PTX:NO ADJ
40724 RFM69:SWR:SEND,TO=0,RETRY=4
40931 !RFM69:SWR:NACK
40933 RFM69:PTX:NO ADJ
40943 RFM69:SWR:SEND,TO=0,RETRY=5
41125 RFM69:SWR:ACK,FROM=0,SEQ=122,RSSI=-54
41129 RFM69:ATC:ADJ TXL,cR=-54,tR=-80,TXL=12
41134 RFM69:PTX:LEVEL=12 dBm
41138 TSF:MSG:SEND,22-22-0-0,s=255,c=4,t=2,pt=6,l=6,sg=0,ft=0,st=OK:010001002005
41146 !OTA:FRQ:FW UPD FAIL
41299 RFM69:SWR:SEND,TO=0,RETRY=0
41506 !RFM69:SWR:NACK
41508 RFM69:PTX:LEVEL=13 dBm
41519 RFM69:SWR:SEND,TO=0,RETRY=1
41725 !RFM69:SWR:NACK
41728 RFM69:PTX:NO ADJ
41762 RFM69:SWR:SEND,TO=0,RETRY=2
41969 !RFM69:SWR:NACK
41971 RFM69:PTX:NO ADJ
42014 RFM69:SWR:SEND,TO=0,RETRY=3
42221 !RFM69:SWR:NACK
42223 RFM69:PTX:NO ADJ
42258 RFM69:SWR:SEND,TO=0,RETRY=4
42465 !RFM69:SWR:NACK
42467 RFM69:PTX:NO ADJ
42477 RFM69:SWR:SEND,TO=0,RETRY=5
42684 !RFM69:SWR:NACK
42686 RFM69:PTX:NO ADJ
42721 !TSF:MSG:SEND,22-22-0-0,s=1,c=1,t=16,pt=1,l=1,sg=0,ft=0,st=NACK:0
42729 RFM69:SWR:SEND,TO=0,RETRY=0
42950 !RFM69:SWR:NACK
42952 RFM69:PTX:NO ADJ
42995 RFM69:SWR:SEND,TO=0,RETRY=1
43005 RFM69:SWR:ACK,FROM=0,SEQ=124,RSSI=-55
43010 RFM69:ATC:ADJ TXL,cR=-55,tR=-80,TXL=12
43014 RFM69:PTX:LEVEL=12 dBm
43018 TSF:MSG:SEND,22-22-0-0,s=255,c=3,t=0,pt=1,l=1,sg=0,ft=1,st=OK:20
No detection
43026 MCO:SLP:MS=30000,SMS=1,I1=1,M1=1,I2=255,M2=255
43030 RFM69:SWR:SEND,TO=0,RETRY=0
43065 RFM69:SWR:ACK,FROM=0,SEQ=125,RSSI=-56
43069 RFM69:ATC:ADJ TXL,cR=-56,tR=-80,TXL=11
43075 RFM69:PTX:LEVEL=11 dBm
43077 TSF:MSG:SEND,22-22-0-0,s=255,c=3,t=32,pt=5,l=4,sg=0,ft=0,st=OK:500
43585 TSF:TDI:TSL
43587 RFM69:RSL
43589 MCO:SLP:WUP=-1
43591 TSF:TRI:TSB
43593 RFM69:RSB
43595 RFM69:SWR:SEND,TO=0,RETRY=0
43606 RFM69:SWR:ACK,FROM=0,SEQ=126,RSSI=-56
43610 RFM69:ATC:ADJ TXL,cR=-56,tR=-80,TXL=10
43616 RFM69:PTX:LEVEL=10 dBm
43618 TSF:MSG:SEND,22-22-0-0,s=255,c=3,t=33,pt=5,l=4,sg=0,ft=0,st=OK:30000
43778 RFM69:SWR:SEND,TO=0,RETRY=0
43788 RFM69:SWR:ACK,FROM=0,SEQ=127,RSSI=-59
43792 RFM69:ATC:ADJ TXL,cR=-59,tR=-80,TXL=9
43796 RFM69:PTX:LEVEL=9 dBm

So when this occurs the only way I can think of to force another update would be update the sketch, refresh the repo in MysController and assign it to the node again. Therefore I wonder if this is intended behaviour and if so, if there is some other way to force an update after a failed one.

Thanks.

@Roloz I guess you are refering to the 3.3v output on the Nano. There are two issues with this:

• the Nano IO ports are still using 5v levels. Nrf24 is 5v/3.3v tolerant, but rfm69 is not, so you will need to use a converter.

• if you are using one of the high power versions of the rfm69 and using the high power settings, the Nano might not be able to provide the necessary power.

If rfm69 is your choice (it is mine) using a 3.3v mini pro really simplifies things.

@alexsh1 yes it is.

No wonder, I think I found the way... I found there is a function isFirmwareUpdateOngoing() in MyOTAFirmwareUpdate.cpp that seems to provide that functionality in a much easier way

Hi @peres,

My RFM69HW current during sleep is less than 1 uA aprox, which is consistent with what is shown in the datasheet. Interestingly, this is the result when powering the device with a battery; when powering the device from the PC USB serial, it's around 6 uA - still close enough as it's measured with a "normal" multimeter.

I'Which version of mysensors are you using? I've moved to 2.2.0-beta (due to me needing other functionalities not availabel in 2.1.1, namely ATC which btw works fabulously) and found that support for nrf69 is - although not yet 100% completed - significantly improved. Maybe worth a try to see if that fixes your sleep consumption?

Remember adding

#define MY_RFM69_NEW_DRIVER

to enable the new driver.

Let us know how it goes

That's a good point, I missed that detail in the ds. The sensor is now in service, I'll measure it again when i have a chance. Thanks.

I've been reading the thread here, and decided to open a new one since that one is old, and there were no reports of the consumption being fixed.

I'm in the same situation regarding consumption of my VEML6075 board being around 50 uA while sleeping, when it should be less than 1 uA according to the datasheet.

My specific board doesn't contain any voltage regulators, just a capacitor and the I2C pullups. Specifically, it's this one:

I'm using the adafruit library but I've tried 3 others with different sleep routines, all with the same result. When active, the consumption is much higher, so the chip is sleeping (sort of) it seems.

Any help on reducing the sleep consumption would be appreciated.

I also had to limit power to 13 dBm; in my case I think the reason is that the board needs more power than what the battery can provide when over that level, but I was never able to prove it.

@mmanzanelli I don't think you can, the Mega has a different memory structure not supported by the present bootloaders.

Hi, I'm interested on using the functions in the post title. I'm running Mysensors 2.2.0., and I have

#define MY_SIGNAL_REPORT_ENABLED

in my sketch.

If I add something like

sendSignalStrength (6);

or

sendTxPowerLevel (6);

to my sketch, the Arduino compiler complains about undefined references.

What do I need to do to get them working?

Thanks.

Answering to myself... after many tests I decided to start to start working backwards and started to discard assumptions... finally I discarded :

I know that Mega pins are 5v and in theory RFM69 are 3.3v, but I have more sensors installed in a similar setup with mini Pro 5v and Nano boards that work perfectly.

So I fit a ttl levels shifter between the Mega Pro and the RFM69 and it started to work right away.

It looks like AT328 and AT2560 have different levels of sensitivity as of being able to interpret 3.3v correctly as a "1". Interestingly, I checked the datasheets for both chips and the specification is the same, min 0.6Vcc volts, so anything over 3v should be interpreted as a "1"... go see...

As a final detail, I was able to use a 4way ttl shifter since the MISO line doesn't need to be shifted, which left me with MOSI, SCK, SS and INT. Credit to this forum page for this:

I can also confirm that pin D2 on these boards is connected to INT0 as standard... I don't know why the pinout diagram indicates something different.

I hope this helps others.

Hi,

I'm building a sensor using a Robotdyn Mega Pro board.

[https://robotdyn.com/mega-2560-pro-mini-atmega2560-16au.html](link url)

The pinout of this board is here:

[https://robotdyn.com/pub/media/0G-00005642==MEGA-PROMINI-ATmega2560/DOCS/PINOUT==0G-00005642==MEGA-PROMINI-ATmega2560.jpg](link url)

My network uses RFM69 antennas.

My connections are:

MISO 50
MOSI 51
SCK 52
SS 53
DIO00 2

Power is connected to 3.3v line. I know that Mega pins are 5v and in theory RFM69 are 3.3v, but I have more sensors installed in a similar setup with mini Pro 5v and Nano boards that work perfectly.

I have also tried two different radios to discard hardware issues.

On start my sketch shows:

3 TSM:INIT
4 TSF:WUR:MS=3000
106 !TSM:INIT:TSP FAIL
108 TSM:FAIL:CNT=1
109 TSM:FAIL:DIS

My concern is that pinout diagrams for "normal" Mega boards show that pin D2 is assigned to INT0, while the pinout for this board linked above indicates that pin D2 is assigned to INT4.

In view of this, I have tried adding the following defines with no success:

#define MY_RFM69_IRQ_PIN 2
#define MY_RFM69_IRQ_NUM 0

I have tried all numbers from 0 to 5 for MY_RFM69_IRQ_NUM.

I also tried pins 18 and 19. I can't use 20 and 21 since I'm using I2C comms.

No matter what I try, I'm still getting the same error.

I searched through the forum and on the inet with no success.

I'd really appreciate if someone could point me in the right direction... thanks!

It looks like your sensor is not getting a proper id. There are quite a number of things that coiuld be causing this. Is your gateway connected to a controller?

Hi @atzohy

The info in the page is confusing. The small board between the sensor and the arduino is an on-off level switcher. It provides a digital binary singnal so can't be connected to an analog pin on the arduino.

If you wish to measure the moisture level with an analogic scale, you need to eliminate that board and then use a voltage divider and an analog pin. The sketch will be also different. Everything in explained above in the thread.

You may want to read the full thread and then don't hesitate to come back with your questions.

@zachflem There are no ESP based boards wich such a high number of GPIOs that I know of. But there are some MEGA + ESP boards out there. I'm not sure they would work with Mysensors but may want to have a look.

https://robotdyn.com/mega-wifi-r3-atmega2560-esp8266-flash-32mb-usb-ttl-ch340g-micro-usb.html

https://www.instructables.com/id/Arduino-MEGA-2560-With-WiFi-Built-in-ESP8266/