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

[Yov]

Can you elaborate a bit? 1 or 2 point calibration , same as pH will not solve it?

1 point would be nice. then i can test it with a second humidity meter. 2 point (like PH) is kind of hard to do with this kind of sensor. Humidity normaly is very stable. And i cant just dip it in water or dry it of :)

 

[Yov]

I have been getting those. I assumed it was a problem with the jacks used to plug in the thermal sensors. I was going to replace them in a few weeks With just connectors.. one sensor it was constant and I removed, one it is once or twice a day so I ignore. Never thought it would be a 3.4 thing.

it's a 3.4 thing :)

 

[mr.salty]

Hi everyone. So I seem to think I have an issue with my reef pi. The clock at the bottom of the dashboard never says the correct time?

I have included some pictures as my temperature controller that I have configured to run with my tank temp probe is getting turned off even though I have set the temp to 26c with a 2c hysterisis. The tank temp is 26.5 and its turning it off?

Also have these errors but I think that's due to not having a graph uploaded on the dashboard after a restart.

Another issue is that my temp probes periodically go down to like -1300C for a split second?

Sorry for all the questions but hopefully this is where I can get the answers.

 

[Kerinin]

I've been working on adding support for stepper motors, and I'm interested in some feedback on the best way to move forward with changes to the reef-pi codebase.

My basic approach is to use an arduino to produce step/dir signals for a stepper driver, and to use the Firmata protocol to communicate between the rpi and the arduino. Firmata is a serial protocol designed to allow a computer (in our case the rpi) to control an arduino; it provides messages for things like setting & reading digital pins. I'm using an extension to firmata that adds messages for interacting the the AccelStepper library. This library provides configuration options for step/dir controls and provides a acceleration and deceleration when the stepper is starting or approaching a setpoint.

I've adapted some existing go Firmata libraries to provide the necessary command interface for the AccelStepper messages: https://github.com/kerinin/gomata. I'm now looking at how best to integrate with the existing reef-pi code organization.

Steppers require fundamentally different control configuration that a simple time & speed based pump: multiple pins need to be configured, the path of the arduino's serial port needs to defined, a firmata "device ID" needs to be specified, etc. The existing "dosing" code is configured using a "jack", a "pin" and a dosing duration. I have a branch that attempts to use the doser resource in either case by proving configurations for both types of pump:

type Pump struct {
    ID                 string              `json:"id"`
    Name               string              `json:"name"`
    TimeConfig         *TimeConfig         `json:"time"`
    FirmataStepsConfig *FirmataStepsConfig `json:"firmataSteps"`
    Regiment           DosingRegiment      `json:"regiment"`
}

type TimeConfig struct {
    Jack  string  `json:"jack"`
    Pin   int     `json:"pin"`
    Speed float64 `json:"speed"`
}

type FirmataStepsConfig struct {
    Firmata      string  `json:"firmata"`
    DeviceID     int     `json:"deviceID"`
    WireCount    byte    `json:"wireCount"`
    StepType     byte    `json:"stepType"`
    HasEnable    byte    `json:"hasEnable"`
    Pin1         int     `json:"pin1"`
    Pin2         int     `json:"pin2"`
    Pin3         int     `json:"pin3"`
    Pin4         int     `json:"pin4"`
    EnablePin    int     `json:"enablePin"`
    Invert       int     `json:"invert"`
    Speed        float32 `json:"speed"`
    Acceleration float32 `json:"acceleration"`
}

This solution re-uses a decent amount of code, the difference between the two implementations mostly boils down to a switch in the runner's dose function:

func (r *Runner) Dose(volume float64) error {
    if cfg := r.pump.TimeConfig; cfg != nil {
        var duration = volume / cfg.Speed
        return r.timeDose(cfg, duration)
    }

    if cfg := r.pump.FirmataStepsConfig; cfg != nil {
        return r.stepDose(cfg, int32(volume))
    }

    return fmt.Errorf("ERROR: dosing sub-system. Unconfigured pump")
}

func (r *Runner) timeDose(cfg *TimeConfig, duration float64) error {
    //...
}

func (r *Runner) stepDose(cfg *FirmataStepsConfig, steps int32) error {
    //...
}

I've just started looking at how this change would affect the UI - I think the doser configuration would need some type of modal, maybe with a "doser type" radio button to switch between stepper and timer config.

