MVP - Product Design


Yes, very much so.

  1. There seems to be height based stratification if I don’t have a fan blowing. The dynamics change based on whether the grow light is on or off.
  2. For microgreens, it seemed like evaporative cooling was lowering the tank temperature below ambient when I had the fan pointed directly at the grow tray.
  3. For AeroGarden lettuce, the LED power supply was under the tank, so it heated the tank about 2°C above ambient without a fan. If I pointed a fan right at it, the tank temperature tracked ambient air. [edit: aquarium pumps or the like could have a similar heating effect]

Based on building inspection thermal imaging work that I’ve done, I can tell you that it’s common for things in close proximity to be substantially different temperatures for surprising reasons. Since we don’t naturally see heat, it’s hard to develop intuition for how it works. DS18B20 sensors are cheap and easy to use, so we might as well stick them on stuff that might matter.

To begin with, I set the timer for on at 6am and off at 8pm, and I used file names with timestamps for all the images. So, it was easy to predict the file names of dark images.

First I used rsync to get a copy of the images on my mac from the pi, then I duplicated the directory to avoid irreversible mistakes, then I used rm with a glob pattern to remove what I didn’t want. Since I picked the image recording times to be 10 minutes away from the timer switching, I didn’t have to worry about clock drift.

I think this would work, but I’m just making it up now, so I might not have done the pattern right. I always test this stuff with ls first anyway before using an aggressive glob pattern with rm or mv.

# file names have the format
rm *_{20,21,22,23,00,01,02,03,04,05}.jpg

I used a similar approach to separate the files for 30 minutes past the hour

rm *_??.{10,20}.??.jpg


I overlooked this question in my earlier reply. Yes, probably so. If you use the Raspberry Pi camera with the raspistill command line tool, it saves exposure details in the jpeg EXIF metadata. By checking the ISO setting, it’s easy to get a relative measure of lots of light vs. not so much light. This comment talks about using exiv2 to check the ISO: Growing food: I just ordered a MicroGrow Kit from Hamama

It’s also possible to make histograms and fancier stuff using ImageMagick (convert, mogrify, etc.), but that takes a lot more CPU than just checking the metadata.

CV and Image Processing for the PFC

I posted a survey to the MVP - Commmunity Development thread. I would appreciate all of your feedback. I hope I did a good job representing the discussions concerns and hopefully we’ll get a few responses which will tell us what users really care about.


@webbhm as an update to my comments on temperature, here’s my current temperature chart for today. Blue dots are DS18B20 and red dots are Si7021, x axis is time, y axis is °C. I’ve got the Si7021 taped to the side of the bookshelf I’ve been using as a growth chamber–about 5 inches up and maybe 0.5 inches out from the side of the shelf. Until 2:40pm, I had the DS18B20 laying on the bottom of the shelf, but then I moved it so it’s hanging in the air about a foot above the Si7021. As you can see, starting at 2:50pm, the DS18B20 is now a little warmer than the Si7021 instead of about half a degree cooler.


Once we get some boxes, these sorts of graphs will be useful to see how much (or little) the circulation fan affects things, leaf canopy, etc.
The other factor we need to watch is callibration. I have several thermometers, and they can be a half degree different from each other.


I absolutely agree with you. In refrigeration manufacturing they commonly test the cases at dozens of places in the unit. They also do these tests at varying levels of content (full shelves, empty shelves). One thing that we’ve yet to even mention is how much as the plants grow that will change the unit. In the very beginning, when the plants are tiny much of the light will be hitting the top of a reservoir (if your reservoir is black, this can really make an impact). As your plants grow, much of that energy that then turns into heat is later blocked by the canopy of your plant. I definitely think there is a huge amount we can learn by comparing the differences inside of a grow box.

@wsnook cool graph btw. Curiosity, why do you think there was a dip midday?


Thermal mass filters and delays heat changes–it’s kinda like an audio filter circuit with a time constant and a phase shift. The big drivers are radiative heating from the sun (really hot) and radiative cooling to the night sky (really cold). Today, 9am was about when the effects of today’s sun caught up with the effects of last night’s cold empty space.


@_ic and (cc Peter & Howard),

I’ve picked a short term direction for my experiments, and I’m interested to hear if you have ideas about ways I might make that work more relevant to your own projects. In particular, I’m curious about maybe porting firmware from Photon to Arduino-like hardware that you might already have.

Last night, I started hacking on my farm controller and firmware, and…

  • I decided to remove everything about the Raspberry Pi camera. My sense is that, for most people, using a cron job with raspistill would probably be sufficient–no need for a custom controller. If you also used a script to make a symbolic link to the latest picture–maybe in a place like /var/www/html/latest.jpg–it would be easy to see the pictures using nginx.

  • I’m in the process of working on a simple plaintext record based file format that can record all of my sensor measurements. Previously, I could only record two temperatures and notes. But, the new way will handle lots of different measurements and metadata. This is a work in progress.

  • Once I collect a day or two of data in a file format I’m happy with, I want to start improving my SVG charting code to display temperature, relative humidity, and pressure.

