Arduinos In The Grow Room: My Project

[odam2k]

Friday, July 5, 2019
GBW Serial Terminal - Update #6

Seems I can't just leave this alone...


Two new features here today.

First, the modules all synchronize their clocks with the MySql Server, which is synchronised with all the other computers on the network. So my development machine will have the same time within a second or so of any of the modules...

The first new feature is an upgrade to an old one. The terminal has been displaying the clock time of the module it is connected to, the idea was that you could compare it to the current time, and you'd know that it was still alive. Then I found a way to be even lazier... The Terminal can monitor the time that the module sends, compare it against the computers clock, and if they are more than a minute apart, the text turns from DarkGreen to OrangeRed, and more than 5 minutes, white on a red background, you can't miss it, even across the room...

Hmm, perhaps an audible warning too? I'll throw that on the todo list....

The next new feature, 5 status lines... These are lines on the display (Just under the RSSI) that each module can use for anything it wants. There are 5 lines available, and using a {{STATUSLINE:1}} tag it can write whatever follows, up to end of line, to Status Line 1. In the screen shot below, the Sensor Module is updating Status Line 1 with the total number of sensor readings taken, the number successfully written to the database, and the number that failed... These numbers are maintained by the module itself, updated when it wants, and in this case, they are updated after every sensor scan, and reset when the module is reset, so this status line will give me a good idea how things are running...

 

[odam2k]

As you can see, I'm taking a bit of a break here...

There are a couple posts on the blog I didn't copy here discussing the communication between the Meg 2560 and the ESP8266 over the hardware serial port. What it boils down to, is the bidirectional traffic, with requests and responses, as well as what are basically push type traffic where data is sent that wasn't specifically requested, such as sensor scan results, module status reports, etc. The problem stems from push type data being sent while requests are still either pending, or being completed. In essence, it's a flow control problem, although not in a hardware sense.

I've had a couple ideas on how to approach this, but because I already made a bad less than ideal choice in how it works now (discussed on the blog) I want to make sure I find the best solution, so I'm in no rush...

Right now, everything is running as well as it ever has, I'm really very happy with it, and in fact, it's getting extremely hard to find new ideas and slip them in. Seriously, I never check plants to see if they need watering, and I never see droopy plants any more.... Once I can afford the pumps etc, I'll be doing completely automated watering, but financially, it's not a top priority.

When I get in a situation like this where sitting here thinking about it isn't getting me anywhere, I just walk away from it, stop thinking about it... First, I sit down and define the problem as best I can, in writing (point form) in a file called thoughts.txt which I edit right in the IDE. Here, I organize, yep, my thoughts... Once I've defined the problem, I start outlining any possible solutions... They down't have to be complete solutions, and can be outside the box so to speak, since I'm just gathering my thoughts at this point. Then I forget about it, move on to something completely different, or go take a nap, or anything to get it out of my head. While I'm otherwise engaged, there's a little part of my brain that, in a background thread, taps into the cosmic knowledge base and sifts through it, and if and when it finds an answer, it will fire an interrupt in my brain, and I'll go "Eureka!"

Ok, it doesn't always work like that... but it has served me well. If I get an idea, I go back to my thoughts.txt file, add it, and review what's already there... If I still don't see a clear answer, I go away again, do something else...

So, it's been a week now, my documents is growing, but still haven't decided yet. No big deal, I'm not in any rush, like I said, it's running fine now, but I do want to make changes more for future capacity...

To keep busy, I've gone back to my R/C cars. My 1:6 scale Beetle is a full FPV rig, meaning I drive it using a video screen and a camera mounted pointing out the front window. I also have a Mustang and a Camaro, each smaller than the other. These are all TOY radio control cars that I've converted to using proper 2.4Ghz radio equipment and modern servos. The radio gear and servos are all left over from my R/C hobby days, so this has been an out of the drawer type project. Anyhow, the Beetle has an OSD, or On Screen Display, module which overlays text on the video from the camera, so when I've driving, I can see things like GPS position, direction, speed, battery voltage, current draw, anything I deem important enough... This OSD module is an Arduino Pro Mini and a Max2456 breakout board, and software I wrote last summer. The Camaro has no Arduinos in it, but the Mustang does. I didn't have another ESC (Speed controller) for the brushed motor, but I did have an L289N H-Bridge Motor Driver board, so I hooked it up to a Pro Mini, and wrote the code to read the R/C receiver channel for the throttle, and to send the proper commands to the L289N to control the motors speed and direction based on the transmitter commands. I also created a voltage sensor for 12v, and monitor the battery voltage so if it gets low, it will limit your speed so it doesn't damage the lipo batteries.

