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

[Ranjib]

^Ranjib, that would be awesome! Dave has been very helpful to me so far, which is a big reason why I hope to choose his DIY array. I am a member of NR, and would be grateful to tag along there too. You are always so helpful, thank you again!

-FF

Dave responded saying it will work just fine

 

[Ranjib]

I know this is off the wall.

Can i run pihole on the same raspberry pi as reef-pi?

It should, you may have to update reef-pi config to bind to an other port , if port 80 is used by pi hole

 

[Des Westcott]

Interesting.. The relays were not meant to switch every second like that. Had he set it to even 3 seconds per cycle I bet it would have lasted much longer. The excess heat is the most likely cause of failure.. But of course the mechanical part failed. This can happen to any Mechanical relay at any time from its first switch to millions...

This does prove they are super Reliable

Agreed. But it does show that the cheapest stuff out there can not necessarily be all that bad. Even the best quality stuff can go bad at any stage, but at least then you have backup and support.

He readily admits that his sample size of 1 is flawed and he does abuse it. But it shows that if you are lucky, they can work for a long time and you shouldn't just dismiss them because of the fact that they are cheap.

 

[Des Westcott]

Ranjib

I'm have ing a strange thing happen again.

Under equipment, suddenly i had the connector description disappear.


I tried to delete the equipment, and got this error in the pink bar.

And when i go to connectors and try delete there, i get the same thing.

This is similar to the problem i had previously.

 

[Erica-Renee]

Ranjib

I'm have ing a strange thing happen again.

Under equipment, suddenly i had the connector description disappear.


I tried to delete the equipment, and got this error in the pink bar.

And when i go to connectors and try delete there, i get the same thing.

This is similar to the problem i had previously.

You can not delete a Connector if its being controlled by a Outlet. or a Outlet if its being Controlled by a Float sensor , Temp probe or anything else..

Example.. Connector 1 Outlet 1 connected to equipment 1,, that is controlled by Float switch ATO LEVEL 1... You must first delete ato level 1.. equipment 1 . then the connector 1..

I have seen this bug. but when it happened to me it was on a TEMP PROBE . There was a looser wire . I did unfortunatly have to refresh the data base.
@Ranjib at some point it would be nice to have either a Auto Database backup,Before it makes changes or the Ability to make manual snap shots from the UI During setting up things.. This is how i do it on my Very Similar designed Estimation Software that is GO Written and runs on a Web server . API DRIVEN..

Thanks Everyone.. Just like the people who make up my business, This project is awesome due to so much Positive input and People working together , Trying to help Tied in by a AWESOME LEADER ....

 

[Des Westcott]

Thanks Erica-Renee

Yes. I know the order to delete things, so when I saw that the relay wasn't listed under the equipment, I tried to delete the equipment first, but failed. I just tried to do the next few for the sake of seeing the result

Des

 

[wykat]

16 channel PWM module (2.5mm connectors) :cool:
Have to allign all components, but basically this should fit to the HAT via stackable connectors. Only the PCA component is SMT which everybody should be able to solder with the right solder iron.

 

[Ranjib]

Ranjib

I'm have ing a strange thing happen again.

Under equipment, suddenly i had the connector description disappear.


I tried to delete the equipment, and got this error in the pink bar.

And when i go to connectors and try delete there, i get the same thing.

This is similar to the problem i had previously.

What versio you are using? Can you check the log when you hit the delete button.
I have a theory that there is a UI bug that has set the connector ID as blank or empty string. Which is why the API server is throwing error. Do a refresh of your browser and try deleting again. If that does not solve, we can use API to investigate/fix things. But dont reset your database, as that will take away the oppertunity to verify and address this bug (if its not already in master).

 

[Ranjib]

16 channel PWM module (2.5mm connectors) :cool:
Have to allign all components, but basically this should fit to the HAT via stackable connectors. Only the PCA component is SMT which everybody should be able to solder with the right solder iron.

SMT soldering will be significantly harder for most DIY folks, I worry.
Any reason to not use the adafruit pca9685 breakout board? I could understand rolling pca9685 in the board if we are doing all the other things as well. Or you are planning to stack these hats ?

 

[Ranjib]

You can not delete a Connector if its being controlled by a Outlet. or a Outlet if its being Controlled by a Float sensor , Temp probe or anything else..

Example.. Connector 1 Outlet 1 connected to equipment 1,, that is controlled by Float switch ATO LEVEL 1... You must first delete ato level 1.. equipment 1 . then the connector 1..

I have seen this bug. but when it happened to me it was on a TEMP PROBE . There was a looser wire . I did unfortunatly have to refresh the data base.
@Ranjib at some point it would be nice to have either a Auto Database backup,Before it makes changes or the Ability to make manual snap shots from the UI During setting up things.. This is how i do it on my Very Similar designed Estimation Software that is GO Written and runs on a Web server . API DRIVEN..

Thanks Everyone.. Just like the people who make up my business, This project is awesome due to so much Positive input and People working together , Trying to help Tied in by a AWESOME LEADER ....

I really appreciate all the help you provide in this thread, this gives me lot of extra time for code development. Thanks again

 

