August 2019 Update

While this site is still somewhat new, and still under construction, this project has been underway since roughly August 2018. Please excuse any unfinished pages, I'm still catching up!

New!
View the Feature Sheet by clicking HERE!

New to the site?

Project information can be found on the "Grow By Wire Site Links" panel. The right side of the screen consists of my blog posts, a window into my thought process as I work on the project.

Tuesday, August 20, 2019

Cool new gadget... OLED Screen for Modules

In this previous post I mentioned that part of rewriting the Sensor Module was to remove bloated code that isn't used any more. Because for the most part, I'm learning as I go, sometimes I discover something that I just have to include.

I'm afraid that may never end...


It's a 0.96" OLED screen, and it plugs right into the I2C buss, runs on 5v, and contrary to the poor quality of the picture, the screen is extremely easy to read under any light conditions. It was under $3 at AliExpress, I grabbed two, but will be grabbing more now that I see how easy they are to use.

I haven't figured out what I need it for yet, just that I need it :)


Dazed and Confused...

I'm stumped...  The new firmware is working extremely well, except for two things...

The module is configured to scan all attached sensors at specific intervals. When it's time, it fetches a lit of sensorId's from the database, and then loops through that liat and loads the configuration for each sensor.  

For some reason, the first sensor configuration is loaded ok, but the rest are not, the records are empty, or in some cases contain weird data that appears to be left over from a previous query, like field names...  I can't put my finger on the problem...  My quick solution at the time was to simple close the database after each use, which has the effect of clearing out the memory buffers used, so the query works now, however, the whole process is slowed down as it needs to keep connecting to the database every query.

The second issue just popped up last night. When a sensor fails the Sensor Test, three things happen:


  1. Send a warning to the Serial Output
  2. Send a notification to my phone using Blynk
  3. Write an entry to the debug log database table


For whatever reason, it will not write the database entry (while every other read and write is working fine, including many writes to the debug log table) and causes the ESP8266 to reboot.  If I remove the call to write the debug entry, it works just fine.

While I have a workaround for both issues, they must be a symptom of something being quite wrong. Whatever is causing this could be causing all sorts of unseen issues, and those can be the most dangerous bugs :)

So, I've tried all sorts of things, and if I can't get a handle on this soon, I guess I'll start over. That won't be so bad, I'll aim to get the sensor test code done first, and see if it still has the same problem, if not, it will be a simple matter of adding the rest of the code back in until it fails...

It looks like I have a game plan, it's certainly going to set me back timewise, but I'm sure I'll learn a lesson here somewhere. :)

Monday, August 19, 2019

The "Mega Shield" Part 3

Link to Part 2

Posted: 10:30pm

A complete rewrite of the Sensor Module firmware deserves a hardware upgrade as well doesn't it?

Introducing the "Sensor Module Backpack" AKA "The Mega Shield"



I've added the 12v to 5v converter, and the Analog and Digital pins will be powered from this power supply which is capable of providing up to 3A.  3A is overkill, but power for the sensors won't be a problem :)  I'm also powering the I2C bus from this as well.

I took that picture before I plugged it in, just in case :)  Good news, no smoke, no bad smells, just what appears to be a functioning unit.   Now I'll take some voltage measurements on the pins just to be sure I hooked it up to the right side of the converter :)  If all goes well, I'll plug some sensors in and see if they work using the transistors to switch the power on and off...


Sunday, August 18, 2019

Effortless Clones - finally!

I honestly think this is the ultimate cloning method. Last year, after years of very successful cloning using peat pellets, a humidity dome, and a spray bottle, disaster struck, and I couldn't get clones to root no matter what I did.

