I assume the cooling would have run for 100% duty cycle for the first 30 minute period, and continue to run without interruption into the second period.
Is that right?
Yes. Barring any active constraints, this is how it’d work.
The wizard set up a minimum ON time (3 minutes) and minimum OFF time (5 minutes) for the actuator.
With that protection in place, what’s the effect of the varying the period?
Having a longer period allows for a longer on time when the setting is < 100%. A PWM with a period of 10min and a duty setting of 80% would turn on for 8min, and then run into the minimum OFF time.
There is some compensation present in the PWM implementation, but you’d still end up with a PWM that can only manage duty settings of 100% and < ~50%.
Seems like a long period, say 60 minutes, is the place to start.
One could back off of that duration if the beer temp fluctuates more than desired.
Am I thinking clearly about this?
Your reasoning is correct. We put the number at 30 minutes for the default setup, but feel free to experiment to find the best balance for your system.
If I set up a PWM with a 6 hour period and maximum On time of 20 minutes, would that guarantee that a 20 minute cycle starts every 6 hours?
While I suspect this is likely, it is not guaranteed. The exact placement of ON/OFF parts of the period is an implementation detail that may change at any time. There already are various under-the-hood optimizations built in that can adjust invididual periods.
You’ll need @Elco to describe current implementation.
As a more practical consideration: a 6 hour period is very vulnerable to reboots. Period start times are not stored in persistent memory, and the PWM will start a new cycle after a reboot.
Normally, the impact of occasional cycle interruptions is minimal, because the system is based on measured temperature, and will adjust the PWM duty setting. We designed the system with this in mind: the controller will reboot if it encounters an error.
These watchdog-triggered reboots are a mechanism to ensure that the system remains stable even if encountering the occasional (and inevitable) bug.
Or is it possible for the On time for the PWM to be staggered somewhere throughout its period?
No and yes. A period will never have multiple ON phases, but it is possible that minimum ON + minimum OFF constraints on the actuator cause the physical pin to switch ON - OFF - ON - OFF within the space of a single period.
Again, exact behavior falls under implementation details.
If the chamber temperature is higher than 58*F, say for an ale fermentation or a diacetyl rest, the PID should output zero and the PWM result in a duty cycle of 0%.
So there is no need to disable this behavior based on beer or fridge temps.
Am I think clearly about this?
The theory is sound. The main objection is the fragility of its dependence on implementation details and 6 hour periods I outlined above.
Whether this is a viable implementation depends on how tolerant the timing interval for your defrosting routine is - can it handle the pessimistic scenario?
If the compressor runs clean though the defrost’s 20 minute period, does that PWM happily conclude its period?
We added some period stretching logic to deal with this edge case, and you’ll likely need a balanced constraint between cooling and defrosting PWMs.
For a definitive answer you’ll need @Elco.
And there are no gaurauntees that the defrost cycle will ever run.
Is that right?
Or is there more to the mutex?
The Balancer exists to deal with this weakness in Mutex designs.
Will the planned logic block apply logic to actuator outputs and drive an additional actuator?
Yes, that is exactly how it will work. Here I do have some good news: the next release will include the logic block. The firmware implementation is currently in review while we figure out UI design, and how to make boolean logic user-friendly.