Can reef-pi be PH controller?

[genericfishname]

I have my tank up and running with just basic timers. I am building out my reef-pi setup to automate things for the next phase. I know that I can monitor PH with reef-pi but, can it be programed to open and close a valve (or valves) on the CO2 reactor that i plan to connect to my skimmer?

 

[Sral]

In the pH tab you can set certain actions very similar to temperature:

I think those work exactly like the "Heater" and "Cooler" Options in the "Temperature" tab, e.g. while pH is too high, the Lowering mechanism runs constantly until pH is below the upper threshold-hysteresis.

In your case, this can be an AC socket that controls the valve on the CO2, opening that will introduce CO2, lowering the pH (hopefully slowly )

 

[genericfishname]

In the pH tab you can set certain actions very similar to temperature:

I think those work exactly like the "Heater" and "Cooler" Options in the "Temperature" tab, e.g. while pH is too high, the Lowering mechanism runs constantly until pH is below the upper threshold-hysteresis.

In your case, this can be an AC socket that controls the valve on the CO2, opening that will introduce CO2, lowering the pH (hopefully slowly )

Awesome Thanks!

 

[Sral]

Awesome Thanks!

BTW, if you are thinking about a safety measure and haven’t thought about this, you can also set up an air bubbler on an AC socket as a raising mechanism. That way, if you ever get too much CO2 inside the tank, the Pi can use these air bubbles to try and extract at least some of the overdosed CO2.

 

[Ranjib]

yes it can. I use the ph tab to actually control a heater, with sensor (ds18b20) wired to an esp32 module. It works, similar to the temperature module. Underneath they both uses the same library and in future i want to combine those two into a single tab (since they are redundant from code side)

 

[Devin_Tesla]

I do this works well. Only problem I've had is at the moment my ph probe goes to 0.16 foe a sec that turns off the co and turns on the air stone till next scan then it goes back to normal

 

[Sral]

I do this works well. Only problem I've had is at the moment my ph probe goes to 0.16 foe a sec that turns off the co and turns on the air stone till next scan then it goes back to normal

Out of interest: what kind of pH probe are you using ?

@Ranjib I think this shows more and more that the sensor handling needs some kind of error-mode detection that sends a notification and either disregards the sensor or at least disables all associated control loops. Specifically for pH and temperature, with a pH being 0 or outside a user-defined area, or the temperature sensors being 0 or outside a user defined area.

 

[Devin_Tesla]

Out of interest: what kind of pH probe are you using?

https://www.amazon.ca/gp/aw/d/B07KG2PQMN?psc=1&ref=ppx_pop_mob_b_asin_title

I have 2 as I change it to see if that was a problem but it's been in the tank for 5 years.

 

[Sral]

https://www.amazon.ca/gp/aw/d/B07KG2PQMN?psc=1&ref=ppx_pop_mob_b_asin_title

I have 2 as I change it to see if that was a problem but it's been in the tank for 5 years.

Sry, I actually meant to ask what pH circuit you are using to read the probe.

 

[Ranjib]

I do this works well. Only problem I've had is at the moment my ph probe goes to 0.16 foe a sec that turns off the co and turns on the air stone till next scan then it goes back to normal

i want to introduce some safety mechanism to deal with this. This is a common issue for me as well, specially with esp32 based sensors .

 

[Ranjib]

Out of interest: what kind of pH probe are you using ?

@Ranjib I think this shows more and more that the sensor handling needs some kind of error-mode detection that sends a notification and either disregards the sensor or at least disables all associated control loops. Specifically for pH and temperature, with a pH being 0 or outside a user-defined area, or the temperature sensors being 0 or outside a user defined area.

Yes, I’m leaning towards disregarding values if it’s below certain threshold .

 

[jbmia]

What about a user defined time delay? The spikes I've seen are very brief... waiting to see a consistent low or high reading would avoid false alarms...

 

[Sral]

What about a user defined time delay? The spikes I've seen are very brief... waiting to see a consistent low or high reading would avoid false alarms...

Not sure if that can be programmed nicely while avoiding other problems. What for example if your signal has a slope that‘s just fast enough to not count as „consistent“ ? That would be disregarded as well until it slows down and suddenly your pH jumps because everything in between was not regarded as „consistent“.

A more stable method might be a median value filter, a low-Pass filter or a running average filter. That‘s however more like filtering, so should be treated separately.

 

[jbmia]

Perhaps consistent is the wrong word. Could just be a simple time delay… if out of defined range for x counts/sec/min, then trigger an out of range condition. This would avoid momentary anomalies and the inadvertent triggering of lowering / raising mechanisms.

 

[jbmia]

To add to my last post, as a point of reference, it appears Apex has the Defer function, Defer [DURATION] Then [ON/OFF] which seems to be their solution to the issue.

Here’s a related example:

Scenario: I've got a float that bounces up and down in my turbulent sump. I want to smooth that out so it's not turning my ATO on/off all the time. Solution: Add a Defer to your ATO outlet program of a minute. That will eliminate the little bounces and only turn your outlet ON or OFF after it's been in that state for a full minute.​

