Grow Control - Computer Automated Hydroponics at its Best!

Last updated: #GrowControl Come chat

I always love to hear your ideas or comments, so send them my way!
(optional, leave empty to be anonymous)

High Performance and Feature-Rich
The progress continues..

The new gitblit server is up and can be found here: As I mentioned in the previous post, the buying of github by microsoft goes against the grain of open source projects like this one. We have the server and the open source software to provide this platform is available and pretty good, so it only makes sense to leave github.

I've also set up a private jenkins server to handle auto building the project, and posting the files to the website for download. Nothing available for download yet, but I'm approaching that goal. Stay tuned for more.

The code is going well. I've finished the restructuring of the libraries, cleaned and polished much of it, and things are working well. The plugin system now supports reloading plugins without having to restart the entire program. This still needs very much testing, but will be a great feature to have if it works properly. It's a difficult thing to get right, since the plugins have to be completely unloaded before they'll clear from active memory. A new version of the plugin can then be loaded on-the-fly.

Plenty of other improvements and fixes. The event handling system has been improved, program startup and shutdown, logging and console handling, and many other parts. Moving on from this, I focus on making this thing functional.

It was recently announced, microsoft is buying github... I don't agree with things done by microsoft and this buyout goes against my grain. We will be migrating the code repositories from github to our own privately hosted gitblit server. The project will remain free and open source, and the code will remain publically available. This will also still support pull requests, bug tracking, and automated builds. It just takes time to get everything done.

I've just merged in the last few months of fixes and changes, more than 200 commits. Still many odds-and-ends to finish, but I'm getting to those next. Most recently, I've taken some time to reorganise the pxnCommon utilities library. I've split it into separate library modules, so only what features that are needed can be included into a project, and things which aren't needed will be nowhere in sight. This helps a lot with managing dependencies of other 3rd party libraries. I've also gone over the logger, thread pool, and other parts to fix some known problems and improve things further. Now that I have most of these utility libraries finished and working, I just have to finish the console command input code, and take a look at the plugin and config code.

As for the serial and networking libraries I was working on previously, I've managed to figure out the problems I was having with it. Once I'm ready to use them in Grow Control, I'll go over those libraries once more to give them any finishing touches they need yet. It's quite a bit to do yet, but I think once this is done, Grow Control will be functional.

So, to sum it up, I've finished a ton of code, but quite a bit to go. Is this the homestretch?

Progress continues, slow but steady. In my last post, I talked about writing a new serial library for connecting to devices over usb. I've figured out most of that now, and much of it working, although still have to give it some pollish. I've now been working on a companion library to this, which will handle the data passed over different types of connections. I had planned to use Netty for this, but as I work with it, I can quickly see its bloat and complexity become a big problem to manage.

Solution, I've come up with a simpler way to do similar to what Netty does. A bunch of linked pipe objects handle encoding and decoding of the data. Simply pass data into one end or the other and it processes each step down the chain. I like how Netty does this, so I've simplified it, and making it easily used with things other than network connections, like unix sockets or serial ports. It's as simple as dropping in the transport object and a few pipe objects. This will be used for everything from communicating with devices over usb or ethernet or wifi with a number of supported protocols, the communications between client and server tools, and different API interfaces.

To do this, I'm using a selector interface, which allows many connections to be handled by a single background thread. The thread blocks (waits) at the selector for any connection to be ready for reading or writing, then quickly grabs the data and passes it off to the pipeline decoders/encoders in the proper thread pool. Serial libraries normally don't use this modern method of handling data, so it's a bit tricky, but I'm managing to find good solutions to every problem I come across.

More to come as I finish these libraries over the holidays. The code is all open source, so you're welcome to check it out, or try your hand at some code yourself.

Progress continues, slow but steady. In my last post, I talked about writing a new serial library for connecting to devices over usb. I've figured out most of that now, and much of it working, although still have to give it some pollish. I've now been working on a companion library to this, which will handle the data passed over different types of connections. I had planned to use Netty for this, but as I work with it, I can quickly see its bloat and complexity become a big problem to manage.

Solution, I've come up with a simpler way to do similar to what Netty does. A bunch of linked pipe objects handle encoding and decoding of the data. Simply pass data into one end or the other and it processes each step down the chain. I like how Netty does this, so I've simplified it, and making it easily used with things other than network connections, like unix sockets or serial ports. It's as simple as dropping in the transport object and a few pipe objects. This will be used for everything from communicating with devices over usb or ethernet or wifi with a number of supported protocols, the communications between client and server tools, and different API interfaces.

To do this, I'm using a selector interface, which allows many connections to be handled by a single background thread. The thread blocks (waits) at the selector for any connection to be ready for reading or writing, then quickly grabs the data and passes it off to the pipeline decoders/encoders in the proper thread pool. Serial libraries normally don't use this modern method of handling data, so it's a bit tricky, but I'm managing to find good solutions to every problem I come across.

More to come as I finish these libraries over the holidays. The code is all open source, so you're welcome to check it out, or try your hand at some code yourself.

I've spent the last few weeks tinkering with c, getting to know what each line does and how to make it work. I have some good news, today I've committed a bunch of working code pxnSerialPlus It took much effort, but I now have a working and reliable library to connect to serial ports. Performance of this library should even be better than the popular JSSC library, due to a few improvements I was able to figure out. Now that I've written 500 lines of c to make serial ports work, I need to do it all over again for 2 more parts of the library. The main point of creating this library, when so many others already exist, is to add a few extra features which I feel are very necessary.

I've mentioned this before, the number assigned to a serial port can possibly change when the computer is rebooted. This could be very bad, because if your automation system thinks it's talking to one device, but it's actually connected to another, it's uncertain the damage this could cause. The solution, dig deeper into the system and get the serial number from the usb device itself. I'm starting out supporting this feature on the most common usb/serial chips, the FTDI D2xx, and the Ch34x. I've played with the D2xx API long ago in VB6, but never have I written something this in-depth, so it'll be more fun for me to figure it all out.

The progress is slow but very good. It's all the details like this which make GrowControl stand out from all the others. After all the time I've put into this project, I'd better make a quality piece of software, well worth the effort. More to come as I finish this library.

After burning out on that JNI code, I needed some brain rest. I have some free time this week, so I'm sitting down now to take another look at the code. This code I'm working on is a project all of its own. If anyone thinks they may be able to help, you're welcome to it.

A few days into researching the serial/usb issues I mentioned previously.. I now have a long list of libraries and very many forks of them. Some forks have a good structure, but no precompiled libraries available, others are a complete mess. A few are already set up to build with maven, others use gradle or ant, or are just left wondering what program they used to compile. Some have updates only a few years old, others more than a decade. I've had a few of the library forks working, playing around with them. I'm slowly getting the hang of JNI. I've learned the basics of c/c++ many times over the years, but it never seems to stick very well.

The way things are looking, the best route of action may be a whole new library, containing both serial and d2xx, and a culmination of fixes and improvements from all the other forks. I know, I know, 99 different standards exist, lets make one to rule them all, now we have 100 standards. It'll take some time to do, but I think I can make a reliable library that does everything we need. Then it'll be clear where the code came from and what version, rather than countless other forks, some even without a release version number.

I've finished some new plugin loading code, config loading code, and a bunch of other code. Major parts are getting checked off the list as finished and working. Moving on from the example plugin, starting work on a plugin to communicate with Arduino devices of different types, immediately hit a pretty big road block. How do I properly load the native libraries to talk to serial ports and usb devices?..

This is a difficult thing to get right, which I have had working before. There are a few existing libraries which do what we need, but sadly nothing actively maintained, and nothing that will easily import into maven. I've never written JNI code before, but I'll give it a shot over the next few days and see how it goes. If I can put together a reliable library based on the existing libraries, with serial and direct usb support with d2xx, then we'll be in beautiful shape, and other projects may find the library useful too. I'll keep you updated. If all goes well, we're on the road to making GrowControl actually do something.


  1. First things first, get the thing working. (without taking shortcuts)
  2. Second, get the thing working stabily. (aim for at least 80% automated test coverage of the code)
  3. Add and finish any missing features.

Having finished all the previous code I've been working on, moving on to the plugin system. I had forgotten just how involved the plugin system is. It's more than just a loader and a plugin api. I've started with the config code, which is used to load the plugin.yml file from the plugin jar file. This file tells the system where/how to load the plugin. This is easy enough, cleaned up and ready to go. I use the JCL (Jar Class Loader) library to pull in the jar file and make it usable, which as it turns out, uses the SLF4K (Simple Logging Facade) library for logging. A few days figuring this out and getting things worthing, it's now also done and ready to commit to github. Onward with the plugin system!

I've spent the last few days trying to wrap my head around a bug in the thread pool and scheduler code. Now that I've figured it out, it's a simple fix to a very complicated problem, I like it.

So, I can now get back to finishing the internal scheduler, which I've already finished the scheduler manager and the interval type scheduler. Just need to finish it up and commit to github. The clock type scheduler will be next, but it's straight-forward and I don't anticipate much trouble with that. And lastly, the cron type scheduler, which I need to figure out exactly how to do with the help of the quartz library. Also next on the workbench will be the plugin system, which will be much fun and not very difficult, although I do need to take my time and plan out the plugin api.

Once the scheduler and plugin system are finished, it's only a matter of putting these tools to work in the first few plugins! I'm excited about this as always. Timer plugin has many features to implement, but it's basically just a user front-end for the internal scheduler. The arduino plugin is fairly well planned out already, so although it deals with some complicated serial and tcp/ip code, I know how the pieces go together.

There is still very much to do, but this plan will at least (and at last) make it functional. Stay tuned for more news.

I've reworked much of the thread pool code and have it working. I'm pulling some of the code out of it into their own files so it's a bit more clear how it works. One problem I've had with this code is the mess of thread interrupts, which I've been uneasy about. I've come across a way to use Condition objects instead, which will allow me to make this part more clear and stable.

Updating the jLine library to the 3.x series was a short-lived adventure. After playing with it a few days, I see no apparent benefit to being an early adopter. I've run into a few problems while figuring out how it works and how to use it, but doesn't seem worth the effort while it's still under heavy development. jLine 2.x has been around nearly a decade, is still maintained, and it was working well for this project. There have been, however, a few minor version releases to the 2.x series, which I'm looking over now.

A few more things added to my immediate todo list. Before I really dig into the complicated threading code, I'm doing a bit more overall cleanup. There are new major versions of a few libraries, jline, netty.. It appears there are some big changes to the libraries, but they generally still function the same, so updating the code to use the latest version should be relatively easy. I already have it compiling with the latest jline, although still a few things to figure out there.

