Mycodo VS ghidra

For controlling everything, the plan is to use a Raspberry Pi running Mycodo, which will connect to the the temperature/humidity sensors, and also control the LED lights, the misting sprayers, and the heating coil.

As others have pointed out, there are quite a few alternatives already on the market, including open source ones. If you are attempting to turn this into a marketable product, you might be disappointed.

I'd also take a look at mycodo (here is the repo) which I personally found much more powerful than BrewPi and has an okay API I think if you want to set up your own frontend

Update: Found out about: MyCodo - https://github.com/kizniche/Mycodo (opensource Environmental Regulation System for rasbery pi) https://www.youtube.com/watch?v=nyqykZK2Ev4

Mycodo is great for the software side, but I don't think they have libraries for any wireless sensors.

There's tons of land unused in the US. But I also agree with you. I haven't played with this one yet, but it looks very nice

https://github.com/kizniche/Mycodo

Inkbird has a good reputation at a relatively low cost. Personally, I like to build my own systems using the Mycodo system running on Raspberry Pi W's.

Here's my quick intro to hydroponics.

If you want bridge your grow with automation and coding I recommend everyone take a look at

https://github.com/kizniche/Mycodo

If you're looking for instrumentation/controllers for your grow (CO2, PH, TDS, EC) I recommend:

https://atlas-scientific.com/

If you're indoor and need lighting, build your own LED based lighting. Use the Samsung LM301B or LM301H led. I shopped https://atreumlighting.com/ for my last DIY kit and my light fixture came out perfect.

If you're buying nutrients or supplements, always try to get them in powered formula. Liquid based formulas are typically more expensive because you're paying to ship the water around and water is heavy. Most nutrient lines provide a feed schedule and dosing. When doing nutrients, less is more, never give them too much fertilizer, you will damage your grow and burn your plants.

Yes, I'm growing cannabis, you can see some of the fun we've had over the years at:

https://www.instagram.com/fantasygrowtent/?hl=en

Check out this environmental monitoring and control software I’m using on a raspberry pi with my grows, it’s amazing: Mycodo

[1] https://github.com/boricj/ghidra/tree/feature/elfrelocatebleobjectexporter

I've been working on a specific reverse-engineering technique called _unlinking_ [1] on-and-off for the past 16 months or so. I'm on my third prototype (first a set of Ghidra scripts written in Jython [2], then a fork of Ghidra [3] and now a Ghidra extension [4]) and I've started a blog in order to document it [5], which side-tracked into writing a whole series of articles on reverse-engineering to introduce the topic.

What for, you may ask? Basically I'm trying to decompile a PlayStation 1 video game and I've quickly decided that dealing alone with multiple +500 KiB executables of complete utter spaghetti code wasn't going to work. Instead, I've decided that I'd rather divide-and-conquer the problem, so I've been tooling up to split executables into relocatable object files, in order to decompile those one at a time and _Ship of Theseus_-style my way to success.

Ironically, all of that stuff is so not done that I don't even know what meaningful feedback there could be. My prototypes do work, but only for 32 bit little endian statically-linked MIPS executables. The articles on my blog are draft-quality. As for the decompilation project itself that started all of this, it hasn't seen much progress due to all of those side-quests. The overall topic is so esoteric that so far I've only managed to hear about one group of two persons that tried to do anything remotely similar and one another anecdotal account [6] that this particular skill is very uncommon among reverse engineers.

Personally, I'm starting to think that maybe I could've actually reverse-engineered and decompiled the game in the time I took to get here. I've also tried to engage with Ghidra to upstream the foundations of my modifications in my fork, but after some back-and-forth it became clear that my prototype-grade stuff wasn't industrial-grade and couldn't be merged in its current state, which is why I'm currently reworking the code in my fork as a Ghidra extension.

To those that want to provide feedback after reading all of this: beware, I've had a lot of fun going down that rabbit hole, but this is one hell of a time sink _and_ a particularly tricky mind-bender.

[1] I don't actually _know_ what's the actual name for this technique, given that there are so few resources on it out there. I do know I didn't invent it.

[2] https://github.com/boricj/ghidra-unlinker-scripts

[3] https://github.com/boricj/ghidra/tree/feature/elfrelocateble...

[4] https://github.com/boricj/ghidra-unlinker-extension

[5] https://news.ycombinator.com/item?id=36575081#36590078

[6] https://news.ycombinator.com/item?id=35729232&p=3#35740761

- The relocation synthesizer for MIPS: https://github.com/boricj/ghidra/blob/feature/elfrelocateble...

  - The Ghidra analyzer that leverages this synthesizer: https://github.com/boricj/ghidra/blob/feature/elfrelocatebleobjectexporter/Ghidra/Features/Delinker/src/main/java/ghidra/app/analyzers/RelocationTableSynthesizerAnalyzer.java