sending current into battery
This is my first blog and my first time documenting a personal project - I don't typically consider my work to be useful, interesting, unique, worthwhile to share in the world when everyone has the whole rest of the collected works of humanity available via the internet, radio, and libraries. But this is a personal blog don't expect more. I'm also not a technical expert so rather than attempt to author technical explanations myself, I will try to include decent links and suggest doing your own researching.
The project idea I will be documenting on this new blog is a cliche electronics hobbyist project, microcontroller assisted plant cultivation. Its a simple project that could be a stepping stone into further types of home automation, smart home, IOT, or these types of projects. I'm going to try doing my own.
The very first instance of this I encountered was at a hobbyist scale, found on the website where I got a diy power supply kit over 10 years ago. Through-hole soldering and low number of components make it beginner friendly PCB assembly, and you get a useful, versatile piece of electronics toolkit. not a garbage bound blinky trinket.
sending current into battery
Back on topic, Hydroponics will be new to me, but has many active online communities providing feedback on questions and photos. There's a lot of techniques, I selected one, and for brevity I'll leave out all the details of the criteria I used to choose the specific technique out of the many options. There's not a universal answer here, it depends on available space, crop preference, growing media, access to tools & building skills, money. There's no shortage of easy-to-find information, but here's a <5 minute summary of the method I will be attempting. TLDR mix nutrients and water in a reservoir, put plants in containers with perlite and drainage, periodically pump nutrient water through plants, which drains back into reservoir.
Why? Basically, there is infrastructure to deliver water and electricity to many houses at extremely small marginal cost. If you buy concentrated nutrients, and use your own sunlight, electricity (for electric pumps), and water. What if buying and moving a few gallons of hydroponic nutrients once a year uses less fuel than buying fresh produce each week grown 1000 miles away before it hits your local grocery store where you can pick it up by foot/bike/bus hopefully, or realistically for many with the car.
Goals are to implement electronic timers, pumps and PH and Total Dissolved Solids (TDS) monitoring to the existing and documented process, in a low cost hobbyist friendly way. I've found suspiciously cheap components online, and when they arrive I will evaluate them for accuracy, reliability, repeatability, etc. The specifc outcomes of this project should be some freedom from strict schedule, and get early warning to correct problems without having to constantly monitor manually.
I'm not going to use python, C, assembly, or any language typically used to program personal computers or servers. I will use Ladder Logic as described in IEC 61131-3, used commonly in industrial applications. It often implements fairly simple logic that is counted on to reliably control even critical applications where large numbers of lives, equipment and/or facilities are at risk. Lots of applications from building HVAC systems to manufacturing facilities and power plants, and have heard rumors about use in early spacecraft. Chemicals, temperatures, pressures, stored energy, all of which can be incredibly dangerous at industrial scale, are controlled by this software.
The usual hardware platform for ladder logic programs is called PLCs (programmable logic controllers). These are specialty hardware built with high quality components and rigorously tested and backed by warranties, service, support contracts, and numerous certifications. At the core there is a standardized and interoperable language standard. In reality a plant may have multiple manufacturers installed over decades, all kinds of usual tech nonsense with proprietary bells and whistles and management UIs and addons and additional protocol support, and on and on. And, they're expensive. Prohibitively expensive for hobbyist projects. Even a used, entry level models.
From an infosec perspective, PLCs can be some of the most critical targets. Theres a well known virus which targeted PLCs in a nuclear facility. I recently heard about an infosec PhD project called OpenPLC with the intention to emulate PLC performance sufficiently to perform research on these systems without requiring researchers to buy expensive industrial equipment designed to be installed in an electrical panel not a computer desk. The result is an open source implementation of a software environment. Its doubtful hobbyist home automation DIY stuff was the main idea when this project was started, but it has quite a potential. In fact, I think the industrial automation ecosystem could be considered for a lot of 'home automation' projects.
Theres no shortage of opinions about programming languages on the internet, so I'll try to keep it short.
There is alot of inherent limitations when monitoring or controlling a physical building plant or machine. Many of the features, abstractions, speed, and large scale expandability offered in modern programming languages, especially for web apps, aren't relevant. Venture capital funded efforts lead to subsidized attempts to capture a network, with unnecessarily proprietary, subscription based, data mining products.
Ladder logic is ugly, tedious, constrained, and probably one of the least intriguing programming languages you'll find. In fact, it's more like programming your VCR to record a show at 7pm on wednesday than entering a state of programming induced enlightenment pursued by those who customize text editors (I like emacs).
There is an extensive amount of training material and real life working deployments to learn from. It tends to make you to consider some important factors, like how each bit of state should be maintained during resets or power loss. There's basic but common functionality, such as timers, combinational logic, state machines, about as much math as an 8 bit calculator. Its not fun to write, it won't look good, but it won't be unreadable. Very standard and simple, like plumbing and electrical. You can do it yourself with parts from any hardware store, and specialists can understand and work on systems designed and built by each other. The limitations are its strength, not in what it enables but what it prevents (or at least makes difficult)
The IEC standard defines multiple forms of how the programming language can be represented. The primary one I think of is ladder diagram, which resembles electrical schematics for circuits used to implement small simple combinational logic, using relays (the electro-mechanical version of a transistor). It looks basically familiar if you've seen schematics for household appliances, like a dishwasher, furnace, or washing machine, at least slightly older ones, that are built with knobs, switches, sensors, timers etc. There are other representations of code, something with C like syntax called Structured Text, a bytecode/assembly, and some higher level diagrams suitable for more complex machine.
This is the ideal IDE. You may not like it but this is what peak automation software development looks like
The OpenPLC docs are real nice, installation was very straight forward on my laptop OS for development, and on a raspberry pi 1 w/8GB SD card at least 5 or 6 years old.
The only note I have to add, based on the default Raspian install didn't leave enough space for the OpenPLC install, internet search found dpkg-query -Wf '${Installed-Size}\t${Package}\n' | sort -n to find a few things I'll never use to uninstall.
I wanted to start with pretty bad hardware, which of course is a big departure from real industrial products which use high reliability components. First of all, in my experience, even consumer grade electronics are pretty durable and reliable, they get thrown out because they're unfashionable or obsolete, not because they fail. So, I'm going to collect a datapoint on how long it takes for something to actually fail. Also, this realization forces me to do something else which should be a goal for any IoT device: plan for failures and implement non-electrical failsafes.
Next up