As I go over the tens of thousands of lines of code, it has been apparent to me I'm finally happy with much of the code, after years upon years of work on it. One thing I'm still unhappy with is the maven build system. I've almost wrote my own build system a few times, but it's probably best to stick with something mainstream to handle compiling the java source code. The pom.xml config files for maven aren't very easy to work with, and difficult to read. My solution, I'm putting together a quick php shell script to generate the pom.xml files, using a short 10 or so line json file containing the project specific build information. I'll simply run the script, it reads the json file and generates a new pom.xml file, then I can commit the file to github with confidence that I haven't missed anything hidden in the xml. I've only put an hour or so into it, and it's still unfinished, but it has already helped me find a few small mistakes in the old xml files. A few more things to figure out here, then I'll be happy, and can start another batch of cleanup commits to the github repo. It's coming along nicely once again. Stay tuned for more :-)

I've gone over the majority of the code, and cleaned things up as I go. Almost every utility class has been cleaned up and finished, and the GrowControl server is compiling and running, for the most part. I've finished cleaning up the logger code, and only have to get the command prompt working again in the server program. I still have to finish the threading and scheduler classes, get plugins loading again, finish the socket and protocol code, then we're in good shape to soon have something functional.

If you'd like to try your hand at some java, you're welcome to it. All the code is posted on github

Here are the linux bash scripts I use to set up my workspace, and to compile and run quickly when I'm working on the code.

Just don't get your hopes up to much, this isn't a usable program yet.

Along with the beautiful weather came allergies, and that was the end of any kind of enjoyment. I was hoping to get much done the last few days, but it was delayed due to illness. So, as I start getting back into the swing of things, here's the plan. (typing things out also helps me keep things straight from day to day)

As I'm going over the code and cleaning things up, I'm relocating the utility classes, and restructuring some of the core functions. The current task is the application startup. Previously, the application made a call to the xApp utility class, with a handle to the application class, and loaded things from there. This didn't allow for running both the server and a client at the same time, or running an internal server with no sockets. This problem was known, and finishing this was planned. This starts with a new utility class to make it easier to handle shell arguments within the application startup. The server application can simply start the server, but a client application must either start a client and/or server based on the shell arguments, or display a window allowing the user to select this or connect to a remote server. Another update soon, as this progresses.

Do you want GrowControl functional? Get on my case about it! I can't believe it's been a year already since I last put effort into this project. My dad had passed around the same time, so, it is what it is. Maybe the rest has done me some good. If you have an interest in this project, contact me! Give me a poke and maybe I'll get more done sooner. I need all the assisted focus I can get. Also, I do reply to everyone, so check your junk folder.

I've been doing a bunch of work on a new website for It's just about ready to post, and I'm fairly happy with the state of that code. As for GrowControl itself, I'm itching at the keyboard every time I think about the project. Today, I've finally started getting something done, 11 commits to github today. I commented out a bunch of broken code locally and was able to compile and run the program, which gives me a good idea of the mess I left for myself. To give you an idea what the immediate future holds, about 4000 lines of code are functional after a day of cleaning, and I'll keep working at it. Once it's working and usable, it'll likely be around 20,000 to 30,000 lines of code. My goal right now, I'll get things cleaned up, and get the github copy into a working condition, and I'll do my best to keep it that way. With hope, from that point on, the copy in the repo will compile without errors and maybe actually work. I can then start providing regular releases for download. Quality takes time, especially when I'm coding solo.

Send me your words of encouragement, or ideas to make this project all it can possibly be. Enjoy the nice weather, and keep growing!

It's never easy to deal with the loss of someone you love. My dad passed March 25th, and it's still difficult. Aside from tools, I've gotten a lot of knowledge from him. As a kid, I'd follow him and watch, and help what I could. I wouldn't be where I am if it weren't for him. That said, I'll continue the project in his memory.

State of the project, it's been 5 months already since I last posted here. What I have been working on is a new build system. I've mentioned this side project in previous posts. After a few failed attempts, it's finally just about ready to put an early version into production.

Build Server Check-list
[X] Command line tool
[X] Builds php projects
[ ] Builds java projects
[X] Builds rpm packages
[ ] Builds zip packages
[ ] Release automation
[ ] Monitor github for commits to build
[ ] Manages files on web server
[ ] Website to view status, build logs, and provide download links

10-28-2015 - I have some time tonight to write some code and play with streaming to youtube. I'm doing some work on the gcTimer plugin, but first a new function in the xConfig class to make it easier to load lists of configs with multiple keys in each entry. The timer plugin has entries in the config for each timer, and each timer can have multiple tracks. There's also more than one type of timer, and each type with its own group of settings and tracks.

09-18-2015 - There haven't been any recent dev builds released to the web server in a while, (my fault) because the build scripts I wrote have been insufficient and I inevitably broke it. The last number in the version numbers I was using for a build number, (eg 3.5.x) however a friend convinced me I'm doing it wrong. This number was incrementing for each build jenkins performs. In order to do proper versioning, I decided bash isn't up to the task, and I'm writing a new build script in perl. Rather than only a script to run the required tools, it will also keep files such as .gitignore up to date, auto detect the project version number from a list of files, and a tool to automatically increment the project version number in all files when it's ready for a release. Once these new scripts are finished, I'll also have a new isolated jenkins server to perform package signing, and will integrate better with the website. One thing to note about this, jenkins will create a new build for every push of commits to github. This means there will likely be multiple commits and pushes and rebuilds for each unique version number. I'll find a way to integrate the build number into the project too.

When I have time away from this project, I still need to finish the new website. All in due time.

09-11-2015 - I've finished much work on the event handler code, which is used in many places, not just for routing on/off events out to hardware. It's working well so far. I'm excited to share my crappy youtube video of a blinky light.


The events are currently being hacked in with some testing code, which the event router then passes on to the ArduinoGC plugin which connects out to the Arduino Pro Mini over USB and tells it to turn the LED on and off alternately. Yes, this could be done much simply, but the point is the system as a whole is working. This allows for MUCH further expansion with plugins. Once I've finished and committed the rest of this event code, I'll move on to finish the gcTimer plugin.

09-02-2015 - To compile GrowControl yourself, you'll need a few git repo's. They're all available on github, but I've put together this script to make it a bit easier. Just create an empty directory and save this to a file named then run with 'sh' You should then have everything you need. You will first need to install java and maven. The script will clone the repo from github, compile, and create eclipse .project files which you can then import.

Much of the code I've been finishing either already existed in some form, or has already been meticulously planned out in my head. I remember saying something along those lines a few years ago. Well, the project has come a long way, and I feel it's in a very good state. Major parts are getting finished with many features in place. I've started putting together the ArduinoGC and gcTimer plugins. I have some free time at the moment, so I plan to finish the plugin to communicate with the arduino by end of the week. Auto detecting connect/remove of the arduino usb was easy enough. Queueing events before sending, timeout and resend, multiple arduino devices possible on each virtual comm port, also will support connecting over ethernet or wifi. Even the timer plugin has so many features to include. I believe the event routing code already all exists in the repo, but it hasn't been touched in a while and I'm unsure of its condition.

The remote api is a json stream over a tcp connection on port 1142 (or 1143 for ssl) by default. It's not a good idea to open this port to the public internet yet. Wait until it has been well tested and broken in. Authentication and black listing features haven't been added yet, but should be relatively easy to do.

