Hi @pierrot10 and others,
Sorry, I was called away unexpectedly...

I've had no experience using nails other than testing the gyprock ones in the link I sent.

I think your idea of 9 pairs spread across the wall is excellent as the key data you seek is the moisture source and how it progress across the wall.

You can just connect the 9 sensors to one of those analog switch modules and the Feather and start logging data. You biggest problem will probably working out the distance between the 2 nails. Once it setup (in summer), you can make sure they all read the same value by a software 'calibration value' for each pair.

I'd also suggest putting a newer BMP680 device in the room, perhaps 3" to 6 " away from the wall, just to have a temp, humidity and barometric pressure. I don't know exactly what it my tell you, but one thing I have learned is 'data is like money', there is no such thing as too much! (especially when you only get one shot at it a year).

I think your chances of success look good as long as the distance between the two nails give you a sufficient data range.

Good luck, and I look forward to reading how it turns out.

Paul

@zboblamont maybe it was Trump asking the question (in disguise)?

Paul

@8667 while you are probably correct, the lack of info makes that an assumption. I chose to answer in detail, just in case it was a serious question and there may well be reasons why fixing is not an option at this stage.

Regardless, I hope the answer / method may be of later use to someone else with a 'similar' need to measure the moisture content of something other than soil.

But yes, I too will be keen to see if or when the OP comes back.

Paul

Hello @pierrot10,
Firstly, let's talk about normal ambient (outdoor) humidity for a moment, 100% means the air is saturated with the maximum moisture as it can hold.

In a normal hose, the humidity will typically be the same in every room, unless there is some special factor, e.g. the bathroom humidity will increase dramatically when someone takes a hot shower.

Next, let's think about a humidity sensor, it can only read the humidity in it's immediate (close) proximity.

Now, let's look at the wall in question, is it a normal wall in a normal house? This would be helpful to know, i.e. if it is a wall in an underground cellar (basement) it helps to explain why this particular wall is getting wet.

The fact that the wall is getting wet tells me the humidity in the immediate (close) proximity will almost certainly be 100% when wet and probably ambient 'room' humidity when not. This is where I believe your solution may be, and here is what I would suggest, assuming you want an alarm when the wall is in danger.

My Suggested Solution
I'd suggest you get two small humidity sensors and connect them both to an Arduino and make adjustments as needed in software so they read the same value (at your desk (workbench).

Note: One sensor is to be mounted in the wall and the other to be located in the room, 500mm to 1 meter distance away from the wall, so make your wires the necessary length before you calibrate the sensor readings.

Drill the smallest diameter hole in the wall to fit one sensor in. If the hole needs to be say 20mm diameter, make the hole 40mm deep (100% deeper). I would suggest you angle the hole 3 to 5 degrees so any excess moisture can drain out (and not damage sensor).

Insert one sensor all the way inside the hole, then cover the hole, but NOT airtight. Some examples: Find a plastic bottle cap the same (similar) diameter as the hole in the wall and drill lots of small holes in it. Another option would be to go to your hardware store and buy a small amount of "fiberglass fly screen' (mesh). Use two layers to make the mesh finer (smaller).

The Arduino Code

There are many ways to do this, but based on previous work with humidity sensors, here is what I would do.

