Reef pi, thoughts?

[richiev]

Back in the day, during my original foray into reefing 10yrs ago, I thought the idea of custom hardware controllers was silly. In a world of Arduino, Android, and ubiquitous networking, proprietary devices seemed archaic. I'd started playing with a diy controller, but then I end l exited the hobby and stopped.

Now, getting back into it, I found reef pi and robo tank, and while not exactly what I wanted, it seemed close, so I was intrigued enough to buy one. Particularly because reef pi now supports kasa smart outlets via local network control.

Having played with both, I'm pretty underwhelmed. As with most open source, the UI and documentation are pretty bad. It's rather exacerbated by the lack on uniformity in hardware, and the community mostly being a 800 page forum post. However, that's standard.

More disappointingly, they're not things you code scripts for. The customizability is through a UI "macro" screen, which isn't very flexible. I was expecting to write scripts, responding to signals.

Now I'm wondering if I consider this an interesting experiment, and just abandon the idea.

I'm curious if anyone else has used either of these, and if they've had success / enjoyment with it. Anyone have one, enjoy it, and/or find it useful?

 

[grizfyrfyter]

I've wanted to try the Reef Pi since it was first shared but I had an Apex already.

Now that I'm starting a tank again, I'd love to try it but I'm not paying $75 for a raspberry pi.

 

[Flagg37]

@Ranjib Dey is on here from time to time. He’s the one who “made” it. I haven’t seen him on in a while though.

 

[richiev]

I've wanted to try the Reef Pi since it was first shared but I had an Apex already.

Now that I'm starting a tank again, I'd love to try it but I'm not paying $75 for a raspberry pi.

Technically for the pi you just need a Zero model, which is more on the order of $10. However then you need to add headers, an sd card, a USB power supply + cord, ... Then to use any of the peripherals you need to buy the peripherals + likely build a little circuit to connect it to, + ...

That all being said, the biggest thing is likely the time commitment all that putting together takes. I think unless you enjoy that putting together part, or are extremely strapped for cash, it's likely a far better ROI to buy something like the Robo tank. That likely running closer to $180 + probes.

And after all that, you're using a slapped together assortment of stuff with no warranty nor paid QA team standing behind it. The advanced versions involving building a DIY 120V, controlled, power strip give me major heebie jeebies. The kasa strip idea helps mitigate that, though I wish it supported an Ethernet cord versus required wifi.

Definitely not cheap, both in terms of time, $USD, and likely risk.

@Ranjib Dey is on here from time to time. He’s the one who “made” it. I haven’t seen him on in a while though.

Cool, would love to connect!

Again, I'm all for the theory, I'm just looking for people that have gotten a good experience and high usefulness from these things. I do have mine right now working as a DIY ATO on my QT tank, and it's kinda neat to say I put it together, but cost a lot more than buying a $70 ATO kit.

 

[Prestondeeply]

I agree completely. Trade time for money seems like the trade off. But, actually, one is also trading warranty and a level of expected functional quality. As we all have read and some have experienced, a controller can make a mistake with any number of things (heater, ATO, lighting, DOS) and make for a catastrophe. Personally, I have a different direction. I'm experimenting with video as a feedback system. Add a couple of $10 USB cameras to reef-pi. What can be done with that?

• ATO using Dosing mumps (camera can remove the water level sensors). Now we can compare a camera image of the water level _and_ the amount of water we expect to add (Dosers measure quantity).
• Time lapsed video observation and comparison. Comparing what a tank looks like hour by hour can alert on the fastest moving breakages (like a heater stuck on or a doser overdose).
• Lighting verification. ie, is it ON/OFF, as well as light intensity and some limited color mix checks.
• Perhaps even some pest outbreaks or things that affect one coral group?
• baby sitting new corals, watching for color change and polyp extension over time to see if the placement is an improvement over a previous location?
• Maybe catch that pesky fish that keeps nibbling at that coral?
• Maybe catch that night-time coral war-fare (if a moon-light is in place?).

Well, I'm just having fun with it. USB cameras and reef-pi can give us some really different options that I haven't been able to find. I suppose I could just as easily have assembled the Pi+cameras setup and then imported all of the data from an existing well trusted tank controller....and that would be just fine as well.

