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

I am currently working on a new Reef-pi build for my 220. Has anyone ever maxed out the GPIO on their pi? I am intending on using all of the GPIO and was hoping someone has successfully used a GPIO expansion board for more IO. Do any of you have experience with this?
Thanks in advance.
As of now we don’t have support for any gpio expander . There were plans for supporting mcp23017, but it’s not done yet. Any chance you can use WiFi based outlets ?
 
HELP!

I deleted a driver without deleting the connector first, and now I cannot access the connectors in the Web UI.
The error I get when I go to "Connectors" tab is:

TypeError: Cannot read property 'name' of undefined

in t
in div
in div
in div
in t
in Connect(t)
in div
in div
in t
in div
in t
in t
in div
in div
in div
in div
in t
in Connect(t)
in t
in a



How do I fix this?
 
HELP!

I deleted a driver without deleting the connector first, and now I cannot access the connectors in the Web UI.
The error I get when I go to "Connectors" tab is:

TypeError: Cannot read property 'name' of undefined

in t
in div
in div
in div
in t
in Connect(t)
in div
in div
in t
in div
in t
in t
in div
in div
in div
in div
in t
in Connect(t)
in t
in a



How do I fix this?
About a minute before reading this I did the same thing... Sadly I think the only current way is it delete and reinstall reef-pi but I am not 100%. I don't plan on changing connectors or adding new ones so I will hold off.
 
As of now we don’t have support for any gpio expander . There were plans for supporting mcp23017, but it’s not done yet. Any chance you can use WiFi based outlets ?

Doesn't the PCA PWM driver work for outputs now? I thought I saw support for that
 
Good tip. THe isolator board is toast as I bread boarded it to a test reef-pi build and had the same issues. Thought I was going crazy rechecking my wiring again and again. Careful of that flux and solder joints ya'll!


so I am looking at doing 2 of the DJ power strips for high priority outlet control items. one of the HS300 wifi switches to control mixing station and hand full of levels a few solenoids and temp

16 - relays to control 120v
1 - Temp 1 wire
7 - levels
2 - solenoids

Total I would like to have 5 temps
I will also have the HS300 and two Shellys 1 that will be be a master over the two DJ power strips but that does not require I/O

I would not be against using all wireless HS300 for all outlets but with the startup issues I have it makes me a little scared not that power goes out often but when it does Im out of town and have a tank sitter who knows nothing about my tank other than feed the pre setup containers on the day marked on it lol.
 
Doesn't the PCA PWM driver work for outputs now? I thought I saw support for that

If that is the case could do this and use it to control my solenoids for R/O and mixing tank that should fee up enough to do what I want
 
HELP!

I deleted a driver without deleting the connector first, and now I cannot access the connectors in the Web UI.
The error I get when I go to "Connectors" tab is:

TypeError: Cannot read property 'name' of undefined

in t
in div
in div
in div
in t
in Connect(t)
in div
in div
in t
in div
in t
in t
in div
in div
in div
in div
in t
in Connect(t)
in t
in a



How do I fix this?
About a minute before reading this I did the same thing... Sadly I think the only current way is it delete and reinstall reef-pi but I am not 100%. I don't plan on changing connectors or adding new ones so I will hold off.

You can also reset the database by running this.

sudo systemctl stop reef-pi.service
sudo rm -rf /var/lib/reef-pi/reef-pi.db
sudo systemctl start reef-pi.service

 
Doesn't the PCA PWM driver work for outputs now? I thought I saw support for that
If that is the case could do this and use it to control my solenoids for R/O and mixing tank that should fee up enough to do what I want

Yeah you can connect many PCA9685 modules for more outputs.
 
Can you run two PCA9685? I could run one to do lights on the frag tank and the second one to do the 16 outputs needed to run the 120v outlets

You can connect 62 so 992 outputs. :)

EDIT: I should clarify, when you add these modules they communicate using I2C but this protocol isn't designed to be run through long cables so you will have to keep the modules as close to Pi as possible, less than 12", and run long output cables. Connecting 62 would be a nightmare so I shouldn't have even said that.
 
