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.