So, if you want to build something that just isn't out there yet, reef-pi does provide that platform for experimentation. That is what is driving my personal build.

 

[JVU]

I agree completely. Trade time for money seems like the trade off. But, actually, one is also trading warranty and a level of expected functional quality. As we all have read and some have experienced, a controller can make a mistake with any number of things (heater, ATO, lighting, DOS) and make for a catastrophe. Personally, I have a different direction. I'm experimenting with video as a feedback system. Add a couple of $10 USB cameras to reef-pi. What can be done with that?

• ATO using Dosing mumps (camera can remove the water level sensors). Now we can compare a camera image of the water level _and_ the amount of water we expect to add (Dosers measure quantity).
• Time lapsed video observation and comparison. Comparing what a tank looks like hour by hour can alert on the fastest moving breakages (like a heater stuck on or a doser overdose).
• Lighting verification. ie, is it ON/OFF, as well as light intensity and some limited color mix checks.
• Perhaps even some pest outbreaks or things that affect one coral group?
• baby sitting new corals, watching for color change and polyp extension over time to see if the placement is an improvement over a previous location?
• Maybe catch that pesky fish that keeps nibbling at that coral?
• Maybe catch that night-time coral war-fare (if a moon-light is in place?).

Well, I'm just having fun with it. USB cameras and reef-pi can give us some really different options that I haven't been able to find. I suppose I could just as easily have assembled the Pi+cameras setup and then imported all of the data from an existing well trusted tank controller....and that would be just fine as well.

So, if you want to build something that just isn't out there yet, reef-pi does provide that platform for experimentation. That is what is driving my personal build.

Interesting ideas. Seems like you are attempting to simulate and automate what we all do instinctually- look at our tank to see how it’s going and catch problems early. Then take it to the next level maybe.

 

[richiev]

I agree completely. Trade time for money seems like the trade off. But, actually, one is also trading warranty and a level of expected functional quality. As we all have read and some have experienced, a controller can make a mistake with any number of things (heater, ATO, lighting, DOS) and make for a catastrophe. Personally, I have a different direction. I'm experimenting with video as a feedback system. Add a couple of $10 USB cameras to reef-pi. What can be done with that?

• ATO using Dosing mumps (camera can remove the water level sensors). Now we can compare a camera image of the water level _and_ the amount of water we expect to add (Dosers measure quantity).
• Time lapsed video observation and comparison. Comparing what a tank looks like hour by hour can alert on the fastest moving breakages (like a heater stuck on or a doser overdose).
• Lighting verification. ie, is it ON/OFF, as well as light intensity and some limited color mix checks.
• Perhaps even some pest outbreaks or things that affect one coral group?
• baby sitting new corals, watching for color change and polyp extension over time to see if the placement is an improvement over a previous location?
• Maybe catch that pesky fish that keeps nibbling at that coral?
• Maybe catch that night-time coral war-fare (if a moon-light is in place?).

Well, I'm just having fun with it. USB cameras and reef-pi can give us some really different options that I haven't been able to find. I suppose I could just as easily have assembled the Pi+cameras setup and then imported all of the data from an existing well trusted tank controller....and that would be just fine as well.

So, if you want to build something that just isn't out there yet, reef-pi does provide that platform for experimentation. That is what is driving my personal build.

That's the type of extendability I was thinking of regarding it being open source. As I noted in the other thread though I'd keep your expectations muted. All of that is great, but the big gotcha is it assumes a very stable underlying platform, with high extendability. That currently doesn't really exist IMO.

The nice part is it's open source, so in theory you can improve it and share it with everyone. Just know it might not be as reliable as you're hoping, and the system isn't necessarily as plug in able to do something like that.

It is however a lot further along than trying to do it all from scratch!

Processing wise, I'm not sure about the raspberry pi 4, and I know there's extension boards out there, but I'm not sure if the pi is going to be powerful enough to do all the AI models. I'm not sure it has a GPU, and definitely doesn't have a tensor chip, though maybe those are add-onable. You certainly can run it in cpu, with lower frame rate captures.

The only concern I'd have on it as CPU is the pi isn't a realtime processing device. Given we're not controlling space ships that's fine, but at higher CPU utilizations is when reef pi appears to have even more reliability issues, from what I've read. It's probably not ideal to use the same cpu for controlling "turn dosing pump on, wait 10 seconds, turn off" as one that's burning through image processing algorithms. You might be better off running that off board on a secondary device/pi.

 