Last edited:
You can connect 62 so 992 outputs. :)

EDIT: I should clarify, when you add these modules they communicate using I2C but this protocol isn't designed to be run through long cables so you will have to keep the modules as close to Pi as possible, less than 12", and run long output cables. Connecting 62 would be a nightmare so I shouldn't have even said that.

I would only need two so 62 is like 60 more than I need and no problem on length it's all in the same box.
Thank you
 
I am currently working on a new Reef-pi build for my 220. Has anyone ever maxed out the GPIO on their pi? I am intending on using all of the GPIO and was hoping someone has successfully used a GPIO expansion board for more IO. Do any of you have experience with this?
Thanks in advance.
If you max out, you can use a pca9685 as an i/o expansion and instead of pwm, just turn the channels to 0 percent and 100 percent.
 
About a minute before reading this I did the same thing... Sadly I think the only current way is it delete and reinstall reef-pi but I am not 100%. I don't plan on changing connectors or adding new ones so I will hold off.

Literally did the same thing a few days ago.. lol. Maybe we can formally request a button to export the DB to a backup, and restore it?! :)
 
Literally did the same thing a few days ago.. lol. Maybe we can formally request a button to export the DB to a backup, and restore it?! :)
It is one of the itemized feature thats planned since 2.0, but i never got to actually implement it. Its complicated by the fact that reef-pi 's internal database is going through changes (which i expect to settle by next year, release 5) and lack of validation logic in the controller.
This particular problem comes from the fact that reef-pi allows you to delete drivers without deleting the corresponding connectors first, leaving them zombie.. which results in this. Theres a backend validation logic which should not allow this, as well as front end reliability logic , i.e. the ui should not crash if the driver is not present/undefined. I'll make sure we address this as soon as possible (yes, this work itself is also itemized and im working on it in 4.0). Since the introduction of HAL our feature capability has increased and so is the surface area of different driver induced issues.. we just have to address them one by one and do a much more rigorous job in field testing. Ofcourse, your inputs/feedbacks are the cornerstone of this process.. so thank you .
 
Literally did the same thing a few days ago.. lol. Maybe we can formally request a button to export the DB to a backup, and restore it?! :)

Here is a "Feature Wishlist" started to keep track of things like that


Please copy this post there

One request / "wish" per post and feel free to "Like" any ideas you think are worth seeing. Nothing is a guarantee it will be implemented, but the Devs can get an idea what the community wants and can prioritise what they can implement.
 
It is one of the itemized feature thats planned since 2.0, but i never got to actually implement it. Its complicated by the fact that reef-pi 's internal database is going through changes (which i expect to settle by next year, release 5) and lack of validation logic in the controller.
This particular problem comes from the fact that reef-pi allows you to delete drivers without deleting the corresponding connectors first, leaving them zombie.. which results in this. Theres a backend validation logic which should not allow this, as well as front end reliability logic , i.e. the ui should not crash if the driver is not present/undefined. I'll make sure we address this as soon as possible (yes, this work itself is also itemized and im working on it in 4.0). Since the introduction of HAL our feature capability has increased and so is the surface area of different driver induced issues.. we just have to address them one by one and do a much more rigorous job in field testing. Ofcourse, your inputs/feedbacks are the cornerstone of this process.. so thank you .

Hey Ranjib

How about a teaser of what we could see in the final release of 4.0. ie what features are the team working to include??
 
I'm having some issues with Macros, I think its a bug but could be me, using 3.3.1

If I setup a macro to turn on a piece of equipment wait 1 second and turn it off, then attach that macro to a sensor it works. When sensor is open the macro doesn't run and when sensor is closed the macro runs over and over.

I only want it to run once and this is where the problem occurs.

At the end of the macro I add a step to disable the sensor, this does cause the macro to run only once so the sensor seems to get disabled however when I view the ATO sensor tab it still shows it's on and when I click the on/off button nothing happens for it or any other sensors setup up. If I click on/off, leave tab and return, the change is reflected on other sensors but the sensor I just disabled via macro will go off but immediately come back on. Also the communication from UI to system stops, it's like the program is in a loop it can't exit. When I try to change settings they don't take effect as it's not communicating, press refresh and it won't reload. I then power cycle the Pi and I'm able to delete this macro and everything will resume back to normal and I can turn on/off sensors again so it does repair itself once the macro is gone.

