# Full tank automation system



## crazymittens (Jun 4, 2012)

So, spent some time writing stuff down, finally got it diagrammed.

This will be Arduino-controlled (maybe Raspberry Pi?), because it's simple/available/proven/relatively cost-effective. The entirety of the design is based around 'ensuring control is maintained'. i.e. no disasters are being allowed for because I cheaped out on $50 of sensors.

*Disclaimer: * I have 3 boys aged 4 and under...so _when_ this actually happens is up in the air. If nothing else the layout of the systems should clarify to folk the 'how' of automating systems like this. If you find errors, please ping me and I'll update the diagram.

The whole point of this is twofold. First, how would one go about doing all these things. Second, what parts and code are required to actually pull it off. I want folk to view this as open-source/community-built. So please, if you have ideas/improvements let me know.

Features

Automation of water changes and top-offs (via constant slow trickle, instead of 25%/week)
PWM control of lighting (based on CO2 levels, sunrise/sunset, thunderstorms for bling)
Automated CO2 injection (dual pH sensors ensure correct CO2 levels maintained at all times)
Automatic system shutdown (since flow meters are present at all major points, disaster scenarios can be coded in)
Data gathering (for long term monitoring/analysis)
Alerts/notifications to email/SMS

I left heaters off because I ran out of time...but you get the idea. "Temperature Control System", comprised of temperature sensors and heaters on relays.

Why build instead of buy?

Easily add/remove redundancy
Sensors are cheap, controllers are not
One of my work 'goals' is to write my own not-work-related software project...so hay
There are a lot of folk interested in this kind of thing these days - the code will be posted on Github
3-12v system instead of 120v means a LOT of fun options (think small 12v pumps)
The proliferation of Chinese components means parts cost is stupid cheap
I am a tinkerer/builder by nature, so this project immensely interests me
Buying an equivalent system would easily run into multi-$k territory

I will update the diagram here as I have time. It was created using the absolutely fabulous: https://www.draw.io/


----------



## crazymittens (Jun 4, 2012)

Added the temperature control system bits.

Next have to map out the electrical (actual) & sensor wiring...

Annnd we have a github repo... https://github.com/christrotter/aquariumAutomation

If there are any interested parties, weigh in on: *Arduino vs. RaspberryPI vs. ?*


----------



## Nordic (Nov 11, 2003)

I'm also designing a semi-automatic system. It is for multiple tanks with air driven filtration so it doesn't need the recirculating bits.
I am going to make PVC draining overflows with joint top intakes. The pipes will all run to a control panel on the outside wall where they will each go through a 12V solenoid valve. There will also be an intake solenoid and maybe float valve in each tank.

I will program a PIC to open the intake valve, and then one or two drain valves sequentially a few seconds later, when air is purged.
Refill will be from a Raised 100gal tank or selectable direct from hose. This means no power drinking pumps required.
Tanks will be dosed with prime via perestaltic pump during refill. I will never have enough water in the tank to do all the tanks in one go, but being able to alternate which banks are being cleaned is much less work than carrying buckets with a bad back.










I like your style of design. My thought pattern works better with visualising the result and then working my way back to the product.


----------



## crazymittens (Jun 4, 2012)

Nice! Is that for a fish room scenario? Also, nice Sketchup! That program came in handy when I was designing the original display/sump system a few years back. I will probably do a 3D version of the near-finished full system to help visualize what this would look like all put together.

The peristaltic pump for prime dosing is a great idea - the whole dosing system piece (for ferts) was in the back of my mind, but never thought about adding this to the dosing process.


Did more reading, *Arduino is what we'll be going with*.

We are really only looking to take sensor input and make decisions (_key point being analog sensor input - something not native to R.Pi_)
We do not need on-board graphics, etc (_data visualization will be handled by either 3rd party or something Heroku-based_)
The current Arduino stuff has on-board ethernet (which is our key to sending data out)
The Arduino Mega has enough juice/pins to provide for almost the entire/fully redundant system set (_dosing system probably will send over the edge_)


----------



## Waterski (May 4, 2015)

I would recommend some kind of dosing system for ferts. It keeps the water chemistry stable over time. 

Is it possible to design a water topoff/changer system that is completely mechanical. Some way where you have a constant flow in/out adding to a 50% water change every week?? Maybe some kind out of outflow spout with inflow controlled by a needle valve.


----------



## Nordic (Nov 11, 2003)

Well, I already have a fishroom scenario,it is just a mess, I run more tanks than both LFS in town, so I might as well make it look pretty and run a little shop part too.
Arduinos are cool, I'm just too old to learn new languages, I still do everything in assembly language.


----------



## crazymittens (Jun 4, 2012)

Waterski, the auto-fill/drain system is SUPER ripe for disaster.  That's why I built in so much redundancy/checks/balances.

In an ideal world you'd have a simple mechanical system, yes. i.e. the system physically cannot hold more than X water level because you have an overflow on the sump that dumps straight into a floor drain. The input side is IS mechanically restricted - but actually seeing it work in real life will be a different thing. How will the RO system deal with the back pressure?

The reason why I didn't take this route is that very few people will have the ability to dump into a floor drain (myself included).

===================
A lot of how I designed my setup is based on what I figured to be 'best practices' for aquarium design. e.g. it's hard to argue there is a reason to NOT do the beananimal drain system from the perspective of 'which system is the most reliable/effective'. 

Similarly, it's hard to argue against a sump from the same perspective. ALL aquariums benefit from a sump, period.

Now, you can argue cost/difficulty/complexity/etc...but this is a DIY thread.  If you wanted a simple display tank w. canister filter, you wouldn't be here.
===================

That all being said, I will certainly draw up the mechanical drains design and have it as an alternative - it is a great suggestion! My only caveat to the mechanical system is that you would still want flow meters on the input and output pipes. The entire system will work at its best with the most input data to work with.

Further, noted on the fert system - that's 'already a thing' that I will pirate from others. Many are hesitant/simply don't post the source code though. It will add a whole other level of complexity that may or may not be worth it. For example, that $80 unit off ebay does a lot! Except notify you of low levels, tell you how much it's injected over X period, tell you if it's stuck on or off, etc etc.... 

I'd like this project to simplify the understanding of what systems there are in an aquarium, plus make it easy for folk to pick and choose what automation components they want, plus provide a library/compendium of X device plus Y sensors = do this.


----------



## ScubaSteve (Jun 30, 2012)