a Lora radio will not give you the distance you need, so I would use an ESP8266 or ESP32 chip (with WiFi). The ESP8266 Node 1 would be ideal for this project and is very well priced. This will allow the device to upload the data to a cloud server, of which there are many free ones to select from (check out AdaFruit's I/O Cloud Service, from memory it offers nice graphic display of data etc. I support / recommend AdaFruit because the provide lots of free code and drivers to the hobby community. It's a nice way of saying thanks!

The WiFi device will also allow you to remotely connect, read the data, modify sensor calibration values etc and most importantly, you will be able to perform OTA (over the air) software updates.

*Create a 3 by 24 array of bytes for data storage.
*Every 60 minutes, take 5 readings from in-wall sensor, discard any obviously bad readings, and average the good values. Repeat the same for the in-room sensor.
*Record the hourly average for each sensor as well as the difference between to two (just for convenience), into the array of bytes, using one set of 3 bytes for each hour of the day.
*Upload the three hourly values to a cloud server, along with the date/time as required.
*At midnight (hour zero), just overwrite previous array data values.

Reasoning Behind Design
By placing the sensor deep in the wall and covering the hole a bit, this sensor will read the humidity in its immediate environment, but the holes are important to make sure water does not accumulate in the hole and damage the sensor or cause faulty readings.

By having a second sensor away from the wall, it will read the general room temperature. Be comparing the two values, you can raise an alarm when the in-wall sensor is greater than the in-room sensor by x%. This way, on cold damp winter nights, when the in-room sensor and in-wall sensor read say 93% and drop the next morning to say 70%, you know that 'normal. But I am sure over time, you will see the the difference between sensors will steadily increase as the wall accumulates more and more moisture.

Once you 'prove the system', you could have the Arduino turn on a heater, blowin(g) on the wall etc etc.

Possible Adjustments

• If during the first winter testing you find moisture collecting on the sensor PCB, increase the ventilation holes a bit at a time.

• If you find the value of the in-hole sensor is almost always the same as the in-room values (even when the wall is damp / wet), Roll up a narrow (10mm) strip of newspaper, but NOT too tight and put a pin through it to hold it together as a roll (i.e. decrease the ventilation flow, but do not block it completely). You just want a small 'roll' of newspaper to put in the hole close to the vent. This paper will act as a 'buffer' to isolate the in-hole sensor from the outside, maybe a small piece of sponge will do, but just make sure nothing touches the sensor.

I can't guarantee you this design will work, but it is how I would tackle the problem and think you will find it produce fairly useful data to make a decision with.

Good luck, and please post your progress as I'm sure others would like to know also.

Paul

@grumpazoid one thing I meant to add..

The way you propose, using a battery and regulator is the ideal path. Removing the LED is critical as the LED would probably use more power than everything else.

One thing you may not realise is the Arduino and motion sensor can run on as little as 1.8 volts, providing all regulators are removed and the battery starting voltage is no more than 3.3. If you use an alkaline battery, you can suck on those babies until they reach 1.8 volts, at which time they are pretty much empty. Whereas rechargeable lithium batteries have builtin 'over-discharge' protection which switches off the output a 3.[something] volts.

I suggest considering 2 by 'AA' cells in a holder, with the Arduino mounted on the back of the holder with double sided sticky tape, or my preference where size is important is to use one CR23 (3 Volt) battery (they are about 2/3 the height of one 'AA' ). Either option should give you over a year between replacement.

NOTE: On ALL MySensor nodes, make sure the antenna section of the (standard) RF2401 is not directly on top of anything metal. Where possible, let that antenna part overnang the battery pack for example. It's not critical, but could cost you 20% to 25% of your range IMHO, so I try to keep it clear wherever I can.

I've seen it argued that metal behind the antenna, can act as a 'ground plane' and actually boost range. I'm certainly not a radio expert, but even if that is true, it will make the antenna very directional, meaning signals to/from behind the 'ground plane' will be blocked. All I can say is I haven't had any range problems will any of my nodes, including some in another building.

Whatever battery arrangement you use, measure the voltage of a fresh set of batteries (in use), and make a note of the voltage when the node dies. This will then give you the useable voltage range which may be for example 1.83v to 3.12v. Once you know the usable range, you can then modify your code to calculate and send a very accurate "Battery Remaining %". In the meantime you can just guess the 'empty' voltage.

Paul

p.s. You don't have to wait a year, you can just put in a fairly 'empty' set of batteries just to see the point at which the node dies, if that makes sense.

@grumpazoid yes, you seem to be right on track.

One other point that may save you some grief, mount the motion sensor away from the RF2401 and gron the voltage dropping device, assuming it's a 'buck regulator' (which is more efficient).

Both the regular and the RF radio output high frequency noise which can cause false triggers by the notion sensor. But, be warned, distance is a double edge sword, the further away the motion sensor is (longer wires), the more prone it becomes to power supply noise. So just don't place the motion sensor right on top of the radio etc.

On the positive side, 'electrical noise' can be fixed with a capacitor. Try putting a 47uF capacitor on the motion sensor across the points where the positive and negative power wires connect. (Note the capacitor is polarity sensitive (look for the negative marking). If you still get false triggers, you could try increasing the capacitor to 470uf, but in my opinion, if 47 doesn't work there is another problem somewhere.

Also, from memory, those sensors need a fairly long warm up period before they stabilize, so you should get your code to ignore any readings initially. I think it's under a minute but do a google search for "HC-SR501 warm-up" to check.

You can simply sleep(xxx) in the startup loop, or ignore all triggers with a statement like "if (millis() > 30000)". The value returned by the millis() function is the number if milliseconds since startup, so you could only do a 'send' command if the milliseconds are greater then the warm up period.

Paul

I agree with the others, low cost sensors vary from one unit to another. For many, where they refer to "Accuracy", they often mean repeatable accuracy, which basically means if its calibration is out by say +5 degrees and they quote an 'accuracy' of plus/minus 1%, it will always read an extra 5 degrees plus or minus 1%.

As a result, I started paying extra for 'factory calibrated' devices, but as you have found, this appears to mean very little.

After purchasing and testing a LOT of devices and constantly being frustrated, I ended up building a test node with two each of three different sensors (6 in total) which I calibrated myself and used offsets to get them reading the same. That test node also computes and transmits average values also. Over a long period of time I found that an individual sensor will go out a bit, then return to match the others. A year later, I repeated the calibration tests and the avg value was spot on.

Now, whenever I build a new device, I build offsets into the software which I can send to the node (using MYSController) and they are stored in EEPROM. This allows me to occasionally check its value compared to my 'test rig', and correct any offsets without taking the unit apart or reburning the code.

My conclusion, after four years of using just about every reasonably priced ($2 to $12) device on the market, is that there is little difference between most of the units once you have set the correct offset. As a general rule, they all seem to drift occasionally and by similar amounts, but return again. Most importantly, by having a 'trusted' set of values to compare a new sensor to, I can recognise a faulty sensor very quickly, typical symptoms being they often need a larger than normal offset and the next day it's reading is significantly different again. At first, I tried adjusting the offset again and again, but now I toss them straight in the bin. If a new sensor (regardless of price) can stay in sync with my test rig for 48 hours, it will continue to be moderately accurate.

Cheers

Paul

Hi, Just a few comments that you may find useful. Because this is a battery powered device, I assume battery life is reasonably important and there are improvements you can make.

The IR Motion sensor you are using is actually a 3.3 volt device and has a regulator to drop the 5V input to 3.3v, so it's just a waste to use 5V only to drop it to 3.3v. Although I have not measured how much energy the regulator itself uses, but it may be more that the Motion Sensor itself which only draws 50 micro-amp (50 millionth's of an amp). The circuit for that device is available on the internet and you can actually bypass the regulator just by changing how one of the jumpers are setup, i.e. no soldering, or you will find posts here on how to remove the regulator (and a diode). Just look at the circuit, find the regulator and look at how it is connected to one of the jumpers and you should be able to work it out.

Another option is to try running the motion sensor (as it is) direct from the battery. The regulator is probably an LDO (low drop-out) meaning it will accept an input from 5V down to a little more than about 3.4 volts (as the battery drops).

If you are not already using sleep mode and interrupts, you should as it's possible to get the average power consumption to not much more than the battery's normal self discharge rate (shelf life). With that particular sensor, you should be able to achieve a fantastic battery life by putting the Arduino and radio to sleep and only waking when the motion sensor activates. You simply need to connect the motion sensor output to the Arduino pin 3 (which is an interrupt pin). There is a good example (with comments) about using interrupts in the MySensors examples folders, it's called something like "Binary Switch Interrupt". (I'm not at a computer with Arduino at the moment)

