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

in fact I'm not following this discussion but already I solved two problems aahaha I'm following the discussion on the adafruit site but in the guide I suggested you use a relay power strip instead I used relays to which I will connect the European plugs for the rest I'm following and buying what the guide recommends :)
 
I never looked at these things. In fact I try to avoid pretty much everything thats fancy and based on something thats more original.
My experience has been that we are not limited by CPU/Memory. Yes there are cases where we have hit the ceiling , and may be there are some use of extra CPU/Memory. But 99% of the time we are actually struggling with neat features, reliability, documentation etc. Put other ways, my personal focus has always been to get the story right, i.e. get a functional controller running that can does the daily chores of reef keeping and can be built by most DIY enthuthiast. Sticking to original Raspberry Pi and avoiding most fancy things helped me achieve that, as I ride on the shoulder of those giants. We get to use standard raspberry pi/adafruit community help, and continued software improvements. This does limit us in some way, but I think its worth the compromise. Its ok to not be able to run both webcam and the entire controller in pi zero, as long as it can does the main controller bits, for each of us, easily and forever without hiccups.

In the very beginning when I started reef-pi development, reef-pi was named reefer and I was aiming to make it compatible in all sorts of hardware (Raspberry Pi, Intel Edison, Beaglebone ... etc), I also had all sorts of fancy things (like level sensors , etape). But after doing all of that for good 8 months, I realized that very few of those things actually help me in better reef keeping. In fact it was clear that I can do reef keeping without a controller, but having one that does the monotonous work and adds some extra safety gears is actually worth my time and effort.

Now, all that being said, after reef-pi 3.0 release I think we'll nail down some of the advanced features as well (peristaltic pumps, wavemakers, clustering etc) and I am open for suggestion on moonshot ideas, but I would still emphasize on use case first. i.e. we have to think about what this particular thing gives us, just more of anything is not useful, but if we have a use case (for example, we may decide that we'll do time series analysis on the temperature /ph data and predictively alert folks when equipment or tank act anomolous, instead of fixed threshold based alerting) that actually benefits reef keeping , and the new fancy things is required for that, then I'll definitely consider it

I dont mean to be rude, but I want to keep reef-pi features (software and hardware) coherent, for it to be effective and for me to be able to maintain it easily. Hope you understand :)

Bravo!
 
This is why I plan on making my own temp probe. With so many counterfeit ones out there might as well buy the actual legit part and seal it in a piece of tubing yourself. Then you know you have a legit sensor and it’s been sealed by you. Can anyone recommend a reef safe epoxy? Something that you could just dip the sensor and wires in?

https://www.digikey.com/product-detail/en/maxim-integrated/DS18B20/DS18B20-ND/956983

You might also think about putting it in a glass tube and heat shrinking it in the tube. Just a thought.
 
I never looked at these things. In fact I try to avoid pretty much everything thats fancy and based on something thats more original.
My experience has been that we are not limited by CPU/Memory. Yes there are cases where we have hit the ceiling , and may be there are some use of extra CPU/Memory. But 99% of the time we are actually struggling with neat features, reliability, documentation etc. Put other ways, my personal focus has always been to get the story right, i.e. get a functional controller running that can does the daily chores of reef keeping and can be built by most DIY enthuthiast. Sticking to original Raspberry Pi and avoiding most fancy things helped me achieve that, as I ride on the shoulder of those giants. We get to use standard raspberry pi/adafruit community help, and continued software improvements. This does limit us in some way, but I think its worth the compromise. Its ok to not be able to run both webcam and the entire controller in pi zero, as long as it can does the main controller bits, for each of us, easily and forever without hiccups.

In the very beginning when I started reef-pi development, reef-pi was named reefer and I was aiming to make it compatible in all sorts of hardware (Raspberry Pi, Intel Edison, Beaglebone ... etc), I also had all sorts of fancy things (like level sensors , etape). But after doing all of that for good 8 months, I realized that very few of those things actually help me in better reef keeping. In fact it was clear that I can do reef keeping without a controller, but having one that does the monotonous work and adds some extra safety gears is actually worth my time and effort.