On a related note, I just started using reef-pi recently, but my recommendation based on similar use cases would be to add conditionals to the macro function where the ‘wait’ function can be used… Here’s a simple example:

• If pH > X, then… (test)
  • “Wait” 15 seconds
  • If pH > X, then…(retest)
    • Lowering mechanism
  • Else
    • End
• Else
  • End

You could then put that macro on a timer.

Similar discussion here: https://www.reef2reef.com/threads/if-then-else.956158/

jb

 

[Sral]

Perhaps consistent is the wrong word. Could just be a simple time delay… if out of defined range for x counts/sec/min, then trigger an out of range condition. This would avoid momentary anomalies and the inadvertent triggering of lowering / raising mechanisms.

It would definitely solve the problem, I’m however not convinced that this is a good solution as it adds unnecessary complexity and possibility for failure.

If one has to define a value range anyway additionally to the delay, why not disregard every value outside of a defined range to begin with ?

It’s also unnecessarily complex for the average user, since the appropriate range would have to be adjusted to the delay. Consider a very short delay with a range that’s too small. This would lead the system to disregard fast slopes indefinitely, possibly crashing the tank.
Additionally it would create lag in the control loop that isn’t desirable in all cases.

I believe this complexity comes from convoluting two different processes: disregarding erroneous values and filtering in one. I would therefore suggest to split this into two features:
- an error mode that disregards values outside of a defined range outright
- a filter that filters values with a time constant proportional to the measurement rate, e.g. typically:
- median value
- average value (analog signals only)
For 5 consecutive values, for example.

The error mode would work well for pH and temperature, while especially the median value filter would work for your ATO problem.

 

[jbmia]

If one has to define a value range anyway additionally to the delay, why not disregard every value outside of a defined range to begin with ?

Because, at least for me, it's just those momentary, apparently anomalous readings that are the issue.. Today, these values in the circles would trigger a raising mechanism when they really, in this example and in my opinion, should not.

It’s also unnecessarily complex for the average user, since the appropriate range would have to be adjusted to the delay. Consider a very short delay with a range that’s too small. This would lead the system to disregard fast slopes indefinitely, possibly crashing the tank.

I disagree on the average user finding a delay feature too complex. Go look at the Apex programming manual on page 55... https://www.neptunesystems.com/downloads/docs/Comprehensive_Reference_Manual.pdf

Again, I'll wager that given the choice between Apex and Reef-Pi, the less technical user would always go to Apex and look what they're doing with programming logic. Adding some conditional's and a delay fucntion to macro's is too technical? Not buying it. When most folks running reef-pi had to go build the circuits to begin with?? Again, not buying it. Happy to agree to disagree though.

With regard to the short delay and too small range crashing the tank, then adjust the delay or the range appropriately. Doesn't seem too difficult.

You can crash the tank today by setting the wrong values in the control values of a sub-system and I don't see introducing a simple delay any more complex. e.g., this example below w/ pH.. this range avoids adjustment altogether till the tank has crashed and yet it's there today and my guess is not that many tanks are crashing because of this feature...

Again, the DEFER function is working for Apex.. I wager their users are an order of magnitude less technical than reef-pi users...

I believe this complexity comes from convoluting two different processes: disregarding erroneous values and filtering in one.

Disagree here as well. A time delay would filter out momentary erroneous values and would also put more power in the hands of the user rather than being locked into an average or a median. I could filter in an erroneous value today using the same sub-system control function, in this case pH, so why would a time delay introduce unacceptable risk? See below, upper/lower thresholds...

