reef-pi :: An opensource reef tank controller based on Raspberry Pi.

[MrWheelock]

Hey guys how are the ReefPi's doing? Kicking around the idea for my 75gal.

Are the following features available?

1. Salinity probe

2. Ability to use 2 dosing pumps for ato (control specific on time duration (time x dose volume computed for x run time) to achieve desired water change volume.

3. The ability to have a level sensor on a fresh water tank close a solenoid on the RODI output when the fresh water container is full, reversely the opposite open when its empty.
[Can do the same for fresh top up on ato container coupled with a pmup pump to fill the ato from fresh tank]

4. A scheduled task on an auto feeder.

5. Is there a toggle for maintenance IE return off, skimmer off with delay on, heaters off?

These features are important to me along with the following normal tasks
On/off of t5 light, wave pumps, return pump, skimmer, fuge light, heaters at specific temps

I'm sure im missing some but these are major for me.

Thanks guys

 

[Des Westcott]

Does anyone know if there is an external WiFi antenna solution that works well on a Pi3 or 4? I'm having occasional signal issues and I must either add a WiFi extender somewhere in the house, or use improve the reception of the Pi.

Thanks

 

[Ranjib]

Might I suggest putting a series of links in the first post in this thread (edit that post)? the links could still die, but if they have a detailed description, we'd at least know what you're talking about. Even better if you could put that in the markdown file in the repo. only just discovered this thread; I was thinking about developing my own controller on the pi (I'm a C# dev by profession), and stumbled onto this, yay! When I get this on a pi, I may tinker on a fork and see if there's anything I can do to contribute.
I'd love to see this list broken up in a few bits. maybe the 'base' can be the pi itself + basic probes (temp, salinity, ORP, pH) sensors/solenoids for ATO. 'Plus' can add a series of on/off 110v outlets and some 0-10VDC digipots. 'Premium' can add other probes (ORP, maybe even some of the pinpoint (NO2, Ca, etc probes), electronic valves, pressure sensors, flow monitors, etc. Just as a nice way to break up the list (and ya, I'm expecting not all of these are supported).

You willing to sell these? I'm hoping to pick up a pi 4 kit to start this and would like a nice box

- The adafruit guides have individual links. We can consolidate those to reassemble the 2.x parts list again. I am currently focused on 3.0 release, and would prefer to do such work as part of 3.0 release (and hopefully this time we'll have more stable links, with static part details). I like the idea of source controlling the BOM. The website itself is under github.com/reef-pi/website, and a BOM is present there as well (not with as much details as I would love to). So we can start with improving from there.
- Would love to get any and all type of contribution, code, design improvements, docs, translations, build threads.. anything that help the project in any way.. we appreciate all of it :-)
- Can you expand on the broken down bits aspect. Currently the design aims for extensibility and modularity. wich is you can build a single unit powered by pi zero and only with one module or a combination of many modules. In the code its pretty well segragated (reef-pi/controller/modules), there are horizontal libraries (drivers, telemetry, storage etc) that are seperate repos or standalone packages. The nano/pico/premium distinction is in the electronics/enclosure land ... not so much on the software side from design. It does bring in new performance challenges, but thats a different aspect. Most cases we know the safe limits, or we get to see when we are crossing it
- Bunch of the sensors you mention are already supported, some other will work without much changes (e.g. ezo based ec and orp probes) but not cleanly (modeled as ph), in 3.0 we have done some foundation work on driver side (Hardware Abstraction Layer) that will make the ground up support for new probes very easy. tplink smart plugs (kasa) are based on this. I hope to write many more as part of 4.0. Humidity is one of the main one.
- Selling ? Not really in that way. I dont think I can legally do that, neither I find it makes sense financially. And I am definitely pretty lazy when it comes to shipping etc.. But if you are in bay area, and willing to pick up manually, then Im up for giving it away for a beer :-) . I'll have to get rid of them some way, as I want to iterate and print newer models, I am learning a lot on that front recently.

Thanks for giving reef-pi a shot,

 

[Ranjib]

