Arduinos In The Grow Room: My Project

[odam2k]

I think I may try using a dc motor driver L298N based, since the pump IS just a dc motor... I'll try that later tonight if I'm up in the middle of the night, as usual...

Well, that didn't solve the problem, so, it HAS to be the pump. I don't know how yet, but noise somehow being transferred into the system... This time, the LCD screen seemed ok, didn't glitch, but as soon as the pump came on, my code started complaining that it couldn't read the DHT22 digital humidity/temperature sensor. In my code, it toggles the power to it if the reading comes back as NAN. I did notice this popped up in my earlier testing, but usually the LCD had already glitched, so I ended my test...

The pump is physically about 4 feet away from the arduino. Keep in mind, if I power the pump DIRECTLY without trying to switch it on or off using the arduino, everything works fine.


Time for a break...

 

[odam2k]

I've read that the Mega 2560 already has 10K Ohm pull up resistors on the SDA and SCL lines, so I removed the ones I added, again, no difference...

I may just step back and rethink this... I'll start with a standalone Pro/Mini who's only task is to control the 8 relay module based on what I type into the serial monitor. Once I can confirm that there are no issues there, I will consider how to communicate with the Main Module.

 

[odam2k]

I started fresh, I have an Arduino Pro/Mini hooked up to the 8 relay module. At this point, there is no i2c hooked up, or included in the software... I've also used TWO different Arduino Pro/Mini's

Interestingly, the problem seems to lie in the Serial port, not the i2c bus.

I have a button, and when I press it, it closes the relay, waits 360 seconds, then opens the relay. During that time, it prints the elapsed tie on the serial monitor every second.

In setup() I do a Serial.begin(115200);

If the USB is plugged in (CP2102) (DTR/TX/RX/VCC/GND) it does something to the serial port that causes it to stop printing properly, and reboots the pro/mini It also glitches the other Arduino Mega which is plugged into the same USB Hub! There is no other connection between them... The Mega is also powered externally from a 12v source.

If I power the Arduino from an external source, so the USB is just DTR/TX/RX/GND, same result...

If I remove the USB altogether, and just power the arduino from an external source, the pro/mini activates the relay, the pump comes on, and after the "duration" time specified, shuts the pump off. Works fine... It does not reboot.

Also, if I do NOT power the pump, but simply have the relay close, then everything, including the serial port works fine...

It really sounds like a power brownout, all the symptoms are there...

But!

The Pro/Mini and the Mega are powered externally, and do not rely on the USB for power, the external power is provided by a converted PC Power Supply.

The Relay board (coil power) is provided by an external 5v from the PC Power Supply

The pump is also powered from a 6v DC DC Stepdown module on a 12v wall-wart power supply.

So, I can't see it being a power brownout...

 

[odam2k]

Sorry for all the drawn out rambling posts... it serves two purposes...

It lets me go back and see what I've tried, and re-read in case I missed something obvious...

It lets you in on my methodology for problem solving... I guess it covers my thought process, and how I tend to go at a problem. I am confident I'll find a solution, but right now, it's looking kinda bleak...

 

[odam2k]

One more note... if I power the Pro/Mini from the USB, but do not hook up the DTR/TX/RX, then it runs fine too...

So it's something to do with (the DTR/TX/RX lines) AND (powering the pump) <-- BOTH must be present to exhibit problem...

I wonder if a Nano or UNO would behave the same way.... one way to find out!

 

[odam2k]

ALRIGHT! I think it's an issue with the Pro/Mini, and also with the Wemos Mega 2560.

As I said earlier, I tried another pro/mini with the same results, so this time, I tried a Mega 2560, an UNO, and a Nano v3.

The UNO and Nano passed the test! Well, at least they went through a complete 6 minute pumping without corrupting the serial output. That's success compared to the pro/mini and mega which locked up the serial output almost immediately. I even tried a Funduino pro/mini, same problem...

So, I guess I'll replace the pro/mini with a Nano, and continue on with my testing. Once I'm happy it runs without corruption, I'll put the I2C code back in, hook it up, and try that.


As a recap, the problem appears to be either hardware or software related specifically to the Wemos Mega and the Pro/Mini (Funduino and Geekcreit) For some reason, the Serial port becomes corrupt, to the point it either stops outputting characters, or it actually glitches and causes problems with other arduino's on the same usb hub.

At first, I treated it as a problem with the I2C bus, then spent many hours chasing power issues as it REALLY looked like a brownout problem, although physically it didn't make sense....

I'm fairly confident this is it, fingers crossed!

 

[odam2k]