Wow...my head's spinning after looking at that! Well done crazymittens...I might have to look into this when I start up my 75 gallon show tank (it's still a long way off).


----------



## crazymittens (Jun 4, 2012)

ScubaSteve said:


> I might have to look into this when I start up my 75 gallon show tank (it's still a long way off).


I made the jump from a 50 gallon display to 125 gallon - definitely worth the extra effort to get the 6' long tank if you have the space!


Did some reading on the pH probe stuff, found some absolutely fascinating articles, and discovered that this is a solved problem - so yay! I believe the fastest way to get into pH automation is with the probe adapter offered by Atlas Scientific, and then just making sure to use a (quality?) calibration on the probe once a year. Apparently the design of a pH probe means that it WILL age and start providing bad readings, so that's even more impetus to use cheap probes. (something that data will bear out)

Here are the remaining big question marks for me before I order equipment:

Since pH probes aren't the simplest to add here - do the other sensors require the same treatment?
Will an Arduino Mega run the code required? (i.e. will all these sensors/outputs max the system capabilities)
Is the Arduino 'sketch' IDE up to the task - can we use Visual Studio or the like? (the most cursory google results, lol - super yes)
Is an Arduino 'project' capable of the organization we'll need?
Should we be breaking this up into many smaller systems? e.g. IoT - although I want to say no, because you still need a central point to control it...and I don't want to have that central point in the cloud or off on the network somewhere (or maybe that's ok?)...
re: smaller systems, what's the consensus on having many Arduino Unos talking to a central brain Arduino? I think that's unnecessary complexity...


----------



## 691175002 (Apr 28, 2009)

A system like this should be modular. I/O should be separate from logic.

I would personally group related I/O on individual boards (kind of like the Apex modules) and have them just send/receive sensor values over SPI/I2C.

The main controller could be a raspberry PI running python. Coding is enormously easier and you have the option of a full GUI or even internet if desired.

I don't really think you want to do the whole thing on a microcontroller. Nobody wants to dive into config files and recompile/flash for every tiny adjustment.


----------



## crazymittens (Jun 4, 2012)

Excellent feedback, thanks - that confirms how the UI piece will be handled. Looks like I have more research to do.  So would you do something like Arduino Uno for each module? (or is there something even smaller/still sufficient) Your thoughts...give them to us...this project is supposed to be community-built, after all.

===================
Brief searching indicates that pH is the most complicated sensor to deal with in our context (mostly because of noise). TDS seems somewhere in the middle (Interfacing a cheap TDS meter with microcontroller).

Temp sensor and flow meters seem pretty straightforward. Optical water level sensor also an unknown, but shouldn't be too complicated...it's just an on-off kinda thing.

Another avenue here is to just bite the bullet and go with Atlas Scientific for everything...but that amplifies the cost quite a bit. I think the proof of concept will use cheapie sensors. For me, pH/TDS is a round 2 kinda thing, so we really just care about flow meters and temperature to start.


With the above post from 691175002, I'll revise the diagram/plan and post the update later today.


----------



## mistergreen (Dec 9, 2006)

I'd use an arduino. A PI is useful for processing intensive usage like with video or a database.
It's not practical to use I2C or SPI for sensors. Not all sensors have those interfaces, some are one wire digital, some are analog, and so on.


----------



## crazymittens (Jun 4, 2012)

Right, so where my initial concern lies is how complex this project will actually be once you have all the systems in place. So, is a single Arduino config the right place to put lots of complex logic? Based on what I've seen, most Arduino code is a single page (I have not seen a lot).

Also, the project must have some sort of GUI for data visualization, and probably a basic setup app (i.e. define what modules you have present).

So how do we deal with those issues?


----------



## crazymittens (Jun 4, 2012)

Random thought for later - diagram out the data-in/control-out flow... I think the idea of a controller for each piece of data in/out makes sense, but it would have to be very simple to work properly i.e. IoT kind of thinking - but instead of sending to the cloud, you send to the brain - the more inputs the brain has, the smarter it gets.


----------



## 691175002 (Apr 28, 2009)

mistergreen said:


> I'd use an arduino. A PI is useful for processing intensive usage like with video or a database.
> It's not practical to use I2C or SPI for sensors. Not all sensors have those interfaces, some are one wire digital, some are analog, and so on.


I was thinking more of daughterboards with a small microcontroller for each sensor or group of sensors.

Upon further consideration I think it would be convenient to have a USB/Serial IO board that does all the sensor/output interfaces and presents a very basic text/json interface.

Make an arduino/teensy shield with 10-20 pins broken out and define a basic set of commands like:

```
Set Output0 100
Set Output1 50

Get Input0
> Input0 60
```
A more complex interface could identify inputs/outputs by use (Temperature, Lighting, pH, etc...) or implement more complex commands such as fades or scheduling.

This way any device with USB or serial can be used to implement logic. (including a computer/raspi or just a second arduino).

If someone needs more inputs/outputs they can plug any number of boards into the same controller (its just USB). A cheaper auxiliary IO board could also be produced.

This way a single piece of hardware can scale to systems of varying complexity. Using it could be as simple as typing a few lines into the terminal, or as complex as a 5kloc python script which logs to a web app.

Bump:


crazymittens said:


> I think the idea of a controller for each piece of data in/out makes sense, but it would have to be very simple to work properly i.e. IoT kind of thinking - but instead of sending to the cloud, you send to the brain - the more inputs the brain has, the smarter it gets.


I was thinking the same thing, but later realized that 90% of the users will probably want the same features: Temperature, pH, ~4 lighting channels, ~2 relays (CO2/Pump) so you might as well put them all on the same board.

As long as IO presents a simple and consistent interface you can use almost anything as the brain, and even use multiple IO boards for systems that are more complex.


----------



## crazymittens (Jun 4, 2012)

Ok, so really what needs to be defined here is our major use case - the proof of concept will be based on that, and the system will have provision for multiples of any 'module'.

So the POC will be a single Arduino w. network that talks to a R-Pi which does data visualization. Expansions will just be additional Arduinos sending more data to the brain, and the brain can then just enable more functionality as more inputs are added...?

I guess the other argument is: 'where does the value lie?' i.e. I really wanted to lean toward full redundancy as a feature, because generally you don't ever get that in a home setup...but maybe that has a use case of one...me...


----------



## mistergreen (Dec 9, 2006)

I think coding and interfacing for one brain is easier than multiple brains for practical reasons although the other idea sounds good.

This reminds me of my arduino project. I create generic virtual 'devices' and the user configure what they need from it.