- The adafruit guides have individual links. We can consolidate those to reassemble the 2.x parts list again. I am currently focused on 3.0 release, and would prefer to do such work as part of 3.0 release (and hopefully this time we'll have more stable links, with static part details). I like the idea of source controlling the BOM. The website itself is under github.com/reef-pi/website, and a BOM is present there as well (not with as much details as I would love to). So we can start with improving from there.
- Would love to get any and all type of contribution, code, design improvements, docs, translations, build threads.. anything that help the project in any way.. we appreciate all of it :)
- Can you expand on the broken down bits aspect. Currently the design aims for extensibility and modularity. wich is you can build a single unit powered by pi zero and only with one module or a combination of many modules. In the code its pretty well segragated (reef-pi/controller/modules), there are horizontal libraries (drivers, telemetry, storage etc) that are seperate repos or standalone packages. The nano/pico/premium distinction is in the electronics/enclosure land ... not so much on the software side from design. It does bring in new performance challenges, but thats a different aspect. Most cases we know the safe limits, or we get to see when we are crossing it
- Bunch of the sensors you mention are already supported, some other will work without much changes (e.g. ezo based ec and orp probes) but not cleanly (modeled as ph), in 3.0 we have done some foundation work on driver side (Hardware Abstraction Layer) that will make the ground up support for new probes very easy. tplink smart plugs (kasa) are based on this. I hope to write many more as part of 4.0. Humidity is one of the main one.
- Selling ? Not really in that way. I dont think I can legally do that, neither I find it makes sense financially. And I am definitely pretty lazy when it comes to shipping etc.. But if you are in bay area, and willing to pick up manually, then Im up for giving it away for a beer :) . I'll have to get rid of them some way, as I want to iterate and print newer models, I am learning a lot on that front recently.

Thanks for giving reef-pi a shot,

BTW, all the enclosure designs are also opensource and available on Thingiverse. You can use those and a 3d printing service like shapeways to get them printed and delivered. I would not recommend them right now as the models are really very simple and primitive (you have drill and use standoffs, lot of those stuff can be offloaded to the design itself), unless the cost / benefit is ok for you.

 

[Ranjib]

Hey guys how are the ReefPi's doing? Kicking around the idea for my 75gal.

Are the following features available?

1. Salinity probe

2. Ability to use 2 dosing pumps for ato (control specific on time duration (time x dose volume computed for x run time) to achieve desired water change volume.

3. The ability to have a level sensor on a fresh water tank close a solenoid on the RODI output when the fresh water container is full, reversely the opposite open when its empty.
[Can do the same for fresh top up on ato container coupled with a pmup pump to fill the ato from fresh tank]

4. A scheduled task on an auto feeder.

5. Is there a toggle for maintenance IE return off, skimmer off with delay on, heaters off?

These features are important to me along with the following normal tasks
On/off of t5 light, wave pumps, return pump, skimmer, fuge light, heaters at specific temps

I'm sure im missing some but these are major for me.

Thanks guys

- Salinty probe: Nope. Way back in the day (pre 1.0) , I wanted to get this done. But after building ATO and learning more about its impact vs opex/capex , I deprioritized this. After 3.0 if there's enough interest, we can get this done , since HAL works made it very easy to add support for new driver. All we have to do is there's folks who are willing to test it on the field and use it in the longer run. This is important, as I won't be running this probe.
- Currently theres no clean way to do two equipment controlled by a single sensor. You can do a hardware hack with a single GPIO output controlling two relay/outlets. Or a software hack where you define two atos in reef-pi both with the same probe but different equipment. This will change in 3.0, where we'll be able to attach multiple equipment to a single sensor.
- I have not read the details, but I think 4,5,6 are all possible with timers (period equipment control) or macros (serial execution of equipment or some key tasks [such as waiting]). In 3.0 this will become more powerful, as we'll be able to combine them (macros on timers)

Start a build thread and call out the expectations, I think they are feasible, but let others who have built or used reef-pi share their views. Those are more relevant as thats from a user perspective. Your skill and patience level will be great multiplier :0-)
thank you for considering reef-pi

 

[Ranjib]

Does anyone know if there is an external WiFi antenna solution that works well on a Pi3 or 4? I'm having occasional signal issues and I must either add a WiFi extender somewhere in the house, or use improve the reception of the Pi.

Thanks