[Ranjib]

Development updates...
I am happy with the current state of "macro" subsystem that is in development. It is at a point that I would like to deploy it in some of my builds and start with using macro for weekly water change. I do think they can use some more validation and couple of feature enhancements, but I think that will always be the case, and I would really like to test it on the field and then combine feedback from that with what I already think, and fix all the major bugs before public release. That said, I think even though there are some big safety nets, by and large, macro features can significantly alter the overall performance/behavior of the controller. This is due to macro subsystem exposing wide and deep features of the entire reef-pi platform, which should unlock workflow automation (water change, photography etc), clustering (multiple reef-pi controlled from a single controller).
Tonight (or during the weekend) I'll cut the final beta release of reef-pi 2.0, which means there will be no more breaking changes in reef-pi 2.x series. We can have more features, but nothing can break any old 2.x components. Though feature freeze is imposed, we are like to have more pre-releases or alpha, which are bug fixes. The last alpha which is bugfree (release blockers) will become the final candidate for 2.0 public release. I am aiming for 2.0 release before Christmas, around Thanksgiving. This gives me at least three months to do field testing, bug fixing, and documentation. I am pretty bullish about the field testing & bug fixing, but for documentation, I could use all the help I can get.

 

[sjeff35]

Development updates...
I am happy with the current state of "macro" subsystem that is in development. It is at a point that I would like to deploy it in some of my builds and start with using macro for weekly water change. I do think they can use some more validation and couple of feature enhancements, but I think that will always be the case, and I would really like to test it on the field and then combine feedback from that with what I already think, and fix all the major bugs before public release. That said, I think even though there are some big safety nets, by and large, macro features can significantly alter the overall performance/behavior of the controller. This is due to macro subsystem exposing wide and deep features of the entire reef-pi platform, which should unlock workflow automation (water change, photography etc), clustering (multiple reef-pi controlled from a single controller).
Tonight (or during the weekend) I'll cut the final beta release of reef-pi 2.0, which means there will be no more breaking changes in reef-pi 2.x series. We can have more features, but nothing can break any old 2.x components. Though feature freeze is imposed, we are like to have more pre-releases or alpha, which are bug fixes. The last alpha which is bugfree (release blockers) will become the final candidate for 2.0 public release. I am aiming for 2.0 release before Christmas, around Thanksgiving. This gives me at least three months to do field testing, bug fixing, and documentation. I am pretty bullish about the field testing & bug fixing, but for documentation, I could use all the help I can get.

I'm more than happy to test it.

Thanks again for all you!

 

[Erica-Renee]

Development updates...
I am happy with the current state of "macro" subsystem that is in development. It is at a point that I would like to deploy it in some of my builds and start with using macro for weekly water change. I do think they can use some more validation and couple of feature enhancements, but I think that will always be the case, and I would really like to test it on the field and then combine feedback from that with what I already think, and fix all the major bugs before public release. That said, I think even though there are some big safety nets, by and large, macro features can significantly alter the overall performance/behavior of the controller. This is due to macro subsystem exposing wide and deep features of the entire reef-pi platform, which should unlock workflow automation (water change, photography etc), clustering (multiple reef-pi controlled from a single controller).
Tonight (or during the weekend) I'll cut the final beta release of reef-pi 2.0, which means there will be no more breaking changes in reef-pi 2.x series. We can have more features, but nothing can break any old 2.x components. Though feature freeze is imposed, we are like to have more pre-releases or alpha, which are bug fixes. The last alpha which is bugfree (release blockers) will become the final candidate for 2.0 public release. I am aiming for 2.0 release before Christmas, around Thanksgiving. This gives me at least three months to do field testing, bug fixing, and documentation. I am pretty bullish about the field testing & bug fixing, but for documentation, I could use all the help I can get.

I will load it as soon as i can onto my test build. I am going to build a second and put it in use in a week or so.( As time permits)

As far as putting everything on the same board, I am thinking this is not the best ideal other then those with very tight spaces, It adds complications,Testing of issues and replacing a whole board -Loosing the whole system if something goes wrong Modular with bigger housing to me makes me sense.. again just a opinion .Not to mention i can By a RKE OR Apex ... I am all about small and OPEN SOURCE..
Just my opinion...

 

[sjeff35]

I will load it as soon as i can onto my test build. I am going to build a second and put it in use in a week or so.( As time permits)

As far as putting everything on the same board, I am thinking this is not the best ideal other then those with very tight spaces, It adds complications,Testing of issues and replacing a whole board -Loosing the whole system if something goes wrong Modular with bigger housing to me makes me sense.. again just a opinion .Not to mention i can By a RKE OR Apex ... I am all about small and OPEN SOURCE..
Just my opinion...

This brings up (probably a dumb question on my part)... If you don't have everything on one board and have modules like ATO, Dosing, Lighting... Can they still be ran off of one Pi ? So there is only one web interface to work with??? I'm seeing folks with builds that seem to use several different Pi boards.

Thanks

 

[Erica-Renee]

