Troubleshooting, arduino not executing the code as it is written

Those earlier failures you had that mysteriously went away after a reset did NOT fix the bug(s), just masked them. No need to comment out the Serial statements, the bits just fall on the floor.

I see several items of concern, but first I would fix the following

if (moisture1_value >= 28)
{
digitalWrite(RelayPin1, LOW);
delay(43785);
}
else
{
digitalWrite(RelayPin1, HIGH);
}
{
digitalWrite(RelayPin1, HIGH);
}

The last 3 lines are wrong. Also, if the then and else are ony 1 line then the {} are not needed and just make the code volume higher with less understandability.

You have a lot of that kind of error and a lot more.

@fritigern

Posted by: @fritigern

Hello.

My Nano based project is having a nervous breakdown. (sorry, but it's the best way to describe it).

It is a system that waters my tomatoes by periodically detecting the soil moisture level in four separate planters and switching relays connected to the appropriate water pumps on for a duration as set in the sketch, giving the water time to soak in and doing a second read and half water splash of all four troughs and then waiting an hour and starting again.

I have tested it in the kitchen and it worked there, and I have ironed out problems like a faulty relay board, two not working pumps and a water sensor that reported the test parsley's soil to a lot wetter than the others did. As I have quite a lot of very cheap components I can expect some hardware faults from what is a pocket money project and thought I sorted them without cursing.

BUT now the little gizmo is screwed to the back wall of the house and the pumps are submerged in the water reservoir/mosquito nursery, all the wires are checked and in place the arduino has lost its mojo.

It is now cycling between turning relays 1 and 2 on, occasionally inviting number 3 to the dance. It showed willing on one of its expressions of independence by switching on relay4 but lost interest after that one go. It leaves the relays on for a lot longer than my sketch tells it. All the troughs are full of dry compost, so I was expecting it to do a full watering on all four followed by a second helping for all.

It is a warm day today (for England) at about 80 degrees F. I thought that the Arduino might be suffering sunstroke, but it claims to be good for up to 70 degrees C, which is quite a long way outside the environmental expectations here. I have powered it off, waited for the buck converter to power down and repowered the arduino a couple of times, but it does the same repetitive alternation between relays 1 and 2, and it it keeping them on for minutes not seconds.

When it gets dusk enough for me to re-upload the sketch I shall do that, but I am out of ideas. It did have a minor breakdown during testing a month or so ago when it did a morse code trick with the relays' LEDs, but a restart without re-loading the sketch sorted it.

Has anybody got any suggestions?

Thank you

Fritigern

sketch below, it worked in testing without laptop attached but Serial.print not commented out

1tommy_gizmofinal_test_screenprint.ino

 

A few things I'd like to point out...

Firstly, the Analog to Digital Converter on the nano is 10 bit, which 2^10 = 1024 values, which equals the range of: 0 - 1023. This means that you can completely remove all constrain functions from your code, as the values will always fall in that range.  Likewise the "map(...)" function's job is not to "decimalise the readings" - The readings are integers, and the "map(...)" function itself performs the constraint of the values to your desired range.

Secondly, you should not use the "delay(n)" function at all, and prefer to use the "millis()" function instead by storing it's value and then checking against that for your desired period.  The "delay(n)" will suspend all execution until it's time is up, which means that once one box is read and the delay activated, then no other if statement will even be read for other boxes until the delay has passed, and I don't think that is what you want

Thirdly, @zander has pointed out the errors in your if statements, but I'd also like to highlight that you have repeated a number of "digitalWtite(...)" statements in succession, which doesn't make any sense at all, so you might want to correct that too

Cheers

Thank you both.

My code passed the tick box check, the superfluous (constrain) and (map) commands are a signature of asking Mr Google too find similar code and then me editing it.

Ron, the different lengths of delay for the pumps was a deliberate attempt to equalise the output of each hose- and to account for differing lengths of hoses. The long hoses deliver less volume of water in a specific time period than the short ones, so after a test I increased the duration to account for that. These are little "impeller" type pumps, so they can "slip water" ie you can block the output and they will turn without receiving damage until the output is opened. On reflection the power of the pump will have little effect on the volume of water it can pump unless the hose friction starts to induce water slipping, but it will affect the height it can lift it to, so a high resistance pump attached to a long hose needs more time to deliver the same water volume as a low resistance one on a short hose. I had no idea about using the "style" thing. The "uint16_t" lines became necessary when I added the "constrain" and "map" lines to the original sketch that simply set the "int moisturex_value" to 0. With "constrain" and "map" added the sketch failed the internal credibility test until I added the "uint_16". I can't remember whether I commented out "int moisturex_value" because it was necessary or the sketch failed the test with it enabled. I don't see an A10 in the code, I use Digital 1o to power up the sensors because they don't need much current and I can switch them off after they have done reading. When I had the sensors powered on 24/7 in kitchen testing the results were counter intuitive, with a plant reported as  gradually getting wetter without receiving any water. I don't know if the tiny current attracted moisture over time, but switching it off between reads made the outputs conform to common sense and simple plant biology. As an aside, dropping a sensor into a glass of water gives a reading of 95, ie super dry, but living it dry and out in the air gives a reading of about 50. I'll compare your corrections to my code and learn.

it would have been less problematic to have electronically controlled stopcocks applied to mains pressure hoses, but I have not seen such things, nor am I in a position at the moment to make and attach such a rig to the garden tap. it's a lot of work for a dozen tomato plants. Though thinking about it......

frogandtoad, er yes, I now see it is unnecessary to constrain something to its own range, and I did feel that not using map would merely require me to use non- mapped thresholds for the dampness (which I already had from earlier iterations of the sketch's evolution), that was very much a Google-inspired diversion. The Delay function  is to shut down activity so that the water has ten minutes to soak into the soil to make the second reading informed by the addition of the first water splash. the "digitalWrite" statements after the "else" statement to the same effect, I thought I was "making sure" it didn't leave a relay set t LOW, ie enabling a pump.

I did re- upload the original (unnecessarily verbose) code in the garden using my laptop, and the thing worked fine powered by the USB, the sensors measured the water in the soil and the relays fired in sequence, then it waited and did the same thing again.

This would have been fine except the pumps didn't come on..... because they had no power supply.

The pumps have individual resistances of a little over 10Ω which means they draw a bit less than 600mA at 6V and less than 500mA at 5V. (or <3W at 6V, <2.5W at 5V) I believe this is too much for the Arduino to supply, especially as the power out pin has got to provide power for the relay board at the same time, hence the Buck converter/ old 12V power supply solution.

As soon as I plugged in the 12Volt power supply the Arduino went bananas. it reread the sensors and then alternated between enabling (ie LOW) the relays for pumps 1 and 2 for random periods of time.

So the power supply induces an imaginative interpretation of the code. BUT the same code worked indoors with the 12V supply. Yesterday (in order that I could monitor the sensor reads) I didn't pull the USB cable before powering up the 12V supply, which I had done in testing, so that could be the issue, but I now need to get to work with my multimeter and oscilloscope to check that the 12V DC power supply is giving a completely constant 12V.

But after I have tidied the code and ironed out the power supply problem, physics is a bigger problem..... After I returned from posting yesterday I found my reservoir/mosquito nursery with four inches of warm water in the bottom. As soon as each pump turns off it turns the pipe into a siphon and lets nature do the rest.

Again, thank you for your help and explanations. 

OK I have sorted it.

1- nervous breakdowns- these were caused by running the arduino off the 12volt power supply. Everything always worked when it was powed via its usb, but the 12V (and a 9V phone line handset charger) gave it electronic indigestion. The code changes merely stopped the pump relays from switching off so I reverted to the original. I have the arduino powered by an old smartphone charger through USB and the pumps still running off the buck-converted 12volt supply.

2- syphoning of water out of the reservoir/mosquito nursery- the only way to deal with this is by a wier system using an extra pump and relay and a piece of dowel to hold the pumps in a diagonal upward configuration. So now a pump fills the wier (a former washing machine soap-pod container) for a couple of minutes and then the first pump fires up. On ending it will try to siphon water but will drink the water down to its base as the next pump will be  sucking its share. When the final pump is done arduino switches off the wier filler pump, leaving the last pump just the water below its neighbour's base to siphon and job's a good 'un.

F.