http://www.plantedtank.net/forums/2...-controller-arduino-green-web-controller.html

Also Check out this arduino project
http://www.plantedtank.net/forums/2...ch-interface-aquarium-controller-arduino.html

It's set in what and how you should configure devices.


----------



## crazymittens (Jun 4, 2012)

Ok, so here's what I'm reading the actual implementation to look like:

Break systems down into something modular/expandable, each mini-system's pieces will connect to a single mini-system controller via networking
The mini-system controller(s) would then talk to the central brain for logic
The central brain would have three pieces: logic, configuration, data visualization
Mini-system example: TemperatureControl: temp sensor(data out), heater relay(control in)
Mini-system example: FlowControl: flow meter(data out), solenoid valve(control in)
Mini-system example: LightControl: PWM signal(control in), lighting relay(control in)

The initial proof of concept would then simply have a single mini-system that reacts to control input, and sends a constant pulse of data out.

Part 2 would be adding another mini-system (good use case would be water in, water out for ATO/AWC) and the brain logic.

Part 3 would be adding visualization.

Part 4 would add the user input of configuration.

Seem reasonable? Is there a better approach?


Next steps will be to diagram out the rough architecture and start looking hard at a mini-system itself.

Bump:


mistergreen said:


> http://www.plantedtank.net/forums/2...-controller-arduino-green-web-controller.html
> 
> Also Check out this arduino project
> http://www.plantedtank.net/forums/2...ch-interface-aquarium-controller-arduino.html


Wow, a lot of this stuff is already a solved problem - love it!

Need to spend some time going through these projects...but it definitely seems like I can leave the GUI stuff to the pros and focus instead on the mini-systems, sensor library, and logic side. (_all of which would, of course, be heavily pirated from stuff folk have already done_)

The good news is that I have zero intention of commercializing this, so it's not like I'm all disappointed that others are already doing this kinda thing. In fact, makes my task easier! 

Edit: Yup, definitely glad I had no plans to commercialize. And definitely certain that I no longer want to sacrifice the redundancy aspects just to broaden the audience.



*The goal of this project: *Provide an open-source codebase/schematics (_folk will have easily accessible arduino/sensor/etc code to use in their projects_), use common and cheap parts, have web-based data visualization (_make decisions based on data_), and be easily expanded. Ideally the logic side will be as bulletproof as possible, but will work best with the most sensors in the mix.


----------



## crazymittens (Jun 4, 2012)

Ok, so here's my first draft of a mini-system. The drain system really requires two of these mini-systems, and you could even take it a step farther and have a 'pump system' that removed the pumps from the equation. Then your input system would have two 'flow control' systems rather than something copied from the drain system. Yeah...that'll be the next step.











So the intention with this design is that the brain simply needs to say 'RUN PUMP' with a simple digital signal. As long as the sensor is powered up, data is being shoveled out to the brain. The logic simply requires that the brain is supplied with data. If the mini-system stops providing data, it gets a kill signal and is considered dead until the user fixes it (acks the issue).

In theory you can have a single Arduino do all this - but with the gotchas I found with pH sensors, it really would get complicated fast. I like the suggestion to offload the logic from I/O, makin' a lot of sense to me.

Added the diagram to the github repo!


----------



## mistergreen (Dec 9, 2006)

pH sensor with arduino & pi code examples
https://www.sparkfun.com/products/10972

Seeedstudio.com 
And adafruit.com are good sites too.

I don't know if you know but you can use external libraries in code where the logic of the sensors are. You just include to a main logic brain. So doing what you plan in software instead of hardware.

So you can have a flow library to do what you plan with only one main logic board.

Sent from my iPad using Tapatalk HD


----------



## crazymittens (Jun 4, 2012)

Aha, didn't realize you could do logic in a library. I was counting on libraries for the sensors and whatnot.

Thanks for the link, that came up the other day in searching. When I get a chance I'll post up the stuff I've found on sensors. The real trick is simply understanding how the sensor itself actually functions. Then you need the electronics know-how to isolate/clean up the signal, and then whatever happens next is code.


----------



## Ben Belton (Dec 12, 2008)

I could never do anything like this, but it is just awesome to read. I can't even do the PVC plumbing stuff. The nerd in me really jumped out. I subscribed to keep up with your progress and, I hope, success.


----------



## crazymittens (Jun 4, 2012)

Actually, you could! You just have to be willing to try.  

PVC plumbing is as simple as 'can you operate a dabber/brush thingy' and 'can you push two pieces of pipe together'. Oh wait, 'can you operate some sort of saw'. 'can you read a measuring tape'. And when you inevitably mess something up (_that never happens. ever._), can you operate a saw to cut it out, or can you adapt your design to deal with the change of direction. 

Dat's it! It's really as stupid simple as cutting things up, and gluing them together. Laying it all out in the right order has already been done by folk like Mr. Beananimal.