[Prestondeeply]

Great insight, thanks. I've been using rpi zero W for a number of video projects, typically time-lapse. I've connected 8 cameras to a single Pi zero, via USB, and then takenmulti-angled time lapse. In that case, it is sampling all of the cameras for a single image each, every 30 seconds. Works great, but as you said, there isn't much processing going on....basic image entropy calculations to maximize data for later image processing. In this case, for reefing, I'm thinking one sample every 5-10 minutes across 3 cameras (2 for main DT monitoring and 1 for the sump). I can manage the available CPU by shifting out sample time.

I'll take that 'noisy neighbor' interference problem to heart though. I didn't know that about the rPi hardware extensions. I certainly do not want to have image handling affect core functionality. So, I'll make sure to put something in place to avoid those kinds of priority collisions. I haven't used rPi for any hardware control before. -Thanks for the insight

 

[richiev]

Great insight, thanks. I've been using rpi zero W for a number of video projects, typically time-lapse. I've connected 8 cameras to a single Pi zero, via USB, and then takenmulti-angled time lapse. In that case, it is sampling all of the cameras for a single image each, every 30 seconds. Works great, but as you said, there isn't much processing going on....basic image entropy calculations to maximize data for later image processing. In this case, for reefing, I'm thinking one sample every 5-10 minutes across 3 cameras (2 for main DT monitoring and 1 for the sump). I can manage the available CPU by shifting out sample time.

I'll take that 'noisy neighbor' interference problem to heart though. I didn't know that about the rPi hardware extensions. I certainly do not want to have image handling affect core functionality. So, I'll make sure to put something in place to avoid those kinds of priority collisions. I haven't used rPi for any hardware control before. -Thanks for the insight

Sounds like you're all over it. I'd just keep an eye on https://rpilocator.com/, buy a second one, and run the controller separate from the camera. Worst case you end up with two and you can resell it, but realistically I think it'll be a lot more flexible to have the devices separable and just have them speak to each other over your wifi network, at least initially. Later you could all-in-one it, and/or just run a cross-over cable between the two to remove the dependency on wifi if so desired.

While doing the prototyping I think you'll also want that, because if you start having the tank(s) controlled by the pi, you're not going to want to disconnect it while you're fiddling with the cameras.

And if you find a 2W you can buy, buy two and I'll pay you for one .

 

[richiev]

One more data point @Prestondeeply, here's a screen grab of my pi's cpu/memory usage, as reported by reef pi. I think it's a 3B or B+, I can't remember and didn't check.

It's nearly using 100% of a core just doing whatever it's currently doing. I only have this one controlling an ATO and a heater. I think both are checking every 20 seconds or so. Plus whatever normal stuff a pi does.

Just as a reference point for planning load.

 

[Prestondeeply]

OK, so I've heard that running PWMs by hand can do that. But for an ATO, I'm sure it isn't constantly dumping one drop at a time. So, to me, that just looks like a straight up miss on how something was implemented. Like something should have been event based and instead was implemented with a once per second poll.

I'm not there yet, this next week I'm assembling the full solution and I'll be able to dig into any situations like that.

This is all _great_ info and something I'm going to be watching out for based on your experience. I fully expect a system like this to be idle 99.9% of the time if there isn't real work to be done. I'll let you know if I find anything with easy to correct answers.

I really appreciate the data points.

 

[richiev]

OK, so I've heard that running PWMs by hand can do that. But for an ATO, I'm sure it isn't constantly dumping one drop at a time. So, to me, that just looks like a straight up miss on how something was implemented. Like something should have been event based and instead was implemented with a once per second poll.

I'm not there yet, this next week I'm assembling the full solution and I'll be able to dig into any situations like that.

This is all _great_ info and something I'm going to be watching out for based on your experience. I fully expect a system like this to be idle 99.9% of the time if there isn't real work to be done. I'll let you know if I find anything with easy to correct answers.

I really appreciate the data points.

I have no comparative baseline for the pi without reef pi running, but yes that's an unexpected usage. Maybe they DIY'ed a scheduler with a busy loop. Though again it's not like a pi is a power house.

 

[Prestondeeply]

