Troubleshooting NULL data

I haven’t had much to say over the past bit, due to a LARGE amount of troubleshooting I was doing over the last week.

After Charles and I got the bank of Neopixels repaired and reinstalled, a new problem surfaced. The NodeMCU was doing a lot of crashing and rebooting on a new and completely frustrating level.

The short version of the explanation, best that I can tell, is that my soil sensor (or lack of) was the cause.

The first data that the Uno looks at while going through the loop of commands is the TDS, which was connected and working happily. After processing the TDS sensor, the next step in the loop was looking at the soil moisture sensor.

Using the serial monitor, I figured out the “tdsTransfer” data was dropping around the time the Uno was processing the Soil Moisture data and saving it as “SoilA”. After a few days of head scratching, I was (eventually) able to figure out that the soil sensor wasn’t connected to the Uno, and that the pin I thought it was connected to (A1) was generating a phantom value. When this phantom number was used to create “SoilA”, it had the unexpected side effect of causing my tdsTransfer data to nullify. POOF! Bye bye.

As soon as I reconnected the soil sensor, my tdsTransfer data reappeared on my final output and everything started running smoothly.
That took me about 4 days to figure out. Ugh.

There is one other thing here that bears mentioning… something that kinda (seriously) breaks my initial theory on the cause of the problem.

I disconnected the soil sensor again, and it didn’t break anything.
The Soil numbers did go wonky, however not quite as wonky. My initial phantom numbers were in/around -110 , while the second (deliberate) disconnect yielded results around -98. Could that extra digit have been the deal-breaker somehow?

Cannabal

Part time mad scientist, gardener, tinker and dreamer.

https://www.cannabalurges.com
Previous
Previous

Scheduling A&X data

Next
Next

Props, Charles!