Now, all that being said, after reef-pi 3.0 release I think we'll nail down some of the advanced features as well (peristaltic pumps, wavemakers, clustering etc) and I am open for suggestion on moonshot ideas, but I would still emphasize on use case first. i.e. we have to think about what this particular thing gives us, just more of anything is not useful, but if we have a use case (for example, we may decide that we'll do time series analysis on the temperature /ph data and predictively alert folks when equipment or tank act anomolous, instead of fixed threshold based alerting) that actually benefits reef keeping , and the new fancy things is required for that, then I'll definitely consider it

I dont mean to be rude, but I want to keep reef-pi features (software and hardware) coherent, for it to be effective and for me to be able to maintain it easily. Hope you understand :)

I agree, good useful features, easily built by a hobbiest and easy to obtain parts. Thats what attracted me to your project!
Im looking to keep an aquarium running and be able to monitor and turn equipment on and off, and use as a failsafe, and reef pi does just that, and so far does it very well!
 
Dipped sensor testing continues

051e9005ed65ec0c8d1755a87498e7e3.jpg


Both the urethane and acrylic dips are holding up nicely. The urethane is currently where I’m steering as it’s more flexible and applies thicket even though it takes a lot longer to cure.
 
Dipped sensor testing continues

051e9005ed65ec0c8d1755a87498e7e3.jpg


Both the urethane and acrylic dips are holding up nicely. The urethane is currently where I’m steering as it’s more flexible and applies thicket even though it takes a lot longer to cure.
This is in salt water, I'm assuming? What temp? My only concern with room temp vs 78-80F is the possibility of leaching.
 
I'd just be cautious about long term exposure in a saltwater environment with higher than normal temps. I'm guessing both will be OK, but I would think the acrylic would be 'more reef safe', since it's a fairly common polymer used in our equipment already.
 
@Ranjib - is there a way to get a dummy UI up and running on apache or something similar so I can work on that 'offline' from the main controller?
You dont need apache or anything. reef-pi is a standalone http server. You can run it in dev_mode (where all device communications are faked) in your laptop. Thats how we develop it (in macbook or windows). If you are trying to run reef-pi in laptop or other non raspberry pi environment then just follow the development environment setup guide.
 
@Ranjib Just wondering where you are at with support for Roberto's ph board.
Also would something like this work with the board? I know it's cheap and probably won't last to long but I'm thinking it will work just fine for testing and be replaced with something better after I make sure everything is working as expected.
https://www.amazon.com/Connector-Co...UTF8&qid=1546875579&sr=8-44&keywords=ph+probe

The super cheap sensors do work, but expect a lot more drift over time. They also aren't well sealed.
 
You dont need apache or anything. reef-pi is a standalone http server. You can run it in dev_mode (where all device communications are faked) in your laptop. Thats how we develop it (in macbook or windows). If you are trying to run reef-pi in laptop or other non raspberry pi environment then just follow the development environment setup guide.

I get this error when running the 'make' command, after 'make install':

make go
make[1]: Entering directory '/home/dari/gospace/src/github.com/reef-pi/reef-pi'
go build -o bin/reef-pi -ldflags "-s -w -X main.Version=2.0-17-ged309ed" ./commands
# github.com/reef-pi/reef-pi/controller/connectors
controller/connectors/inlet.go:51:51: cannot use fmt.Sprintf("GP%d", i.Pin) (type string) as type int in argument to inputDriver.InputPin
controller/connectors/jack.go:40:39: cannot use fmt.Sprintf("%d", channel) (type string) as type int in argument to pwmDrvr.PWMChannel
controller/connectors/outlet.go:35:54: cannot use fmt.Sprintf("GP%d", o.Pin) (type string) as type int in argument to outputDriver.OutputPin
make[1]: *** [Makefile:21: go] Error 2
make[1]: Leaving directory '/home/dari/gospace/src/github.com/reef-pi/reef-pi'
make: *** [Makefile:12: bin] Error 2

