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

I remember. Very interesting use :-)
The doser pumps should work as expected. 2.0 had a bug. What version you are running?
Without checking, I believe it would be 2.0 based on the release dates.

I'll update this hopefully over the weekend and test again

Thanks.
 
So I'm assuming that all the new releases will be 3.x?
The UI looks good and easy to navigate.
That’s my current thought. Since all of this will break existing api /database . Expect a long beta /alpha phase for 3.0
 
thanks a bunch Mikeneedsahobby, this did the trick written in a way I could understand. I think I need to follow a single thread (this one way too long), been reading too much, to decide which options I want to employ. Need simple terminology (like above) as I'm new to all this programming language. Do you have a build thread? or is there one you'd recommend?

Yes I have a reef pi build thread. I think if you click on my mustang pic it will pull up a menu to choose threads started by me. It is there. I don’t know if it is good or not. I have only built a functional thermometer so far but i tried to be thorough and keep it simple. As for others. There are many. I personally follow diamond1 and theatrus threads the most but they both go over my head a lot.
 
@Ranjib , I was poking around the doser settings, I couldn't see how to do multiple dosings per day, am I missing something or is this not implemented (yet)?
 
So I am still using the custom 2.0 release with configurable PCA9685 address, but my theory on the memory only rising during the day is incorrect.
There was a steady increase since just before 0700 yesterday.
upload_2019-1-25_12-34-16.png

upload_2019-1-25_12-34-41.png


I attempted a reload from within the GUI while at 65% usage and received the allocation error, but I am not sure exactly where the threshold is.

Would it matter if I always have the GUI up on my laptop browser and possibly the memory increase ceases when the laptop is sleeping?
 
@Ranjib , I was poking around the doser settings, I couldn't see how to do multiple dosings per day, am I missing something or is this not implemented (yet)?

@stefanm Here is how I have mine set up. Mine is calibrated to 1 ml per second so I have it set to dose 5 seconds and several different hour points in the day. The second one is the same doser but its an adjustment value. So If I needed to dose say 28 ml. I would dose 5 seconds 4 times in the first rule and one time for 3 seconds in the second rule.

46822524742_3a8c83b293_h.jpg
 
@stefanm Here is how I have mine set up. Mine is calibrated to 1 ml per second so I have it set to dose 5 seconds and several different hour points in the day. The second one is the same doser but its an adjustment value. So If I needed to dose say 28 ml. I would dose 5 seconds 4 times in the first rule and one time for 3 seconds in the second rule.

46822524742_3a8c83b293_h.jpg

Thanks, now I get it looks straight forward.
 
I’ll watch the memory usage things for a few week. From my initial assessment it’s not a leak wand as expected .
reef-pi keeps all usage data across all modules in memory, to minimize disk io , and periodically writes them back on disk (and during reload/ shutdown ). The memory issues arise from this . Till 2.1 the retention period was hard coded (fixed to a set value in the code) for a week worth of high granularity data and a month worth of hourly averages. With 2.2 we have ability to control this and thus limit the memory usage.
This comes at a cost of loosing older data. I’ll be thinking about how to best address this. Dashboards will use this data very often, I don’t want to do disk io a lot. So card failure will be more painful than memory induced reload or being restricted to see only limited historical data.
 
I’ll watch the memory usage things for a few week. From my initial assessment it’s not a leak wand as expected .
reef-pi keeps all usage data across all modules in memory, to minimize disk io , and periodically writes them back on disk (and during reload/ shutdown ). The memory issues arise from this . Till 2.1 the retention period was hard coded (fixed to a set value in the code) for a week worth of high granularity data and a month worth of hourly averages. With 2.2 we have ability to control this and thus limit the memory usage.
This comes at a cost of loosing older data. I’ll be thinking about how to best address this. Dashboards will use this data very often, I don’t want to do disk io a lot. So card failure will be more painful than memory induced reload or being restricted to see only limited historical data.

I wouldn’t worry about card wear. A number of systems periodically do atomic disk I/O, even down to ext4. Just writing directly to disk through the page cache should be just fine.
 
I am working on adding a new type of connector to represent analog inputs , like the ones used for ph, orp, salinity etc, and I am thinking what to call them. We have outlet representing digital output, inlet representing digital input , jack representing variable dc output,,, any suggestion for the new connector name that will represent analog input ?

Just call them what they are - I would rather see "Variable DC Output" instead of "Jack" or "Digital Output" instead of "Output".

So for me, the "Analog Input" should be "Analog Input"

It's just the way my brain prefers associating making the associations.

Des
 
Just call them what they are - I would rather see "Variable DC Output" instead of "Jack" or "Digital Output" instead of "Output".

So for me, the "Analog Input" should be "Analog Input"

It's just the way my brain prefers associating making the associations.

Des

I agree with Des. You should work toward getting the terms in line with industry standards. Analog vs digital inputs and outputs, one wire input and so on. Refer to them like this throughout the documentation and build.
 
I haven't updated yet, but I am no longer keeping the web page open in my browser, and so far it is flat since the last restart.
Does the system cache anything locally when the web page is opened on another device?
upload_2019-1-26_13-1-37.png
 
I haven't updated yet, but I am no longer keeping the web page open in my browser, and so far it is flat since the last restart.
Does the system cache anything locally when the web page is opened on another device?
upload_2019-1-26_13-1-37.png
When the dashboard is open, it will constantly pull reef-pi server to get latest data. This should caused some cpu utilization but should not impact memory ...
 
Hello hivemind,
I have cut a new release , 2.2 , builds are available in usual location: https://github.com/reef-pi/reef-pi/releases/tag/2.2

Highlight for this release are:
Features:
- ATO controller has now an option to automatically lock down when max usage threshold is breached and alert is triggered
- Stats retention across all modules (temperature, ato, health metric etc) are now configurable. By default its set to 1440 data points for current stats (a day worth of data at highest resolution assuming sensor is configured at 1 minute polling interval), and 720 data points for historical stats (30 days of data at hourly average).
Bugfixes:
- ATO usage alert was broken. Fixed now
- Dashboard layout for 1 column configuration was not proper, it was hardcoded for two column setup . Fixed now
- Timers were not showing up on macro tabs unless user have visited timer tabs. Fixed now

This releases (2.x series) are not from master (current development branch of reef-pi), as master has all new hal (hardware abstraction layer) changes with ph driver etc. These releases are derived from 2.0/2.1 code base with bugfixes and selected features cherry picked onto them. This is to not break API/database, which mean you wont get the new driver goodness (and all the untested bugs that comes with it), but you also will be able to upgrade without any issue.

I do not expect to cut many 2.x release in future, unless we have serious bugs. I'll start cutting 3.x alpha/beta releases from march., for the early tester on ph board.

Thank you for all the help you provide in this project, all of us deeply respect your feedback. For those of you dealing with the memory issue, try configuring the current and historical stats limit to a minimum (say 3 hours of current data, and 7 days of historical, which corresponds to 180 and 168 respectively), if this contains the memory usage, then it means we dont have a memory leak, and the memory usage is legitimate utilization of memory by the stats model. I;ll work on a better scheme to persist stats on disk.. we'll talk about that after the initial finding from tuning stats limits.
I just updated to 2.2 how do I change the memory usage is there a write up somewhere? Also what are the benefits of limiting the usage?
Thank you for you amazing work building my 3rd and 4th pi now.
 

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%

New Posts

Back
Top