This brings up (probably a dumb question on my part)... If you don't have everything on one board and have modules like ATO, Dosing, Lighting... Can they still be ran off of one Pi ? So there is only one web interface to work with??? I'm seeing folks with builds that seem to use several different Pi boards.

Thanks

Yes .. I have a Pi hat board that has temp , ato , and Uln built on and pins to connect other things like servo board for lighting and dosing.. There is also room to add connectors for a ph, probe (Next on my list..

I think (prob version 3) @Ranjib is planing adding the ability to control micro builds from a Master reef-pi (If so i would run the Reef-pi server on my File server (it runs debian with TONS OF SPARE POWER) and the macro controllers each close to the tanks and there controlled devices.. Again this is why i think balancing how much implemented on one board with macro controller ability . This macro controller or modular as RANJIB calls it.. Will limit your tank or System of tanks like mine to a Single failure . Like my Construction company Spreading Risk is As important as the Craftsman/Craftswoman ship of our People who do the work..

SO . Yes you can run everything on one pi.... or spread functions on different builds.. I think above explains how i feel. But this does not mean others cant have a ALL IN ONE BOARD SETUP. There is logic to both and even somewhere in between.. This is what open source is supposed to be about..

Yea i know ,, I talk even more then i type....

 

[Ranjib]

This brings up (probably a dumb question on my part)... If you don't have everything on one board and have modules like ATO, Dosing, Lighting... Can they still be ran off of one Pi ? So there is only one web interface to work with??? I'm seeing folks with builds that seem to use several different Pi boards.

Thanks

Not yet, this is something I plan to work on post 2.0. I am calling this as "clustering", which is to provide a single control plane/UI for managing a set of reef-pi controllers from one place

 

[Ranjib]

Yes .. I have a Pi hat board that has temp , ato , and Uln built on and pins to connect other things like servo board for lighting and dosing.. There is also room to add connectors for a ph, probe (Next on my list..

I think (prob version 3) @Ranjib is planing adding the ability to control micro builds from a Master reef-pi (If so i would run the Reef-pi server on my File server (it runs debian with TONS OF SPARE POWER) and the macro controllers each close to the tanks and there controlled devices.. Again this is why i think balancing how much implemented on one board with macro controller ability . This macro controller or modular as RANJIB calls it.. Will limit your tank or System of tanks like mine to a Single failure . Like my Construction company Spreading Risk is As important as the Craftsman/Craftswoman ship of our People who do the work..

SO . Yes you can run everything on one pi.... or spread functions on different builds.. I think above explains how i feel. But this does not mean others cant have a ALL IN ONE BOARD SETUP. There is logic to both and even somewhere in between.. This is what open source is supposed to be about..

Yea i know ,, I talk even more then i type....

Spot on.

 

[Des Westcott]

SMT soldering will be significantly harder for most DIY folks, I worry.
Any reason to not use the adafruit pca9685 breakout board? I could understand rolling pca9685 in the board if we are doing all the other things as well. Or you are planning to stack these hats ?

I don't mind the idea of these HAT's.

But what I think would be a "better" idea is one of a custom ribbon cable that could plug onto a Pi and have all the possible plugs to plug the other commonly used boards onto it. A sort of "wiring harness", like the ribbon cables you get inside a normal "box-type" PC. There are always a few plugs that are not used depending on what options you have. Maybe also have adaptors between common plugs and specific boards. This should also make troubleshooting easier because there will be less of a chance that you could have gotten GPIO pins mixed up.

I don't know, but to my "Road - Builder" mind that would seem easier.

 

[Erica-Renee]

I don't mind the idea of these HAT's.

But what I think would be a "better" idea is one of a custom ribbon cable that could plug onto a Pi and have all the possible plugs to plug the other commonly used boards onto it. A sort of "wiring harness", like the ribbon cables you get inside a normal "box-type" PC. There are always a few plugs that are not used depending on what options you have. Maybe also have adaptors between common plugs and specific boards. This should also make troubleshooting easier because there will be less of a chance that you could have gotten GPIO pins mixed up.

I don't know, but to my "Road - Builder" mind that would seem easier.

Every Road Leads to Another Road leading to another road.. Does your Job make your head spin...?

 

[wykat]

This should also make troubleshooting easier because there will be less of a chance that you could have gotten GPIO pins mixed up.

You can't mix up the GPIO ports, on the HAT all ports are fixed and the relais sequential aligned (see below).
Only mix up can be with the PCA9685 I2C address but that's similar to breakout board solutions.

Top 10 pin connect relais:

Pin 1 : GND

Pin 2: GPIO 5

Pin 3: GPIO 6

Pin 4: GPIO 7

Pin 5: GPIO 8

Pin 6: GPIO 9

Pin 7: GPIO 10

Pin 8: GPIO 11

Pin 9: GPIO 12

Pin 10: 12V

Bottom 10 pin connector relay:

Pin 1: GND

Pin 2: GPIO20

Pin 3: GPIO 21

Pin 4: GPIO 22

Pin 5: GPIO 23

Pin 6: GPIO 24

Pin 7: GPIO 25

Pin 8: GPIO 26

Pin 9: GPIO 27

Pin 10: 12V