I've 'finished' the first round of my Reef-Pi inspired project. I say Inspired, because about 75% of the way into it, I stop using the Reef-pi code base but still referenced and used the HW designs.

I started with a Hygger 4 Doser. Cheap, has commodity well known parts, and has plenty of space inside the box. Here is the before and after:

closed and under test:

Back and Sides:

The 4 black jacks on the right are 4 temp probes (2 per tank so I can cross check the temp). The 3 vertical jacks on the left control 3 separate lighting systems.
On the back I have two different power supplies, one for the electronics and one for the motors to avoid interference.

The Hygger buttons, display, and 4 front facing LEDs were all re-usable. So now the entire system runs from a menu-ing system right on top of the unit. It controls the 3 different lights (color, intensity, and schedule for each), the 4 dosing pumps (volume and schedule), and samples the temperature.

For me, this one small box runs the lights and ATO (Dosing pumps) for two Nano tanks. We do large water changes once a month so we don't typically dose the Nanos. There is still a USB port on the RPI so we plan on getting a USB controlled power supply to control a couple of heaters. All in all, two nano tanks fully controlled in the space of a single 4 port doser. We're pretty happy with the results and ease of use so far.

The menu, buttons, scheduler, etc all run in a Python script of about 1k lines which took about a week of off-and-on programming. So, I don't use Reef-Pi software now. The python script takes 5-9% of the CPU constantly...mainly sampling the thermostats since the oneWire interface just seems to suck the CPU away. I've just ordered an auto-focus camera for the RPI so that will be part of the next round along with the power control.

I'm happy to post more detailed pics of anyone is interested. Much thanks to the reef-pi project.....that was huge in making the hardware approachable. Standing on the shoulders of giants.

-Andrew

 

[richiev]

I've 'finished' the first round of my Reef-Pi inspired project. I say Inspired, because about 75% of the way into it, I stop using the Reef-pi code base but still referenced and used the HW designs.

I started with a Hygger 4 Doser. Cheap, has commodity well known parts, and has plenty of space inside the box. Here is the before and after:
View attachment 39867
View attachment 39868

closed and under test:
View attachment 39869

Back and Sides:
View attachment 39872
View attachment 39874

The 4 black jacks on the right are 4 temp probes (2 per tank so I can cross check the temp). The 3 vertical jacks on the left control 3 separate lighting systems.
On the back I have two different power supplies, one for the electronics and one for the motors to avoid interference.

The Hygger buttons, display, and 4 front facing LEDs were all re-usable. So now the entire system runs from a menu-ing system right on top of the unit. It controls the 3 different lights (color, intensity, and schedule for each), the 4 dosing pumps (volume and schedule), and samples the temperature.

For me, this one small box runs the lights and ATO (Dosing pumps) for two Nano tanks. We do large water changes once a month so we don't typically dose the Nanos. There is still a USB port on the RPI so we plan on getting a USB controlled power supply to control a couple of heaters. All in all, two nano tanks fully controlled in the space of a single 4 port doser. We're pretty happy with the results and ease of use so far.

The menu, buttons, scheduler, etc all run in a Python script of about 1k lines which took about a week of off-and-on programming. So, I don't use Reef-Pi software now. The python script takes 5-9% of the CPU constantly...mainly sampling the thermostats since the oneWire interface just seems to suck the CPU away. I've just ordered an auto-focus camera for the RPI so that will be part of the next round along with the power control.

I'm happy to post more detailed pics of anyone is interested. Much thanks to the reef-pi project.....that was huge in making the hardware approachable. Standing on the shoulders of giants.

-Andrew

Super cool. Open sourcing it?

 

[Prestondeeply]

Super cool. Open sourcing it?

Oh certainly. I'd prefer someone, somewhere, builds something similar or even the exact same thing! I don't want to be the only one off in the weeds of DIY reef controllers. Heck if Hygger wants to copy the entire thing for a single box Nano-keeper, I'm all for it. I would have bought one if there was one available. Everything I looked into was just HUGE and expensive and designed for large tanks. My tanks are counter-top 10g Nanos. No cabinet to store all of the gear in.

I'll put it all up on github later in the summer when I have time to document it all and get the the camera+power control going. Until then, if anyone wants to experiment, DM me and I'll send over everything I've got.