Ideally, Pi 3, zero w should never have wifi issue if they are not underpowered and properly configured. If this is a router issue then wifi antenna will not help, if this is a distance /reach related issue then may be a extender /access point will be better. If you provide your setup (pi's and home network) and issues you are facing, we'll be able to help better.

 

[AbjectMaelstroM]

The sensor look very similar to the one that I use, except it does not have the breakout board. The breakout board

But its very simple to do this on PCB/breadboard, and I think you dont even need all the components, here is the schematic of that board

If I was you I would remove all the caps/resistors and go simplest possible circuit and see if it works. In this case pin 1 & 2 goes to GND, pin 3 goes to 3.3v (or 5V??) and finally pin 4 goes to GPIO (whatever you are choosing)

So this is the chematic provided by eBay listing.

Colors on my sensor don't match, red green white black. But I tried to hook it up directly to the hat and no go. I'm wondering if it's expecting the little breakout board.

I'm going to grab one of those and maybe a capacitance water level sensor see how it works out.

 

[BenB]

Is this sensor supported??

Non-contact_Liquid_Level_Sensor_XKC-Y25-T12V_SKU__SEN0204-DFRobot

wiki:This is a non-contact water level sensor for Arduino. It utilizes advanced signal processing technology with high-speed operation capacity to achieve non-contact liquid level detection.

wiki.dfrobot.com

 

[Des Westcott]

Ideally, Pi 3, zero w should never have wifi issue if they are not underpowered and properly configured. If this is a router issue then wifi antenna will not help, if this is a distance /reach related issue then may be a extender /access point will be better. If you provide your setup (pi's and home network) and issues you are facing, we'll be able to help better.

This is what I get that seems to be signal related to me

 

[MrWheelock]

- Salinty probe: Nope. Way back in the day (pre 1.0) , I wanted to get this done. But after building ATO and learning more about its impact vs opex/capex , I deprioritized this. After 3.0 if there's enough interest, we can get this done , since HAL works made it very easy to add support for new driver. All we have to do is there's folks who are willing to test it on the field and use it in the longer run. This is important, as I won't be running this probe.
- Currently theres no clean way to do two equipment controlled by a single sensor. You can do a hardware hack with a single GPIO output controlling two relay/outlets. Or a software hack where you define two atos in reef-pi both with the same probe but different equipment. This will change in 3.0, where we'll be able to attach multiple equipment to a single sensor.
- I have not read the details, but I think 4,5,6 are all possible with timers (period equipment control) or macros (serial execution of equipment or some key tasks [such as waiting]). In 3.0 this will become more powerful, as we'll be able to combine them (macros on timers)

Start a build thread and call out the expectations, I think they are feasible, but let others who have built or used reef-pi share their views. Those are more relevant as thats from a user perspective. Your skill and patience level will be great multiplier :0-)
thank you for considering reef-pi

So no if optical x then solenoid y?

 

[Des Westcott]

If you are familiar with linux, then you can track down what are the exact things that are bogging down cpu/memory and nuke them selectively. I do this as my paid job :-/ which is why I am little bit aware of this process. For my personal use though, I'll always do the reverse and instead of reducing a full-blown desktop into a kiosk, I'll prefer to extend a barebone text based installation to support just my one chromium tab. Typically this means
- installing a lightweight window manager (lightdm etc)
- install chromium
- configure the systems to autostart chromium in incognito + kiosk (full screen) mode
- configure systemd boot target to launch just those bits, post network initialization
This is an awesome setup if you dont have any network connectivity, its completely offline yet functional controller. Much less security and reliability headaches . I ran several builds like this till i moved to google wifi + grafana/prometheus setup. Because may other things at home gets impacted when the wifi is bad, so i had to improve the control plane. And after doing that, the kiosk mode use case is going down. I think it will be reduced to only the layout/diorama use cases , thing where im hacking reef-pi to use with model rairoad /toys/terrariums etc. Mostly my son's assets :)

OK. A couple of those things you suggested there may as well be in a foreign language to me.

BUT

I did manage to follow this tutorial https://pimylifeup.com/raspberry-pi-kiosk/ and get Reef-Pi running in Kiosk mode. I am very happy. It is exactly what I wanted. A dedicated Reef-Pi interface from which I can control the whole tank. If anything, it seems a little more laggy to me, but it isn't anything I can't live with. I have configured the dashboard to display 12 metrics as a test. This Reef-Pi isn't running on a tank at present, I just have 3 x temp sensors and one level sensor running on the desk. So a few duplicate metrics, but you get the idea.

 

[Bigtrout]

Does anyone know if there is an external WiFi antenna solution that works well on a Pi3 or 4? I'm having occasional signal issues and I must either add a WiFi extender somewhere in the house, or use improve the reception of the Pi.

Thanks

Is the pi in a metal enclosure? A metal enclosure would act like a faraday cage and cut wifi signal to and from the pi considerably.
As far as wifi on a pi zero, i am using one and my pi never has signal issues, so either you are too far from your router, have a source of interference, or your home/enclosure construction is cutting the signal.

Use a wifi signal app on a mobile and check the signal where your pi is located, maybe an extender or additional access point could help.

 

[burningbaal]

- The adafruit guides have individual links. We can consolidate those to reassemble the 2.x parts list again. I am currently focused on 3.0 release, and would prefer to do such work as part of 3.0 release (and hopefully this time we'll have more stable links, with static part details). I like the idea of source controlling the BOM. The website itself is under github.com/reef-pi/website, and a BOM is present there as well (not with as much details as I would love to). So we can start with improving from there.
- Would love to get any and all type of contribution, code, design improvements, docs, translations, build threads.. anything that help the project in any way.. we appreciate all of it :)
- Can you expand on the broken down bits aspect. Currently the design aims for extensibility and modularity. wich is you can build a single unit powered by pi zero and only with one module or a combination of many modules. In the code its pretty well segragated (reef-pi/controller/modules), there are horizontal libraries (drivers, telemetry, storage etc) that are seperate repos or standalone packages. The nano/pico/premium distinction is in the electronics/enclosure land ... not so much on the software side from design. It does bring in new performance challenges, but thats a different aspect. Most cases we know the safe limits, or we get to see when we are crossing it
- Bunch of the sensors you mention are already supported, some other will work without much changes (e.g. ezo based ec and orp probes) but not cleanly (modeled as ph), in 3.0 we have done some foundation work on driver side (Hardware Abstraction Layer) that will make the ground up support for new probes very easy. tplink smart plugs (kasa) are based on this. I hope to write many more as part of 4.0. Humidity is one of the main one.
- Selling ? Not really in that way. I dont think I can legally do that, neither I find it makes sense financially. And I am definitely pretty lazy when it comes to shipping etc.. But if you are in bay area, and willing to pick up manually, then I'm up for giving it away for a beer :) . I'll have to get rid of them some way, as I want to iterate and print newer models, I am learning a lot on that front recently.

Thanks for giving reef-pi a shot,

I found the adafruit guides, that's definitely helpful. One note is the bom on github.io page is a dead link, though I see the md file in the repo that is supposed to be that page.
Question (being new to pi-life and to go): Is the idea that you put several pi zeros together in some sort of network of modules or that you have a larger pi as a master and several modules under it? I was thinking I might pick up a big pi 4 and add the modules as I see fit, but seeing the lighting guide that includes a pi zero, I'm not sure if that's just the simplest way to make a reef-pi that's just lighting, or if it's representative of a pi-network approach.

I'll have to do some digging in the repo to get my head around the codebase, but I'm hoping to find two things in particular:
1. A place for new-hardware-code so I (or others) could drop in a new class (presumably implementing an interface) to easily add a new type of hardware, either to our own local build, or via a pull request.
2. A place for inidividuals to add our own scripting with access to whatever hardware is installed, via some sort of subscription/callback model so a given script can be triggered based on a sensor. I'm sure lots of users can learn some basic go or js, so they could do the same custom scripting neptune is known for, but with a sane framework:) Some examples: (a) 'pH of tank is below 7.8, turn off calcium reactor', (b) 'temperature of display is over 84F, turn off all lighting'. Similarly, scheduled things could happen 'at 2pm everyday, turn off ATO, open solenoid A to let water out of manifold to the drain until sensor B is dry, then turn on pump X (from new saltwater) until ATO sensor is wet, turn on ATO', boom...Auto water change.

 

[Ranjib]

I found the adafruit guides, that's definitely helpful. One note is the bom on github.io page is a dead link, though I see the md file in the repo that is supposed to be that page.
Question (being new to pi-life and to go): Is the idea that you put several pi zeros together in some sort of network of modules or that you have a larger pi as a master and several modules under it? I was thinking I might pick up a big pi 4 and add the modules as I see fit, but seeing the lighting guide that includes a pi zero, I'm not sure if that's just the simplest way to make a reef-pi that's just lighting, or if it's representative of a pi-network approach.

I'll have to do some digging in the repo to get my head around the codebase, but I'm hoping to find two things in particular:
1. A place for new-hardware-code so I (or others) could drop in a new class (presumably implementing an interface) to easily add a new type of hardware, either to our own local build, or via a pull request.
2. A place for inidividuals to add our own scripting with access to whatever hardware is installed, via some sort of subscription/callback model so a given script can be triggered based on a sensor. I'm sure lots of users can learn some basic go or js, so they could do the same custom scripting neptune is known for, but with a sane framework:) Some examples: (a) 'pH of tank is below 7.8, turn off calcium reactor', (b) 'temperature of display is over 84F, turn off all lighting'. Similarly, scheduled things could happen 'at 2pm everyday, turn off ATO, open solenoid A to let water out of manifold to the drain until sensor B is dry, then turn on pump X (from new saltwater) until ATO sensor is wet, turn on ATO', boom...Auto water change.

I am assuming you have found this already, not super updated, but this is the 2.x list: https://github.com/reef-pi/website/blob/master/content/guides/bom.md

regarding how many pis and their workload distribution, My recommendation would be dont complicate the aspects that you are learning, and take on risk on aspects where your strengths are, and where it operationally makes sense. If you know nothing about electronics but comfortable with terminal etc, go with pi zero and get one module done (up and running) before investing anything. If you are not familiar with electronics as well as computers, go with pi 3 as it has enough CPU to run a full GUI, USB ports etc. If you are familiar with both electronics and computers, pi zero AIO setup, unless you have really elaborate setups (multiple probes, powerstrips etc).


All hardware drivers are located here: https://github.com/reef-pi/drivers , they all conform to a common Hardware Abstraction Layer (https://github.com/reef-pi/hal), core reef-pi is not aware of drivers and only operates on HAL layer. This make its relatively easy to write drivers (write enough code to confirm hal) and integrate it with core reef-pi

Macros (auto water change like features) are implemented via the UI. reef-pi does not provide any domain-specific language for extensibility. I believe most of the features that such DSL provides can be done straight over the UI. DSL adds programming/logic burden for the novices. In terms of extensibility, reef-pi is entirely API driven , and its trivial to consume the API and use cron and other scripts to do the custom things you want. Given we build the controller ourselves, we have access to whole linux/raspbian userland, hence this kinda approaches work for us. The ability to execute arbitrary script from the controller itself (hooks or callbacks as you mentioned) are deliberately excluded to due performance and UX concerns. People may learn JS/Go, but I dont think its a good assumption for our typical users. I want the core features to be as accessible, frugal and robust as possible, while it still offers insane amount of hacking capabilities for all DIY folks. I think later on (4 or 5) I would love to add an dynamic language interpreter (js or ruby), that will have a better, turing complete DSL, backed by the API, but compiled and executed by the same go runtime. There are projects that already does this (mruby, js compilers in go etc), but I want to wait till they become more mature, pi gets more stable and we sort out the LTS (long term support) APIs for reef-pi that we are confident enough for a 4-8 years lifespan.

 

[Ranjib]

So no if optical x then solenoid y?

yes, you should be able to do this. Optical sensor, floatswitches etc are all modeled as Inlet in reef-pi and you can use them to control any outlet (solenoid in your case).

 

[Des Westcott]

Is the pi in a metal enclosure? A metal enclosure would act like a faraday cage and cut wifi signal to and from the pi considerably.
As far as wifi on a pi zero, i am using one and my pi never has signal issues, so either you are too far from your router, have a source of interference, or your home/enclosure construction is cutting the signal.

Use a wifi signal app on a mobile and check the signal where your pi is located, maybe an extender or additional access point could help.

It actually is in a metal enclosure, but the one side is open. And the open side is facing the direction of the router(s)

 

[pais]

Hi everybody, a suggest if you want to implement any other sensor (digital or analogic) is to use an arduino connected via i2c ro the rpi. I'm succesfully using this technique to achieve a reading of both analog ph-meter and an ec-meter. I perform also value-based actions on these sensors. I have seen ranjib talking about the new feature homeostatis, THANK YOU for the great work, now im waiting for that being implemented to reduce the arduino tasks.

 

[Ryan115]

It actually is in a metal enclosure, but the one side is open. And the open side is facing the direction of the router(s)

If you have a direct connection (or if you are getting enough of a signal to remote in to the pi), run this code in terminal to get a report on your signal strength.

sudo iwlist wlan0 scan | egrep "Cell|ESSID|Signal|Rates"

 

[Ernie E]

Totally following should you decide to post any examples of your setup and/or scripts used on the arduino to do the translation!! Which pH probe are you using?

Hi everybody, a suggest if you want to implement any other sensor (digital or analogic) is to use an arduino connected via i2c ro the rpi. I'm succesfully using this technique to achieve a reading of both analog ph-meter and an ec-meter. I perform also value-based actions on these sensors. I have seen ranjib talking about the new feature homeostatis, THANK YOU for the great work, now im waiting for that being implemented to reduce the arduino tasks.

 

[Ranjib]

Hi everybody, a suggest if you want to implement any other sensor (digital or analogic) is to use an arduino connected via i2c ro the rpi. I'm succesfully using this technique to achieve a reading of both analog ph-meter and an ec-meter. I perform also value-based actions on these sensors. I have seen ranjib talking about the new feature homeostatis, THANK YOU for the great work, now im waiting for that being implemented to reduce the arduino tasks.

in this route, where you are primarily using the arduino for analog input, how you do galvanic isolation? reef-pi currently has a HAL Analog driver interface that we can use to implement an arduino driver. We can totally do it if it makes sense (i.e. the results we get are good enough for our use case, and theres enough appetite for such use case)