A well designed interrupt based node can easily run more than a year on a set of batteries. I have been running a node with Temp, Humidity, Pressure and digital Lux sensor reporting whenever any data changes, or after 5 minutes with no data changes. It's been running two months now and hasn't even dropped one hundredth of a volt, so far so good.

Good luck!

Paul

Hi @mfalkvidd,

Problem is, when your code can't compile because you are one (or several) bytes short of ram, nothing else matters.

As to readability, I assume you know about that rarely used compiler feature called 'comments'? I hear they use zero Arduino RAM and even less ROM memory. .

Ok, I'm just being cheeky, so don't flame me, it just seemed a good opportunity for a reminder to everybody. Point being we are all guilty of not using enough comments in our code.

You said you are worried about readability and maintainability - it's just like code backups, it's a problem only because we only worry about them 'after' a drive crash, or in the case of comments, two years later when we are trying to remember what the hell this weird code does.. THE REALITY: If we are really worried, we would add liberal comments and do regular backups - otherwise I say we're not really 'that' worried.

Cheers,

Paul

@strixx
BEFORE YOU USE analogRead()
You need to be aware that the MySensors core Ver 2.2 has code to support sensors reporting the chip VCC voltage. As I recall, this code is enabled by default and all readings of the analog port will return 65,535, -1 or hex FFFF, depending on the type of variable you read the value into regardless of what voltage is applied to the analog pin. MySensors has changed the 8266 configuration to read the chip VCC and ignore the analog input and I gather the MySensors coders decided to return 65,535 as an indicator.

