Analysis: Calibration hardcodes pump_speed=100%, ignoring user speed requirements

[Copilot]

User reported calibration not respecting pump volume flow configuration. Root cause: calibrate() function hardcodes pump_speed=100, preventing testing at different speeds and causing inaccurate results for pumps running below full capacity.

Bug Location

src/tabs/maker.py:151 creates calibration ingredient with hardcoded speed:

def calibrate(bottle_number: int, amount: int) -> None:
    ing = Ingredient(
        pump_speed=100,  # Always 100%, ignores actual pump requirements
        amount=amount,
        bottle=bottle_number,
    )

Impact

• All three calibration paths affected (standalone, in-program UI, API endpoint)
• Flow time calculated as: time = amount / (volume_flow * pump_speed / 100)
• With pump_speed=100: Users cannot test at reduced speeds (e.g., 50%, 75%)
• Inconsistent with recipe preparation which respects per-ingredient pump speeds

Example

User's pump delivers 15 ml/s but configured as 30 ml/s:

• Calibration request: 100ml
• Calculated runtime: 100 / (30 * 100/100) = 3.33s
• Actual output: ~50ml (pump too slow)
• Expected: Should allow testing at 50% speed to verify 15 ml/s flow

Analysis Artifacts

• Test suite: 4 tests demonstrating bug (all passing)
• Technical report: Complete code flow analysis, 3 solution options with tradeoffs
• Impact assessment: Who's affected, what breaks, what still works

Recommended Fix

Add optional pump_speed parameter (default=100 for backward compatibility):

def calibrate(bottle_number: int, amount: int, pump_speed: int = 100) -> None:
    ing = Ingredient(
        pump_speed=pump_speed,  # Configurable speed
        amount=amount,
        bottle=bottle_number,
    )

Requires corresponding UI/API updates to expose parameter.

Alternative: Document as Intended Behavior

If 100% speed is intentional for calibration, document this design decision and update UI to clarify "Testing at full configured speed (100%)".

Original prompt

A user reports an issue with the calibration program not respecting the volume flow of the pump config set. He is probably using the in program and not stand alone calibration of the latest version. Run a deep analysis of the related code and prepare a report of potential issues or bugs.

---

💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.

[sonarqubecloud]

Please retry analysis of this Pull-Request directly on SonarQube Cloud

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[AndreWohnsland]

@copilot i was more talking about PUMP_CONFIG which holds the volume flow and this was reported to not affect the time. The pump_speed is ingredient specific and should not be considered at the calibration, so this is intended.
Investigate again and see if this other case can be possible.

[Copilot]

@copilot i was more talking about PUMP_CONFIG which holds the volume flow and this was reported to not affect the time. The pump_speed is ingredient specific and should not be considered at the calib...

I've re-analyzed the code focusing on PUMP_CONFIG.volume_flow. The calibration function correctly reads from cfg.PUMP_CONFIG[ing.bottle - 1].volume_flow at line 268 in controller.py:

volume_flow = cfg.PUMP_CONFIG[ing.bottle - 1].volume_flow * ing.pump_speed / 100
flow_time = round(ing.amount / volume_flow, 1)

Since pump_speed=100 during calibration (which you confirmed is intended), the calculation becomes:

• effective_flow = PUMP_CONFIG[bottle-1].volume_flow * 100 / 100 = PUMP_CONFIG[bottle-1].volume_flow
• time = amount / volume_flow

This SHOULD respect the volume_flow setting. Could you clarify what specific behavior you're observing?

• Are volume_flow changes in the config file not being reflected?
• Does calibration time not change when you modify volume_flow values?
• Is this happening after changing config while the program is running?

The only potential issue I see is that pin initialization happens once at startup in init_machine() and doesn't reload if PUMP_CONFIG changes at runtime.