Sorry for the random - @Cary I keep forgetting to mention that you and I live like one town apart and we're probably the only people in DFW using Reef pi. Small world.
In other news, can someone PM how to submit edits to the Reef pi guide?
reef-pi :: An opensource reef tank controller based on Raspberry Pi.
- Thread starter Ranjib
- Start date
-
- Tags
- controller raspberry-pi
- Tagged users Ranjib
Sorry for the random - @Cary I keep forgetting to mention that you and I live like one town apart and we're probably the only people in DFW using Reef pi. Small world.
In other news, can someone PM how to submit edits to the Reef pi guide?
To report on my progress I got the ATO and the Temp up and working (not too much of a challenge thanks to the software 
) I think the whole project is a singular most helpful thing, making the fish keeping so much easier. Plus it is highly rewarding to be able to do something on your own
The change introduced in the latest build allowing to reverse a relay state made the whole endeavor really easy. It seems that my relay board is kind of reversed in its reaction to the state changes. Thanks for bringing that up and making that in the software.
Where it comes to some feature suggestions I have three that for sure can wait for their turn to make the cut:
1. It would be handy to use Celsius as a temperature scale - (I live in Europe) - but is a luxury right now, I can perfectly live with mister Fahrenheit on the scale - the lowest priority for me
2. I think the ATO module would benefit from addition of a possibility of using a second fluid sensor/float switch located in the top-up water container. The purpose of that sensor would be to stop the whole ATO module when the level in the container goes too low. That way the pump in it would not run "dry". It is a bit of safety I think.
3. for the ATO I think it would be another safety level if there would be a possibility to define a maximum time a pump would be allowed to run continuously regardless of a state of a sensor in the tank - should the sensor fail in the "too low" state that timer would prevent the whole top-up water being pumped into the tank.
) I think the whole project is a singular most helpful thing, making the fish keeping so much easier. Plus it is highly rewarding to be able to do something on your own The change introduced in the latest build allowing to reverse a relay state made the whole endeavor really easy. It seems that my relay board is kind of reversed in its reaction to the state changes. Thanks for bringing that up and making that in the software.
Where it comes to some feature suggestions I have three that for sure can wait for their turn to make the cut:
1. It would be handy to use Celsius as a temperature scale - (I live in Europe) - but is a luxury right now, I can perfectly live with mister Fahrenheit on the scale - the lowest priority for me
2. I think the ATO module would benefit from addition of a possibility of using a second fluid sensor/float switch located in the top-up water container. The purpose of that sensor would be to stop the whole ATO module when the level in the container goes too low. That way the pump in it would not run "dry". It is a bit of safety I think.
3. for the ATO I think it would be another safety level if there would be a possibility to define a maximum time a pump would be allowed to run continuously regardless of a state of a sensor in the tank - should the sensor fail in the "too low" state that timer would prevent the whole top-up water being pumped into the tank.
OP
OP
I am very happy that reef-pi provided some value to your reef keeping journey. DIY projects are indeed very rewarding.To report on my progress I got the ATO and the Temp up and working (not too much of a challenge thanks to the software
The change introduced in the latest build allowing to reverse a relay state made the whole endeavor really easy. It seems that my relay board is kind of reversed in its reaction to the state changes. Thanks for bringing that up and making that in the software.
Where it comes to some feature suggestions I have three that for sure can wait for their turn to make the cut:
1. It would be handy to use Celsius as a temperature scale - (I live in Europe) - but is a luxury right now, I can perfectly live with mister Fahrenheit on the scale - the lowest priority for me
2. I think the ATO module would benefit from addition of a possibility of using a second fluid sensor/float switch located in the top-up water container. The purpose of that sensor would be to stop the whole ATO module when the level in the container goes too low. That way the pump in it would not run "dry". It is a bit of safety I think.
3. for the ATO I think it would be another safety level if there would be a possibility to define a maximum time a pump would be allowed to run continuously regardless of a state of a sensor in the tank - should the sensor fail in the "too low" state that timer would prevent the whole top-up water being pumped into the tank.
Regarding your feature suggestions,
1. It is funny, that you ask Celsius based temperature metrics, cause the actual probe (ds18b20) reports it in Celsius. I am more comfortable with Celsius (being from India). But here in US all things are in imperial metrics ( very weird), and so is all reef related discussion. I'll keep this in mind, it should not be hard to have it configurable.
2. Both ATO suggestions are important, and have been suggested already. One of them (3rd one) is likely to be part of 1.0. The other one (multiple sensor support) might be in post 1.0 road map, if not before 1.0. But definitely , both of the feature suggestions are on the radar and reef-pi will have them sooner or later.
Ryan115
Well-Known Member
Even being from the US, I wish we had all been taught the metric system from birth. It makes so much more sense.
Though science may have also biased me towards metric.
reef-pi spreading worldwide!To report on my progress I got the ATO and the Temp up and working (not too much of a challenge thanks to the software
The change introduced in the latest build allowing to reverse a relay state made the whole endeavor really easy. It seems that my relay board is kind of reversed in its reaction to the state changes. Thanks for bringing that up and making that in the software.
Where it comes to some feature suggestions I have three that for sure can wait for their turn to make the cut:
1. It would be handy to use Celsius as a temperature scale - (I live in Europe) - but is a luxury right now, I can perfectly live with mister Fahrenheit on the scale - the lowest priority for me
2. I think the ATO module would benefit from addition of a possibility of using a second fluid sensor/float switch located in the top-up water container. The purpose of that sensor would be to stop the whole ATO module when the level in the container goes too low. That way the pump in it would not run "dry". It is a bit of safety I think.
3. for the ATO I think it would be another safety level if there would be a possibility to define a maximum time a pump would be allowed to run continuously regardless of a state of a sensor in the tank - should the sensor fail in the "too low" state that timer would prevent the whole top-up water being pumped into the tank.
Somehow I have missed the posts with the ATO features. Thank you for the clarification. I am a willing volunteer to create a list of requested features so it could be published on the site.
As the the Fahrenheit scale, by now I am used to it since most of my reef tank research is based on US sources so the Celsius scale is just nice to have.
Ryan115
Well-Known Member
Ranjib,
since the latest update with the new telemetry feeds I have been noticing a pretty steady reduction in free memory.
The spike was a reboot.
Running top, it looks like most is being tied up in buffer/cache. Any thoughts?
since the latest update with the new telemetry feeds I have been noticing a pretty steady reduction in free memory.
The spike was a reboot.
Running top, it looks like most is being tied up in buffer/cache. Any thoughts?
Main page UI suggestion:
This would be the main page (i.e. the home page of the web interface). All items would be purely informational. No state changing (no turning items on or off, no changing brightness, etc.). That functionality would be on the respective tab (you'd be able to turn equipment on/off on the Equipment tab, change brightness on the Lighting tab, etc).
The graph is tank temperature over the last 24 hours (just dummy data for the chart) in half-hour increments. I know that currently you have it set up to use Adafruit for telemetry, but it would be pretty nice to be able to have basic logging and graphing capabilities built into the main page for key metrics (temp. other probes as added) for at least the prior 24 hours. For longer term display, I think Adafuit would work great.
"reef-pi" in the upper right corner would be user definable as the name of the tank.
This would be the main page (i.e. the home page of the web interface). All items would be purely informational. No state changing (no turning items on or off, no changing brightness, etc.). That functionality would be on the respective tab (you'd be able to turn equipment on/off on the Equipment tab, change brightness on the Lighting tab, etc).
The graph is tank temperature over the last 24 hours (just dummy data for the chart) in half-hour increments. I know that currently you have it set up to use Adafruit for telemetry, but it would be pretty nice to be able to have basic logging and graphing capabilities built into the main page for key metrics (temp. other probes as added) for at least the prior 24 hours. For longer term display, I think Adafuit would work great.
"reef-pi" in the upper right corner would be user definable as the name of the tank.
Last edited:
In addition to the temperature graph in the above image, the ability to add additional graphs as support for additional probes (as functionality is added) would be good. As would the ability to show multiple graphs of the same probe type if installed (i.e. if multiple temperature probes are installed for display tank/sump/lighting fixture/etc.).
(Forgot to note that in the above post, and I was outside the edit window)
(Forgot to note that in the above post, and I was outside the edit window)
Additional clarification (maybe one day I'll learn to include everything in one post):
The "State" column takes into account for the NO vs NC configuration for that outlet.
Example:
If the the relay is wired in a NO state (or that's the only option) and reef-pi is not sending a signal to energize the relay, it would read as "Off" with a red background. Conversely, if the the relay is wired in a NC state (or that's the only option) and reef-pi is not sending a signal to energize the relay, it would read as "On" with the green background pictured above.
The "State" column takes into account for the NO vs NC configuration for that outlet.
Example:
If the the relay is wired in a NO state (or that's the only option) and reef-pi is not sending a signal to energize the relay, it would read as "Off" with a red background. Conversely, if the the relay is wired in a NC state (or that's the only option) and reef-pi is not sending a signal to energize the relay, it would read as "On" with the green background pictured above.
OP
OP
A formal list of feature requests in website might be useful, but will be misleading. As there is no guarantee that those features will be developed (and timeline). We do not have dedicated developers who are working on specific feature requests, neither do we have any milestones. What we have though, is ideas of improvement and possibility of me working on those. This is currently sitting as a TODO list on my developer workstation, and I think it will be helpful to publish that in reef-pi's code repository, for anyone who is looking for whats being currently worked on or whats next priority. We can link that from website.
OP
OP
This is expected. Linux kernel will utilize any unused memory for caching, to boost IO read performance. So, you should notice the free unutilized memory being used as cache/buffer (think of all the time you are hitting the webui, and kernel has to read the css/javascript files from sd card, after sometime, they'll be served from memory). Kernel will reclaim those caching memory anytime something else needed them, i.e. this will not cause memory starvation.Ranjib,
since the latest update with the new telemetry feeds I have been noticing a pretty steady reduction in free memory.
The spike was a reboot.
Running top, it looks like most is being tied up in buffer/cache. Any thoughts?
But that brings a very valid question: Is it really a helpful metric? And I think it is not, I did not think through while implementing the heartbeat. My focus was to emit minimal health information comprising of cpu and memory utilization. I'll update the code to emit used memory instead. That is a better metric.
Thanks for pointing this out
OP
OP
I am torn on having equipment states in the dashboard. I know we'll have more probes going forward, and I have already looked at what @cypho did with his DIY controller. I am leaning towards having similar (show the status of critical functions, instead of individual equipment) style in dashboard. Also I would prefer to have an upperlimit on how many widgets/charts are present in the dashboard, it has to be clutter free to be really useful.
I agree that there should be an upper limit, but it would be easily doable to display 2-4 of them, probably 2 per row, up to 2 rows.
As for why you wouldn't want to have the status of each piece of equipment on a status dashboard? Isn't that the exact purpose of a status dashboard? Should the dashboard not be a place that can easily be looked at to see the status of the items being controlled by the system?
I know if I were to look at the main page of such a system I'd want to be able to quickly scan down the page to see that everything is turned on or off, according to how I wish each particular item to be operating.
It's like the dashboard of a car: you have your speedometer. This would be like your tank's temperature. If you drive any type of performance car (especially if it's a standard transmission) you'd have a tachometer. I'd think of this like another chart to be displayed, like the pH of the tank. You have indicator lights for your headlights, high beams, individual turn signals (plus a 3rd display type for your hazard lights). My car has a light for when the wheels break traction and spin. Newer cars are adding indicator lights for blind spot detection, etc. Each of those items is important and is readily readable on the dashboard of the car, much like I would want to know about the pumps in my system.
I'm not trying to argue or anything. I just truly don't understand why complete status information wouldn't be displayed on a consolidated panel.
Ranjib, I do agree with your approach. For me the list of things to add or TODO is just a list of ideas that where proposed by the community. That way an eager new comer (like me) does not invent a "wheel" again
and propose something that has been already discussed. The thread is very long and I did my best to read all of it but still have missed some information. I think there are others beside me that might have missed a bit or two here.
marspeed
Community Member
Oh happy day even though I found this thread quite confusing at times because reef pi is constantly being improved I would like to say I am extremely happy today I installed the OS configured it installed reef pi , VNC and adafruit io then played with a lighting schedule and to my surprise I find my lighting feeds on adafruit io all this on my first try
Thank you Ranjib
Thank you Ranjib
OP
OP
hugs
OP
OP
I see. I'll publish the TODO/Future feature list soon. This should help the new comers on what has already been proposed and agreed upon as new features.Ranjib, I do agree with your approach. For me the list of things to add or TODO is just a list of ideas that where proposed by the community. That way an eager new comer (like me) does not invent a "wheel" again
Hi,
I have a RPi3B and Adruino Uno. I would love to collaborate on this subject. Looks you have some knowledge in this area. Are you a programmer? Although i have an aptitude for this, i find that evrythimg seems new to me. let me know via PM. looks really good. looks like youre at a point where you can start slimming everything down and refine.
I have a RPi3B and Adruino Uno. I would love to collaborate on this subject. Looks you have some knowledge in this area. Are you a programmer? Although i have an aptitude for this, i find that evrythimg seems new to me. let me know via PM. looks really good. looks like youre at a point where you can start slimming everything down and refine.
Similar threads
