reef-pi :: An opensource reef tank controller based on Raspberry Pi.
- Thread starter Ranjib
- Start date
-
- Tags
- controller raspberry-pi
- Tagged users Ranjib
marspeed
Community Member
Solid state relay
OP
OP
I am a programmer. We use Raspberry Pi and some extra electronics for this project, but no arduino (it was not fully opensource when I started the project. I do not think we'll ever need arduino ). Let me know what you want to do with reef-pi, this is an opensource projects, and community is key. I'll always look for collaborators.
OP
OP
I did not. I never needed it. My understanding is SSRs uses triacs internally. Do you have a use case that requires TRIACs and can not be done by relays?
OP
OP
Yup. Most SSRs will have lower amp limits (2 amp most common), then most mechanical relays (10 amp)
OP
OP
No. Status dashabord does not show status of everything
The purpose of status dashboard to get the overall health of the system at a glance, as quickly as possible, as effortlessly as possible. Having details that can be captured by other means will incur visual and performance pain. For example, an ATO subsystem controls water pump equipment, so if we can show what time and how much water was added (time duration of the pump being on) that in turn indicates when and how long the pump was on, or whether the pump is running or not at that moment. Same goes for temperature controller etc. Unless its a buggy system and we dont have any confidence, state of individual equipments is not the most important thing to show in the dashboard. A would repeat an old wisdom (taken from RFC1925 point number 12):
Take a look at @cypho 's dashboard , if you have not
thats the stuff ! I think its better than most commercial controller, I find some of them full of not-so-important details.I ensure reliability in distributed systems made of fragile components. And I use dashboards (command center as its known) to diagnose overall system health. The focus here is to keep it effective in spotting any system wide anomaly (does my ato runs more than normal? why is tempertature consistently high? etc... ), any further diagnosis, that is component level will involve fine grained charts/status pages. i.e if you find something fishy from the overall dashboard, you may jump into the equipments tab to figure out the exact details.
Then I suppose we philosophically disagree with what the purpose of the dashboard is. I see the dashboard as reflecting what the software is doing at this point in time, not the health of the system. I don't think there is nearly enough data (and that's not a sleight on the software) to determine the health of the system that your eyes couldn't already provide.
Yes, we are using the software to promote a healthy system, but that's not the goal of the software. There software's goal is to provide a framework for automating tasks. To me, part of that is providing centralised feedback on what it thinks it's doing so that we can see how that visually compares to reality.
At the very least, I believe that it should be user configurable, so that they can choose to display the information that is important to them. Personally, in my ideal system, I would want a section that shows sensor data (the charts), a section that shows the current state of the items powered by the system, as well as a section that shows any variable PWM controls (lighting or DC PWM wavemaker control if added).
But I can still find a plus in this. If there's no all in one status page, I have little that's tying me to buying the 7" Pi touchscreen (and any associated items that I would require). That item's entire purpose was "touch the screen to display what's going on" without having to navigate screens or menus. If there would be navigation involved, I would be far more likely to just grab my laptop.
Yes, we are using the software to promote a healthy system, but that's not the goal of the software. There software's goal is to provide a framework for automating tasks. To me, part of that is providing centralised feedback on what it thinks it's doing so that we can see how that visually compares to reality.
At the very least, I believe that it should be user configurable, so that they can choose to display the information that is important to them. Personally, in my ideal system, I would want a section that shows sensor data (the charts), a section that shows the current state of the items powered by the system, as well as a section that shows any variable PWM controls (lighting or DC PWM wavemaker control if added).
But I can still find a plus in this. If there's no all in one status page, I have little that's tying me to buying the 7" Pi touchscreen (and any associated items that I would require). That item's entire purpose was "touch the screen to display what's going on" without having to navigate screens or menus. If there would be navigation involved, I would be far more likely to just grab my laptop.
OP
OP
No thats not the entire purpose of touch screen. A physically connected touch screen allows you to run reef-pi without any network requirement.
You are right we philosophically disagree on the purpose of status page. And as I mentioned, i dont see much value in cluttering all possible information (albeit they might have some value).
reef-pi was build ground up to be as affordable and as hackable as possible. Which means it is trivial to remove everything that not needed, and still be able to build a light controller under 30$. It also means you can run reef-pi backend and use any other software as UI and conroll reef-pi using its API.
Finally, since reef-pi is opensource, one can always make the code changes to support composable dashboards. I am open to have such capabilities. Its just I personally do see much value in it, hence I am not signing up for that piece of work.
Right, but I will be on a network, so if the software doesn't have a feature that was the main use I would be buying it for, I can do without. That saves me about $100 that can be used elsewhere. Its use was to be a status monitor, I was always going to do any change/config work through a machine with a keyboard and mouse. And that's fine. It's not your duty to provide software that is everything to every person.
As you said, there's an API, so if it's that important to me I can always build a status page using that. I certainly would never go far enough that I'd fork the application. Maintaining it would be far more work than a status monitor would be worse. For one, I don't know anything about GO, and the overwhelming majority of my programming experience was 20 years ago, and I'd be willing to bet that programming languages haven't stood still in that time. Learning a little JSON/JQuery, on the other hand, looks doable. Or accessing JSON data via PHP looks easy enough, and I have at least a passing familiarity with that.
As you said, there's an API, so if it's that important to me I can always build a status page using that. I certainly would never go far enough that I'd fork the application. Maintaining it would be far more work than a status monitor would be worse. For one, I don't know anything about GO, and the overwhelming majority of my programming experience was 20 years ago, and I'd be willing to bet that programming languages haven't stood still in that time. Learning a little JSON/JQuery, on the other hand, looks doable. Or accessing JSON data via PHP looks easy enough, and I have at least a passing familiarity with that.
Last edited:
No worries. When @Ranjib mentioned there was an API (I'm sure it was mentioned earlier in the thread, but I must have missed it) I went diving for the documentation.
I've flown through DFW (I assume, based on your location noted as Allen, TX) many, many times, but it's never been an endpoint to my journey.
I've flown through DFW (I assume, based on your location noted as Allen, TX) many, many times, but it's never been an endpoint to my journey.
Ryan115
Well-Known Member
Ranjib,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.
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
I agree that the minimum system health is good to monitor, but may not be "telemetry worthy". What are your thoughts on having reef-pi check the health metrics and have a telemetry section set for errors/warnings alerts. That way there is only something sent if it needs to be brought to the users attention. This could contain many safety checks for all aspects of the system (i.e. extreme temperature, alert from floatswitches that should never be triggered, etc...)
Can telemetry accept text, or only numeric values? If that is the case, maybe a list of error codes and then alerts setup within adafruit io?
Cary
Well-Known Member
Ranjib and all, I am not proposing this (see graphic), because it is quite divergent from our path at this time. But, when I was looking at aquarium controllers on the internet, I found this one and it peeked my interest. I captured the URL in the graphic, if you want to look at it.
The dashboard quite explanatory - the URL has an assortment of dashboard screen captures.
The dashboard quite explanatory - the URL has an assortment of dashboard screen captures.
Cary
Well-Known Member
Ranjib, If I wanted to use a larger SD card in my Pi that is running reef-pi, what is the procedure to save the configuration and use the larger card? The card that I have would have an older copy of Raspbian and reef-pi on it.
I wonder if this is something others might want to do in the future?
I wonder if this is something others might want to do in the future?
OP
OP
Copy reef-pi database file (/var/lib/reef-pi/reef-pi.db) to the new sd card , after installing reef-pi in it, and restart reef-pi, that should be it
Similar threads