Over and over, it works!

I have it set up so that when you turn on a pump to water a plant, it first turns on another pump to stir the water in the bucket first, to make sure the nutrients aren't settling to the bottom....

I need to make up a custom shield to plug the nano into, which then plugs into the relay module. The shield will include pins for vcc/gnd/sda/scl and I'll try again controlling it from the main module via i2c.

 

[odam2k]

All done, ready to move on to re-enabling I2C access, and test, test, test!

 

[odam2k]

I2C works, but just a note, you must share ground too, not just SDA/SCL

I thought I'd power this nano separately, and just removed the vcc and gnd from the 4 wires coming from the Main Module. Immediately the LCD screen garbled on the Main Module... I am now powering the nano from the 5v regulator on the Mega (it is powered by 12v at VIN)

Wow, what an ordeal just to get a pump working eh?

Tomorrow I'll move the bucket and module into the grow room and install my first I2C Trunk Line I'll probably just allow watering on a "by command only" basis until I can see that it never malfunctions outside my expectations...

I already added the I2C connection on the back of Module 2, I'll just have to update the software and plug it in!

 

[odam2k]

Added an HC SR04 Ultrasonic Sensor to mount at the top of the bucket. It measures the distance to the water level, and deducts that from the depth of the bucket, and I know exactly how much water is left in the bucket. I'll have it check before and after each watering, and it will send that information back whenever the Master Module contacts it.

I think this part of the project is finished, I've been testing all day and no further issues at all! Guess I better order more pumps and relays... I guess I'll need a couple more Nano's as well...

 

[odam2k]

One last thing... I made the Ultrasonic Sensor into an I2C Water Depth Sensor Module. Yep, just because I could

 

[odam2k]

Oops, had a short between vcc (5v) and SDA on my custom perfboard module. I'm getting lazy, I usually check every pin with my meter to make sure it connects where its supposed to, and not anywhere else, a very tedious job sometimes...
That's what I get for taking shortcuts!

I couldn't figure out why whenever I plugged it into the I2C bus, the main module would freeze up. At least this one was easier to figure out, AND I did plug in my Relay Controller, my Dual Level soil moisture probe, and the Water Depth sensor, all into the I2C bus, which consists of about 15 feet of cable, and 4 home made splitters, so I am confident this is going to fit my needs...

 

[odam2k]

