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

[bishoptf]

nevermind, figured it out

 

[Ranjib]

I’m a actually referring to the second dosing pump rule that says feb 08 on the bottom. It ran at 7:05 on the 8th for the first time. Then ran again at 7:05 on the 9th, 10th, etc. like it’s supposed to. the date always stays the same but the time counts up. Tomorrow at 7:05 the pump will run, the date will stay the same (feb8th), but the roll up will change to 25.

I’m not sure why it does this because the dashboard on top is the same pump just a different timer and it reports the hourly

Ok. So, its the time label (17:05), that you expect to be different. The rollup logic is implemented in a way that the timestamp for very first entry in an hour will be used to denote the rollup stats for that entire hour.

 

[Ranjib]

@b4n patching reef-pi as we chat, to change doser chart to show daily dosing times. Also fixing temperature chart showing 4 decimal precision instead of two.

https://github.com/reef-pi/reef-pi/pull/732

@pickupman66 changed reef-pi to store stats every hour/day during rollup. In case a hard reboot occurs, everything except current hours stats will be retained. I'll run some field testing soon.

 

[Ranjib]

nevermind, figured it out

Which one? API ?

 

[KevinDodge]

Help me understand the current design of Dosing Pumps? Currently it is controlled via a single PWM pin, and following the guide you have to sort of "hack" in the forward/reverse pins to get the example in the guide working correctly. Under the current setup I can only do 2 dosing pumps using the pi pins. If I need more then I will have to duplicate what is shown in the lighting setup, which seems like a lot of work.

Is there some inherent advantages to using PWM for dosing pumps? Is there a reason why the forward / reverse equipment objects were not incorporated directly into dosing pump object? Would I be overstepping my bounds to suggest some redesign for dosing pumps?

I currently have plans to use 5-6 pumps for metered dosing (Calcium, Alkalinity, Magnesium, Auto Water Changes, Autofeeder of liquid food) and wish there was an easier way. I could potentially use equipment and timer together to get this functionality, but in doing so I lose the functionality I want from dosing pumps (such as calibration and reporting). In addition I found a bug in "timer"/"equipment" where if the pi dies during a timed run of equipment then when the pi reboots that equipment is enabled at start up and runs for a significant period of time before being turned off.

Hopefully my comments are seen as constructive and not criticism. I really appreciate what has been done so far.

 

[pickupman66]

@Ranjib Now that I have it back up I have an error in Reef-pi. I am sure i missed something

 

[Bigtrout]

@Ranjib Now that I have it back up I have an error in Reef-pi. I am sure i missed something

With all the re-install/repairs done on raspian that @Tom Bishop had you do, you probably have to go in to raspi-config and enable i2c again

 

[Ranjib]

With all the re-install/repairs done on raspian that @Tom Bishop had you do, you probably have to go in to raspi-config and enable i2c again

ditto .. user raspi-config to enable i2c and reload reef-pi

 

[bishoptf]

With all the re-install/repairs done on raspian that @Tom Bishop had you do, you probably have to go in to raspi-config and enable i2c again

Yeah I mentioned that last night but we had lots going on so I think it just got overlooked. I plan to write up a short backup and recovery doc that should help with this in the future.

 

[Ranjib]

Help me understand the current design of Dosing Pumps? Currently it is controlled via a single PWM pin, and following the guide you have to sort of "hack" in the forward/reverse pins to get the example in the guide working correctly. Under the current setup I can only do 2 dosing pumps using the pi pins. If I need more then I will have to duplicate what is shown in the lighting setup, which seems like a lot of work.

Is there some inherent advantages to using PWM for dosing pumps? Is there a reason why the forward / reverse equipment objects were not incorporated directly into dosing pump object? Would I be overstepping my bounds to suggest some redesign for dosing pumps?

I currently have plans to use 5-6 pumps for metered dosing (Calcium, Alkalinity, Magnesium, Auto Water Changes, Autofeeder of liquid food) and wish there was an easier way. I could potentially use equipment and timer together to get this functionality, but in doing so I lose the functionality I want from dosing pumps (such as calibration and reporting). In addition I found a bug in "timer"/"equipment" where if the pi dies during a timed run of equipment then when the pi reboots that equipment is enabled at start up and runs for a significant period of time before being turned off.