Another solution would be to introduce a new "doser" implementation, like "stepper-doser". This would cause some code duplication, and creating a new top-level resource to work around implementation details of different physical pumps seems non-ideal. The benefit of this approach is that it would be less likely to cause migration problems for existing users.

So I'm interested in feedback on the general approach - does this seem like the right way to go? What type of forwards-compatibility guarantees are expected - if this introduces breaking changes to the doser data schema is that a problem?

This is the branch I'm working on fwiw (no guarantees this link will remain usable for long): https://github.com/kerinin/reef-pi/compare/master...kerinin:rm/stepper2

 

[Michael Lane]

Hi everyone. So I seem to think I have an issue with my reef pi. The clock at the bottom of the dashboard never says the correct time?

I have included some pictures as my temperature controller that I have configured to run with my tank temp probe is getting turned off even though I have set the temp to 26c with a 2c hysterisis. The tank temp is 26.5 and its turning it off?

Also have these errors but I think that's due to not having a graph uploaded on the dashboard after a restart.

Another issue is that my temp probes periodically go down to like -1300C for a split second?

Sorry for all the questions but hopefully this is where I can get the answers.

The time is based on the rpi system time. The most likely reason for it to be incorrect would be a bad time zone setting. This guide has some short instructions to fix that.

The hysteresis question makes sense, and I agree that the behavior you describe is confusing. I read through the source code for that function, but it's not making sense to me this morning. Ranjib probably has a better understanding of it, so he may chime in. The following command might provide some details from the log.
sudo journalctl -u reef-pi.service --since=today | grep "Current value"

I believe your assumption about the errors is correct. It is probably from a graph trying to display information for a sensor that does not have any data logged.

The problem with the temperature dropping to -1300 is often reported. It's often been linked to bad wiring or connectors, but I don't think that's always the case. I was planning to work on some temperature sensor code coming up, so I'll consider adding rejection for these kinds of readings.

 

[Michael Lane]

I've been working on adding support for stepper motors, and I'm interested in some feedback on the best way to move forward with changes to the reef-pi codebase.

My basic approach is to use an arduino to produce step/dir signals for a stepper driver, and to use the Firmata protocol to communicate between the rpi and the arduino. Firmata is a serial protocol designed to allow a computer (in our case the rpi) to control an arduino; it provides messages for things like setting & reading digital pins. I'm using an extension to firmata that adds messages for interacting the the AccelStepper library. This library provides configuration options for step/dir controls and provides a acceleration and deceleration when the stepper is starting or approaching a setpoint.

I've adapted some existing go Firmata libraries to provide the necessary command interface for the AccelStepper messages: https://github.com/kerinin/gomata. I'm now looking at how best to integrate with the existing reef-pi code organization.

Steppers require fundamentally different control configuration that a simple time & speed based pump: multiple pins need to be configured, the path of the arduino's serial port needs to defined, a firmata "device ID" needs to be specified, etc. The existing "dosing" code is configured using a "jack", a "pin" and a dosing duration. I have a branch that attempts to use the doser resource in either case by proving configurations for both types of pump:

type Pump struct {
    ID                 string              `json:"id"`
    Name               string              `json:"name"`
    TimeConfig         *TimeConfig         `json:"time"`
    FirmataStepsConfig *FirmataStepsConfig `json:"firmataSteps"`
    Regiment           DosingRegiment      `json:"regiment"`
}

type TimeConfig struct {
    Jack  string  `json:"jack"`
    Pin   int     `json:"pin"`
    Speed float64 `json:"speed"`
}

type FirmataStepsConfig struct {
    Firmata      string  `json:"firmata"`
    DeviceID     int     `json:"deviceID"`
    WireCount    byte    `json:"wireCount"`
    StepType     byte    `json:"stepType"`
    HasEnable    byte    `json:"hasEnable"`
    Pin1         int     `json:"pin1"`
    Pin2         int     `json:"pin2"`
    Pin3         int     `json:"pin3"`
    Pin4         int     `json:"pin4"`
    EnablePin    int     `json:"enablePin"`
    Invert       int     `json:"invert"`
    Speed        float32 `json:"speed"`
    Acceleration float32 `json:"acceleration"`
}