My questions for you folks:

  1. Does the sensor file format I’m working on sound interesting to you? What about the SVG chart generation code? If the answer is “yes” to either of those, is it a problem that I’m writing the code in golang? Would it be a lot better for you if I were using Python?

  2. Do you think the firmware I’ve been working on (sensor & actuator drivers + serial control protocol) has the potential to be useful in your projects? Are you interested in trying to run it on other Arduino-like platforms? Photon is mostly compatible with Arduino, so there’s a good chance that my code might work fine in the Arduino IDE for many other devices.

  3. Do you have any ideas about ways I could steer my work that would help with your projects? I make no promises, but I would enjoy seeing my code be helpful outside my own little experiments.

[edit: here’s a gist with a sample of the data I’ve been collecting since last night: I’m not happy with the record format yet, but it’s a good start. I think something like this would be better: ]


@wsnook We seem to have pivoted in different directions. Now I think a camera is vital, and after a question from Peter, I’ve decided to build my next controller around a Pi Zero.
I think the MVP should support all popular platforms, including Arduino (covers ESP, Edison and the new boards), but I’m more focused on a full PFC for now.

For the recipes, my plan was that the PFC would store data in a .csv file, something like this
time,air_int_temp,air_int_rh,co2,air_ext_temp,air_ext_rh,water_temp,water_ec,water_pH,ppfd_red,ppfd_green,ppfd_blue,hpa_feed,hpa_interval,hydro_feed,hydro_interval 1495646318,22,60,,23,70,19,,,30,12,7,1500,600,,

Blanks where the PFC can’t capture that data, or if it doesn’t apply, ie hydroponics or HPA
This file can be processed afterwards into a recipe that analyzes changes and important conditions.

For your questions, I have no preference for the code language.
For the firmware, our data acquisition methods are quite similar, but most of my code is for MQTT. I’m not familiar with how the Photon’s WiFi works, is that a wireless serial bridge? I would like to see how it develops. When I return to Arduino, I think the methods could be useful.
I don’t know how and where our projects could intersect at the moment, mostly because my direction is in limbo.

Let me know what you think of the data format, and I’ll post my Brainbox plans soon


I agree that cameras are very useful. I removed the camera control stuff from my code in the last couple days because it seems like I was going to a lot of trouble to accomplish a task that cron and a bash script could do better. I still think images are important.

I started off using a column based file format, but I got frustrated with it. The trouble is that it’s hard to anticipate in advance what you might want to add or change. On the other hand, a big advantage of CSV is that it’s easy to import into a spreadsheet. Chapter 5 of “The Art of UNIX Programming” has an interesting discussion of plain text file formats.

[edit: For your question about Photon wifi, I’m not sure what underlying protocol they use. Their focus is on an ecosystem of APIs to provide things like low latency event notifications (haven’t tried it), over the air firmware updates (this is what I care about–it’s great), IFTTT integration (haven’t tried it), and webooks (haven’t tried it). In my firmware, I mostly leave the wifi turned off and talk to a Pi Zero or Pi 3 over usb serial.]


Particle seems to be working nicely, but fighting Pi.
The logic to get lights on/off from the camera (especially if using a USB camera) gets to be a bit tricky, so I decided to go with a simple ($1) photocell. After getting no readings (and it works fine in Arduino!), I discovered that Raspberry doesn’t really implement analogRead. So I grabbed my handy TSL2591. Again nothing, though it works fine on Arduino with my old code. Turns out I have a Grove version which doesn’t work with Particle’s Adafruit public library. So, order another sensor via Amazon. My $1 solution has now jumped an order of magnitude.
It looks like Particle will not write to a local disk (it is IoT), so will likely dump data out to a Google spreadsheet (code examples already exist). Some of the Spark dashboard looks nice for output, but keeping it minimal for now.
The problem with data formats is you either have to say (almost) everything in one line, or you need a relational database. For sorting and extraction, I like each reading on a separate line (rather than bundled by sensor); but then there is the problem of associating readings to sensors and/or locations - where to put this relationship information. The other issue is where to put context which is needed when uploading/consolidating data; do you put this identifier (which one?) on each sensor reading, or add it when doing the uploading. I can go either way, but inclined to ignore space issues and make a full record from the start.
I don’t have a Pi Zero at the moment, but if they work with Particle then it might be a cheaper option to the Pi 3. Either way, I am starting to see the price point of the MVP to be at or below $200.
At the rate we are moving forward, my tomato may soon require a box and controlled environment.