Anyhow, that's what I've been up to, and why there have been no new posts...

 

[Latitude17]

Have you looked in to MQTT for your messaging? I'd highly recommend it if you haven't already.

Glad you're taking a break, that's how the creative mind operates... the ebb and flow of creativity isn't something you can just do on demand and we all need a bit of time to decompress too!

Will be very interested in following along with your pump automation!

 

[odam2k]

Have you looked in to MQTT for your messaging? I'd highly recommend it if you haven't already.

I only need to pass messages from the 2560 to the 8266, both ways. MQTT requires access to a server? (broker?) The 2560 has no network access, that's why it needs to talk with the 8266. They will communicate over the hardwired serial link between them.

Will be very interested in following along with your pump automation!

Funny you should mention that I just plugged the AutoWater module in tonight for the first time in weeks. I've made so many software changes to all the other modules, that this one doesn't work any more, lol... Once I get the codes up to date, I'm thinking of going ahead and automating a couple plants just to get some idea of how it's going to work...

I've also made another changes, small, but important. I've been using what are called Dupont connectors, the servo plugs we're used to when connecting our arduino stuff together. The problem is, with two wires, there is no shell for for the female end, so you end up just butting the two plastic connectors together, one with pins, one with holes and hope they stay together. I use these to connect the soil moisture sensors to the wire going to the module. I've switched to the red JST plugs like you find on batteries. I picked up 100 pairs of pigtails, so I don't even have to crimp, just solder the wires together... These are solid connectors...

 

[odam2k]

Tuesday, July 16, 2019
Sensor Module update - confirmation of database inserts

Nope, don't need em...


Oh, you'd like to know why?

I'm still looking into how to better manage sending data between the Mega 2560 and the ESP8266 which share a circuit board and hardware serial interface, but certainly any decrease in the amount of data sent back and forth will help.

Originally, when the Sensor Module booted up, the 2560 would request a copy of the module configuration from the 8266 by sending an XML request string over the serial port. The 8266 would query the mysql database over the WiFi connection, and return the configuration data to the 2560 over the serial port, again, in XML strings.

Then the Sensor Module requests a copy of the Sensor Configuration, a list of all it's sensors... the 8266 again, gathers the data and sends it back over the serial port.

The 2560 scans each of the sensors to get its reading, and sends it all back to the 8266 again, which writes the data to the mysql database. The 8266 then sends the confirmation list back to the 2560 with the record id from the database for each record inserted. Nothing is done with that information other than displaying it on the 2560 serial monitor output... That's a lot of back and forth just to save the sensor readings.

Each time the module does a sensor scan it also reloads the module and sensor configurations....

With all this back and forth, it was hard to tell where data was being lost when some data was not being written.

First off, I added an Acknowledgement function on the 8266, so when the 2560 sends data, it can, in certain instances, expect an acknowledgement.

So now, the Sensor Module loads it's Module Configuration ONCE at boot up. Unless I change the configuration, reloading it is a complete waste of bandwidth. Originally, I didn't expect the system to be as complex as it is, and this never would have been an issue. I will let the 8266 check the last update timestamp every 10 minutes or so, and if it finds an updated record, it can just go ahead and send it to the 2560 as required.

I THINK I'll do the same with the Sensor Configuration... I say think, because I'm not certain yet... Changes to the sensor configuration is more likely to change than the module, and checking a last update timestamp on every sensor all the time would be a resource hog as well, so some thinking to do on this one still...

Now, sending the data from the 2560 to the 8266, and sending confirmations back. Here's where I made the biggest change. Because the 2560 sends all the sensor data to the 8266 BEFORE the 8266 starts writing to the database, I was never guaranteed it got all the data... I know that on occasion, records got scrambled or lost... Now, each sensor data record is sent, and then the 2560 waits for a specific acknowledgement from the 8266 for that sensor. If it does not receive the ack within 5 seconds, it will resend the data for that one sensor. It will retry up to 5 times. Once it receives the ack, it moves on to the next record, and sends the data for the next sensor...

The 8266 now has all the sensor data, so it goes off and writes it to the database, and that's it, there is no confirmation response back to the 2560, since the 8266 already acknowledged receiving each record, and is therefore responsible for ensuring it gets saved.

Now, because there is no indication of when the 8266 finishes writing all the data from a scan, the possibility exists that the 2560 will attempt to send more data before the 8266 is ready. In this case, there will be no acknowledgement, so the 2560 will simply retry sending it...

