Seeing some really exciting progress on cbox and brewblox! Just wanted to throw in a feature request that I think would remove a frequent pain point of mine.
Current status quo (two pain points, one inefficient positive feature):
Scenario: Wifi resets during active fermentation
Given: controlled beer is actively fermenting
And: temperature is stabilized by accumulated integral
And: spark loses connectivity to pi (thus stopping logging)
When: user resets power to spark to resume logging
Then: logging resumes
And: accumulated integral is reset to zero
And: controller loses control of fermentation until integral re-accumulates
Scenario: brief (perhaps intentional) power loss during active fermentation
Given: controlled beer is actively fermenting
And: temperature is stabilized by accumulated integral
When: power to spark is (perhaps intentionally) cycled
Then: accumulated integral is reset to zero
And: controller loses control of fermentation until integral re-accumulates
Scenario: too much integral
Given: controlled beer reaching end on active fermentation
And: accumulated integral from more active fermentation persists and fridge set point lower than neccesary
When: power to spark is intentionally cycled
Then: accumulated integral is reset to zero
And: controller re-accumulates more more appropriate component integral
My suggestion is to
- log PID values to the pi’s datastore (this will also make PID tuning easier)
- give an options:
a) after a power cycle, restore accumulated integral to the last logged value (or have integral persist on controller through a power cycle) and/or
b) at any time, user can manually change the integral to an arbitrary value.
With suggested feature:
Scenario: Wifi resets during active fermentation
Given: controlled beer is actively fermenting
And: temperature is stabilized by accumulated integral
And: spark loses connectivity to pi (thus stopping logging)
When: user resets power to spark to resume logging
Then: logging resumes
And: accumulated integral is reset to previously logged value
And: controller remains in control of fermentation
Scenario: brief (perhaps intentional) power loss active fermentation
Given: controlled beer is actively fermenting
And: temperature is stabilized by accumulated integral
When: power to spark is (perhaps intentionally) cycled
Then: accumulated integral is reset to previously logged value
And: controller remains in control of fermentation
Scenario: too much integral
Given: controlled beer reaching end on active fermentation
And: accumulated integral from more active fermentation persists and fridge set point lower than neccesary
When: user wants to manually reset accumultor
Then: they have option to do so manually via the UI
And: controller set to more appropriate integral component
And: fridge set point is more appropriate for level of yeast activity
Scenario: PID tuning
Given: User needs to tune the PID for their equipment
And: User lacks intuition to decompose factors affecting setpoint curve into P I and D components
When: User is trying to diagnose problems
Then: they can look directly at logged PID values
And: explicitly see factors driving unwanted behavior
And: adjust accordingly