Credit must go out to the ausie (haven't yet asked permission to post his name) for contributing a new client for GrowControl. I'll need to do some work on it myself to make it use the common code libraries for GrowControl, but for now I continue my focus on the server and plugins. It's all making great progress, but still to far out to guess at a release date. You're welcome to try it. Let me know if anything breaks and I'll fix it.

08-12-2015 - A short break has done me good. I've cleaned up the code, finished a good chunk of the netty server side code, finished most of the built in firewall, the client loads again (although the connect button is waiting for client side netty code), all the config files are loading properly now, there's also a new profiles.yml file for the login/connect window of the client gui.

I've currently been working on the problem of finding the right json library to use for the api. I've spent weeks searching before, when I finally settled on the json-simple library for its small size and high performance. I start using it when I notice it's missing one feature I need. I've spent some time digging into how it works, and I'm now working on an even smaller custom version with every feature needed. Once I've finished this, I'm pretty sure I know how the api protocol should be structured, so I can put the new json library to use there and finish the client and server netty code. There may be a few steps in between, but after that, the client gui will then connect to the server and log in. We can then go from there.

I had started adding unit tests into the project before. I've also now implemented code coverage reports for the automated tests. I've quickly realized how much work it will be to add tests for all the existing code. Utility classes are already all tested automatically, but most of the high-level code will be challenging to test. This isn't as bad as it sounds. What matters is that the project compiles and runs properly. Automated testing can be added along the way to help ensure very stable results. Every piece of code gets thoroughly tested after every compile, inside and out, even parts the end user can't affect.

I'd like to thank the aussie who donated and joined the irc channel for getting me focused on the project once again. I've really wanted to continue work on it, but seeing strong interest from the community really helps get things done.

03-19-2015 - I've been doing well not breaking the code in the github repo, but it is currently broken, so I'm not making a new build on jenkins just yet. I've been doing much work on the thread pool class, and I know where the problems are. Once I finish this and some work on the scheduler, it should be better than it was before. Then, I can get back to work on netty and an api for php. The changes I've made to the thread pool may improve performance very slightly, but should help prevent lockups which were rare but a big problem.

03-13-2015 - Well that was fun and surprisingly easy. I came across this website. Turns out there's a javascript engine built into java. I've put together some classes which add this feature to the GrowControl server. It's not super fast, but it does seem to work well. On my computer, it seems to load about 5 scripts in a second, with 5 individual engines. What I like about this, it can run java code and access other parts of the server without needing to compile anything. Here is a list of scripting languages supported by this platform, although I'm not yet sure how to install them. The javascript language comes built in already, so easy to get started.

03-11-2015 - The socket api is off to a good start so far. The Netty library seems to be a great choice for this. For my testing, I've put together a simple php script which connects to the GrowControl server, authenticates, and communicates with json. The format of the protocol is relatively easy to use. The first 2 bytes are the data length in binary, with a max of around 65k, then the data is json formatted text. File transfers will also be possible over this protocol, for instance when the client application connects and downloads the plugins from the server. SSL is also supported, as well as multiple ports and address bindings, an internal firewall and bruitforce protection, and bandwidth throttling. Don't think I've left anything out. More work to do on the protocol and api.

Update: I've figured out how to stream json data with Netty. (makes me very happy) This means once you connect to the server with a socket, you just send one json message after another, with no length bytes needed. For example: {"packet":"auth", "username":"lorenzo", "password":"mypass"} This is the first message you'd send to authenticate your session. You can then send more messages after that, spaces and new lines optional.

03-04-2015 - Building the project: I've recently finished a new build system for the project, which runs on the jenkins ci server. The scripts are included in the shellscripts package in the yum repo, and builds the project by simply running xbuild which reads the xbuild.conf config file, builds for windows and linux, then deploys to the web server for you to download. As simple as this is, it's not likely you'll need to use it yourself. Just clone the github repositories using git clone and git clone then run mvn clean install in each workspace to build the project. For the sake of simplicity, you can download the exe or zip or rpm or jar files right from, whichever format you prefer. The project is progressing well as always, but still much to do.

I'm still making good progress adding ssl support, which will be great to have when the time comes to use it. Security should not be an afterthought. Build it from the ground up with best practices in mind.

Update: Ok, this is a bit crazy, but it's interesting to see what software can do. Netty is a great library for sockets, which I've decided to use for this project. I put together a simple web server which responds with hello world. Some quick benchmarks on my dual core desktop, 1 million requests in 41 seconds, handling 23,000 http requests per second. Even without keepalive, making a new socket connection for each request, I'm still seeing around 6,000 requests per second. My conclusion, yes netty will do the job a million times over. I'm satisfied.

Concurrency Level:      1000
Time taken for tests:   41.904 seconds
Complete requests:      1000000
Failed requests:        0
Keep-Alive requests:    1000000
Total transferred:      103000000 bytes
HTML transferred:       14000000 bytes
Requests per second:    23863.84 [#/sec] (mean)
Time per request:       41.904 [ms] (mean)
Time per request:       0.042 [ms] (mean, across all concurrent requests)
Transfer rate:          2400.37 [Kbytes/sec] received

02-09-2015 - Making good progress adding ssl to GrowControl! It's pretty interesting to see how ssl works. The details behind making it work can be overwhelming, but once the connection is successful, it's as simple as sending data and receiving it on the other end. Everything in-between is securely encrypted. It is optional to use this, for instance it's really not needed if you're not connecting across the interwebs, but you can feel safe if you do. I plan to use a relatively simple json text protocol to communicate between the client and server, and also provide an api for use with php or cell phone apps or other platforms. It takes time, but it's coming together very well.

01-20-2015 - How many people are interested in buying a kit? Send me a comment to let me know. If it'll make things easier for some of you, I may put together a basic kit, but only if there's enough interest in this. As much as I'd love to buy tons of arduino's, I need to know they'll be used. I may include both the Arduino Pro Mini and the Due, or maybe one of them and give you the option. A few waterproof temperature sensors, a soil moisture sensor (can also be used as a water level sensor), a relay board, and perhaps a solid state relay for larger loads. Also one of those neat little wifi cards for the arduino (although I'm still waiting for mine in the mail and haven't tried it yet.) I can flash the arduino for you, but you'll still have to assemble it yourself. Not to worry, most of it you just plug in a few wires in the right places, then tell grow control which pin it's in.

I have a few parts of the project in progress, but I've put them on the back burner for a moment to do some polishing. I've moved some classes around, and symlinks are no longer needed in the workspace. This will make things easier for you windows devs. I'm doing some testing on Ubuntu and Windows to be sure things work the same as on my CentOS and Fedora dev machines.

Things I still need to finish, the scheduler classes work, but I still need to make the timer plugin which will make use of the scheduler. I'm still looking for the best way to handle sockets connecting the client app to the server, but I think the Netty library might be the right choice. Sockets are easy, but when it comes to ssl, the difficulty quickly jumps to advanced. It would be fun to start work on something new, like putting together the GUI, but sockets are needed for everything client side.

Update: I've committed a bunch more fixes. The server now runs well on fedora, ubuntu, and windows. That's good progress. I'll find something else that needs to be finished tomorrow.

01-12-2015 - Coding this software is going well, and the latest dev version is available on the jenkins build server. Lets talk some hardware! Check this out ESP8266

This is a WiFi module for the Arduino, and the Adafruit OLED display, for less than $5 each. I'm unsure if the Arduino Pro Mini which I had planned to use will have enough memory to handle this display, but the Arduino Due has plenty to handle this, and is also low cost. I've also ordered a few Dallas 1-wire waterproof temperature probes. Many of these can be connected to a single pair of wires, and it's all digital, so there's no chance of a connecting wire affecting the temperature calibration. Also, each sensor has a unique serial number which can be handy. Add to that a barometric pressure sensor, and a soil moisture probe, and a light intensity sensor, we are well on our way to a full environment monitoring station. Lets not forget about pH and EC/PPM, (but this I'll leave for later). Have I forgotten anything at all?! Have we even reached $40 total yet? I'll provide the firmware/sketch for these features, as well as plugins to make it all work with GrowControl.

As I may have mentioned before, one of my first goals is climate control. I'm also interested to see the software logging and charting the temperatures. And once I get the WiFi module in the mail, I can put the temperature sensors anywhere I want, and add/remove extra sensors as needed.

Update: Yea.. the smaller 328 Arduino's can handle only basic displays with the OLED. I attempted displaying a few Dallas 1-wire temperature sensors with the Arduino Pro Mini, but it runs out of memory and gives me gibberish on the serial console. Connected it to the Arduino Due and it works great. Displaying 3 temperatures here on my desk. It's easy to read, but I have to say, the OLED is quite bright.

01-10-2015 - Just finished and committed new classes to handle cron formatted scheduling. I've finished interval scheduling earlier this week. These, as well as the thread pool, are now automatically tested by jenkins at each build. I'll do more automated testing as I go, but I think these are some of the most complicated code in the project. If something does happen to break in this, it would be good to know immediately if something is wrong.

Next up, back to work on plugins. Most of these libraries I'm writing, such as the schedulers, are all built right into GrowControl, so any plugin can make use of them, as well as groovy scripts. The way it's going, I may have the timer plugin working in the next few days.

As far as climate control, I would like to get this working very soon, possibly by using groovy, although I'm still fuzzy on exactly how I'll handle events which need to request a value. This is something I can now use the scheduler to keep a temperature value updated.

01-05-2015 - I hope everyone has had a great holiday. I appreciate the comments I've been getting, however please do provide your email address so I can reply. As much as I love writing code, it does help keep me interested and focused in the project when I get a comment. If you give GrowControl a try, please do give me your feedback. Beware, it may be confusing right now, as config files aren't automatically created and nothing can be configured from the gui yet, but I'm always on irc if you need help.

For these early releases, I plan to add a bunch of default/example config files to the zip to help get you started. I'll also provide an exe version of the programs for you windows people, which should be interesting because I compile on linux. Now that I think of it, there is a bug running the GrowControl Server on windows. It works, but the console colors don't work and you'll see some gibberish. I'll fix this eventually. Let me know if it affects you, and I'll fix it sooner.

State of the project: The server runs well. Basic functionality is getting finished. The event system works, and a few of the plugins are starting to work. Timers and schedulers are almost ready. I'd like to have climate control working soon, but I'm still very unsure how exactly it should work. I've found it's very easy to use Groovy, which is a scripting language similar to Java. This may be the solution to so many problems. Simple and complicated events could be handled by Groovy scripts, which you can edit while the server is running. I'll let you know more on this soon.

Update: Well duh.. comment form was part broken, no wonder every comment was anonymous. I've fixed it now. I still do have a new website coming, once I've finished some of the details.

12-08-2014 - Here's the latest screenshot of my terminal below. Messy with temporary debug info, but I'll be cleaning that up next. Why am I marking this moment with a screenshot of this mess? I turned on and off an LED plugged into an Arduino with console commands. I used the set <address> <value> command to manually trigger an event, which gets routed to the SerialControl plugin. This plugin listens for events on specific addresses, then sends the specially formatted command out the serial port to the Arduino. If all is well, the Arduino responds with a result. Still more to do on this.

Turned on an LED

11-29-2014 - Finished the new Arduino firmware, and it works very well. The SerialControl server plugin is loading config files and scans comm ports. Any Arduino devices running the SerialControl firmware which are connected to configured comm ports will then reply with their id number and firmware version. The plugin remembers these id numbers and uses them to listen for events from other plugins. This latter part, the meta data event system, I'm still working on. This is the API which plugins use to communicate with each other when a device changes state. When a timer turns on, a meta event is routed to the output plugins. This does sound like it'd be simple, but I assure you it's a complexity that's been plaguing me since converted the project to object oriented java. Finding the best way to manage all the different data types, and allowing them to work interchangeably and route to the correct plugins with the right parameters. I think I'm finally on the right track with my latest solution. A console command starts with 'set' followed by this format: <SerialControl> { id: 22, pin: 13, value: on } which sends an event to the SerialControl plugin, which then sends out a signal to the Arduino with the id 22 to set the output high for pin 13. The moment you press the enter key, you'll see the status led turn on. Plugins use this same data in the form of objects to send events between each other. Strings in this format, the plugin name, then a short json map of key/value pairs, can be easily converted into meta objects.

edit: Rethinking this meta routing already. Problem is, all the different types of plugins and hardware use their own addressing scheme. A simple example, X10 could use A1 as an output address, or an Arduino could use a device id and pin number. A timer plugin needs a simple way to call a specific plugin and a specific address, without knowing how its formatted. What I'm thinking might help simplify things, hash codes. Every plugin that accepts a meta event could have a unique generated hash key as an address, which is set in config files to relate to the specific id and pin. For example, if you want to turn on the status led of an arduino, the command might look like this: set c30fcbe6 on At the time of finishing this post update, I have this functionality partly working already. I'll still need to see how this works with plugins and config files.

11-18-2014 - Progress is good. I've gotten plugins to compile with maven, and loaded the RXTX library to use comm ports. I've found the arduino ide and libraries have changed, enough so that the ArduinoGC firmware I wrote for this project no longer compiles. This code worked well, although it was written a bit sloppily. I've found the project SerialControl which uses simple commands to control the io pins of the arduino. This is similar enough to the ArduinoGC project that it should make a good replacement. I will need to make some upgrades to it to support ethernet shields, and maybe a simple password. Next update once I have a plugin working and communicating with SerialControl running on an Arduino.

11-11-2014 - I've been getting some comments on the state of the project and this website. I hope to clear this up for you right now. Also, anonymous comments are always welcome, but please provide a return email address if you expect a reply. I've had some life issues to deal with as of late. My beloved dog Beau has passed, but will always be remembered. Some time away from code can always help me stay refreshed, as does the wonderful group meditation I've attented tonight.

I've been putting together a new website, which I'll have ready soon. I know the downloads page has been broken, but there hasn't been anything stable enough to post just yet anyway. The build server can be found at and automatically compiles what can be found in the github repositories. There is also a yum repository at for CentOS and Fedora linux users. The project does compile and run, although still doesn't do much of anything. I have some seeds planted for my winter herb garden, and I do plan on using GrowControl to automate it, so hopefully I may have the project working again soon. Either that, or my plants will die and there will be no fresh lemon tea for me.

At this moment, I must work on the method of compiling plugins for the project using maven and the jenkins build server. I haven't entirely figured this out yet, but should have it soon. I must go back to the basics and put together a temporary mock-up, to get a better grasp on exactly how the dependencies will work in maven. From there, I can add more details, like the gui and config files for the plugins. First, a working example plugin, then second is the plugin to communicate with an Arduino over USB or ethernet, then third plugin will be a configurable timer. From there, the only limit is imagination.

More info and screenshots to come as I progress, and also a new website. Thank you all for your interest in the project.

10-03-2014 - The github repo for grow control is stable now, with only one in 16 builds failing to compile. The jenkins build server is almost finished. I've made a custom plugin to provide download links to grow control from this website and jenkins, which is just about ready. I've also been working on an rpm build script. This method will only work on linux, but I've set up a yum repo so grow control can be easily installed or updated. 1) I write some new code and push it to the github repo. 2) the jenkins build server sees the new changes and compiles new jar files and a zip, and also a new rpm file, which gets uploaded to the yum repo. 3) your linux computer checks for updates, downloads and installs the new version. If only setting up this system was as easy. GrowControl does also run on windows, however you wont have the fancy yum install and update features.

Release Formats:

  • Development Builds - Bleeding-edge version. The jenkins server automatically compiles a new development build each time a change is detected in the github repository. This version is considered to be unstable and shouldn't be used in a situation where reliability is needed. This will, however, be the first version to receive bug fixes.
  • Pre-Release - Once new features are finished and bugs have been fixed from development builds, a pre-release version will be provided. This is the final testing phase, and is considered mostly stable. This version may be used in real-world applications at your own risk.
  • Final Release - This version is considered stable and safe to use. After a few pre-releases, and endless computer-hours of testing, if no major bugs remain, a new final release version will be provided.

First successfully built set of rpm's!

09-21-2014 - The first successful build within jenkins! I still have a bunch of code to put finishing touches on and commit to the repo, but this is a great milestone. As I commit code to the github repo, jenkins will compile it all and provide a download link. I'll do my best not to break the code as I'm going.

The current state of build #1, well.. the client and server both compile and run, although I still have to commit code for the login and other windows, so the client doesn't yet have a gui, I have to finish adding the default config.yml files, and plugins aren't far off but aren't ready just yet. Much of this will likely be finished and working in subsequent builds before I post here again, so stay tuned.

09-19-2014 - I've set up a jenkins server, which will auto-build the project when any code changes in the github repo, and will provide a download link for the snapshots. At the moment, I have a nice group of mostly finished code, however much of it still needs to be committed. In other words, it sits on my dev server, and needs to be finished and cleaned up, and uploaded to github. Once the github code is able to compile without errors or missing pieces, I can enable the auto-build in jenkins.

04-08-2014 - anonymous comment: "I love this project." Yes, as do I. So much is possible with this type of system, with proper planning. I'm doing this all myself, with few other minds to bounce ideas off. I've never seen another project like this one, so it can be difficult to visualize exactly how the pieces should work together. Object oriented programming is very meta, and helps to have something physical to compare a concept to, like personification, if that makes any sense. Ontop of this, it needs to be extremely flexible and perform fast. Piece by piece it's coming together. If something doesn't work right, I tend to scrap it and start over on that piece. I may have something functional again soon :-)

03-12-2014 - One thing I've been looking into, I'd like to mention. This software would be great for automating so many types of systems, but lets go green. I think this guy is awesome. Living in an efficient off-grid home takes constant attention. Solar power collection, a backup power source, water management, heating and ventilation, lighting and appliances, not to mention your green house and aquaponics. Think of the automation and fine tuning possible with an open source powered system.

Here's what it currently looks like. It's been to hell and back multiple times. I've been going over the sets of classes and finishing my most recent improvements. Many classes that were hundreds of lines are now much simpler and efficient. I'm still adding back in the new classes, and it's only displaying test data, but it's looking good and working great!

02-08-2014 - I've recently gotten a few comments. Thank you, but unfortunately no one has provided their email address, so I'm unable to reply. I had wanted to finish this project years ago, and I remember 3 times having a working version running a small pepper garden, but that was back in vb6. I've since upgraded to java, which can run on just about any computer. The server half of the project is mostly written, but still in pieces at the moment. I'm working to clean up the code I have, get things committed to the repository, and get everything working together. The goal is a minimal viable product. Finishing the necessary pieces to make it usable. Great care is put into the base classes, which are the foundation of the system. Standards and methods are well thought out to be sure plugins will have what they need to be great at what they do.

These code repositories have been public for a while, but I haven't "advertised" them, so I guess I should tell you what they are. The CommonJava repo is a general use set of classes and utilities. I've just finished writing a new simpler event system for the server. Plugins can tap into this to listen for events. I'm finishing cleaning up the thread pool class, which allows events to run in new threads, and manages tasks run in the main server thread. The socket client/server classes need some clean up, but it's a bit complicated internally for how simple it's supposed to be to use. There are also classes for database connections, and a logging system and command prompt. If you checkout the code, you may need to move things around a bit to get it to compile. I use a script to set up symbolic links in my workspace automatically, but I'm on linux and I suspect you're on windows.

Here are the code repositories. Please don't expect this code to work just yet. It may take some tweaking to compile.

08-28-2013 - Some finishing touches to the ticker scheduler. I've been busy the past few days, so it was a good chance to rest the brain, and a good place to start work again. It loads the tick rate from the config, and made some improvements to how it handles sleeping the thread. It finds the milliseconds to sleep for until the next task will be ready to run, subtracts 10% from that, then sets a maximum of 1 second sleep time. When a task is about to run, the thread dynamically speeds up until it triggers, then goes back to checking once every second. I believe this method will be the most precise, and effects from system load should be minimal.

My initial tests with these improvements, running at a 1 second tick rate, I'm seeing between 1ms and 5ms lag. Running at a 20ms tick rate (50 ticks per second) or a 10 second tick rate, I see about the same lag, even when open/closing programs on my desktop. Very stable and precise, the way I like it. To be honest, how often will even 100ms lag affect your system, or even be noticeable? But it is an important part of the program. Plugins have the option of using the ticker for simplicity, but there's also the full scheduler built in, which uses the same underlying code as the ticker.

I have some bugs to work out of the meta router next, which handles event communication between plugins. Have to remember where I left off, but that part is almost finished too. I have had the timer and arduino plugins working and communicating once before, as a mockup, but I'm now finishing and perfecting as much as I can as I go. Features are in place, configs are loading, a few commands to start with, full plugins emerging from the mockups.. I have a tinny linux VPS running the latest dev version constantly, soon to be connected to physical hardware.

Hardware - I have the Arduino Uno and Duo, both the unofficial 28j60 and wiznet ethernet shields, and the Udoo should be here next month with gigabit and wifi built in. That's a nice range of devices with some power. 16 bit, 32 bit, and quad core arm + 32 bit processors. I have a small black box which contains (and protects) the Arduino, with standard RCA jacks on the sides. I use every day audio patch cables to connect that to my relay outlet boxes, which have female RCA pigtails, as well as as 12 volt power pigtail. The relay does require external power, until I find a cheap, safe, reliable, and small power source. I put the mosfet transistor on the circuit board along side the relay to keep it simple. I have a nice range of mosfets to use, which can handle anywhere from 50ma to 5 or 8 amps. I also have a well built relay board, with 16 relays and optocouplers. I'll find a use for it. The Arduino itself can only handle a few milliamps. Mosfets do a great job of amplifying the current to power relays. 5ma pull from the Arduino can supply up to 5 amps from the mosfet. Any more than an amp, other solutions should be used anyway, but a relay is usually between 50ma and 150ma. The only problem with my easy design is the possibility of static killing the arduino. The mosfet or optocoupler would be better suited inside the box with the Arduino, however this would complicate adding sensor inputs later.

This is the automation system I've dreamed of, and it's coming to life.

Progress Roadmap - The project is making good progress, and I'm finally happy with the code. If I start to burn out and make mistakes, I'll stop work on it before I destroy the good code I have now. I'm still fixing small bugs here and there, but I don't expect to have many big bugs, and shouldn't be any problems threading related. As soon as I have a functional plugin, so the program can do something, I'll then start preparing an alpha release.


  • Base client/server model
    • Commands
    • Configs
    • Logger (console and file)
    • Plugin framework
    • Socket client and server
    • Multi-thread pool/queue
    • Internal scheduler
    • Event data routing
  • Base for first official plugins

To Do

  • Complete client and server functionality
  • First bunch of official plugins (functionality and client side)
  • Display views in client
  • Wire routing between plugins in the client
  • Website control panel
  • Smart phone app

Log level set to finest

Normal operation, running the commands version and stop

08-21-2013 - I wrote all the internal meta data code last night, with all the default types. Then, I started over tonight. The class structire was very bad. I think I've come up with a good structure this time. There are 2 class trees. meta types and meta values, then the value contains the type. This is much cleaner code than attempting to contain everything in one class tree, which isn't proper anyway. I have this code almost finished. It's compiling and running without crashing, but I do have to find one small bug so far. Get a simple timer working again tomorrow night, maybe get the arduino driver working again, and it'll be functional.

The big change this version, it's finally what I envisioned. It'll have all the features I want, all the settings and configs, all the powerful tools, and fast. Want it to do something common or specific, or even custom, just drop in a plugin.

08-18-2013 - I've been planning the next phase of development in my head and a little on paper. The plugins will have access to a meta data router, which keeps track of input/output handlers by name, and decides where to send data and events between plugins. It may also send updates to the client and stay in sync in real-time, and will perform the function of virtual wires.

For example, you have a timer and a thermostat. Your air conditioner will turn on when you get home from work at 5pm (17:00), and turn off when you leave in the morning at 8am (8:00). To do this, we could feed both the timer and thermostat into an AND gate, then out to the Arduino. In this setup, the air conditioner would only turn on if both inputs were true. If the timer says it's between 5pm and 8am, and the thermostat says it's warm in the room, then the AND gate activates its output and the Arduino turns on the air conditioner. As soon as it's cool enough in the room, or 8am comes around, one of the AND gate inputs goes to false and the output turns off.

This is all handled by the router. The GUI will have ways to select where each bit of data is sent from and to, between the plugins, and also virtual wires. Drag a wire from the output of the timer to the input of the AND gate, and same with the thermostat. Then drag a wire from the AND gate output to the input of the Arduino. The router will then route the data and events in that path, and send live updates to the client.

If you have debug mode set, you'll see the thread pools all stop after they haven't been used for 5 minutes. This value will likely be much lower, as it's relatively quick and easy to create a new thread when activity returns to the queue. It would be possible to have the program automatically adjust this value as needed, using a rolling average, but I'll play it by ear. It's still unclear how well the server will perform. I'm still estimating thousands of events per second, but the program could be run on a system with 24 cpu cores, or it could be a much smaller single-core embedded system. Benchmarking and real-world use will give a better idea as to how many threads perform best. Generally, you might have n+1, meaning your cpu core count plus one. A quad core server might perform best with 5 threads. 4 of the threads would run at the same time, and the operating system will swap them out randomly leaving one sleep. However, most tasks will be very short-lived and complete very quickly. For example, tasks are created to route events from 1000 timers into a few logic gates, then out to multiple Arduino and relay units connected over gigabit. If these timers all update at the same time, how many threads would perform best at handling these tasks? The goal is for every task to be run as fast as possible, and as near to simultaneous as can be. If there is a long delay between the first device to get an event and the last, it could cause odd delays in the real world, or even cause a problem. If a delay is wanted, between the state change of 2 devices, then a delay can be explicitly added using a plugin. For example, you want a row of lamps to each turn on or off in sequence. A plugin could be used to delay the events from a timer or light switch or remote. But, if you want a room to fade to a soft glow, using multiple lamps connected on separate dimmers, this is a case where you'd want all of the dimmers to update to the same value at nearly the same time. At least fast enough to not be noticeable.

Some rough math to get an idea of this concept: 1000 timers into 200 AND gates, then out to the Arduino devices. You start with 1000 timer event tasks, add the outputs of 200 AND gates, 1200 tasks to run quickly. An 8 core server would roughly mean 8 threads can run at the same time, leaving the entire event to take the time of 150 sequential tasks. This is only a guess, but if it takes 2ms to run a task, that leaves us with 0.3 seconds, a third of a second. But, this is only the time it takes to route the events to the proper plugins. Add onto that the time of processing the event within the plugins. In the spirit of java, maybe we can optimize for a better experience by having groups of timers update at once. As it turns out, this system needs an extremely heavy and short burst of high performance, but most of the time sits waiting.

Another idea comes to mind. I can make a plugin to link multiple servers together. It could be fun to link a bunch of VPS's together and have events pass between them all. Start an endless loop, now I'm getting evil. One idea, you could set your neighbors up with a system for their outdoor lights, and link them all together over the internet. When night comes, the lights for each house turn on in sequence down the street. Actually, the Arduino can already do this, using an ethernet or wifi shield, and a port forward to the server. If christmas light shows are more interesting, I believe one server could run an entire block of christmas light shows. You could pre-design the show in a simulator, then load the config to the live server to run it. Saving the new config file then restarting the server will first trigger plugins to perform their shutdown sequences, maybe set to a default level, then stop and exit. The server then starts again and performs startup sequences, or starting the new show. The server takes only a few seconds to restart, with a few plugins loading. This will be much faster when a proper reload command is finished, as it wont stop the server application, but will stop and reload only some of the classes, and the config files. It may take only a split second, less than the blink of an eye, to reload the server and plugins, so a startup delay may be wanted at that point.

Also, there is a sequential timer plugin, so 1000 timers wouldn't really be needed, only as an example to stress the system. You could use a few sequential timers, each with a set of tracks to control the devices or lights. Like I said, produce a show. These plugins are open source, so if you're a programmer, you can submit your own improvements or make your own plugins. I plan to have an online store of free plugins.

08/16/2013 - Just about working :-o yea, I think I'm finally happy with most of the code at this point, and most of the basics are finished. The server and client programs both compile and run. The server has a library of powerful features which plugins can use. At the moment, these features are sleeping under the hood, waiting to be put to use. It's all multi-threaded java. The internal clock automatically syncs up with a time server, basic commands are being added, the configs all load, the client connects to the server and starts the handshake, the logger will have an option to log to file with only a few lines left to add. The internal scheduler can be used in single or multi-threaded mode. Triggered by a fixed interval, fixed time, or in cron format, or just use a simple ticker which defaults to once per second. The thread queue is used by a few other features, and can be used by plugins. Setting the max threads value to 0 forces the tasks to run in the main server thread, 1 in a single thread of its own, or any higher number creates a dedicated thread pool. New threads are created as needed to handle the queue, up to the max threads limit, at which point all threads in the pool work to clear the queue. When the queue becomes empty, the threads wait for more tasks, and loop around every so often, until they are eventually killed off after a set period of time.

There are still things I need to finish. The framework is there to make everything work, but a few key parts are next to be worked on. It takes some thinking and planning to build it right. If it's not perfect and works as intended, I'll rewrite it until it is. You can think of plugins as devices. You drop in a few timers and wire them up virtually to the physical outputs of the Arduino. This is done with meta data types and a meta router. The data types I've added so far, the standard IO for on/off, variable for dimmers or sensor readings, thermal for temeratures, EC/ppm for monitoring liquids and pH, and also commands and general triggers. The meta router is what will handle finding where each virtual wire is connected, and pass the data along. The client will have all these features in different views.

At the moment, the client isn't very functional. The connect screen mostly works so far, and the dashboard screen comes up once it connects, but I've yet to figure out the details of how the dash will work. A tree view on the left side, aand windows you can move around where you want, and each plugin/device has its own window. A floor plan view is what it says. You draw a floor plan of your home or building and place buttons or hot-spots on it to control real world devices. There will also be a wire view of some kind, where you connect virtual wires between the plugins/devices. Each view should have a good use. This will all connect to the server to get live updates, and multiple connections can be made for things like downloading the plugin files, or streaming video or other high bandwidth real-time data. Both the client and server connect to an internet time server, so they'll be synced up and the client could then predict changes to display if the connection to the server isn't fast enough.

The plugins I've been working on, I may have mentioned a few of them before. gcTimer is a general use timer, with many features and types of timers. gcPromptDisplay is a useful tool for testing or monitoring from console. It replaces the standard command prompt with the status of things you're monitoring. gcIRC is obviously an IRC bot, however I haven't decided exactly what/how this plugin will work. It is already capable of chat, but it'll do much more. ArduinoGC is basically a driver to talk to an Arduino over USB or your network. This plugin was actually designed to work on an Arduino Uno, with much less memory and flash, so this can be updated with more features for the Duo and Udoo. You install plugins only to the server. When the client connects to the server, it'll automatically download any plugins it needs from the server. Plugins like gcTimer will have a gui which runs client side and communicates with the server in real-time.

I would love to hear your comments. Give me your input or ideas. I attempted making a video to post for you, but it lost audio when it transcoded to youtube. I think I'll make a new video and post the file here for you.

07/07/2013 - Here's what's going on. I've been getting a little bit done here and there lately. When I get back full swing into this project, the next phase will be putting together a set of plugins for different tasks, and putting together more of the gui. So far, only the login/connect window has been finished. The client will also download plugins straight from the server, will update automatically, and there may be a plugin manager of some kind.

The repo can be found here although I guess it's best to be officially "copyright" until I decide exactly what open source license is best for the project. May be good to state that here. If you have any input on this subject, please do tell. I am currently using a subversion repo, which is what I personally prefer, however I do see many great benefits to using git. I'll make this deal: If someone starts contributing useful quality code to the project, and would like the project to switch to git, I'll very likely move the main repo over to github. It'll be much easier for others to submit pull requests to the repo to contribute code. Everyone gets their own copies of the repo to work on, including myself, then we push to the main repo when the code is ready and working. That way the dev version should stay mostly stable and usable as it's being developed.

The Udoo has done very well on kickstarter, with almost 24 times more funding than their original goal. This should be a great little board to work with for some time to come. I should be getting mine in the next few months. $150 usd for basically a complete computer, compatable with the arduino. I can't put to words the creative possibilities with a low cost board like this. A 1ghz quad core cpu with 1gb ram, there will be nothing holding back home automation projects. By the way, grow control is fully multi-threaded. Commands and tasks performed by the server software can process all the different queues simultaneously, as it can run on all 4 cores at the same time when needed. I'm eager to see this system perform a complex christmas lights show. Hundreds of brightness levels for many thousands of different lights, all running in real-time.

04/24/2013 - Udoo - WOW, perfect!

This thing really is great. First shipments are going out later this year. I have mine on order! Let me tell you about this thing. This is a fully functional quad core computer for under $150, with a built in Arduino! Ever hear of the Raspberry Pi? This is an upgrade from that, with an on board Arduino. I'm telling you, this is exactly what we need!

It has dual arm processors, one is a quad core running your choice of Android or Ubuntu Linux. The second is the arm based Arduino Due. Both CPU's have access to the arduino pin headers and usb ports. The quad core has hdmi with a 3d accelerated GPU, 1gb ddr3 ram, gigabit ethernet and wifi, sd card slot and sata port, among many other things. You can plug in a keyboard mouse and monitor to the quad core CPU and use it to write code and flash to the Arduino CPU on the same board. It also has connectors for a touch lcd screen and a camera. Don't toss out your old Arduino Uno just yet. Have an ethernet shield? Use it as a remote slave to the Udoo, or plug it right into usb to expand to more than 100 or 1000 io ports. Put an ir receiver/transmitter in every room, pick up any remote programmed to work with Grow Control.

What's this mean for Grow Control? This means the system can be 100% self contained. The Grow Control Server is needed to do any kind of simple or advanced scheduling or tasks or plugins, but you can run the server right on the quad core CPU, right along side the Arduino CPU it communicates with to control the io ports, which go out to the mosfets and relays. Plug in this one device and connect to it over wifi with an app on your cell phone, or a website control panel, or the desktop gui client, or write a plugin to use it some other way. That's open source baby!

01/03/2013 - I hope everyone had a great holiday. Welcome to 2013. A year for great things.

So I was looking over my web server, doing a little general clean up, when I noticed this website ran out of bandwidth just as the month was coming to an end and the new year arrived. It must be mostly Arduino IDE downloads, but that's ok, the limit was set very low. Plenty more bandwidth to spare for when Grow Control is released. The website itself actually used almost half a gig of bandwidth, so it's getting plenty of visitors. I hope a few of these blog posts are interesting. If there are any elite java devs out there interested in this project, I'd love to hear from you. Beginners are welcome too. I'm setting up a mailing list for the project, which will have information on creating your own plugins, as well as new and up-coming releases of Grow Control. Everyone who has emailed me about this project over the past few years, I'll be sending you all an email in the next few months telling you about this mailing list, and the up-coming public release of Grow Control 3.0! (No worries about spamming you. I plan to only send one email to everyone. You may join the mailing list if you'd like to keep receiving emails from me)

12/30/2012 - I got this anonymous comment, "Hi! can you share the code or software? I can't find the link on the web-site". That's probably because I haven't posted it on here yet. It is available, if you know where to look. Since someone asked, I'll post the link. Much has been finished, and line-count is ever increasing, but don't expect to checkout the source and compile it. There are a few areas of the project that are only hacked into place to make it work, in which case, it's expected to be very temporary and hasn't been committed to the repository. Unfortunately, this means it can't be compiled without some knowledge of java. I'm continuously working in the direction of a pre-release I can post here on the website, so once that has been done, I'll avoid breaking the repo.

Right now, I'm still working on file transfers from the server to client. As I've said, once this is working, the client will be loading plugins and will be partially functional. What makes this difficult is attempting to transfer binary data over a text-based protocol. It can be done reliably, but it's a bit of a pain to add this functionality into an existing abstraction. I've been thinking it would be best to add this code to the shared library, and handle the file transfers outside of the client/server code itself. To be sure it's still secure and safe, I'll have a consumer class in the server to decide if it's ok to send that file. Once the file transfer is started, only binary data can be sent until the entire file size has been sent. In the future, this can be improved to send chunks of data at a time, and be pausable. Can't wait to get this part done and move on to some plugin gui's!

12/25/2012 - The server now has a main thread queue. This was fairly simple to implement, but pretty fun too. This is just a queue of runnables which run in the order submitted, one at a time. This will help keep things thread-safe, and avoid having tons of extra threads to do simple things. Some tasks are of a lower priority, but need to be run one at a time. Anything running in this thread is inherently safe to access without having to worry about complex thread-safety, or random odd glitches caused by unsafe code. Server startup and loading plugins are the first things to run in this thread. While startup is running, other threads are spawned to wait for other high priority tasks to perform, such as listening for incoming connections from clients, and sending files. When I work on the scheduler more, I'll try moving the internal ticker to the main thread and see how that works. Either that, or I may add an option for a main thread ticker or multi-threaded/non-blocking. I'm really unsure what the requirements could be in the future, when more complex plugins are being developed. Features like this can always be added later. Right now, my test server is starting up and loading 3 plugins, and updating from a time server, in under 1 second. Almost instant. I'm still thinking I should move things like event listeners to the main thread also. Merry Christmas all!

360 2012-12-25 23:34:42 [info] Internal time adjusted by +113.838 seconds
360 2012-12-25 23:34:42 [debug] System time:   25-Dec-2012 23:32:49.081
360 2012-12-25 23:34:42 [debug] Adjusted time: 25-Dec-2012 23:34:42.949
360 2012-12-25 23:34:42 [info] Started thread queue..
[[ Starting GC Server ]]
360 2012-12-25 23:34:42 [info] GrowControl 3.0.4 Server is starting..
360 2012-12-25 23:34:42 [debug] Loading config file: config.yml
360 2012-12-25 23:34:43 [info] Set log level: info
360 2012-12-25 23:34:43 [info] Loaded [ 2 ] zones.

12/24/2012 - That was a good amount of work, 10 commits in one day. I filled the log above, which displays the latest 10 commit logs. The protocol listed right below is what I just finished. Everything except the actual file transfers. The username/password verification needs to be finished too, but that's fairly minor. Just gotta save the info someplace and check it when a connection is made to the server. Everything is now in place to keep moving forward. Next, the plugin jar files will download to the client, then will load automatically. The only plugins that will be officially supported will be open source, and freshly compiled before uploading to the website. I may add a feature later on, where you can install plugins automatically by entering commands, and will download everything right from a repository on I think... I may have a proof of concept demo ready soon. I'm excited to start designing the timer plugin, which will start with custom control components for the gui. The client is currently maybe 1 line of code away from loading a plugin window to the dashboard. That will be exciting to see working too, but it'll be finished next also.

The Protocol
  • *client connects to server*
  • client -> server | HELLO <client-version> <username> <password>
  • server -> client | HEY <server-version>
  • client -> server | LIST zones
  • server -> client | ZONE <zone-name>
  • client -> server | LIST plugins client
  • server -> client | PLUGIN <plugin-name> <plugin-version>
  • client -> server | FILEREQUEST: <filename>
  • server -> client | FILESENDING: <filename> <size-bytes>NULL<binary-file-data>NULL

12/20/2012 - Hey, the end of the world is tomorrow. Hope it's a nice day out. Grow Control is doing well, and will continue development. A quick update, plugins are one step away from downloading to the client and loading windows to the dashboard. Last night, I created and implemented a much better method of handling the state of the client application. I've put a class in charge of updating or loading/unloading windows when a connection is made to the server. Previous code was pretty ugly, but was only temporary anyway. I'll also need to improve how this class and others interact with the windows. This is something I was expecting, but haven't looked into it at any extend until now. Memory concurrency bugs that are similar to any non-thread-safe code running in a multi-threaded environment. It turns out to be a very important issue when designing a gui. I haven't yet experienced any odd issues or random crashes caused by this, but it can be extremely difficult to track down the culprit if something is overlooked. The solution I'm picturing, any public function that modifies or loads/unloads a window will throw an exception if it's not running from the gui event thread. All such actions will need to be queued up by the Event Dispatch Thread. Sounds complicated, and it is, but shouldn't be very difficult to implement this solution. If it's enough code, I'll move it to the api library, but I don't suspect it'll be more than only a few lines.

So I was doing a little interesting reading on the subjects above. Here's an interesting article. "It takes determination, commitment and perseverance to be willing to continue working on a project when nobody but you seems to be interested in it." Surviving a Hobby Open-Source Project I can relate to much of this article. Few people see the commitment I have for this project. It really does take a lot of time and effort to develop an entire application alone. I know there's many people out there waiting for a release. It gets quiet on my side, maybe one comment a month. I have a list of more than 100 email addresses for people waiting to hear from me. I'm not sending any emails until I have a functional release in sight. I will continue working on the project and blogging my progress here, but patiently waiting to send out any notifications. Believe me when I say, this project has come a long way.

12/14/2012 - I've done some performance testing on the socket server/client library I wrote for this project. Initial results were fast, but not very. It never got past 30Mb/s, and CPU usage was very high. Turns out to be just a long-standing issue I've had with my desktop. I ran the client on my windows xp vps, with the server running on the linux host os, the network graph immediately shot up to 100% on a 100Mb/s virtual nic. After switching the virtual nic to the intel e1000 gigabit nic, just needed drivers, it transferred a 420MB file in 21 seconds. By my calculations, 160Mb/s. That's more like it! So, to sum it up, if you're using gigabit and your computer isn't crap, this software can max out the speed of a ssd without breaking a sweat. Is gigabit performance really needed for home automation? Not at all, but it's great to know the capability is right there! In fact, the plugin file transfers will need to be throttled back, to prevent the possibility of bogging down your internet. Not to worry, I can easily put a setting for this in the config file. By default, it'll still probably download all your plugins in under a second, but wont burst at an insane rate. So, it's coming along. I'll have the client downloading any plugins it needs and loading them within the next few days.

12/10/2012 - Here's an example of how the new socket api can be used. This example is a multi-threaded tcp socket server, listening on port 88. All this example does is start listening for connections, create a pool of sockets and threads, and dump any incoming data to console. It's basically 2 lines of code, and the rest is just required to make it work. Client connections are done in a similar way.

pxnSocketServer socket = new pxnSocketServer(80, new processorFactory() );

public class processorFactory implements pxnSocketProcessorFactory {
	public pxnSocketProcessor newProcessor() {
		return new processor();

public class processor extends pxnSocketProcessorThreaded {
	public void processLine(String line) {

12/08/2012 - As you can see above in the repo logs, I've been working on moving the socket classes into the shared library. In my previous post, I explained how the client is able to connect and communicate with the server. Well, so far the client is only sending a single packet "HELLO" and the server is only dumping it to console. But the server is actualy doing it with 3 threads per connection, and most of the code to handle this is finished. The client on the other hand, is only a single socket with a reading thread that doesn't yet work. Again, I've decided to move code to the library, but at the time of writing this, it's mostly finished already. Both the client and server share the same code which handles the 3 threads per connection. The data processor can be implemented as threaded or blocking (meaning it can run with either 2 or 3 threads per connection). This is because I'm taking advantage of TCP's duplexing ability, to transmit and receive at the same time. One thread to receive data, one to transmit, and an optional thread for processing the received data. I'm not adding this to any config file, it will just always internally run 3 threads, but plugins will have the option of using 2 threads if performance isn't an issue. And yes, any plugin can use these socket classes! Say you're writing a plugin that requires a high performance multi-threaded socket server, this new api can probably be used with only 5 lines of code. I do have a bit more work to do on these classes, but I should have it committed tomorrow night.

I have a guesstimate of the performance of this new socket server. Messing around flooding the server with junk data, I got a rough estimate of 6000 lines being processed per second. It may slow down a bit as I finish adding the processing code, but it'll also speed up more when it's not dumping every line to console. I already have code to display debug logs showing how full the incoming queue fills and how much, but I think it'd be a good idea to also calculate how long it takes to process that queue. I'm also interested to know if it processes the incoming data faster than it receives it. I may have answers as soon as tomorrow night.

Check it out

12/06/2012 - Check this out. Not quite functional yet, but in the screenshot below, the client connects to the server, sends the first packet, and the server receives it and dumps it to console. A bit more work and the client will be logging in, then I make it functional! On the server side, one thread listens for new incoming connections, and three threads handle each established connection. One reads the incoming data, one processes the data and performs whatever actions needed, and one more thread sends data back to the client. This is designed with incoming and outgoing thread-safe queues, the socket on each end, and the processing thread in the middle. In this format, the server can do as much as possible in parallel, to prevent any latency possible. It can be receiving data and adding it to the processing queue, while a long list of some kind (or a file even) is being processed and sent back to the client. One thread never waits on another thread unless the queue is empty.

Grow Control Client & Server

As I've said before, when I described the beginnings of this protocol, the client sends a HELLO packet to the server, the server authorizes the connection, and sends a HEY packet back to the client. So far, all the base code is written and working to send and receive the packets, and the client is sending the HELLO login packet to the server, which displays it. Next, I'll remove the displaying in console, and write some code in the processor thread to actually handle it and reply to the client. Then, the fun of doing it all over again client-side. The client will need to listen for incoming data, process it in a second thread, then do what it needs to, and finally in a third thread, send a request to the server for plugin information. Wow, describing this as quick as possible makes for some long sentences.

So, once a list of plugins is requested and sent to the client, the client will need to check which plugins it has already, load those, then request file transfers from the server for whatever plugins it needs. Somehow, the client and server will need to keep track of how many bytes are in each file, as it sends chunks of the files in packets. I have a good idea how to do this, and I've worked with file transfers before, just never both client and server with a custom protocol.

Quick Update: Since the server is partly working, and is starting to handle data from the client, I thought I'd start working on the client side of this code. Wait, this client/server socket code really should be moved to the library. Here goes a bit more work, but this means the socket api will be available for plugins to use also, and not just for the connection between the client and server. It's really shaping up. Imagine a 5 or 10 line plugin using this socket api. Piece of cake for any java programmer to use.

12/03/2012 - Here's another early dev screenshot of the Grow Control Client/GUI. As you can see, there's not much to it yet, but it's coming along pretty fast. Next, I'll be adding more content to this, and making it all work. Receiving the packets from the server, processing them, and displaying the dashboard. Also, something a bit more complicated will be implemented right away. The client will need to request a list of plugins from the server, then request file transfers for any plugins it doesn't have, or that need updating. These file transfers will be done over a second tcp connection, but I've been considering doing all the transfers and communications over a single connection to start off. The client can't display anything until the plugins it needs are loaded, so it probably wont matter much if the communications are blocked by file transfers for a while. The plugin jars are pretty small files, only a few kb each, so it'll probably be finished loading in less than a second. The first plugins I'll have working in the GUI will be ArduinoGC, and a simple timer and toggle button for controls. If you have any comments or suggestions on any of this, now's the time to send me a comment. I'm designing this to be functional, but I'm always trying out new methods and designs, and I welcome a chance to talk about the project with a potential end user.

gcClient early dev

Moving to a shared/compiled-in library

11/28/2012 - This is something I've been debating since I started on the code last week. I was excepting I'd run into this issue; the client shares a lot of the same code as the server. It's very inefficient and messy to copy/paste the code over, then try keeping them both updated when I make changes. What I needed was a shared library of classes both the client and server share in common. (The library may even be useful for other programs or projects.)

It's a complicated project. The first night I did great, planning out the new library and moving classes over. Making it actually work took a few extra days, but tonight, I have it compiling and running. I've been doing all this code in a sandbox branch, so now that I have working code, next I'll finish and clean up the code as I move everything to the trunk. Meaning, I'm moving my test code over to the main project. The trade-off doing all this extra work, the server gets some rearranding, but the client gets a nice chunk of already finished code. So all the plugin listeners, events, and other objects and tools that were written for the server will all be available to the client. Once this library is finished up and committed, I can focus on the gui more without so much work on background processes. I'm creating this library using SVN Externals, so there is no library to compile or include. Just do an svn update and compile.

A Connection Has Been Made

11/22/2012 - Below is the very first window of the Grow Control Client. The dropdown list at the top saves your connection info. The username and password fields are optional, depending on the security settings in the server. This window, I just made last night. Tonight, I'm making it functional. Just moments ago, this new client program made its very first connection to the server! The handshake is next.

Grow Control Login

Now, we're finally getting into designing the actual communications protocol between the client and server. The server listens on a port, usually 1142, with a pool of sockets. It discretely listens and silently waits. When the client makes a successful connection to the server, the client sends the first packet of commands to the server to initiate communication. The client/server communication will be handled similar to the way console commands are handled. In fact, if the plugin chooses to, console commands can be run remotely from the client.

  1. HELLO - The client sends the HELLO command to the server, including the username, password, and the clients running version number.
  2. HEY - If the server decides the login is successful, it sends the HEY command back to the client, including the servers running version number.
  3. Well that was a short list. Actually, it's extremely difficult to design a good protocol without code to base it around. The internal objects haven't all been created yet, so their data needs are still unknown.

The Big Question - So yeah, a few more days to finish up making this "Connect to server.." window fully functional, and a successful handshake with the server to tell the program to close the window and open up the dashboard window. I'm very happy with the state of the project right this moment. Basic features are being finished up, and function is bringing it to life. So the question is, at what point do I stop and make the release?! What features are still crucially needed to make this project functional enough to make you (the user) happy with it? I will have download links for both the jar and exe versions of the client and server, as well as startup scripts and batch files for linux and windows. The basic few plugins I've made so far will also be included in the packages. The ArduinoGC driver, a simple test output display for the console, and a generic timer to control your devices. A GrowLog logging plugin is also in the works, which will log everything. The basic plugin API is finished and working. The first version I release will be labeled 3.0.3 and will include everything I've finished so far, and will be functional.

11/15/2012 - Just finished some work on the plugin loader. It's much improved, with a new simpler event listener. Tomorrow, I'll clean up the command event code and get that working. You'll then be able to type commands right to the ArduinoGC plugin, which communicates with an Arduino to control lights and such. Say you'd like to manually turn on a light on pin 5 of the Arduino from the console, 'arduinogc pin 5 on'. This may be make simpler in the future, using a command something like 'lamp on', possibly a device alias feature or plugin. Internal communication between plugins, however, is a bit different. The same information is transfered, but in the form of an event object. The sending plugin would just call an api function to trigger a new event, every loaded plugin gets a chance to handle the event or just ignore it.

Once this is finished, probably by tomorrow, I plan to next remove the quartz scheduler and write a simpler custom scheduler, more specific to the needs of this project. By default, each plugin gets a tick event once per second, on the dot. The internal clock is actually synced with a time server over the internet. The timers can be accurate down to around 5 or 10ms, so you could possibly set it to run 100 ticks per second. Each tick gives a timer a chance to update or change its state, on or off, or dimming. I do plan to do an in-depth review of the performance of this system once it's ready for it. I'd like to post stats on how many devices per second this software can update, using a single Arduino, or multiple over ethernet. Once I get an Arduino Due, I'll also test with that. A blind guess, it can probably handle 500-1000 updates per second on a single microprocessor. It depends on the speed of its network controller chip. We'll see how well it performs. The Grow Control software is fast enough, it can probably handle a few dozen microprocessors at max speed, if not more. I'm really just guessing at how fast it should be, based on the performance I've seen and my knowlege of the hardware. Anyway, the tick rate of the server can be changed in the config.yml file. This is a feature I'm sure some people will love and take for granted.

Gettin it done!

11/12/2012 - I'm really liking how this new java version of Grow Control is turning out. It does take time to figure things out and write good quality code, but it helps having a good plan laid out in my head and on paper. In the past, dealing with a closed source project, I never wanted to release anything until I was sure you (the end user) wouldn't have any issues getting it to work. This turned out to delay releases time after time. I feel more comfortable putting out an early release now that it's all open source. You're not running programs blindly, unsure what in the world is going on under the hood. If something does break, the source code is available to help you figure out what's going wrong. If you're comfortable with java, you can even modify it to your own liking.

Keeping you up to date - The server is functional and has been since this past summer. The server itself doesn't do a whole lot on its own. It's more of a hub for communication. I currently have 3 plugins working with the server, for connecting to an arduino, displaying fake hardware outputs for testing, and a generic timer. The client GUI program connects to the server and displays a graphical dashboard of your automation system. The client is still in design stage, but it does connect and communicate with the server, and functionality is currently being added. The way plugins work, each plugin can have 2 startup classes or starting points. gcServerPlugin classes run on the server. When the client connects to the server and logs in, it gets a list of plugins to load, and downloads the plugins from the server automatically, and runs gcClientPlugin classes. This means it's as easy as dropping a plugin jar into the server and everything else is automatic from there. Both the client and server run the plugin from the same file even from across the internet.

This is a screenshot I took over the summer, but never posted it on the website until now. This is the server console. Off the bottom of the screenshot is a command prompt. You can access this console using screen, or have the client run it for you in the background.

Grow Control 3.0 - Now open source!

07/06/2012 - If you can't tell, I'm excited to see this project quickly coming together into the potential I've envisioned. I have a working prototype about 70% finished. I'm reworking some of my first draft plans and finishing up the critical features. I've already had it working, but I have some things to change, and some class files to finish. The way it's looking, I may have the first alpha version ready by the end of the week.

I've been tossing ideas around in my head for so long now.. One of them is open source. I strongly feel keeping the source closed and charging for the software will only hold back what this can become. I believe my ideas could be the next big thing, and by no means do I want to stifle it or keep it to myself. I want the community to join in! Most of the real functionality of this software will come from the plugins it runs. Even basic timers and environmental controls like pumps or fans, and hardware interfaces like the arduino, will all be contained in plugins. If you don't like how a timer works, you can easily create your own plugin that does. The plugin system is designed to be easy to use. A simple plugin can be made in only a handful of minutes, and a powerful set of libraries will help you add complex features in no time.

06/29/2012 - Just a quick update I'd like to tell you about. A finished feature. When the Grow Control server starts up, it can ask a time server for the exact time. Timers and plugins will use that precise clock to automate your garden with accuracy down to the millisecond! Next, I'd like to get the first timer working and communicating with the ArduinoGC plugin, and the arduino itself.

Grow Control 3.0 - Now with Java!

06/27/2012 - I have to say, it's coming along fast. I've had this idea planned for quite some time, but I never expected it to fly together at this speed. It is still in the planning stage, not even alpha yet, but it'll be there in no time. Now that I have something started and I know what will work and what's possible, I'll take the time to explain my vision. Grow Control will have a client and server app contained in a single jar file (or possibly exe). By default, it should seamlessly run the client gui and connect to the server running in the background. This will allow you to run it like a normal app, or run it on a headless server and connect to it from a desktop using the same gui. It will natively support both Linux and Windows, that means no need for wine!

This new Grow Control server sports a hot new scheduler. Timers will be just as configurable as the original was intended. I wont restrict you to just a lamp timer and a pump interval. That's like holding up a glass of water, "this is the ocean!" How powerful are computers today? The power of timers should only be limited by your imagination! I'm not just blowing smoke. I've always intended to spoil you with features and configurability.

One thing java does make more than 10,000% easier than in vb6, plugins! Anyone play minecraft? Ever set up your own bukkit server? It'll be as easy as that. Just drop a plugin jar into the plugins folder and start Grow Control. The plugin will load and you're ready to use it. I'll make a few plugins myself, then I expect the community will take over and put out some awesome plugins to do whatever you imagine. There will be both client and server plugins, and plugins that can run as both. That means, for example, say it's a journaling plugin. The server side of the plugin would handle saving logs for temperature and timer events. The client side of the plugin could have a nice gui to enter your own logs and observations, and display some charts. The plugins use Grow Controls own internal framework to communicate between client and server.

More importantly, what's done? I'm not starting on the client side or the gui yet. I am only human at the moment. The engine of this machine is the server. So far, the server starts up, displays some standard logging, loads plugins and schedulers, and allows you to run commands in console. Plugins can register to listen for commands, and there's a handful of built in commands. The first plugin is half finished, and is called ArduinoGC. When the plugin loads on the server, it attempts to connect to any configured arduinos, either over usb or ethernet, and gets some status information from it. Timers and other plugins can very simply communicate with the arduino by Grow Controls built in framework.

Grow Control will not die!

06/03/2012 - No fear! This project is not dead, only on hold for the time being. Grow Control is very much alive. I'm busy doing some other development right now, but when I get back to this, I will finish it and all will be awesome.

One problem I've giving a lot of thought. With the future release of the windows 7 replacement, support for older visual basic 6 programs like this one will be severely crippled or completely lost.. I suspect a lot of people will use this program on an older computer used as a dedicated system, but it's still not desirable. I've been polishing my java skills, and considering using java for this project. I'm unsure how this would turn out, but it would have native support for both windows and linux, and likely a client/server model.

01/24/2012 - Grow Control is finally communicating with plugins. I finally feel like I've accomplished something. The screenshot below is what it looks like at the moment. The timer is sending commands to the plugin, which is the window with the green and gray led pictures in it. Tomorrow I drop in the Arduino code and it should be working! Next I'll work on the timer code. There are a few bugs in the hot start protection, and a few more features to add to customize the timers. I can't wait to see some of these new, more advanced features in action.

Grow Control 1.4.29

I've had the software working a few times over the few years I've been working on the project. I'm stunned by the amount of work that goes into a project to take it from just a hobby to a finished product. It's taken countless thousands of hours to get to this point, but I think the software has evolved enough to work out most of the design and implimentation bugs. We'll work on getting it stable and reliable, then open it up to the community to use and make requests. I'm still unsure what will be in a pay version, but the first versions I release will be 100% free. Most of the features will always be free, but some things may have to be pay version only. There's a lot of inventment to recoup, and future development to fund. Check back again soon to see my progress, or maybe I'll even have a finished version ready for you!

Currently 21,000 lines of code. Most of it finished :-)

Random Screenshot

Making good progress!

01/22/2012 - The Arduino code has been rewritten and greatly improved. It now fully supports usb and both ethernet shields (wiznet and 28j60). On the pc side, queueing has been finished, to improve communication to and from the Arduino. The next step is to import this new communications code into a plugin that works with Grow Control. Here, I run into a wall. I spent weeks working on code that Grow Control will use to communicate across processes to the plugins, but it seems no amount of bug fixing will ever keep it from crashing.. Lesson learned: subclassing is a very bad idea in VB6, in all cases. A complex method has failed me, so it's back to the drawing board with K.I.S.S. in mind. A much easier method is to use the registry. It's not instantaneous like subclassing is, but it's still pretty fast and not heavy on resources. The communication delay should only be around 50ms, and it should still be able to handle hundreds of commands a second.

So that's where I'm at. A bunch more work, then it's finished. I should have Grow Control sending commands to the Arduino sometime this week. Timers need a bit more work yet, but they are working and usable. Some more work to finish up climate control, and that will be finished and working too. A few more weeks and I'll be down to just clean up and some quick testing.

Hard at work once again

I'll attempt to give a description of what work is left to do on the next release. I'm currently rewriting some of the website code. I have an api module left to finish, which I'm about to start on. After that, I can upload the new version of the website. That's it for the website update phase. Next phase is to finalize work on Grow Controls main program code. As far as I can remember, mostly everything is finished and working, but I probably will come across something that needs work.

Documentation is another phase running in parallel. I've started it, and it's looking good. It will include guides to build the electronics. I hope to have at least 2 versions of the guides. One for beginners and a more advanced and detailed version.

Update: I'm having some odd issues again where the development ide crashes when I run Grow Control. I'll have to reassemble the project from scratch to find the problem. I'll start on this once I have the above mentioned code finished.

I'll update this more soon.

Arduino 1.0

There is talk in the mailing list of a beta2 release in the next week, and a full release of 1.0 mid next month. This is good for the Grow Control project because then we can get back to work on the firmware. ArduinoGC will then have much better support for more shields. Both the official and unofficial ethernet shields, and soon after, wifi. We're looking for help! If you're an Arduino 1.0 programmer and think you can help, contact us!

I have been back to working on Grow Control the past few weeks, but nothing major finished to report yet. I'm working on what needs to be done to get it out. I'll post more news soon.

Need an arduino programmer!

Anyone a good arduino programmer with an etherShield or wiznet Ethernet Shield? I could use some help writing better software to run on the arduino. My code works, I'm just doing some updates to it right now, but it could be written better by someone with more experience in that area.

Short hiatus

I'll be back to work on Grow Control in about a week. I'm giving my other website,, some very long over-due updates. I'll post on there what the updates are, but I do plan on adding an Arduino section, and maybe one for hydroponics. It's just about finished.

When I get back to work, I do realize it's been a while sinse the last release, and there have been many bug fixes and new features. The next release, I plan to finish up some testing on my own, then get the first public free version released.

Happy New Year!

The goal for this month: to get to a stable point where the Grow Control Free Edition can be released. So keep an eye out for it!

ArduinoGC 1.3.5 Released - Many new updates to the testing app and the Arduino software, and I've renamed it to ArduinoGC. These 2 programs pair up to give you control and monitoring capabilities for each of the pins of the Arduino. This software is essentially the controller hub that connects Grow Control to the hardware of the garden.

Most notable, pin monitoring has been finished. Each pin can be set to report its current state back to the computer, twice a second. This will be most useful for temperature sensors, which are already working in Grow Control and will be in the next version. Please note, the etherShield itself doesn't support persistent connections, so pin monitoring wont work. A solution for this is in the works.

Calibrated Temperature Sensors!

12/30/2010 - Here's a sneak peek at what I've been working on. Take a thermistor, dunk it in 3 different temperature cups of water and capture the ADC values returned from the Arduino, then click the calibrate button. The software does all the complicated math in the background, and sets the A, B, and C values. Those values can then be used by the software to give you a very precise temperature reading. What more could you ask for! These temperature sensors can easily be found online for around 25 cents each. Just give it a good calibration and you're ready to go. 2 weeks of research, and trial and error. It's finally working! More to finish up on this, but it will be posted soon.

auto calibrated temperature sensors

Arduino Ethershield Support Added!

The Arduino Ethershield is finished and working well. The code that runs on the Arduino has been updated, and support for the Ethershield has been added. The official Ethernet Shield will be supported eventually, but I don't have one to work with at the moment. The Grow Control software has many updates for the upcoming beta 4 release. I'll most likely include the early version of the scripting engine.

I've been doing some real-life testing of the system. Communication over ethernet has been working very well for me, but I did have some trouble with usb communication locking up. That turned out to be the fault of my usb hub. It's always a good idea to avoid using hubs with something like this. The Arduino should be plugged directly into the computer, or at least use a good quality hub with it's own power supply.

Grow Control 1.3.249 beta 3 released

Grow Control has never felt so complete before today. The Options window is finished with it's complete rewrite. Every feature currently supported in the program can now be set up right in the Options window. No need to go in the registry for anything. And, it's now packaged in an installer. Please note, Vista and 7 users may have to right click on the installer and Run As Administrator if the installer locks up. Should be fixed next month

The scripting engine, an automatic updater, and support for the Arduino ethernet shield will be coming up next! We'll have to start finding ways to break the program and making a list, so they can be fixed.

Progress of beta 3

11/09/2010 - The new arduino driver has been finished, as well as a new graphical timer control. The edges of the yellow timer blocks can now be drug with the mouse to adjust them. These are both finished and working in the Options window. This phase of the project is wrapping up. Over the next few days, I will be finishing up the Timers page of the Options window, then create a quick and simple page for adding/editing rooms. At this point, I will be ready to mark it as beta 3 and upload the new installer to the website. I'm bad at guessing these time frames, but I'll guess 3 days from now.

There is a new Screenshots page, and a new Docs/Guides section. I will be posting guides here for basic setup and operation of the Grow Control software, as well as electronics how to's to help you put things together.

10/06/2010 - Work on the options window has been set to the side to improve another piece of code that is needed to continue the on options window. I've completely rewrote the usb device detection method for arduino's. The driver api libraries for it are buggy, and I wasn't satisfied with any of the tricks I could come up with to try improving it. It hangs up the program for a moment when it's called, and the results are unpredictable with newly plugged devices and ones that are already in use. I found a much more reliable and faster method to detect usb devices right from the os and bypass the normal ftdi api's. No need to understand any of this. I've finished the work, and there shouldn't be many problems with this new code. It's been tested on windows xp and 7, with default security settings.

To sum it up, I have finished this new arduino usb detection code, and I'm starting work adding it into the options window tonight. I may get a release of this out very soon.

09/11/2010 - The big change in the next release will be the Options window. A complete rewrite of it to smooth out rough spots when loading. The basic settings are finished, and a few of the hardware types are configurable now, but the rest will be finished up in later releases. I am currently finishing up the Arduino config page, then I will have a release ready to put out.

Here's a quick picture of a device I'm putting together. It's a 12 volt power supply with a special feature. It has a 2 channel pwm amp built in. I'll draw up some schematics and tutorials eventually, but it's really pretty simple. Just 2 resistors and a mosfet per channel, the relay is optional. I plan to use this to power a cheap 12 volt fan I got from walmart. The pwm speed control should work with just about any low voltage fan, but reversing polarity doesn't work with most computer fans.

In the picture, I just have the mosfets hooked up to 2 of the solenoids, just messing with it. I was planning to use small relays to switch the solenoids on and off, but I do love how well the mosfets work. They can be directly connected to the arduino without a transistor in the middle to buffer it. They only draw less then 10ma on the arduino, but can switch 5 amps easy.

GrowControl 1.3.224 beta 2 Released!

08/26/2010 - This release fixes a few big bugs found in the arduino interface and the licensing system. There's still room for beta testers. Read below if you'd like to help test a copy. We can use your help.

Starting a rewrite of the options window next. I found better methods to make it load much smoother and organize the code. This shouldn't take very long. I'll have a release out in a week or 2 like this one was. I'll just get the most needed option fields working first.

GrowControl 1.3.218 beta 1 Released!

08/18/2010 - Beta testing has begun. Email me if you'd like to join the testers. We are currently focusing on the Arduino hardware and simple light timers, but the printer port and other hardware is also supported. A word of warning, this may even be an alpha release. Many parts of the program are unfinished, but we're working on it one feature at a time. Testing will remain private for now, until we have a stable application, but will eventually be made public and free. Don't forget to check out the yahoo group/mailing list

Valid XHTML 1.0 Transitional
ProSiteManager Core 3.0 by Mattsoft
Run this portal on your own site!
Render time: 0.012 seconds - Queries: 0