If you add an appropriately sized capacitor, you can measure resistance with a digital pin using RC time constants. Adafruit has a good article explaining how to measure photocell resistance on a Pi along with a longer tutorial on photocells that gives more background.

Where did you look? Have you read this, this, and this on the Particle forums? I haven’t tried using the SDFat library they recommend, but I’ve been thinking about getting a microSD card breakout adapter and having a go at it. Even if it works and saves maybe $10-$20 in parts over just using a Pi Zero, I’m not sure if it would be worth it though. It’s hard to beat the convenience of ssh, scp, and rsync for moving data around.

Yes, I agree. That’s a big part of why I’ve switched my code from logging with a TSV file format to using records. Relational databases are popular, but people forget that they aren’t the only way to implement records (see my link above to The Art of UNIX Programming, my code to parse the log file, my code to draw charts from the parsed log data, and this gist with my sensor data from the past couple days).

I like the tomato picture.


I saw the idea of using a capacitor and timer to coerce an analog pin, but the accuracy and issues with processor lags scared me off. I will likely do a ‘bake off’ with the I2C sensor and this method and see how they compare, nothing to loose since I have the photocell and can probably scrounge a capacitor. Have you ever tried this, how well did it work?

I missed the SDFat and other postings, will definitely have to look into that as it would greatly simplify the architecture and keep all data local. Thanks for the reference! If do this, then we definitely need to get into discussions on file formats.

Just stumbled over another problem (minor) which is the flip side of the analog read - controlling fans. I have had my circulation fan hard wired to GND and 5v, but was thinking of an analog pin for the exhaust fan: 1) There is no analog out (though can fake it with a capacitor), 2) Raspberry only has 3v on the GIPO, which would cut the speed by 1/4 of normal (12v). I hate adding more stuff, but seriously thinking of a 12v PWM fan with power from a wall wart and hooking the PWM to a pin. I believe @Webb.Peter used this trick on his early growth boxes. Might just do both fans this way, for consistency; and it would allow experimenting with the circulation fan and its affects on plant strength. Any opinions or thoughts?


Yes–years ago on a Basic Stamp and it worked great. But, if you use a Photon instead of the Raspberry Pi beta, you can just make a voltage divider circuit, use a real analog pin, and be done with it.

I’d suggest you think low tech and just get a fan that’s rated for the voltage and flow rate you want. If you buy from an electronic parts supplier like DigiKey or Mouser, it’s easy to get detailed specs before you buy. If you want to experiment with flow rates on the cheap, buy more than one fan and swap them out. Alternately, since a lot of the relay boards have multiple relays, you could use more than one fan and adjust the flow rate by how many fans you have turned on at once. Or, you could wire up a low-flow fan to be always on and supplement it with a switchable higher flow rate fan.


@webbhm I’ve been thinking about what it would take to make a mostly offline data logger and controller that will periodically try to phone home to the mother ship (Particle API, local server, or whatever) and upload its sensor log.

The SD cards we talked about would be one option for storage, but I’m not so sure about the cost benefit in code complexity, hardware, and ridiculously over-provisioned storage capacity. Using the record format in the gist I linked to above, 24 hours worth of DS18B20 + Si7021 + BME280 data recorded at 20 minute intervals only took 6691 bytes.

By my calculation, at that rate, it would take about 400 years to generate 1GB of data. One year would take about 2.5MB, a month would take about 210KB, and a week would take about 50KB. My present record format is meant for easy human readability including units and full sensor names. I could easily shrink it down to 4543 bytes per day (1.7MB/year, 150KB/month) without affecting readability much, and a packed binary encoding could go a lot lower.

All that is to say, SD cards might be the wrong way to go. Perhaps we should look at things more like this 32KB I2C FRAM chip (fast like RAM, non-volatile like flash, and lasts a long time). 32KB would be big enough to go several days without network connectivity.

  1. @wsnook I personally (and I feel like others would too) find value in a post (even a thread) describing your chart generation techniques. As for the code question, I don’t have a ton of experience with either, though I do have some with Python. The only charts I’ve ever made from scratch were using Google Charts. I definitely think charting is a necessary function of our application. The lazy part of me wants to ask is it really necessary that we build our own charts from scratch? Most of what I’ve done over the past few years for my day job is reporting/dashboarding configuration (fan of Power BI). I would love to try and integrate into some pre-existing BI tool that we can piggy-back off of for free (similar to Particle). Perhaps I’m thinking more on the analysis end and you’re trying to get at real-time monitoring. This is just my opinion if you feel this is a bad direction to go in I’d love to hear why.

  2. Yes, depending on which sensors you are picking. I am extremely interested in trying to test different controllers with similar code, I think if we develop our work with that mentality it will allow us to pivot and experiment much easier down the line. I’d be most interested in knowing what is different between platforms. One of the reasons I was checking out Blynk early on was because it seemed to allow for such ease switching between controllers using its virtual pin interface.

  3. I’ll answer this more in other posts.

