Cultivating The Fungus Amongus

A while ago, [Kyle] built an automated mushroom cultivator. This build featured a sealed room to keep contaminants out and enough air filtering and environmental controls to produce a larger yield of legal, edible mushrooms than would otherwise normally be possible.

Now, he’s at it again. He’s expanded the hardware of his build with a proper, grounded electrical box for his rig, added more relays, implemented PID for his temperature and humidity controller, and greatly expanded the web interface for his fungiculture setup.

Like the previous versions of his setup, this grow chamber is controlled by a Raspberry Pi with a camera and WiFi module. Instead of the old plastic enclosure, [Kyle] is stepping things up with a proper electrical enclosure, more relays, more humidity and temperature sensors, and a vastly improved software stack. Inside the enclosure are eight relays for heaters and humidifiers. The DHT22 sensors around the enclosure are read by the Pi, and with a proper PID control scheme, controlling both the temperature and humidity is simply a matter of setting a number and letting the machine do all the work.

The fungi of [Kyle]’s labor include some beautiful pink and white oyster mushrooms, although with a setup like this there’s not much fungiculture he can’t do.

16 thoughts on “Cultivating The Fungus Amongus

  1. Happy to see “Temporary file system (RAM) to reduce writes to SD card”. I was going to post a comment explaining why they should add such a feature. But no point since they already know about the 3000-5000 writes per block before almost all SD card fail into read-only mode.

    1. Not at all fussed about this.

      Firstly the range is closer to 5k-10k for typical NAND flash used in SD cards. Secondly the cards have wear levelling. There’s been a few tests of various older generation cards that showed even back in the 256MB days cards could typically write many terabytes before suffering from failure.

      If you somehow manage to kill an SD card by writing to it too much in this application then you’ve done something very wrong.

      1. Interesting. I’ll admit I’m not that familiar with all the techniques employed to prolong SD life, but with a log write every minute, 5k writes would occur in just under 4 days (excluding log, graph generation, etc.).

        I saw it as an easy way to eliminate all those writes and get a small speed improvement. The only downsides I can see are if my server load is really high and I start using swap (which I haven’t seen yet, even with over 30 users on the system last night) and the loss of a few hours of log files if power to the system spontaneously cut before a merger to the SD card logs can occur, but I’m sure there are other disadvantages.

      2. I’ve killed loads of them, by accident, mostly when I forget about the limitations. I write a quick and dirty script that gets bad input data and ends up writing millions of tiny (byte-couple of bytes) updates 24/7 – RIP SD.

        1. It’s interesting that you can kill loads of them by accident when the people who write code specifically to kill them on purpose for stress testing end up with systems that take months of continuous writing to kill an SD card. I’m going to assume when you say loads you actually mean a few, and when you say SD cards you actually mean the cheapest thing you could get your hands on (something which a few stress tests have also shown makes a big difference).

      3. Ideally, wear leveling should be handled transparently by an MCU built-in to the SD card. However, it’s my understanding there is NO REQUIREMENT in the official SD spec for this feature. Nor any reliable way to test if this feature is included, short of testing the card to destruction. Therefore, manufacturers could leave wear leveling out to cut costs if they choose, and still correctly claim it’s fully SD spec compliant. Which may occur with cheap off-brand SD cards. Or a name-brand card, if it turns out to be counterfeit, and we all know how common those are nowadays.

        So assuming no wear leveling occurs, and taking matters into your own hands, seems like a wise move. Using a temp filesystem that’s periodically flushed will also help cover your arse in case a bug causes writes to the logfiles far more often than intended.

  2. about flash cards / usb flash…

    not all things are defect free.
    usually defective flash wont fail when used VERY sparsely.
    i think defective flash heats up 10000% when defective but still works fine,
    until that is, you go to make reads-and-writes for more then say one minute.

    then it fails and confuses the wear-leveling and you need to reformat the stick.
    im not sure if what im talking about is counterfiet-related or not.

    sometimes the wear-leveling does not get fully reset by unplugging it and then formatting it and the whole thing siezes up.

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.