I got rid of the Sprintf and passed in just i.Pin, channel and o.Pin and it worked...
 
Last edited:
I get this error when running the 'make' command, after 'make install':

make go
make[1]: Entering directory '/home/dari/gospace/src/github.com/reef-pi/reef-pi'
go build -o bin/reef-pi -ldflags "-s -w -X main.Version=2.0-17-ged309ed" ./commands
# github.com/reef-pi/reef-pi/controller/connectors
controller/connectors/inlet.go:51:51: cannot use fmt.Sprintf("GP%d", i.Pin) (type string) as type int in argument to inputDriver.InputPin
controller/connectors/jack.go:40:39: cannot use fmt.Sprintf("%d", channel) (type string) as type int in argument to pwmDrvr.PWMChannel
controller/connectors/outlet.go:35:54: cannot use fmt.Sprintf("GP%d", o.Pin) (type string) as type int in argument to outputDriver.OutputPin
make[1]: *** [Makefile:21: go] Error 2
make[1]: Leaving directory '/home/dari/gospace/src/github.com/reef-pi/reef-pi'
make: *** [Makefile:12: bin] Error 2

I got rid of the Sprintf and passed in just i.Pin, channel and o.Pin and it worked...

@Ranjib is in the middle of swapping types in the HAL layer back to pins being just an int (instead of a name). Since reef-Pi doesn’t use any pinning (glide, or new go modules) if all repos aren’t in sync you’ll get issues.
 
I get this error when running the 'make' command, after 'make install':

make go
make[1]: Entering directory '/home/dari/gospace/src/github.com/reef-pi/reef-pi'
go build -o bin/reef-pi -ldflags "-s -w -X main.Version=2.0-17-ged309ed" ./commands
# github.com/reef-pi/reef-pi/controller/connectors
controller/connectors/inlet.go:51:51: cannot use fmt.Sprintf("GP%d", i.Pin) (type string) as type int in argument to inputDriver.InputPin
controller/connectors/jack.go:40:39: cannot use fmt.Sprintf("%d", channel) (type string) as type int in argument to pwmDrvr.PWMChannel
controller/connectors/outlet.go:35:54: cannot use fmt.Sprintf("GP%d", o.Pin) (type string) as type int in argument to outputDriver.OutputPin
make[1]: *** [Makefile:21: go] Error 2
make[1]: Leaving directory '/home/dari/gospace/src/github.com/reef-pi/reef-pi'
make: *** [Makefile:12: bin] Error 2

I got rid of the Sprintf and passed in just i.Pin, channel and o.Pin and it worked...
Use the driver_ui branch. https://github.com/reef-pi/reef-pi/tree/driver_ui
I am in the middle of a large scale refactor to introduce driver api/ui. This will allow us to add new hardware drivers via API /UI (they need to be physically connected for work, for sure). We'll use this to support ph board, multiple pca9685, mcp23017 , base board etc. This (broken master) will be for a short duration. It was definitely not intended, but one thing led to another.. and its better done now than later
 
Use the driver_ui branch. https://github.com/reef-pi/reef-pi/tree/driver_ui
I am in the middle of a large scale refactor to introduce driver api/ui. This will allow us to add new hardware drivers via API /UI (they need to be physically connected for work, for sure). We'll use this to support ph board, multiple pca9685, mcp23017 , base board etc. This (broken master) will be for a short duration. It was definitely not intended, but one thing led to another.. and its better done now than later

Always a construction zone - that just means exciting things are happening :)
 

ARE YOU READY TO CONFESS TO CRAZIEST, DUMBEST, FUNNIEST THING YOU’VE EVER DONE IN REEFING?

  • Yeah, I'll confess! (Share your story in the comments!)

    Votes: 26 63.4%
  • Nah, I'll keep mine a secret...(Don't be like that, share with the class!)

    Votes: 15 36.6%
Back
Top
Home
Post thread…
Market
What's new