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

theatrus

Valuable Member
View Badges
Joined
Mar 26, 2016
Messages
1,941
Reaction score
3,329
Location
Sacramento, CA area
Rating - 0%
0   0   0
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.


1596092194202.png
 

Yov

Community Member
View Badges
Joined
May 24, 2020
Messages
51
Reaction score
44
Rating - 0%
0   0   0
@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 :p....
 
OP
OP
Ranjib

Ranjib

7500 Club Member
View Badges
Joined
Apr 16, 2016
Messages
9,825
Reaction score
17,041
Location
Pleasant Hill, Concord
Rating - 0%
0   0   0
@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 :p....
Can you elaborate a bit? 1 or 2 point calibration , same as pH will not solve it?
 
OP
OP
Ranjib

Ranjib

7500 Club Member
View Badges
Joined
Apr 16, 2016
Messages
9,825
Reaction score
17,041
Location
Pleasant Hill, Concord
Rating - 0%
0   0   0
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.


1596092194202.png
Groovy :)
 
OP
OP
Ranjib

Ranjib

7500 Club Member
View Badges
Joined
Apr 16, 2016
Messages
9,825
Reaction score
17,041
Location
Pleasant Hill, Concord
Rating - 0%
0   0   0
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
 
OP
OP
Ranjib

Ranjib

7500 Club Member
View Badges
Joined
Apr 16, 2016
Messages
9,825
Reaction score
17,041
Location
Pleasant Hill, Concord
Rating - 0%
0   0   0
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

Valuable Member
View Badges
Joined
Jan 1, 2019
Messages
1,344
Reaction score
1,720
Location
Missouri
Rating - 0%
0   0   0
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

Active Member
View Badges
Joined
Mar 21, 2019
Messages
305
Reaction score
254
Rating - 0%
0   0   0
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

Valuable Member
View Badges
Joined
Jan 1, 2019
Messages
1,344
Reaction score
1,720
Location
Missouri
Rating - 0%
0   0   0
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

Active Member
View Badges
Joined
Mar 21, 2019
Messages
305
Reaction score
254
Rating - 0%
0   0   0
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

Community Member
View Badges
Joined
May 24, 2020
Messages
51
Reaction score
44
Rating - 0%
0   0   0
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

Community Member
View Badges
Joined
May 24, 2020
Messages
51
Reaction score
44
Rating - 0%
0   0   0
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

Active Member
View Badges
Joined
Apr 22, 2018
Messages
113
Reaction score
204
Rating - 0%
0   0   0
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.

Screenshot_20200801_065343_com.teamviewer.teamviewer.market.mobile.jpg Screenshot_20200801_065225_com.teamviewer.teamviewer.market.mobile.jpg Screenshot_20200801_065147_com.teamviewer.teamviewer.market.mobile.jpg
 

Kerinin

Community Member
View Badges
Joined
Jun 8, 2020
Messages
40
Reaction score
28
Rating - 0%
0   0   0
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:

Code:
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:

Code:
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

Well-Known Member
View Badges
Joined
Aug 11, 2018
Messages
677
Reaction score
1,123
Rating - 0%
0   0   0
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.

Screenshot_20200801_065343_com.teamviewer.teamviewer.market.mobile.jpg Screenshot_20200801_065225_com.teamviewer.teamviewer.market.mobile.jpg Screenshot_20200801_065147_com.teamviewer.teamviewer.market.mobile.jpg
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

Well-Known Member
View Badges
Joined
Aug 11, 2018
Messages
677
Reaction score
1,123
Rating - 0%
0   0   0
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:

Code:
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:

Code:
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

Active Member
View Badges
Joined
Apr 22, 2018
Messages
113
Reaction score
204
Rating - 0%
0   0   0
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!
 
OP
OP
Ranjib

Ranjib

7500 Club Member
View Badges
Joined
Apr 16, 2016
Messages
9,825
Reaction score
17,041
Location
Pleasant Hill, Concord
Rating - 0%
0   0   0
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.
 
Back
Top