Found it, you were right.
@Tom Bishop I was incorrect:
| | Temp | < | Heater threshold | => | Heater goes on |
| Heater threshold | < | Temp | < | Heater threshold + Hysteresis | => | Heater stays on |
| Heater threshold + Hysteresis | < | Temp | | | => | Heater turns off |
Same the other way arround for the cooler:
| Cooler threshold | < | Temp | | | => | Cooler goes on |
| Cooler threshold - hysteresis | < | Temp | < | Cooler threshold | => | Cooler stays on |
| | Temp | < | Cooler threshold - hysteresis | => | Cooler turns off |
@Ranjib Found a possible technical issue.
In the code you check for
case h.pastTarget == downerTarget && math.Abs(o.Value-h.config.Max) < h.config.Hysteresis:
when the cooler = downer should continue. However, when the temperature rises faster than the hysteresis within the check period it turns off immediately. This will make the cooler turn periodically on and off, when the hysteresis and/or period is too small. Same for the heater, which might not be desireable, since you are in that case already way past the threshold and definitely dont want the heater/cooler to fluctuate.
I would suggest to change this to:
case h.pastTarget == downerTarget && h.config.Max - h.config.Hysteresis < o.Value:
and
case h.pastTarget == upperTarget && o.Value < h.config.Min + h.config.Hysteresis:
respectively.
I was thinking whether this has some security feature when the sensor crashes, but this would immeditely switch the Heater/Cooler on the next period again anyway. So I think it might be usefull to program this kind of "bad sensor" error mode more effectively.
Looking over the ESP32 code it doesn't look like it, yet. This gave me an idea however: there are convenient Arduino libraries for running a stepper motor on an ESP32:
The Arduino programming language Reference, organized into Functions, Variable and Constant, and Structure keywords.
www.arduino.cc
The Arduino programming language Reference, organized into Functions, Variable and Constant, and Structure keywords.
www.arduino.cc
@Ranjib I haven't looked at them myself yet, but it might be very easy to incorporate Stepper Motor functionality that way.
Security wise I'm afraid it is currently the same as with the PCA9685: if the ESP32 doesn't get an off command due to WiFi or Raspberry issues, it doesn't change its state. That should be easy to fix though:
- The quick and dirty method would be to manually define maximum runtimes in the ESP32 code, either generally for all jacks (even if it is used for a light) or specifically for the jack that the doser is connected to.
- The proper way would require an additional feature in the Reef-Pi ESP32 driver and doser handling and establishing a separate method in the ESP32 code for "dose with PWM power x for interval y"