This solution re-uses a decent amount of code, the difference between the two implementations mostly boils down to a switch in the runner's dose function:

func (r *Runner) Dose(volume float64) error {
    if cfg := r.pump.TimeConfig; cfg != nil {
        var duration = volume / cfg.Speed
        return r.timeDose(cfg, duration)
    }

    if cfg := r.pump.FirmataStepsConfig; cfg != nil {
        return r.stepDose(cfg, int32(volume))
    }

    return fmt.Errorf("ERROR: dosing sub-system. Unconfigured pump")
}

func (r *Runner) timeDose(cfg *TimeConfig, duration float64) error {
    //...
}

func (r *Runner) stepDose(cfg *FirmataStepsConfig, steps int32) error {
    //...
}

I've just started looking at how this change would affect the UI - I think the doser configuration would need some type of modal, maybe with a "doser type" radio button to switch between stepper and timer config.

Another solution would be to introduce a new "doser" implementation, like "stepper-doser". This would cause some code duplication, and creating a new top-level resource to work around implementation details of different physical pumps seems non-ideal. The benefit of this approach is that it would be less likely to cause migration problems for existing users.

So I'm interested in feedback on the general approach - does this seem like the right way to go? What type of forwards-compatibility guarantees are expected - if this introduces breaking changes to the doser data schema is that a problem?

This is the branch I'm working on fwiw (no guarantees this link will remain usable for long): https://github.com/kerinin/reef-pi/compare/master...kerinin:rm/stepper2

I've never used Firmata, so my assumptions could definitely be off. This is also more of a brainstorm/train of thought response.

Your code looks understandable and quite readable (plus I appreciate keeping the swagger doc updated). I'm also curious what the hardware looks like and if it's something that can be easily recreated by others.

My first thought is that the firmata set up should be moved to a driver in order to remove the pins details from the doser. Although, I'm not sure if that totally makes sense since firmata is more like a bus (I think). Or maybe it makes more sense to create a doser connector that uses Firmata. Then the connector is where the FirmataStepsConfig would be set up.

I would rather not create a new top level component. I think we could add a field to the doser UI where you choose which kind of pump to use (which changes the rest of the fields) - similar to Timers with the function field.

There's a lot to consider here, and I'm sure Ranjib will have opinions too.

 

[mr.salty]

The time is based on the rpi system time. The most likely reason for it to be incorrect would be a bad time zone setting. This guide has some short instructions to fix that.

The hysteresis question makes sense, and I agree that the behavior you describe is confusing. I read through the source code for that function, but it's not making sense to me this morning. Ranjib probably has a better understanding of it, so he may chime in. The following command might provide some details from the log.
sudo journalctl -u reef-pi.service --since=today | grep "Current value"

I believe your assumption about the errors is correct. It is probably from a graph trying to display information for a sensor that does not have any data logged.

The problem with the temperature dropping to -1300 is often reported. It's often been linked to bad wiring or connectors, but I don't think that's always the case. I was planning to work on some temperature sensor code coming up, so I'll consider adding rejection for these kinds of readings.

Thanks very much and yes let's see if ranjib can help out.

The issue with the time is that it is not advancing at the same rate as the clock. It will lag and then catch up and lag again for a while or stick for half an hour and then jump to the time?

I did think it would be a wiring issue with the temp probes I'll take a look at that.

And yes I got the historic graph for temp back on the dashboard and the errors went away.

Thanks!

 

[Ranjib]

I will give it a try and report back. They were not expensive and look to be pretty flexible. Worst case I use them for some other project.

btw - my son got a big thrill today turning the aquarium lights on and off with the reef-pi from a browser. Its like magic!

I can relate to that :-) , I felt same 4 years back.

 

[Ranjib]

Running 3.3.1, it may be just my understanding of how its supposed to work, my top off is pretty consistent, say 25sec every time it tops off. What I wanted and what I thought those options would do for me is to send an alert when usage was above my normal usage and if you wanted to disable it when it alerted you could enable that also. Since mine is pretty consistent I wanted it to disable and alert if it went say, 40 sec as opposed to the normal 25sec.

Hope that makes sense, right now I have it set but it ran longer and did not send an alert or disable the ATO function. Its not as critical since I use a fallback float but would be nice to at least get an alert if it runs longer than I think it should...

:)

