Grow Control - Computer Automated Hydroponics at its Best!



esper.net #GrowControl Come chat

  
I always love to hear your ideas or comments, so send them my way!
Comments
Email: 
(optional, leave empty to be anonymous)
Anti-Spam:         



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 http://ci.poixson.com and automatically compiles what can be found in the github repositories. There is also a yum repository at http://yum.poixson.com 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! http://ci.poixson.com/job/GrowControl/ 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.

Finished

  • 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. http://code.google.com/p/growcontrol/ 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 growcontrol.com. 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 {
	@Override
	public pxnSocketProcessor newProcessor() {
		return new processor();
	}
}

public class processor extends pxnSocketProcessorThreaded {
	@Override
	public void processLine(String line) {
		System.out.println(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, SchematicsForFree.com, 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 http://tech.groups.yahoo.com/group/computerhydro/


PWM Circuit

7/5/2010 - Try using this PWM Driver Circuit for speed controlling computer fans. The Arduino software I wrote supports PWM, and so does the Grow Control software. I'm building a similar circuit, but with the EMF protection diode in the right place, and using a signal to base resistor of 680 ohm in place of the 1k. By my calculations, their resistor value is wrong, putting a limit of 3.6A, collector to emitter. Their specs say each channel can handle up to 5A, and so does the tip120 Darlington Mosfet I got from Radio Shack. The resistor value should be 680ohm to allow the mosfet to pass it's max continuous current. I may be wrong, so someone please check my work.

5V - 1.4V = 3.6V
Ib = 5A / 1000 = 5mA
I = V / R
3.6V / 1K = 3.6A
3.6V / 680ohm = 5.2A

My biggest 12 volt fan is a cheap thing from walmart. All 3 fans that I have fried their own wall transformers, plus a few others I had laying around. I put together a quick 12 volt 10 amp unregulated power supply, and have been running one of the fans on it's low setting with good results. My guess is, maybe the fan motors have some kind of damaging inductive feedback going back into the small power supplies. I'll be testing the PWM circuit with this fan soon, but I have to finish testing and building it first. I'm interested to see how well the mosfet will handle such a power abusive fan. Keep in mind, I'm mounting the mosfets on good heat sinks, with the proper insulating kit and grease.

Another idea, my final design will have a DPDT relay on each channel to reverse polarity on the output when activated. It doesn't have to be used or even hooked up. It will just stay default polarity when not in use, but may be very handy for future use! Some fans can be reversed, or could be used for opening/closing automatic shutters or loovers, or for reversing the direction of a light mover. Who knows what crazy ideas might be thought up.











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