This is how I set it up, the last line is what breaks it.

macro_error.jpg


My idea is another macro is triggered via a timer, that macro will enable this sensor which is in a closed position, once it opens it triggers this macro that switches some equipment and then disables the sensor as its no longer needed.
 
Last edited:
I'm having some issues with Macros, I think its a bug but could be me, using 3.3.1

If I setup a macro to turn on a piece of equipment wait 1 second and turn it off, then attach that macro to a sensor it works. When sensor is open the macro doesn't run and when sensor is closed the macro runs over and over.

I only want it to run once and this is where the problem occurs.

At the end of the macro I add a step to disable the sensor, this does cause the macro to run only once so the sensor seems to get disabled however when I view the ATO sensor tab it still shows it's on and when I click the on/off button nothing happens for it or any other sensors setup up. If I click on/off, leave tab and return, the change is reflected on other sensors but the sensor I just disabled via macro will go off but immediately come back on. Also the communication from UI to system stops, it's like the program is in a loop it can't exit. When I try to change settings they don't take effect as it's not communicating, press refresh and it won't reload. I then power cycle the Pi and I'm able to delete this macro and everything will resume back to normal and I can turn on/off sensors again so it does repair itself once the macro is gone.

This is how I set it up, the last line is what breaks it.

macro_error.jpg


My idea is another macro is triggered via a timer, that macro will enable this sensor which is in a closed position, once it opens it triggers this macro that switches some equipment and then disables the sensor as its no longer needed.

This "issue" ties in with my other posts regarding my challenges with Macros and running them off timers as well as macros running macros. I have been processing in my mind how a sensor triggering a macro would work and the response you are getting is what I would expect.

For a macro to run off a timer, it must be reversible and will only run in reverse.

The Macro ability and associated manipulation of them are what (for me anyway) makes reef-pi so brilliant.

As we are developing use cases for the feature, we are going to come accross more and more of these "hiccups".
 
This "issue" ties in with my other posts regarding my challenges with Macros and running them off timers as well as macros running macros. I have been processing in my mind how a sensor triggering a macro would work and the response you are getting is what I would expect.

For a macro to run off a timer, it must be reversible and will only run in reverse.

The Macro ability and associated manipulation of them are what (for me anyway) makes reef-pi so brilliant.

As we are developing use cases for the feature, we are going to come accross more and more of these "hiccups".

Yeah macros are great but still need some work, I like the suggestion forum as I was just going to bring this up.
 
Hey Ranjib

How about a teaser of what we could see in the final release of 4.0. ie what features are the team working to include??
I think we'll try our best to ship all the features in incremental way.. 3.x series. so 4.0 may not be a big bang release, except we'll introduce some breaking changes. that we dont want to do in 3.x series.
Feature wise you are looking at lot more drivers... things like shelly, DLI webpowerswitch pro on the powercontroller side, humidty sensors.. some kinda of sound based alerting (e.g. mp3 based, since we have a full blown audio capability thanks to pi, so we can do more than just buzzer), ability to customize UI theme and dashboard (its not in a good state in 3.0), ability to log custom parameters, mqtt integration (and in general improvements to allow more home automation in general), ability to run reef-pi as its own wifi hotspot (not wifi client), lots of stability improvements (validation, performance etc) are some of the things that we are working on.

You can get an idea of whats exactly being shipped here: https://github.com/reef-pi/reef-pi/projects/3
 

IF YOU HAD TO TAKE A REEFING EXAM, WOULD YOU PASS?

  • Yes!

    Votes: 32 45.7%
  • Not yet, but I have one that I want to buy in mind!

    Votes: 9 12.9%
  • No.

    Votes: 26 37.1%
  • Other (please explain).

    Votes: 3 4.3%
Back
Top