Hopefully my comments are seen as constructive and not criticism. I really appreciate what has been done so far.

Feedbacks like these are most welcome. Theres no bad word or disrespectful elements in it, and thats all we worry about. Calling out Glitches and possible improvements are always a good thing and useful for other members , thank you for sharing your feedback.

The pwm feature in dosing pump allows us to control the speed of dosing pumps. Currently we recommend (the guide) dc peristaltic pumps, but we'll move to stepper motors at some point, which requires pwm as well. Hence its written with pwm support in mind. If you are using something that does not require pwm (for example BRS dosing pump) then just a normal timer should do the job.
The forward/reverse thing is bit hacky as it possible due to the l293d chip we have used in the guide. Now, though this is handy, its not a common feature across all dosing system. Which means enforcing this feature in doser module will make it hard for many other dosing system to work with reef-pi. It is possible to just alter the l293d circuit and have jumpers to change direction (and user have to change them physically to alter direction), and keep the software simple, without direction control .
You will need the pca9685 IC (light controller) for more than two pwm channels, its bit complicated than the dosing guide but should not be very different. Again, if you dont need pwm/speed control just use the timer feature. On this note, we are allowing sub-second durations in timers in next version of reef-pi.

 

[Ranjib]

Regarding the behavior of Pi during abrupt shutdown, its bit more complicated problem. I have some ideas, but we are far from addressing this problem in a sound way. If you have any suggestions, I am definitely interested in them.
The doser module was introduced in 2.0, as new feature, expect us to use all these feedback to make it better in next few versions. We didnt really had any opportunity to do a lot of field testing before that.
I'll remember the timer graph issue. I think you have a valid point there, it should not be very hard to have a doser like charting feature. I am thinking how to implement this, as unlike doser timers can be very often (once every two second) or very rare (once every month) which makes the charts less useful.

 

[Ranjib]

Help me understand the current design of Dosing Pumps? Currently it is controlled via a single PWM pin, and following the guide you have to sort of "hack" in the forward/reverse pins to get the example in the guide working correctly. Under the current setup I can only do 2 dosing pumps using the pi pins. If I need more then I will have to duplicate what is shown in the lighting setup, which seems like a lot of work.

Is there some inherent advantages to using PWM for dosing pumps? Is there a reason why the forward / reverse equipment objects were not incorporated directly into dosing pump object? Would I be overstepping my bounds to suggest some redesign for dosing pumps?

I currently have plans to use 5-6 pumps for metered dosing (Calcium, Alkalinity, Magnesium, Auto Water Changes, Autofeeder of liquid food) and wish there was an easier way. I could potentially use equipment and timer together to get this functionality, but in doing so I lose the functionality I want from dosing pumps (such as calibration and reporting). In addition I found a bug in "timer"/"equipment" where if the pi dies during a timed run of equipment then when the pi reboots that equipment is enabled at start up and runs for a significant period of time before being turned off.

Hopefully my comments are seen as constructive and not criticism. I really appreciate what has been done so far.

Welcome to reef2reef, you'll love it here .

 

[pickupman66]

Thanks I thought I enabled it but may have missed it. I have pushed it on now. Thus far it seems to be much happier.

 

[daveCB]

At the moment v3 is more than an enhancement of the current project. You can see here some features:
https://github.com/reef-pi/reef-pi/projects
Multilingual will be a feature i'll implement, i've made the Proof Of Concept but have to finish the implementation.
Also with @Michael Lane we've talked about some programming features we wanted to put in it.

The question to have an mobile app too is still a concern, i have some ideas to not be tied to cloud implementation. Have to discuss with the team.

If you have some ideas about features and so on, feel free to create an issue on the project: https://github.com/reef-pi/reef-pi/issues

Do you want us to enter suggestions on that tab or just issues? Suggestions may just clog up the tab.

 

[daveCB]