Are you trying to actually go into the image itself or the meta? I was under the impression there was a way we could determine the brightness of the image just by reading the metadata, I can’t remember but I think it was @wsnook who pointed me to that idea.

What are the hardware requirements? (Wire to the cell, breadboard, resistors, etc).

Did you end up saving to a local disk? If so what’s your preference on file formats?

@wsnook how would you manage images if you moved away from an SD card? Also, do you see yourself as having intermittent connectivity? I understand the desire for this in remote locations or specific applications, but most users I feel will want some sort of real-time monitoring. Would you plan to have both options depending on the connectivity?


This is the first of many future actuators that will cause problems for us. This is why I really like the idea of controlling EVERYTHING from the beginning off of a 120V AC relay. Similiar to the AC Control Block in the V1 PFC:

The BOM and assembly instructions are 1. here:

I bring this option for two primary reasons:

  1. Simplicity - I haven’t dug into the code on the V1 yet for the control block, but I’m going to assume it’s pretty straight forward. If we stick with a relay as opposed to some sort of PID or PWM. This simplifies not only our software, but our hardware as well. In terms of a driver for the 12V fan this is what I used previously. The moment we try and actuate things above 5V the “user” will have to purchase lots of little parts, something we may not mind, but it increases the difficulty in sourcing and assembly. Here is an idea of what was required when I did this previously.
  2. Easily customized - User won’t have to rewire anything to unplug one actuator and plug in another. We can default TL (Top Left) Exhaust fan and then just turn the relay on and off when necessary. This gives the user a system that’s just waiting for an “expansion pack” to add on a heater, or humidifier.


Wow, you are all rock stars. Such a great diversity of ideas and discussion. Sorry I am late to reply. Thank you for starting the party @Webb.Peter!

Here are my personal opinions (not those of the OpenAg lab) for the Product requirements of an MVP:

  • Brain:
    • Use only the Raspbrry Pi, no arduino. It is inexpensive and has a full Linux software stack.
  • Camera:
    • Only one camera is sufficient to monitor growth and do a timelapse. Placed at the top works the best.
  • Enclosure:
    • Whatever is cheap and easy. I think we should make some sized designs and leave the material up to the builder. Perhaps a list of pros/cons on various choices (foam, Al/plexi, wood, tubs, etc). I suggest the interior be reflective to maximize the light to the plants - the roll of reflective insulated material or even aluminum foil.
  • Lighting:
    • Off the shelf grow lights. LED’s are too expensive, specialized and difficult to get in the correct power output to grow.
  • Reservoir:
    • Suggest just specifying basic dimensions and letting the builder find the best local solution.
  • Oxygen:
    • $5 Aquarium pump.
  • EC:
    • Manual control.
  • PH:
    • Manual control.
  • Water top off:
    • As suggested: two sensors, peristaltic pump. Allows unattended operation for days.
  • Environment:
    • Temperature:
      • Just a PC fan to exhaust the heat from the basic grow light.
    • Humidity:
      • Not required in the bots we have been using, the evaporation from the water in the tub is enough (if the enclosure is reasonably sealed).
    • Co2:
      • Ignore.
  • Software - I like both options:
    • PFC V2 stack: complex, but already (mostly) done and can be hacked to be simpler for the MVP.
      • Pros: will read existing recipes and write the same format data.
      • Cons: complex SW stack.
    • Blynk: fun, easy (I used a pi, mag relay, usb camera to make a garage door monitor/closer)
    • Scratch:
      • I wrote the ML demo that @Webb.Peter mentioned. My schedule for making it real and integrating it into the PFC v2.+ is late this summer. For now, I suggest doing the non-user friendly option of hand editing JSON recipes (it is what we do daily).

MVP - Community Development

We are working too hard (with Particle). Logging to the SD is brain dead (after you figure it out). It turns out that all Linux functions are available, as well as all standard C++ stuff. Thus, forget SDFat (which is needed for Photon) and go straight to old fashioned C++ streams.

using namespace std;

ofstream myfile;
void setup() { ("/home/pi/example.txt");
myfile << “Writing this to a file.\n”;

I have data dumping out to a file as we speak.
Looks like this also might be an easy way to dump to a full database.

Also discovered my local, friendly electronics store. Got a 1uF capacitor and pumping light data. Still need to calibrate it for ON/OFF.

Now just need to copy the fan controller software into the file (and get the fan) and should be able to call this demo done.


I made a thread for you at Howto: draw charts from sensor log file with python & matplotlib.