For some reason, I was getting 1 out of 15 or more that would root, that was it. Nothing changed in my methods.  I even tried a DWC clone machine, but after one or two good runs, it was a flop. It was so bad I was having to reveg my plants after harvest, or I would have run out :(

Then I created the "Mister Clone Clone Mister" - I'm kidding about the name. lol...

The Automated Clone Mister project, it's purpose, to ensure the clones are misted regularly to keep them properly moist at all times.  I've now done 3 batches of clones, and hit 90-95% sucess rates, al rooted within 2 weeks. This batch, I have 6 rooted at 10 days out of 20. Very very pleased, PLUS I don't have to do anything, check on them every couple DAYS, not hours...  just make sure  the water jug is full, and at one week, I like to change the water and wash the trays etc.

Here's the setup...

I have a plastic shelf unit, with only 3 shelves, and the space between the 2nd and 3rd shelf is surrounded with Panda Plastic, with the white side inside. There is a LED light inside, the kind you might find in your hallway... works good for the clones and seedlings in a protected area...



On the bottom is a heated seedling mat. I have not hooked this up to a relay yet, but if I needed to turn it on and off I could. As it is, leaving it plugged in all the time was perfect.

Over the heated mat are some 1/4" square dowels, just to lift the seedling tray up off the mat so there is an air gap, to prevent too much heat...





The seedling tray sits on the wooden  pieces, and is filled with water, just enough to float the smaller seedling tray inside. This allows the heat to warm the water, which keeps the upper tray warm, but also provides lots of humidity, which the dome traps inside.  Note the multiple trays... I'm paranoid about leaking water :)






The dome is set on an angle, this allows air flow, plus it aligns the big hole in the end with the spray bottle, so when it sprays, it mists the entire inside of the dome, and all the plants.  With two of the smaller trays floating inside, I was able to fit 20 cuttings inside at once all in peat pellets.




Initially for the first 3 or 4 days, I have it set to spray 5 times every 5 minutes, then every 10 minutes, then every 20 as time passes and the cuttings start making roots.

Once I see roots poking through the peat pellets, I plant them in the red Solo cups, and move them under the 250W MH light. 









Saturday, August 17, 2019

An afternoon ramble...

When I embarked on this project, I was quite a rookie. Sure, I'd been a programmer for nearly 40 years, and that experience was invaluable, but not directly useful.

First off, I had just been through the worst part of my life, from the tragic loss of my Mother and Brother, the night before Christmas to a Carbon Monoxide leak, to a near addiction to opioids, not street drugs mind you, these were prescribed like smarties by the "pain clinics", to a near-complete mental breakdown.

This project was meant to give me something to focus on as I struggled to quit the pharmaceuticals and get ON the pot, so to speak... I had just started growing my own, my first legal grow, and had just completed my first build with an arduino. It was a carbon monoxide alarm, how fitting eh?  I actually made it for the car, since we used to be into car camping...

Anyhow, after struggling through that build, I saw the potential to have an arduino monitor the soil moisture level, and there it was, the beginning of an idea...

My point in this rather long rambling introduction is that it was all new to me. And I love to explore new stuff...  Every time I discovered a nifty feature, I had to include it in the project...  Originally all the modules had LCD Screens, Realtime Clocks, multiple LED's, etc.  That's just hardware... the software was so bloated with "cool things" that it started causing problems.  Mainly lack of memory... So I removed the LCD, and the RTC, each having required a library to be loaded.

So now that I'm at the point of doing a complete rewrite, I'm able to pick and choose what will actually go back into the code.  There are also places where I moved the task to another module, such as when I created the maintenance module, or the web server module. That left chucks of code that really don't need to be there, just taking up memory...

Oh look, it's 4:20! Gotta run...

In an orderly fashion...

Posted: 2:30pm


Things are looking pretty darn good right now (knock on wood!).  I don't know how to describe it, but watching it run is like watching a precision military marching band whereas in the past, it was like watching recruits wearing clown shoes...

There is no more overlapping data being sent over the serial port, everything is based on acknowledgements, and knowing what happens next.

For example:

The 8266 sends a scan request to the 2560, and waits for an acknowledgement
The 2560 receives the scan request, and acknowledges to the 8266
The 2560 scans the specified sensor
The 2560 sends the response to the 8266 and waits for an acknowledgement
The 8266 receives the response and sends an acknowledgement to the 2560


That by itself works perfectly... which is how I tested it while writing it, one sensor...

When it loops through a list of sensors, something happens...

Once the 8266 sends the scan request, and gets the acknowledgement, that's it, that is considered one transaction, a complete one...

The fact that the result came back was like a pleasant surprise.... but one the 8266 was waiting for, it had nothing else to do....

But, if once it sends the first scan request, and receives the acknowledgement, it merrily goes off to send the scan request for the next sensor.  Now we have colliding data again.

Lets look at the above statement again...

There is no more overlapping data being sent over the serial port, everything is based on acknowledgements, and knowing what happens next.

You can see the acknowledgments in action in the above scenario, but the knowing what happens next is the new part today...

When we send the scan command, we need to have it acknowledged so we know it was received complete. But we also know that's not the end of the conversation, we are expecting it to do something, and send back a response, and because we know this, and are expecting it for a scan command, we can anticipate it, and wait for it before we move on, just like we wait for an acknowledgement. That's the concept, and it works, I handled it a little differently thoug. Since I want to wait until I have not only received the results payload, but have finished processing it, and saved it to the database, I am using a flag that I set on the sensorCfg record when I have finished with it. 


Friday, August 16, 2019

Ever have one of those days?

Posted: 10:05pm

I've been struggling all day with a problem in the new code.

The ESP8266 has an array which holds the sensorId for any attached sensors. When it is time for the module to scan the sensors, it first fetches this list of sensorIds from the database.

Then it loops through the array, and for each sensor, it loads the configuration. 

Like this

SELECT sensorId from vw_active_sensors where moduleId = 3
Loop the results and add into array sensorIdList[x]

The array can hold 20, there is only one sensor....

Once it has loaded the list of id's, it then loads the config for each, then sends the SCAN payload to the 2560 so it will read that specific sensor and send back the result.

That process occurs repeatedly at a configurable interval, I've set it to one minute for my testing...


So the first time through, it loads the sensorId (#55)

Then it loops the array, and loads the configuration for sensor #55

The request is sent to the 2560 to scan the sensor, and it reports back with the results.

(I don't have it saving to the database yet)

That's it for the first cycle, but it will repeat in one minute, fired up by the Blynk Timer.

The second time through, and all subsequent times, it cannot load the list of sensorIds, no results are loaded, or a whole bunch of fields show up, but they are from the sensor Configuration query?


SELECT `sensorId` FROM `growbywire`.`vw_active_sensor_info` WHERE `moduleId`=3

During the read, I print out the field names and their values, and look at this


FieldName     : Field Value
---------------------------------
sensorTypeId : def
sensorName   :growbywire
moduleId       :vw_active_sensor_info


If I comment out the actual execute of the sql in the configuration load, then the list load works fine. 

It took me all day to get to the point where I could actually pinpoint where it was happening, repeatably...

All I can think is some sort of memory issue, since it still had all the field names from the previous query, but I've been using this library since day one, and never have seen anything remotely like this.

I even thought maybe it was because I was calling this from the blynk timer event handler, but I just called it from loop() every 30 seconds, same problem...

At this point, I'm happy to know where the problem is, and that I can get around it. All I need to do is close the database connection and reconnecting before I try loading the list, and it's fine. Closing the database releases the buffers according to the author, really adding weight to my theory of a memory problem.

I wonder if this has happened in other places, but I'm just not aware of it? It was so repeatable, I can't see how I'd miss it.


Update: 3:05am

I ended up closing the database after every time I access it.  I did see this occur when it was trying to fetch the current date/time from the database using a SELECT NOW();  I wonder if this has been an ongoing thing, or did I do something to suddenly cause this?  Closing the database after each use has solved it, I let it run while I had a nap :)

I initially decided to leave the database open all the time, since I was accessing it so much. The decision was mainly for speed.