You will need to do a search for "ESP analog read" or similar, to find the correct syntax of the special command to change the 8266 mode to re-enable reading of the analog input pin. Note: this analog mode command must be placed at the top of your script before any other functions.

DIFFERENT NodeMCU BOARDS
Please be aware the analog pin 'hardware' varies with different NodeMCU devices and you need to understand how the MySensors restricts how you can use this pin.

First, I have encountered three different 'NodeMcu Ver 1' boards. Traditionally the analog pin expects a range 0V to 1V max. Some docs state going over 1V can destroy the pin, others state it can tolerate 0V to 3.3V but the anagloRead() for voltages of 0V to 1V are as expected, but 1V to 3.3v returns the same value.

On the earlier boards I received, the analog pin of the PCB was wired direct to the 8266 chip (in the metal can) and not connected to anything else.

About a year ago, the boards I received had additional circuitry to protect the analog pin from excess voltage.

More recently I have received a batch of 20 boards which returned values lower than expected? Suspecting a board problem, I traced the circuit and confirmed there is a voltage divider which scales an input of 0V to 3.3V to become 0V to 1V at the actual 8266 chip. I.e. these boards requiire a 0V to 3.3V input on the analog pin. If you code reads values about one third of what you expeted, you may have a 0V to 3.3V board.

VALUES NOT CONSISTENT
As a final tip, I have noticed that no two NodeMCU's return the same value from the analog port. I.e. five 'identical' boards from the same batch will return slightly different values, unlike the Arduino devices, which I find all return accurate readings.

My assumption is, this is due to the 8266 using a different analog to digital conversion method, and the errors are 'possibly' due to some capacitive effect. The differences or minimal, can can be confusing and may need special attention if you are checking for a 'specific' value. Hint: always code analogRead comparisons to look for different 'ranges' of values, rather than "if analogRead(A0) == 350", because the value you get today could be different tomorrow or next week. This is good practice because the value read will vary slightly as your project's supply voltage changes due to changes in load (e.g. several LEDs turned on vs off), or even if your battery or even mains voltage is unstable.

Hope this saves someone banging their head against a brick wall for hours like I did.

Paul