So I guess the next big question is, when to water plant automatically... (See, I hadn't even thought this far ahead... lol)

Obviously the number one most important rule is it should never flood my grow room!

I've already talked about the safety features, such as plastic tarping on floor, water sensors on floor, limited water available, etc.

What I'm talking about now, is, "who" decides when a plant needs water. By "who", I'm thinking "which process" is going to do this. More specifically, what is the process, and where will it reside.

Start with the current sensor reading
Is the current sensor reading VALID?
Compare against recent min/max readings
Are these min/max values VALID?
Is current trend up or down?
How long since last watering?

There's probably more...

As for where it will reside, I'm thinking of firing up another ESP8266 for just this task. All the information it needs is available from the MySQL database (which it has access to), plus, it can use the same database to actually command the appropriate Module (which controls the appropriate relay module via I2C) and it can check at the next sensor update to ensure it went in the pot

Basically I'll create a semaphore table in the database, and the two can talk back and forth like a chat room

To start, I'll write the "decision making" code for the ESP8266 first, then I can monitor the database to ensure it is making smart decisions before I modify the Module code to respond to the commands.

Obviously, I'll have to add something to the web server to allow watering plants manually.

Once I get to that point, I may revisit Android programming and create an app for that!

 

[DrewT]

Great progress!

Is the current sensor reading VALID?

In systems requiring high availability this usually means redundancy. Do you think designing redundant sensors in at the beginning is the way to go?

and the two can talk back and forth like a chat room

As your beginning to think about event invocation and scheduling, consider using an already functional protocol. MQTT seems to be the most popular way to pass messages between sensors, controllers, and storage/logging. This instructable does a decent job of explaining it with a video to boot! Using this messaging stack will save you a ton of time and make messaging more robust (multiple data stores could subscribe to a single sensor for example).

Setting up a MQTT broker on a Mega2560 or ESP32 is on my short list so any experience you could share with me on this would be extremely useful!

 

[odam2k]

Great progress!

In systems requiring high availability this usually means redundancy. Do you think designing redundant sensors in at the beginning is the way to go?

Thanks... No, it's not that critical if we just toss this round and wait till the next. We could report it if it continues to fail. I just don't want to turn on a pump based on invalid data...

As your beginning to think about event invocation and scheduling, consider using an already functional protocol. MQTT is seems to be the most popular way to pass messages between sensors, controllers, and storage/logging. This instructable does a decent job of explaining it with a video to boot! Using this messaging stack will save you a ton of time and make messaging more robust (multiple data stores could subscribe to a single sensor for example).

I will read some more on this, but it was the first thing I investigated, I was not prepared to share public servers (my data would be public unless I paid for a private server?)

I also don't want the system to rely on a working internet connection. When I say they can chat back and forth, really what I mean is that this module is capable of reading all the data from the database, so it already has everything it needs, so there is no need to talk to the sensors etc. When it's time to turn on a pump, it just updates a flag in the database, and when the module does it's "switch event scan" it will pick up on this and flip the switch so to speak...

 

[DrewT]

You and I have A LOT in common with our design philosophy . I will only dev systems that can opt into data sharing on remote data stores. Complete control and access to private data is a requirement. I also don't buy into the "wifi only" approach as my experience tells me robust and secure systems run over the wire as a primary exchange mechanism.

(my data would be public unless I paid for a private server?)

I also don't want the system to rely on a working internet connection

Although you can design direct-to-cloud implementation with MQTT, this is not the only way to use the protocol. Every network needs a message broker, and this can be local or remote. In your case, you would set up a message broker that would sit on the i2c bus and receive incoming payloads published by your sensor array. Then, your DB host could subscribe to the sensor messages (or topics) and insert records based on information in the message payloads it recieves from the broker. This can all exist in an air-gapped system, no requirement on external connections or data stores (except for downloading the initial libraries/code).


Check THIS video out (link starts video right where I think you'll care most about it). I really like how this guy demands there be no external dependancies in his systems

 

[odam2k]

I have no doubt that if I were already familiar with this technology (MQTT), I would already be using it but it seems like too big a topic to try to change my design midstream AND learn the technology.

I will certainly keep it in mind, and if I do another project which could benefit from it, I'll be sure to explore it. I just don't see that it solves any actually problems right now, although it is a different way of accomplishing the same thing (at least what I need from it)

 

[DrewT]

I understand, you've got a good thing going! I'm leaning towards using i2c for sensor modules but moving to CAN or RS485 + MQTT for wired communication between controllers. Here's my current reasoning (apologize for redundancy with things you've mentioned earlier):

• As you know, although i2c can go longer distances depending on shielding, bus extenders, and transmission rates, it's really meant for short distances. If I want to wire up even a smallish commercial greenhouse, i2c simply isn't the right physical layer for scale imo.
  
  
• The number of devices hosted on the same channel is limited to 127 for 8bit system.
  
  
• Unless you add a custom handshake to your protocol and scan the entire bus, you will need to statically assign roles and addresses of connected MCUs.
  
  
• All i2c libraries place some restriction on the packet size you can send on the wire. Larger payloads will need to be broken up on both ends and usually into very small packets (32 bytes seems common). Serializing JSON logs over the wire may move slower because of this.
  
  
• In the case where two MCUs both need to initiate communications, you're forced into making both MCUs multi-masters to accommodate bus arbitration logic.

In any case, as long as you stub out your interfaces well it should be a straight forward adaptation from i2c to whatever. I'm not advocating you change direction, I'm just giving you my reasons for limiting exchange on i2c connected devices to slave sensor modules with close proximity.

 

[odam2k]

Can't say I disagree with anything you've said... I have no intention of using i2c for anything other than querying sensor data. When it requests data from a Dual Level Soil Moisture Probe, for example, it only expects 10 bytes of data in return, up to 3 ints (2 bytes each) and an unsigned long (4 bytes). No data is sent TO the sensor in this case...

In the case of the 8 relay module, it sends only a few bytes, and return will be just an acknowledgement.

It's always the Main Modules (there are two right now) which contain logic, and therefore have actual data to be logged, and acted upon. These modules are Wemos Mega 2560's with built in ESP8266's and are directly connected to the database through wifi. The only real "consumer" of this data right now is the "webserver" which lets me see what's happening visually.

This new module I'm working on, which I'll call processWaterPlants, will be running on an ESP-01 (ESP8266 standalone) and talk only with the database, not the modules, or sensors themselves. It will only act on the latest reported data, not initiate new data readings (although I can do that from a web interface).

I would very much agree, that as a primary data transport layer, i2c is not the way to go.

With that said, I am open to being corrected or re-educated if I'm just not seeing something obvious.

 

[DrewT]

I am open to being corrected or re-educated

Me as well! I learn every day. We'll put it all together at the end .