Hysteresis - above and below the setpoint

[emdubeu]

I agree with the swing bring 1 degree above and below.

[hebnern]

The reason we did it this way is we were noticing that the thermal mass causes the temperature to continue changing after the heater/cooler is switched off. If we switched the heater/cooler off at SP+H/2, we were seeing the temperature oscillate between SP and SP+H. Doing it our way, we were seeing a more even oscillation between SP+H/2 and SP-H/2. I suppose that this is largely dependent on your system though, so I am not sure what the best general purpose strategy would be.

[SLOBrewer]

Interesting. The lag caused by the thermal mass isn't conceptually different than any of the other lag in the system. By moving away from [SP-H/2, SP+H/2] to [SP, SP+H] what you've done is attempt to correct for this lag by offsetting the true setpoint by +H/2.

I would advocate going back to [SP-H/2, SP+H/2]. If people want the behavior you've got now they can simply move their setpoint up by +H/2. If the user wants to properly deal with the lag then they should enable the PID functionality and let the PID autotune to truly capture how the lag manifests in their system

[tyler_mccamish]

Agreed with SLOBrewer. Perhaps this could be a setting that anyone can change in a future version.

[hebnern]

Committed.

[hebnern]

Brian and I have been thinking about this a bit more, and we don't think that the way we "fixed" this is what we really want.

The way we "fixed" it, it uses SP +/- H/2 as the limits for when to turn the outputs ON and OFF like so:

(blue is cooler ON, red is heater ON, black lines are SP +/- H/2)

Notice that this FORCES the temperature above SP+H/2 in heating mode, and below SP-H/2 in cooling mode. Because the criteria for turning the heater OFF is the same as the criteria for turning the cooler ON, you will always see your outputs fighting against each other as they will each push the temperature into the trigger range for the other mode.

The way we had it to originally is to use the SP and SP +/-H as the limits for when to turn on value ON and OFF like so:

(blue is cooler ON, red is heater ON, black lines are SP +/- H)

Notice that the criteria for turning the heater ON is different than the criteria for turning the cooler OFF, resulting in periods where neither the heater nor the cooler are on and they are not fighting against each other.

I think in practice, you wouldn't see it oscillate evenly above and below the setpoint. Instead, it would tend to one side of the line or the other, but I don't think there is any way to prevent this (other than using another strategy like PID).

However, this has the benefit that it is possible to control the temperature with ONLY the heater or cooler since the temp may never enter the trigger range for the other mode. I believe that this is really how it should work.

Thoughts?

[hebnern]

Now, to the separate matter of whether or not the hysteresis value should be split above and below the setpoint. It is not really correct to think of one hysteresis range around the line that applies to both heating and cooling modes. Instead, you have two SEPARATE hysteresis ranges. One for heating (SP to SP+H) and one for cooling (SP-H to SP). Thus I believe that splitting the value is the wrong thing to do.

Thoughts?

[emdubeu]

Now, to the separate matter of whether or not the hysteresis value should be split above and below the setpoint. It is not really correct to think of one hysteresis range around the line that applies to both heating and cooling modes. Instead, you have two SEPARATE hysteresis ranges. One for heating (SP to SP+H) and one for cooling (SP-H to SP). Thus I believe that splitting the value is the wrong thing to do.

Thoughts?

So, for example, if the SP = 68° and H = 1°, then the heater will turn on at 67° and the cooler will turn on at 69°, right?

[hebnern]

Yes, exactly. To me that seems more straightforward. Dividing by 2 is hard.

[SLOBrewer]

Now that you've shown it graphically I agree that the behavior of just cooling to the setpoint and just heating to the setpoint so that there's a gap and you don't get into a tight oscillation.

Since you're fishing for thoughts, really even the set point could be different for cooling and heating. For example, maybe I'd like to heat to make sure that the fermentation doesn't get below 65 °F but I'd like to cool to keep it under 67 °F. Sure, you could use two probes with the current functionality to achieve this but why not let the heating and cooling setpoints and their hysteresis be set independently off of one probe? That would mimic what I can do with a dual stage Ranco.

[hebnern]

So what settings does the dual stage Ranco provide? Sounds like two setpoints? Hysteresis for each one? How does it all fit together?

For sure there are a million settings that we could provide, but at some point it just gets more confusing to configure. I feel like you have to draw the line somewhere, but I really don't know where that line should be.

[SLOBrewer]

Yes. One probe but then two sets of settings. Each set of settings is target temp, cooling versus heating, and finally hysteresis. This all ends up being pretty simple though I'll say that for the majority of the time I leave the hysteresis the same for the heating and cooling sets.

[SLOBrewer]

I thought this was fixed so that the hysteresis is delta above and below the set point that triggers the cooling/heating. I'm running 1.3.0 with a hysteresis of 0.5 and it looks like the cooling doesn't kick in until 1 degree above the setpoint:

https://brewbit.com/dashboard/devices/588/sessions/2294?token=db87c63217bf12a6e49df119cf541ef3

Thoughts?

[hebnern]

Hmm, thats interesting. Yeah a hysteresis of 0.5 should trigger it at 60.5. I'll take a look.

[jshufelt]

I do prefer the hysterersis setting as SLOBrewer is pointing out. That is what I currenty am using for my fermenation chanmber with the Ranco.

[darickbaker]

I am also running 1.3.0 but using a hysteresis of 0.1. Mine seems to be working correctly.
https://brewbit.com/dashboard/devices/564/sessions/2225?token=7558f0f332847c7ec5a536c584d35151

[emdubeu]

@darickbaker, what is the environment or type of setup you have for your fermentation? By the looks of your graph, your cooling device turns on every 45 minutes or so and your temp range is about a 1.5° difference. That's pretty sweet by the way....

[darickbaker]

It is a small freezer; I think it is 5 cubic feet. I can fit four 3 gallon better bottles.
At this point, nothing is fermenting, it is just acting as an auxiliary beer refrigerator.

I've been really happy with how it has been doing.

[ufergus]

I would like to add my two cents to the discussion. Before switching my setup to BrewBit, I was using an Auber controller to control my heating and cooling outputs. I was able to configure the Auber with two set points, one for heating and one for cooling each with their own hysteresis values. For me, these options would be ideal for the BrewBit. For now, the 1.3.0 update has fixed the heating/cooling fight condition due to overshoot which was a show stopper. Thank you.

[hebnern]

So it sounds like you want the setpoint associated with the output rather than the controller. We discussed this a lot before releasing, and ended up associating it with the controller since it makes for a simpler setup. Basically the user just says "keep my beer at X degrees" and we try to make that happen. It was a conscious to go with simplicity at the expense of flexibility. I just feel that it would really complicate the setup process especially when you consider temp profiles. To support this, you would have to input profiles for both heating and cooling, which would add more complexity to an already somewhat busy UI. I am not saying I am against this, but I want to consider all of the implications before I commit to making any changes.