Now, I don't disagree that average and median values would avoid momentary anomalies.. But what about when you your average is actually an average based on a dataset that is low to begin with and you're actually trying to violate the average on the up side (e.g.., ph is running low and you're trying to raise it)... Seems to me with the average you'd still have to define some bound outside of the average that is still valid... Now the average is starting to sound more complex...

Moving on, I also think adding more power to the macro functions with conditionals would provide a ton more flexibility for users.. We already have the 'wait' function, so that could be used to avoid erroneous readings... And, other than time and resources, why not an average/median option as well...

And, no, I'm not suggesting we just replicate what's in Apex... These logical concepts are pretty much universal.

Not trying to be contentious here, just disagreeing with your suggested approach and offering up some arguments for an alternative.

jb

 

[robsworld78]

I find the best way to stop false triggers is to use a delay as @jbmia is suggesting. Something like this.

If temp is greater than 78.3 for 60 consecutive seconds turn off heater. If it hits 78.3 and stays for a few seconds then drops the timer starts over when it hits 78.3 again and nothing is triggered. The number of seconds would be set by the user. This is great for things like float switches as @jbmia mentioned, no more quick on/offs due to waves. In my opinion this is the safest method.

Of course this won't help charts and averaging would be useful but isn't so easy to program. Personally I wouldn't use an averaged number to control equipment as the average is never correct.

@jbmia if you don't have I would try adding a ground probe, you can test with a simple wire. Attach one end to any common DC ground on your controller and put the other end in the water, this might help with those random dips.

 

[Sral]

Because, at least for me, it's just those momentary, apparently anomalous readings that are the issue.. Today, these values in the circles would trigger a raising mechanism when they really, in this example and in my opinion, should not.

What kind of pH circuit are you using ? Seems like a common problem with those. Have you tried to get rid of those on the hardware side ? Like @robsworld78 mentioned, a grounding probe might be useful. Although you should be careful and probably use a GFCI switch, since a grounding probe can endanger the user as well.

Regarding the complexity:
ReefPI already has a comparatively high entrance barrier, that's exactly why Robo-Tank exists and seems to be thriving. You and I might not think of this as complex, but that doesn't mean that's true for every user.
Apex offering this feature doesn't mean it's easy, that's maybe why they don't offer this as a GUI, but a scripting feature. Scripting doesn't sound like it's for the casual user.

You can crash the tank today by setting the wrong values in the control values of a sub-system and I don't see introducing a simple delay any more complex. e.g., this example below w/ pH.. this range avoids adjustment altogether till the tank has crashed and yet it's there today and my guess is not that many tanks are crashing because of this feature...

Difference there is, that you can directly see why your tank is crashing. A pH of either 10 or 3 is deadly, even the most casual user can likely see that the tank is not in a good shape when the pH starts falling way below target.
However, when a delay feature constantly triggers and disregards values, the user can't see anything, since the old normal value is the only that remains in display until the tank is dead.

Disagree here as well. A time delay would filter out momentary erroneous values and would also put more power in the hands of the user rather than being locked into an average or a median. I could filter in an erroneous value today using the same sub-system control function, in this case pH, so why would a time delay introduce unacceptable risk? See below, upper/lower thresholds...

Not quite sure what you mean there. A time delay would filter out everything that's too quick, even if it is permanent and not just momentary.
I also don't quite see how these settings would filter out erroneous values. Looks more like the opposite: you increase their influence. If you get an erroneous value from 9.0 to below 9, the Raising mechanism turns on until it increased pH to 9.5, same the other way around: if pH is erroneously from 9.9 to above 10, pH will be lowered until it reaches 9.5. That sounds like way too much swing, as I typically read that fish don't like pH swings that are above a few 0.1 pH per day.

Now, I don't disagree that average and median values would avoid momentary anomalies.. But what about when you your average is actually an average based on a dataset that is low to begin with and you're actually trying to violate the average on the up side (e.g.., ph is running low and you're trying to raise it)... Seems to me with the average you'd still have to define some bound outside of the average that is still valid... Now the average is starting to sound more complex...

That's exactly the same problem one gets with a delay function. Both introduce delay by design, but the average can't erroneously disregard values. If one needs earlier shutoff, one can simply decrease hysteresis.

Of course this won't help charts and averaging would be useful but isn't so easy to program. Personally I wouldn't use an averaged number to control equipment as the average is never correct.

I think it's actually pretty easy, the historical data view in the dashboard already uses a moving average if I'm not mistaken. About the correctness: the same can be said about the delay ^^
If you wait for the value to be over 78.3 for 60 seconds, the value rises for those 60 seconds, so the temperature on shutoff is also never correctly 78.3, but above that

Moving on, I also think adding more power to the macro functions with conditionals would provide a ton more flexibility for users.. We already have the 'wait' function, so that could be used to avoid erroneous readings... And, other than time and resources, why not an average/median option as well...

And, no, I'm not suggesting we just replicate what's in Apex... These logical concepts are pretty much universal.

Not trying to be contentious here, just disagreeing with your suggested approach and offering up some arguments for an alternative.

jb

I absolutely agree, the macros are an absolutely necessary feature for a lot of useful things. Although I'm afraid there are more pressing matters than introducing conditionals, since right now they can't even turn things on and off properly without risking to freeze ReefPi sometimes

I don't mind a good discussion, as you might have noticed. Especially since I do kind of need to learn how to approach them calmly and make a coherent point without derailing the conversation

In the end its likely @Ranjib's job to decide which way to go, so it's definietly a good idea if different people lay out their visions, ideas and arguments !

 

[robsworld78]

I think it's actually pretty easy, the historical data view in the dashboard already uses a moving average if I'm not mistaken. About the correctness: the same can be said about the delay ^^
If you wait for the value to be over 78.3 for 60 seconds, the value rises for those 60 seconds, so the temperature on shutoff is also never correctly 78.3, but above that

In theory but what happens if you have lots of bad readings or just simply messing around, the average will be way off and will take time to smoothen out. Your right about the charts being averaged, sometimes I get people wondering why the chart value is different then the raw value going to my point that averaging can lead to inaccurate values.

If the water temp rises .1 or more in 60 seconds the user might have bigger problems. 60 seconds is a little on the high side for a heater, just put it as an example. I use this on something I'm working on and it works great, couldn't be without it.

Here's a nice troubleshooting guide someone sent me the other day, the last page it talks about ground loop issues.

https://sensorex.com/wp-content/uploads/2022/01/pH-Troubleshooting-Guide.pdf