Do you have functional eyesight? (_at least one eye, two is preferable_)
Can you search the internet?
Do you have one hand or two? (_if one hand, you'll need a friend who also has at least one hand_)

Anyways, the hope once this automation stuff kicks off (I am ordering something tomorrow - new goal!) is that the community can use this as another point of reference to further their designs, just like Mr. Beananimal.

When I first started aquarium DIY, I didn't comprehend how simple/difficult it was to figure out sump baffles and overflows and all that - doing it really opened my eyes to the wonders of fluid dynamics! Cool stuff. "Fill a box with water" was never so much fun as the first time that overflow box filled up and started draining. Whee!


----------



## crazymittens (Jun 4, 2012)

Vacations and work making it tricky to find time for this...

Did more thinking. 
The correct solution for ensuring the sump doesn't overflow...is to give it an overflow. Pumps/water level sensors are a compromise - lets you not need to fabricate an overflow, but either way you go you need to be draining stuff out. You could argue that pumps would allow more options for routing drain piping, but a gravity-fed drain system is ideal, because there's nothing to go wrong.

So that eliminates one complicated system from the mix! Gravity drains it is.

Another argument would be 'just let the filtered input water run un-checked', but I can't find any filter systems that will run at a trickle - they are all 50GPH or higher. That'll make for a very expensive water bill. I'd need 0.1GPH at most. Anything more than that and we're into timing the system on/off.

Uh rough math time:

24 x 7 = 168 hours in a week
~150G total system capacity
25% water change/week target
35G/week
 35G / 168h = 0.2GPH

So unless we can find a RO system that can do a sustained 0.2-0.4GPH...

I will be ordering parts for v1 prototyping today!

Arduino w. ethernet (getting a Mega and two Unos, one W5100 and one W5500)
Raspberry PI 3 (we'll just run a VM for development - the only purpose of a physical R.PI is to replace a normal computer)
2x flow sensors (12vdc)
2x water solenoid valves (12vdc)
Bunch of 12/120v relays (one quad-relay PCB, two single-relay PCB)
RTC modules (just in case)
Breadboards & components

So for v1 we'll set this as a goal:

Arduino - Input flow system (2x) - sends metrics via ethernet, accepts control signals
R.PI server accepting input and sending control, logging metrics, some basic UI
Live POC using my old 20G tank.

Update: Parts ordered! Woo! ETA of 3-4 weeks, so I have time to start thinking about code. This is kind of a 'waterfall' project, since I have physical hardware that only really works one way, there isn't a lot to the fundamentals that I can change up. How the data/UI side functions though we can do a lot of iterating.


----------



## crazymittens (Jun 4, 2012)

Haha, so when the ebay sellers advertised 3-4 weeks, they actually meant 3-7 weeks.


> Estimated delivery : Wed. 21 Sep. - Thu. 27 Oct.


Oh well, gives me plenty of time to think and practice being patient.


----------



## mistergreen (Dec 9, 2006)

Buying from China will take forever. Try seedstudio next time. They're Chinese products but faster. A little more in price but not much.


Sent from my iPad using Tapatalk HD


----------



## crazymittens (Jun 4, 2012)

Nice, thanks.


----------



## crazymittens (Jun 4, 2012)

Parts have started arriving, but still a long list of to-do items (like...clean the gutters & fix the car) before I can get started.

Some fun side-note-news is that two more projects are accompanying this:

Build-in my current office (it's just divided by the tank right now) - essentially create a wall-size shelving unit thingy that will act as a wall, without having to get into full basement renovations
Buy/build a metal stand - the current stand won't work for re-doing things, and we rushed that part of the project last time - and dealt with results accordingly


----------



## crazymittens (Jun 4, 2012)

Spent some time this weekend getting Arduino stuff set up. Using some sample project stuff got the Uno/W5500 shield online, also played around with buttons/LEDs. Lots of fun, but had some frustrations using the breadboard power units I got. Discovered that I need to order some sort of bulk resistor pack or something...none of the starter kits came with anything aside from 1.0 / 4.7 variants. Need to do more research...

At any rate, made some of the first code commits to the repo. Woo! Also, this is going to need several repos - one for each client, one for the server, and one for the data visualization.


----------



## crazymittens (Jun 4, 2012)

Started on the server piece, now have a node.js webservice that accepts POSTs w. JSON data! Woo! More components ordered, too.

Some geek notes on other stuff: 

Going to use InfluxDB for the datastore - meant for timeseries data, fast, accepts Lucene queries
Not certain what the logic piece will be written in, probably whatever has good support for Lucene
These will ideally run in Docker containers, so anyone can pull down the lot, spool it up, and it'll just work.

Docker will also open the door for making it easy to run them in a hosted location, like AWS - or on a Raspberry PI!  Plus, you can then start to look at building it as a holistic and scaleable solution for taking in sensor data, querying it, acting on it, and visualizing the data. That's the wild theory right now, anyways.

A big driver of this for me is learning programming using tech that we use at work.


----------



## crazymittens (Jun 4, 2012)

Finally got a few hours to work on this.

Using docker-compose, we now have a database and a webservice - you can send 'sensor data' over to the webservice and it dumps it into the database
Because this is docker, anyone can pull the repository and fire it up (albeit Windows-based Docker)
Have a better idea where this is going now...

So the key next steps are:

Work on the beginnings of the logic component, e.g. another process that queries the database and based on results do something
Work on some visualization - already a thing because Grafana exists - this will be kept to scripted dashboards and raw Grafana stuff

Super exciting stuff!


----------



## 300DayZ (Sep 27, 2016)

This is an awesome project! I just read through your thread, and had thought about doing something similar awhile back. Hopefully next year when we buy a house I'll be able to incorporate something of this nature into the space that we buy. 

Arduino is a lot of fun. When I was in my undergrad, I did some work with Arduino programming for a small robot performing basic moving commands. I hope you find it to be what you are looking for, and take the time to learn it. It's really not that hard to learn if you have any experience in programming or even webdesign. 

Looking forward to the coming months of this project!


----------



## monkeyruler90 (Apr 13, 2008)

I'm excited to see the final product!


----------



## crazymittens (Jun 4, 2012)

Thanks, haha it'll sure be months, so don't hold your breath.

I learned a ProTip the other day...what I'm trying to build is a SCADA (supervisory control and data acquisition) system, so there might already be something we can tweak. In the 2 minutes of googling I did, looked like any of the open-source SCADA projects were really old/very dated-looking/no longer open-source/non-existent anymore.

So now that we have a data send/receive endpoint set up, and a database, what's left is that first part 'supervisory control'. 

Option1: Use a GUI to build logic.
Option2: Keep it very structured and simple, but inherently fully-featured - rely on what's present in the DB vs. configuration.

Option1 will cater to the widest audience (not just aquariums), but require a lot more time to build (GUI builder, logic stuff, etc).
Option2 will be very limited in scope (i.e. you'd need to use the sensor combos spec'd out in the code), but simple to build.

Hm, anyways, hopefully have some time this week or next to work on it.


----------



## crazymittens (Jun 4, 2012)

After much delay (life), back to working on this. Thanks to learnings at work, the repo is now fully functional and includes documentation on how to use it!

Of course, I then came across this: https://github.com/RapidScada/scada

Looks to be much more cared for than the other stuff I've come across, and also C#, which I'm somewhat familiar with. So maybe the best bet here is to find a way to get Arduinos talking to this...


----------



## crazymittens (Jun 4, 2012)

lol or not. Code comments are in Russian.

I think we'll just keep the scope limited and have fun.


----------



## sadchevy (Jun 15, 2013)

I like your idea. I will try to contribute to the best of my abilities. Taking, for instance, your flow control. Your flowmeter would only serve to send data to the brain, the brain would then process that data. The brain would then trigger the pump to turn on or off, or in the case of a dc pump, throttle its output. Once flow was back in allowed parameters, data from flowmeter, the brain would trigger the pump. I don't see the need for a solenoid, unless you are opening a valve. Then your brain would trigger the solenoid, which would then trigger the pump. 
In simpler terms, you need a data input, one output trigger, one triggered device. The triggered device can then trigger other devices.

Flowmeter-----> brain----->relay(solenoid/valve)----->pump

The relay in this case is a DPDT(double pole/double throw) meaning it has two seperate sets of contacts activated by one input.
Not sure if I'm thinking along the same lines as you, just trying to simplify the system.
On a sidenote, redundancy, would mean two of every sensor or input device, driving the cost up.

I hope you understand my thinking and what I'm trying to explain. I work with control systems on a daily basis, mostly mechanical. I've been learning programming because even in my line of work, computers are taking over. I'll try to sketch up a diagram later to put a visual to my thinking.


----------



## crazymittens (Jun 4, 2012)

Nice, thanks.

Yeah, at this point the real questions are:

How far do we want to take this? i.e. modular design, easy to add/remove rules?
Do we want this driven via UI? Mobile?
Redundancy is a good idea when dealing with non-trivial amounts of water, and ebay chinese-ium sensors are cheap.

Like, just doing a simple loop for a single sensor stack (e.g. multiple flow meters/valves) is not a big deal. A 2nd sensor stack also not that big a deal. Having multiple sensor stacks function in a systemic way is a different story. Nothing is impossible, but there's accomplishing something, and there's accomplishing something right (getting the foundation right so you can reliably build on it).

Another big mental block right now is that the electronics part of this is not code, and only works one way (because physics and such). e.g. 'flow meter sensor output is 0-12v, but arduino analog input is 0-5v - make it work' (answer might be: 'don't use 12v in a 5v system  )

The 'what' we are trying to put together here is SCADA (I think you're familiar with that, but maybe not the term?), so do we build a SCADA system, or do we just throw together some static code? I am in both camps right now.  Part of me wants to learn programming and so building a SCADA system would help me do that. Part of me wants to move on and finish this. 

Now that I have some hands-on experience actually working w. Arduino right through to database, probably a good time to revisit the initial design and flesh it out/refactor.


----------



## Beer (Feb 1, 2012)

You can run C on the Atmega chips, it is actually what they were designed for. That's basically all the Arduino environment is, a simplified C geared towards non-programming type users.

Next time look into mbed. STI's microcontroller. Lies somewhere between an Arduino and Rasberry Pi and quite a bit cheaper. It runs on an ARM processor.
The native language isn't too far off from Arduino, but they don't have a nice API and their documentation could use some help. It isn't quite as popular as Arduino, so there isn't as much support and you can't think of something you want to do and just go online to find the code that already does it (I'm a little biased against Arduino, I just finished school for electrical engineering and far too many people were using Arduino for senior design projects that should have been using imbedded hardware). It can also run C or other languages if you prefer.


I'll have to come back and read the full thread later, but it looks like you have a lot in order. Some ADCs may help with those 12V sensors. A voltage divider could work; it would be fairly simple but inefficient. I'm sure there is a better method than ADC, but I'm not sure what. There has to be some sort of inexpensive buffer/downconverter out there to handle this. Most microprocessore run at 5V or 3.3.

Since you are on Arduino as opposed to a Rasberry Pi, a mobile app or dumping data to a computer/server over USB/Wi-Fi may be easier. Although I'm sure there are plenty of shields out there that will handle a LED display with a few buttons just fine.


----------



## crazymittens (Jun 4, 2012)

Beer said:


> I'll have to come back and read the full thread later, but it looks like you have a lot in order.


Yes, please.  Cool suggestions though! For anyone wanting to make this a business venture, sounds like that'd be the right direciton.

The goal of this is not to build industrial-worth automation, but attainable automation - hence the arduino/rpi direction. If I wanted to go industrial, it would have been PLCs and such, haha! (I worked with a friend doing regional water treatment automation - very very different from an 'execution' point of view) 

Re: 12v/5v, I found lots of suggestions of using optocouplers (sp?) to do the conversion, as they are the safest way. I suspect the 'best' solution here is to simply not use 12v equipment in a 5v environment.  It's ok, this stuff is pretty cheap, and I'm cool with making mistakes so others don't have to. 

I think project success would be anyone downloading the repo(s), purchasing the stuff on the BOM, wiring it up, and it just working. Tall order, but if you set the bar low... 

Re: Data dumping, this is actually going to be Arduinos dumping to a rPi running Docker instances (and/or data shipping to the cloud/LAN). So the Arduino is really just an HTTP server/client that sends data out, and takes input commands to activate equipment. Visualization would be via a Docker instance on the rPi, or something in the cloud/LAN.


----------



## Beer (Feb 1, 2012)

Funny you mention PLCs, I'm going to start programing them in the next couple of weeks. PLCs would put this out of most people's price range. Extremly stable and robust, once the programming is set up properly, but not cheap by any means.

I've only used opto couplers a couple of times. While they are amazing for isolating noise and preventing transients from causing damage to the CPU, I have never heard of them being used to downconvert a signal. Granted, my experience with them is pretty limited and I was handed the components and told "here, make this with these". I'll have to look into optocpuplers that drop the voltage of an incoming signal, as that would be quite useful to have on hand.


----------



## crazymittens (Jun 4, 2012)

Very cool! Yeah, not cheap, but that technology seems to run a lot of industry/infrastructure.

It would appear that we are both going to learn from this project.  This is the thread that mentioned them: How can I use a 12 V input on a digital Arduino pin? - Electrical Engineering Stack Exchange


----------



## diverjoe (Oct 21, 2016)

I am in much the same boat. I have been kicking the tires on several systems and am one to not re-invent the wheel - like siphons ;-) I am currently running a Reef Angel and it is pretty smooth. I think we are on the same page as far as all that you want to do. I may have a little less redundancy. For me I have to have an interface so I can check/alter things while away. I am looking into things where you dont have to create the UI. I have been looking at both OpenHab and Cayenne as frameworks (IT for 30+yrs) both show ALOT of potential. The electrical engineering part has been a steep learning curve wrought with LOTS of frustration - lol but I have managed to get several of the more difficult beads on the necklace figured out. I love your design approach and the fact you have made a requirements doc to begin with. I would love more than anything to talk with you over the phone as so much of this if far to much to type. Besides, my brain works so much faster than my fingers at the keyboard. I can PM you my number if you are interested.


Right now my system is replacing ~5gal of water daily and I have an ATO that replaces any missing water with RODI mapped to a level sensor. I am in the midst of automating the dosing. I have the mechanical, just need the control system and I overcame a missing piece just last night. Also, the LED lights to a controlled ramp from 0 to 100% and back down across a parabolic curve over the course of the day. The T5 tubes come on in the middle of the day. PH, temp and I am working on EC. Mix of pumps and fans and solenoids - various voltages 5-12v and 110v. Played with various distance sensors and know some gotchas there.

Look forward to working with you guys if youll have me ;-)


----------



## crazymittens (Jun 4, 2012)

Haha sounds like you're ahead of the curve here! Maybe you should be spearheading this! 

Great, now I have _more_ stuff to research...OpenHab/Cayenne...

Uh, will try to address...

Using a pre-existing framework would be excellent - I looked at both, the Cayenne piece - not sure what you have in mind there... Using a home automation system makes sense, I'll have to investigate it.
I think I mentioned it once or twice, but the other side reason for doing this project is to familiarize me with stuff we're doing at work - so I'm (un?)fortunately tied to specific tech (mostly node/C#/docker).
The electrical bit is indeed quite a departure from IT (where I also work...not 30yrs...  ), but at least you know it's not (as) subject to the whimsy of the implementors (e.g. it's all Layer1)
It sounds like you have a lot more time on your hands, lol.
Sure, PM me your number, we can Skype or something. As I mention in post#1, I have 3 small children, so family life is priority number 1 for me. I refuse to promise anyone anything, but I'm sure we can figure out a call. If for nothing else than to swap ideas/stories. 

If anyone else wants in, we can set up a Google hangout or something.


----------



## crazymittens (Jun 4, 2012)

Some random thoughts...

I need to do a better job on the spec/design side of this. Right now it's just (really) vague diagrams and ideas. Coincidentally, I am looking into BDD/better specification/etc for work, so this might be an opportunity to try that stuff out. Further, I think the project should now be broken up into more pieces:

Arduino sensor packages (separate repo(s?) containing Sketches, documentation, BOMs, and schematics)
Listener component (Docker/node.js, listens (HTTP) on a specific address, forwards sensor data to the data component)
Data component (Docker/influxDB, available to all other components, has indexes/dbs)
Sender component (Docker/node.js, sends out HTTP to configured Arduino sensor packages)
Brain component (Docker/dotnetcore?, handles logic based on inputs (queries DB), makes decision based on configuration, talks to Arduino sensor packages via sender component, has an API to deal with configuration)
Data visualization component (Docker/grafana(?), provides dashboards based on configured Arduino sensor packages
Config visualization component(?) (Docker/?, provides a GUI layer on top of the Brain config API(s) that allows a user to select from available options, configure, build logic)

I feel like it's a pretty huge undertaking to deal with the visualization pieces, but maybe that's just inexperience talking. Also something brewing in the back of my mind is 'this seems like a good place to use queuing'.

Key aspects going forward:

Docker heavy - allows portability (Windows/Linux/RaspberryPi/AWS/etc), better project development (consistency, simplicity)
HTTP communications between sensors and listener/sender - simple to work with, albeit higher overhead than a dedicated TCP-type protocol
Separation of components - no code sprawl, keep pieces simple to enable rapid development
Clear specification of components - ensure that story specification is clear before code is written
Tests - all code should have tests associated, practice TDD

If this feels overly like an IT project...well...that's part of the point. My day job is working in a software development environment (_primarily operations/release, but realistically I prefer a holistic/end-to-end approach_), so I'm using the project to help me build awareness/compassion/understanding of the stuff I'm trying to get other people to do (i.e. development, qa, product, business).  I think the fancy term is 'dogfooding'.

Sorry if all of the above was rambly/random. My head is always kinda full of that sort of thing.


----------



## crazymittens (Jun 4, 2012)

Also thinking about something akin to the Megasquirt 'jim-stim', i.e. a test appliance to verify system functionality.

So if we take the concept of fundamental services:

Temperature service - everyone agrees that you need a temperature sensor and a temperature modifier (heater/chiller)
Lighting service - everyone needs a way to turn on/off lights, modifier is the schedule, config parameters include optional ramp-up/down
Auto-top-off service - everyone needs some way to ingress fresh water at a specific rate, and egress waste water at a specific rate

Each of those every aquarium needs (I mean, every automated aquarium  ), so we should use them as the base test system. Maybe the simplest/cheapest/fastest way would be to have a test framework that runs through some test cases:

Temperature system test: Get configuration param for targetTemp. Send 10 data points (i+1 kinda thing). When tempData hits the logic point for kicking on a heater/chiller, verify that the correct command was received.
Lighting system test: Get config param for lightSchedule. Using RTC(simulated), ensure that when 'lightsOn' signal received, 'lightsAreOn' sensorData is being sent. When 'lightsOff' signal received, ensure 'lightsAreOff' sensorData is being sent.

I think you get the idea. Mentally what I'm trying to do here is lay down patterns for building/testing all of this before we start, so code doesn't hit 50% and we go 'oh, that's not testable'.


----------



## crazymittens (Jun 4, 2012)

Got some precious time to think about this. Some starting points for architecture, specification, plus an example (simple) logic loop. Jeepers!


----------



## crazymittens (Jun 4, 2012)

Had a scintillating conversation with mister Diverjoe! Here's where we ended up...

the above diagram is out of date...
node-red will be a foundational piece
IoT is the way to go
Confirmation that open-source is the way to go on this project
A key goal will be to get the system to the point of 'pluggability'

Regarding that last point - we will have succeeded if we can provide a platform where the community can contribute 'sensor package' updates (e.g. Your pH module has a dropdown: pH probe X, pH probe Y - and you want to contribute 'pH probe Z' to the pH module. 

Further, the project boundary (to start) will be at the MQTT (receive data, send commands) demarcation point. Building the 'sensor packages' will be up to the end user. However! The project will provide a definition of what the 'sensorData' format must be. For example, the electrical functionality of your 'sensor package' is irrelevant as long as you meet the data format rules.

At least, that's where things are today.


----------



## Shadar (Jan 30, 2017)

crazymittens said:


> Had a scintillating conversation with mister Diverjoe! Here's where we ended up...
> 
> the above diagram is out of date...
> node-red will be a foundational piece
> ...


It's like you read my mind! Node-red + MQTT is the basis for the distributed sensor network I've been slowly putting together, and it's great. Looking forward to seeing where this goes.


----------



## crazymittens (Jun 4, 2012)

Shadar said:


> It's like you read my mind! Node-red + MQTT is the basis for the distributed sensor network I've been slowly putting together, and it's great. Looking forward to seeing where this goes.


Nice - good to have some confirmation that the design pattern is not out in left field.

Tell us more about your project!


----------



## sfshrimp (May 24, 2016)

crazymittens said:


> Ok, so really what needs to be defined here is our major use case - the proof of concept will be based on that, and the system will have provision for multiples of any 'module'.
> 
> So the POC will be a single Arduino w. network that talks to a R-Pi which does data visualization. Expansions will just be additional Arduinos sending more data to the brain, and the brain can then just enable more functionality as more inputs are added...?
> 
> I guess the other argument is: 'where does the value lie?' i.e. I really wanted to lean toward full redundancy as a feature, because generally you don't ever get that in a home setup...but maybe that has a use case of one...me...



A bit of advice - you better get an arudino mega, you are going to run of out system memory very quickly.

I built an automation system for my tank using arudino + data RTC shield + wing shield + LCD screen. It works quite well.

It automates EI dosing, feeds the fish, records the temperature. I could very easily have it connect to the cloud by adding another shield and using an api like adafruit's io, temboo or watson or some other...

You have a lot of relays built into your system. The water automation is a potential disaster waiting to happen if your float valve fails somehow - I'd be scared, but hey we have had no problems with toilets right?

Two videos that might be of interest:

(redundancy)
https://www.youtube.com/watch?v=l3kFuKMUoAI&list=PLsHFfJAbjgany7CsXGeYhMM4aKOew4At4

top off:
https://www.youtube.com/watch?v=VdIT8peLndI&list=PLK0o6R5iBrJdhrH0KR6MRl-zXrcZLN575&index=4


----------



## crazymittens (Jun 4, 2012)

sfshrimp said:


> Many helpful things


Just as a heads up, it's probably best to read through the whole thread. The project has taken a number of twists and turns. 

I think our next steps will be to completely abandon the electrical side until we resolve the basic problem of needing a framework to build on, and before then, a standard way to define sensor/actuator packages. Once we have our standards defined, anyone interested can pick a sensor package to work on and provide schematics/BOM/Arduino code.

So there will be a number of ways people can contribute:

Framework/server/logic/UI team
Sensor package contributors
UI / Mobile-friendlyness
Testing

Before we open the doors, just have to nail down some (really) basic standards. Further, this project won't be useful until the Framework/server/log/UI is in a alpha/beta state.

In the mean time, anyone is welcome to open 'idea' issues in the github repo.


----------



## sfshrimp (May 24, 2016)

crazymittens said:


> Just as a heads up, it's probably best to read through the whole thread. The project has taken a number of twists and turns.
> 
> I think our next steps will be to completely abandon the electrical side until we resolve the basic problem of needing a framework to build on, and before then, a standard way to define sensor/actuator packages. Once we have our standards defined, anyone interested can pick a sensor package to work on and provide schematics/BOM/Arduino code.
> 
> ...


I don't really want to read the whole thread. It's a basic system, and probably overly engineered to do basic functions for a relatively small sized fresh water tank. I would conjecture you could get the same results with a handful of timers and with a lot less distractions, but if you want to reinvent the wheel go for it.


----------



## Shadar (Jan 30, 2017)

crazymittens said:


> Nice - good to have some confirmation that the design pattern is not out in left field.
> 
> Tell us more about your project!


I'm at work, so this might be a little short on details, but I'll do what I can.

The sensor side of things uses Moteinos and Weather Shields from LowPowerLab: https://lowpowerlab.com/

If you look at the second video on the Jan 1 blog post, you'll see pretty much exactly how I built them (hardware-wise). They sleep most of the time, waking up every 5 minutes to send back temp, humidity, pressure, and battery level. I use 500 mAh liPo batteries, which should run them for at least a few months between charges.

For the gateway, which is what you really care about, I use a Rasberry Pi 3. It has a USB Moteino attached so it can receive the signals from the sensors over serial. The Pi runs node-red and Mosquitto for MQTT. I use node-red to convert the incoming data from sensors into JSON and send it to MQTT topics by sensor node ID. Then I forward the node-id topics to more useful topics like "Living Room Weather" (having the extra step in between makes it easy to switch nodes between different locations/logical mappings). Those topics get passed along to whatever I want to use to actually display the data. I've been experimenting with Adafruit.io (awesome, but limited amount of feeds and no option to pay for more yet), Thingspeak (great for data collection and analysis, terrible for making pretty dashboards), Ubidots (nice, but they changed their pricing model and it's not great), and node-red-ui (very nice, but not trivial to access remotely). I'm still planning to try out Blynk as well, and maybe InfluxDB with Grafana for long term data storage and display.

The weather sensors are mostly a proof of concept. Another thing I plan to add is soil moisture/temperature sensors for my garden and patio plants. I have capacitive soil sensors, I just need to weatherproof them and wire things up. And I have a Moteino Mega laying around that I might use for some aquarium control. I've got an Uno (actually a Sparkfun RedBoard) running my lights right now, and I'll be adding a temp sensor and power switch to prevent heater malfunctions. Using the Moteino would be nice for checking things remotely. If I do that, I'll integrate it into node-red as well.

From my limited experience, node-red is pretty much ideal for this sort of project. Setting up data flows and connections visually is so much better than writing code (and I'm a software developer, so I like writing code). It makes it really easy to change out pieces for experiments and upgrades.

Let me know if you want anything explained in more detail. I'm not going to share my code, because it was hacked together in an afternoon and it's quite frankly embarrassing. It also won't show you anything you can't also get from the Moteino code samples.


----------



## klibs (May 1, 2014)

just make sure you have dev and test tanks working properly in all scenarios before you promote the code to your display tank


----------



## Shadar (Jan 30, 2017)

klibs said:


> just make sure you have dev and test tanks working properly in all scenarios before you promote the code to your display tank


Do you know of any libraries for mocking plants and fish in unit tests?


----------



## crazymittens (Jun 4, 2012)

Shadar said:


> Super cool stuff


Verrrrry cool!!! I have mentally noted you as 'the guy' to harass with questions.  Pretty sweet gig for a day job! Is that primarily home automation then? Moteinos sound like something to look at for the 'sensor packages'.

sfshrimp - Sorry to hear that. Look up optical water level sensors, pretty neat! If you do create something that covers our scope, please post it up! Many people interested in a full automation setup that is open-source (fresh/reef/homebrewers...  )

klibs -  Hilarious! But you're not far off the mark... Putting together a valid test framework is part of this...it is software, it must be tested, there is no question about this. Esp. since we're dealing with flooding as a 'test failure' 

I'll take the time to remind folk why I started this:

Wanted to automate water changes
Wanted to automate temperature control
Wanted to automate all the things
Wanted to see the data
Wanted to learn tech/processes for work, plus something new
Wanted to make this useful for other people

This project won't be for everyone, but it'll certainly be a fun ride.


----------



## Shadar (Jan 30, 2017)

crazymittens said:


> Verrrrry cool!!! I have mentally noted you as 'the guy' to harass with questions.  Pretty sweet gig for a day job! Is that primarily home automation then? Moteinos sound like something to look at for the 'sensor packages'.



Heh, this is a hobby project, not my day job. My day job involves much more complex software, but no interesting hardware.

As for the Moteinos, I love them, but they may be overkill for most of this project. Moteinos have two major advantages: first, they are ultra-low power, and second, their radios have crazy range and penetration. Unless you want to automate an off-the-grid aquarium a hundred meters from your house, you don't need those advantages. Given that they cost more than a typical arduino or an ESP8266, I wouldn't use them for individual sensor components of the system. I'm mostly thinking of using the Moteino Mega for mine just because I have it, and it would run all the sensors and controls for the aquarium.

Of course, if you do want all the sensor packages to be standalone, with consistent and guaranteed wireless communication to a base-station that may be in another room, Moteinos will definitely give you that.


----------



## crazymittens (Jun 4, 2012)

Shadar said:


> Do you know of any libraries for mocking plants and fish in unit tests?


lol


----------



## klibs (May 1, 2014)

Shadar said:


> Do you know of any libraries for mocking plants and fish in unit tests?


there HAS to be something in npm...

i would construct two extra basements for dev/test environments for full test automation of disaster recovery flooding scenarios prior to production use


----------



## crazymittens (Jun 4, 2012)

klibs said:


> there HAS to be something in npm...
> 
> i would construct two extra basements for dev/test environments for full test automation of disaster recovery flooding scenarios prior to production use


If I was going to make a business of this, totes.  Don't forget the all-important 'catastrophic electrical failure during a massive flood' test.


----------



## Shadar (Jan 30, 2017)

crazymittens said:


> If I was going to make a business of this, totes.  Don't forget the all-important 'catastrophic electrical failure during a massive flood' test.


I would also want a shake table to verify that everything behaves as expected during an earthquake.


----------



## crazymittens (Jun 4, 2012)

It _would_ be a good excuse to get a full reef tank... Sharknado?

But how can we _know_ that it'll work!?


----------



## sfshrimp (May 24, 2016)

crazymittens said:


> Verrrrry cool!!! I have mentally noted you as 'the guy' to harass with questions.  Pretty sweet gig for a day job! Is that primarily home automation then? Moteinos sound like something to look at for the 'sensor packages'.
> 
> sfshrimp - Sorry to hear that. Look up optical water level sensors, pretty neat! If you do create something that covers our scope, please post it up! Many people interested in a full automation setup that is open-source (fresh/reef/homebrewers...  )
> 
> ...


You should add a camera so you can do a time lapse. Visual data of what is happening inside the tank is just as important as the graphs. It would be interesting to measure color density + distributions of the photos if you were able to control the photos, and map that to an infographic over time. I am planning on maybe adding that to my setup at some point. I have seen the optical water thing too you speak of. You'd probably want to add power backup too if not listed already.

These are the dosing pumps I have been using - cheap chinese [censored][censored][censored][censored] but seems to work:
https://www.amazon.com/gp/product/B01HRPKBAE/ref=oh_aui_detailpage_o02_s00?ie=UTF8&psc=1

I'm using one wire for the temperature sensor, and cellphone vibration motors to control the distribution of fish food.

There's a similar project here to what you are trying to create:

Supported Hardware - Open Source Automation Wiki

:wink2:


----------



## crazymittens (Jun 4, 2012)

sfshrimp said:


> Cool ideas


Stuff like 'camera time lapse' would be a 'sensor package' kinda thing (?). A module you add to your configuration or visualization setup. Good point to think outside of just sensor data...hmmm...! Still just a data object though, just would live somewhere different. I think the real problem to solve there would be consistency of photos. Would make for a really neat sensor package though!! Gonna put that one down as 'idea'! 

Cellphone buzzer, nice!!!! 

Took a quick look at the other project, similar concept indeed! Someone else to learn from.


----------



## sfshrimp (May 24, 2016)

crazymittens said:


> Stuff like 'camera time lapse' would be a 'sensor package' kinda thing (?). A module you add to your configuration or visualization setup. Good point to think outside of just sensor data...hmmm...! Still just a data object though, just would live somewhere different. I think the real problem to solve there would be consistency of photos. Would make for a really neat sensor package though!! Gonna put that one down as 'idea'!
> 
> Cellphone buzzer, nice!!!!
> 
> Took a quick look at the other project, similar concept indeed! Someone else to learn from.


You could probably even use a XBOX kinnect camera for 3d imaging...

What about hooking up an IR camera to the arduino? You'd end up with a heatmap of the tank.


----------



## crazymittens (Jun 4, 2012)

Submitted two 'module ideas' on the github repo for IR/camera ideas.


----------



## Shadar (Jan 30, 2017)

Here's another thing to look at: Reef Angel Aquarium Controller

It's an arduino based tank monitor/control system that uses a central unit with a bunch of expansions. I think for communication they mostly use I2C over USB cables. I would have used phone cables myself, but the basic idea is sound.

Just one more thing to get ideas from.


----------



## crazymittens (Jun 4, 2012)

Yup, diverjoe has one of those. He's looking to this system to replace that entirely. His comment on it was that it was too limited/restrictive.

Thanks!


----------



## diverjoe (Oct 21, 2016)

Waterski said:


> I would recommend some kind of dosing system for ferts. It keeps the water chemistry stable over time.
> 
> 
> 
> Is it possible to design a water topoff/changer system that is completely mechanical. Some way where you have a constant flow in/out adding to a 50% water change every week?? Maybe some kind out of outflow spout with inflow controlled by a needle valve.




Hey me and crazymittens are working on a system. Love to have some help and thoughts it will be open source so no one owns it and is free to all. We figure many hands make the job easy. Using raspberry pi and node red. Any skills you bring will be welcome


Sent from my iPhone using Tapatalk


----------

