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

[theatrus]

I've been incredibly backlogged with projects, but hammered out the electrical part of a replacement setup for DS18B20 chips to mount into probes. Not going the route of the classic TO-92 since hand soldering those would eat up so much time, and instead using the smaller SOP package + wire pads. I promise to get new Pico boards up soon... but maybe this is a good consolation prize?

Assuming no one freaks out at V-scores at 0.26in pitch, which is the width of each breakout board in the panel.

 

[Yov]

@Ranjib Is there or wil there be a way to calibrate the SHT31D ? i found out mine is off... and well i can only use the PH calibration methode and this is kind of hard to do with a moisture sensor ....

 

[Ranjib]

I'm always amazed at this. I battled and tried all sorts of things for days, and had no success. But as soon as I write a message here, the feed starts working.

Sorry for the disruption!

:hugs:

 

[Ranjib]

@Ranjib Is there or wil there be a way to calibrate the SHT31D ? i found out mine is off... and well i can only use the PH calibration methode and this is kind of hard to do with a moisture sensor ....

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

 

[Ranjib]

I've been incredibly backlogged with projects, but hammered out the electrical part of a replacement setup for DS18B20 chips to mount into probes. Not going the route of the classic TO-92 since hand soldering those would eat up so much time, and instead using the smaller SOP package + wire pads. I promise to get new Pico boards up soon... but maybe this is a good consolation prize?

Assuming no one freaks out at V-scores at 0.26in pitch, which is the width of each breakout board in the panel.

Groovy

 

[Ranjib]

Awesome! My experience it was a gnarly fail too, it keeps trying so it really pummels the whole thing. If you can't reproduce I will set it up again and send my log.

Quick sanity check, is the HS-100 smart plug appropriate for use with reef pi?

Thanks!

Im not sure. I think so. I have tested with 103, and 110. 100 looks very similar

 

[Ranjib]

Can someone give me an explanation for the ATO settings, Disable on Alert and then Alert after...I think I knew what they meant but it's not working as I expected. I wanted an Alert to be sent if the pump goes longer than a set time that I set.

Thanks

Which version you are using? there was a bug which made this functionality work only for the first hour. I fixed it in the latest release. Please share this he details (reef-pi version and to settings) if you think there's a bug. I'll chase it down.

 

[bishoptf]

Which version you are using? there was a bug which made this functionality work only for the first hour. I fixed it in the latest release. Please share this he details (reef-pi version and to settings) if you think there's a bug. I'll chase it down.

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...

 

[ChrisNH]

Running 3.3.1

FWIW it has worked for me in 3.4. I rely on it for my empty reservoir alert as well as my ato fill. It already saved me once when I had knocked the ATO hose out while arranging the rats nest I call "wiring" around my sump.

 

[ChrisNH]

Im not sure. I think so. I have tested with 103, and 110. 100 looks very similar

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!

 

[bishoptf]

FWIW it has worked for me in 3.4. I rely on it for my empty reservoir alert as well as my ato fill. It already saved me once when I had knocked the ATO hose out while arranging the rats nest I call "wiring" around my sump.

I was running 3.4 but was getting temp error messages, so I rolled back to 3.3.1. Thanks for confirming how I thought it was supposed to work, I actually have an additional float in my ATO container that will light an LED for me when the level in the container is starting to get low, but would be nice to have an additional notification if it runs longer than I expect and to have it disabled when it happens.

 

[ChrisNH]

I was running 3.4 but was getting temp error messages

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.

 

[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.