Yeah I mentioned that last night but we had lots going on so I think it just got overlooked. I plan to write up a short backup and recovery doc that should help with this in the future.

Tom - A backup routine (or even better an auto scheduled event) would be great. I am still confused on what and how to back up my configuration.

 

[bishoptf]

Tom - A backup routine (or even better an auto scheduled event) would be great. I am still confused on what and how to back up my configuration.

We know about the database I just need to look at the other important bits and see what we need to grab, should have something in the next couple of days....

 

[stefanm]

Help me understand the current design of Dosing Pumps? Currently it is controlled via a single PWM pin, and following the guide you have to sort of "hack" in the forward/reverse pins to get the example in the guide working correctly. Under the current setup I can only do 2 dosing pumps using the pi pins. If I need more then I will have to duplicate what is shown in the lighting setup, which seems like a lot of work.

Is there some inherent advantages to using PWM for dosing pumps? Is there a reason why the forward / reverse equipment objects were not incorporated directly into dosing pump object? Would I be overstepping my bounds to suggest some redesign for dosing pumps?

I currently have plans to use 5-6 pumps for metered dosing (Calcium, Alkalinity, Magnesium, Auto Water Changes, Autofeeder of liquid food) and wish there was an easier way. I could potentially use equipment and timer together to get this functionality, but in doing so I lose the functionality I want from dosing pumps (such as calibration and reporting). In addition I found a bug in "timer"/"equipment" where if the pi dies during a timed run of equipment then when the pi reboots that equipment is enabled at start up and runs for a significant period of time before being turned off.

Hopefully my comments are seen as constructive and not criticism. I really appreciate what has been done so far.

The pwm is also useful for peristaltic pumps, especially for nano tanks where more precise dosing maybe required, I've hooked up a PCA 9685 and a pair of l293d modules, from this I can run 16 dosers if needed with high precision, I don't think any DIY or commercial unit can do that.

The cheap l293d modules I think are the way to go, less cost and less effort than building a proto board.

Reef pi is definitely the easiest and most flexible DIY controller that you can build and the best part is it's constant evolution, a big thanks to @Ranjib

 

[daveCB]

Not that I know of. I am using the DJ power bar.

Over my last 25 years of having my Reef tank (or tanks), literally everything has failed a minimum of once over time. Some items like heaters and pumps have failed many more than one time. ATO floats have failed. I even had a tank fail once (which ensued in a flood). When you add yet another layer and introduce automation to a tank, you expect that its going to fail at some point.

My belt and suspenders system is like this;

1. My Reef-Pi sends me an email twice per day to just say Hi. I have this setup in the scheduler. That way I know things are running.
2. The most critical item in any tank is temperature. For this reason, I have a backup heater and stand alone thermostat with sensor in the tank. It is set to 75 Degrees. Tank is set to 78 and typically swings -1 to +.5, so in theory, the back up heater never comes on. (this did save my butt last year when my home heating plant went down; Two heaters were enough to keep the tank warm).
3. I have a full home automaton system. Via the API, my system pings the Reef-Pi every half hour. If it gets no response, Both my wife and I get a text and the home automation panels come up with an alert.

So like I said above, the more you add, the higher risk of failure. As good as Reef-Pi is, you are still relying on software and a home built system on a project board. Until this becomes embedded software on a physical circuit board, failures will happen and at a higher level.

I would encourage everyone to do a risk analysis and add in safety features like I have done. And look at the bright side - You never really knew what was going on with your tank when not at home. Reef-Pi has brought the view of your tank to your cell phone 24/7. That is a huge jump from where we all were prior.

 

[Ranjib]

Do you want us to enter suggestions on that tab or just issues? Suggestions may just clog up the tab.

I think it’s ok to submit suggestions as issues , we (the dev team) can triage them weekly and remove duplicates, bucket them etc. thoughts @Zekth ?

 

[theatrus]

I think it’s ok to submit suggestions as issues , we (the dev team) can triage them weekly and remove duplicates, bucket them etc. thoughts @Zekth ?

Issues are the way to go [emoji106]