Right now I've got this new code running on Sensor Module 2, which controls the sensors in the Flower Tent, and out of the first 100 readings, all 100 made it to the database...

 

[odam2k]

DIY Photo Sensor (Light)

I needed another Light Sensor today, and realized I haven't written up any instructions how to make one for the system.

A light sensor consists of a Photo Resistor, an electronic component that changes resistance depending on the amount of light striking it's surface.

I'm using 5mm LDR Photo Resistor GL5528, which I purchased online, I think it was 20 of them for around $6 with shipping. I presume any photo resistor will work.

Like any resistive sensor on the arduino, you will need a voltage divider. You can either put the resistor and photo-resistor on a small perf board, or keep them seperate. I have done it both ways. If you put it on one board, it will look something like this:

This is simply the voltage divider and photo sensor combined on one tiny perf board. This sensor will require 3 wires back to the Sensor Module, so is useful if it is located close by. The one I needed today was for the Flower Tent, and the wire from the Sensor Module to the sensor location is about 15 feet, so I prefer to place the voltage divider closer to the sensor module, and use just 2 wires, I can use cheaper discount speaker wire I buy at an electronics store in Markham for about $2.50 for 30'

I simply solder the photo resistor on to one of my new JST pigitails and the other pigtail goes onto the long wire:

The other end of the long wire will plug into one of my existing DIY 10K voltage dividers which in turn connects with a short 3-wire jumper to the Sensor Module.

 

[Latitude17]

I needed another Light Sensor today

...what for?

 

[odam2k]

...what for?

I had a 3 wire version (with resistor on same perfboard) but that was 15' of good servo wire (need some for my R/C Car project) so I wanted just the photoresistor on the end of 2 wires, since I have lots of that here...

It's in the flower tent now...

 

[odam2k]

Thursday, July 18, 2019
GBW Serial Terminal - Update #7

I don't know why, but I just keep coming up with new ideas for the terminal program...

As you would expect, it lets you follow the Serial output of a module when it is hooked up to a USB port on a computer. This is very useful so you can follow along with what the module is doing. I also have a debug log table in the database, a table which I've been using as a general debugging tool, I can write to it, and even if the module is not on a usb port, I can follow along in the database. The Serial output and the database log are two separate streams of data.

So, today's new feature for the terminal, the ability to follow the debug log from the database while viewing the Serial output. The Debug log view is refreshed every 5 seconds, so it's pretty well real time.

Checking the checkbox "Tail debug table" while connected to a module will open the bottom panel, and refresh it every 5 seconds with the 10 most recent entries from the debug log table. Unchecking will hide the bottom panel.

 

[odam2k]

Will be very interested in following along with your pump automation!

I've got to get going on this, I've had everything ready for a while now. I think, given that I've only got a couple pumps, I'll set up automatic watering on my two mother plants. I only have 2 strains, and keep a mother of each. They are in large pots, and would make perfect test subjects. Of course, I'll keep an eye on them, don't want to kill em...

I have the code up to date now, and it's running with all the changes I've made, so over the next day or so I'll get the wires and hoses strung and get this set up.

Day 4 for my clones using the automated misting module, and I popped the dome off today and had a look. The cuttings are doing better than if I was misting them by hand. I think it's more consistent, the cuttings aren't wilting between mistings.

 

[odam2k]

Friday, July 19, 2019
The "Mega Shield!"

Tonight I'm making a new "Mega Shield" Well, it's sort of like a backpack board for the Wemos Mega 2560 which lets me create exactly the pinouts I need for a specific application.

I start with a blank piece of perfboard, these are 3.5" x 6", a perfect size for the Mega, and add the pins which are lined up to the holes on the Mega.

On the other side, I can solder pins on anywhere, and in any configuration that suits my needs. I use thin "wire-wrapping" wire to connect pins together, it's small enough it can be threaded through the holes. Eventually once I have the design and layout locked down, I'll probably have some nice custom etched boards made.

As an example, here is the Automatic Watering Module, you can see the board sitting on top of the Mega on the right with all the buttons, led's, pins and connectors...

The board I'm working on tonight will be for the Sensor Modules, I want to make it so all the sensors will plug into a row of pins angled off a small daughterboard which plugs into this board. This will save me a ton of space, and make the layout much neater, while still allowing me to disconnect all the sensors easily, yet keep them in order.