Something to note is that, the Alert threshold is checked against how long the ato pump is run (should be always in multiples of check interval) and not after how long the pump is run. It is intended to avoid overrun, and not under-run. You can see my settings here:

Does that answer your question?

 

[Des Westcott]

Running 3.3.1, it may be just my understanding of how its supposed to work, my top off is pretty consistent, say 25sec every time it tops off. What I wanted and what I thought those options would do for me is to send an alert when usage was above my normal usage and if you wanted to disable it when it alerted you could enable that also. Since mine is pretty consistent I wanted it to disable and alert if it went say, 40 sec as opposed to the normal 25sec.

Hope that makes sense, right now I have it set but it ran longer and did not send an alert or disable the ATO function. Its not as critical since I use a fallback float but would be nice to at least get an alert if it runs longer than I think it should...

:)

Just re-reading your post in @Ranjib reply I realised something - You are referring to the time your ATO comes on EVERY TIME IT TRIGGERS - Reef-pi only works on total pump usage per hour. So if your ATO comes on for 25 seconds when it does run, but triggers, say, on average 4 times an hour, you need to set your alert at a number larger than 100 seconds.

If I'm reading your issue correctly. I've been wrong before.

 

[Des Westcott]

Something to note is that, the Alert threshold is checked against how long the ato pump is run (should be always in multiples of check interval) and not after how long the pump is run. It is intended to avoid overrun, and not under-run. You can see my settings here:

Does that answer your question?

I'm so glad to see other people's ATO usages have the gaps and spikes like mine :) I get the occasional spike where I forget to top up reservoir and the gap typically where I add add stuff, - livestock, food, do maintenance

 

[Schreiber]

I'm so glad to see other people's ATO usages have the gaps and spikes like mine :) I get the occasional spike where I forget to top up reservoir and the gap typically where I add add stuff, - livestock, food, do maintenance

Mine directly corresponds with whenever I do my water changes. Apparently, my 5 gallon containers aren't quite 5 gallons, lol.

 

[mkane]

Just starting out with part 1. Curious before I go down the rabbit hole, did anyone port this to an app or is this strictly a webview (browser) experience?

 

[ChrisNH]

So I have a 10 sec interval and set my alert to 32 think it it would catch it when it starts a 4th interval. I want to allow 3 pumps, not 4.

does It do the last interval (so 40 seconds) before alerting and shutting off When I set at 32? Should I set it for 40?

if I set it for 30 will it trigger at the end of the third (not desired) or when it attempts to start the 4th?

Corner case: does it reset the count if a fill spans an hour?

 

[Schreiber]

Just starting out with part 1. Curious before I go down the rabbit hole, did anyone port this to an app or is this strictly a webview (browser) experience?

I do not believe anyone has ported it to an app, though I'd love to be proven wrong!

 

[Ranjib]

Just starting out with part 1. Curious before I go down the rabbit hole, did anyone port this to an app or is this strictly a webview (browser) experience?

Only web view :-/

 

[mkane]

Only web view :-/

Sounds like a side project to me!

 

[bishoptf]

Something to note is that, the Alert threshold is checked against how long the ato pump is run (should be always in multiples of check interval) and not after how long the pump is run. It is intended to avoid overrun, and not under-run. You can see my settings here:

Does that answer your question?

Just re-reading your post in @Ranjib reply I realised something - You are referring to the time your ATO comes on EVERY TIME IT TRIGGERS - Reef-pi only works on total pump usage per hour. So if your ATO comes on for 25 seconds when it does run, but triggers, say, on average 4 times an hour, you need to set your alert at a number larger than 100 seconds.

If I'm reading your issue correctly. I've been wrong before.

I have a better understanding now, mine appears to run once every 4 hours or so, is there an easy way to see average run intervals, trying to do that via the graph is not the best. I assume you can do it from the cli going through the journal. So if your only running once per hour and it runs say 20 secs, you should be able to set your 40secs? My goal like @Ranjib stated would be to avoid an overrun, even though I have 2 floats another safety would be nice.

:)

 

[5ft24]

Also I don’t see how this could be a percentage on the CPU because it regularly goes over 1.0, it’s at 1.6 at one point.

with a quad core CPU, CPU usage can go to 4.0

 

[ChrisNH]

with a quad core CPU, CPU usage can go to 4.0

What is the value given for memory?