It's currently 2am, I tend to sleep in short hour or two long naps, maybe 2 or 3 times a day, otherwise I'm here at the computer for the most part. I especially like the night time. I've had tremors in my hands my whole life, and as I get older, it's been getting worse. But, at night, it's like a miracle, they are almost non existent. I do almost all my soldering at night simply because during the day, the iron is all over the place, yet at night, I can solder stuff so small I need my magnifying light to even see it... well, that's another story, my eyesight... lol... lets just say, thank god for magnifying lamps! and eye glasses!

 

[odam2k]

Saturday, July 20, 2019
The "Mega Shield!" part 2

I've pretty well finished the first Sensor Module Backpack, although I've left room to add new connections.

I started by soldering the wires onto the pins I wanted to access on the Arduino.

Then I threaded the wire around the board trying to keep it somewhat neat and tidy, and easy to follow...

Here's the top view of the completed board, I've added some tags so you can see the connections.

The 16 analog ports are completely configurable as to which Analog Pins they use, and if/which digital pin is used for power. Using a digital pin for power to the sensor means it is not sitting in wet soil with power applied for long periods of time, corroding away... By setting the digital pin high or low, we either apply 5v power, or not.

As for the available ports, there are, as you can see, 16 analog and 4 digital ports. For the pins, I found that on the current modules, trying to plug 16 sensors in all in a row, close together, can be a real pain in the ass, there is so little room. By removing every second set of pins, this will leave plenty of room to easily plug in sensors.

I've also added 4 sets of I2C pins, plus a "header" female connector to plug the I2C Realtime Clock into.

Last but not least, a 5mm RGB LED. When things are running smoothly, the green is lit up, and when something is wrong, red. While it is receiving or sending data, the blue led will flash.

 

[odam2k]

The End...​

If you're still following along, thank you... This has been a long thread with over 10,000 views, so it appears to have served it's purpose. At this time, I'm going to shift my focus to other projects, since this one, Grow By Wire, does everything I set out to do, and much more...

I'm sure I'll tweak it as I go, find bugs, and fix them, maybe even think of completely new features to add, and I will, this will always be an active project...

Thank You!​

...

 

[Latitude17]

I've pretty well finished the first Sensor Module Backpack, although I've left room to add new connections.

nice and clean!

 

[odam2k]

Wednesday, July 24, 2019
Slowing Down...

Well, I've finally reached that point, the entire system is functioning, it does everything I set out to do, and much, much more. Sure there are still lots of loose ends, but I've run out of ideas for new features, or enhancements.

I suppose the next step would be to make it available to a select few who would help me get it into shape so that it could be released as Open Source. The problem is that it was built in place, growing all the time, changing all the time. That means I'm not even sure how to do a fresh install, we'd have to figure all that out. Contact me if you are interested in helping out...

I'm going to take a break from this project for a bit (I think) and work on some other small projects, mostly related to R/C toys... I'm sure I'll find something that needs my attention though, and will update the Grow By Wire blog when I do.
So, if you're looking for me in the mean time, I'll be over at my other blog...

Arduino Adventures​

 

[odam2k]

I've created a Feature Sheet which at the moment, is current

 

[odam2k]

I needed this, a good chuckle this morning.... I have no idea who wrote the intellisense, but they had a sense of humor... it would have been included with vsMicro, the addon that allows me to write my arduino code using Visual Studio.

 

[odam2k]

A few new posts on the blog...

Monday, August 5, 2019
DHT22 Temp/Humidity Sensor - Eureka Moment...
How I solved the problem with non-responsive DHT22 sensors

Monday, August 5, 2019
More power to the sensors
A good solid 5v will yield better results

Wednesday, August 7, 2019
Back in the deep end....
Oh my, tearing things apart...

 

[odam2k]

Thursday, August 8, 2019
Hello? Is there a sensor here?
Finally a reliable way to detect non-working sensors.

 

[Skybound]

Hello @odam2k , hello @Latitude17 . I just noticed this thread in the DIY and felt nostalgic I guess. I wish I woulda saw this thread when it first started. I tried doing something similar that started on a Mega, but being much less skilled than either of you, I had to fake it till I make it as they say. Latitude helped me a lot with my code, but my project had many weaknesses due to being designed by someone that didn't know the contents well was bound to be limited. Maybe about a year ago I had a major mental burnout and I just had to drop everything and switch to a new gear in search of inner peace. I like to tinker, but that only get ya so far, and it got really frustrating that I couldn't take it farther.

I definitely don't wish to wipe the dust of my electronics just yet, I just want to tag along on your project and enjoy your advances from the sideline.