Some modules have hidden struct implementations (e.g. pid) while others do not (e.g. machine_settings). This should be consistent.

Probably something is not being reset correctly.

There is currently nothing checking that the boiler is responding as expected to the heater inputs. This can lead to thermal runaways should the sensor come detached or fail. Functionality should be added to monitor the state of the boiler and enter an error state should a thermal runaway be sensed.
This could be modeled after the thermal runaway logic in the Marlin 3D printer firmware. The basic rules are

1. The temp must be changing at some minimum rate when the machine is settling to a temperature (i.e. responding to control inputs)
2. The temp must not deviate too far from the setpoint after settling (i.e. sensor fails as in #16)

Currently, the auto brew routine can only regulate the flow rate. It is possible that the user may want to regulate the pressure instead. This should be added as an option for the auto brew routine.

A steam boost feature should be added. When in steam mode, activating it would cause the pump to slowly run, adding more water to the boiler. The water's cooling effect will be offset by the feedforward PID term. This should increase the steam power and duration.

There is not enough clearance around the traces caring AC loads on the PCB. The ground plan should be carved out in this area.

Currently, the integral windup bound is set to a fixed value. However, this can lead to overshoot e.g. during flow control when 100% power is needed to reach the target flow rate. This leads to e(t)*Kp + e_sum(t)*Ki = e(t)*Kp + 100 > 100 (where the last inequality holds only when the flow is below the target).

Instead of the fixed bounds, e_sum_lb <= e_sum(t) <= e_sum_ub, the windup bound on the integral term should dependent on the proportional input: e_sum_lb - e(t)Kp <= e_sum(t) <= e_sum_ub - e(t)*Kp. This is equivalent to the fixed bounds when at the set point, but it keeps prevents the error sum from growing when the error is large (i.e. the proportion term is dominate).

Using the local dial and pump switch, though functional, is very clunky. With the newly expanded setting structure (120 folders!) it takes a long time to navigate and get set the way you want it. It would be much easier to do this with a console interface prior to the implementation of a remote application.

Problem Summary

There is a note in section 4.3.1.3 of the RP2040 data sheet discussing the use of the RP2040's I2C hardware. It reads

Note: There should also be external pull-ups on the board as the internal pad pull-ups may not be strong enough to pull up external circuits.

However, the current schematic relies on the internal pull-ups. This could be the cause of the intermittent problems communicating with the NAU7802.

Proposed Solution

Add 4.7KOhm pull up resisters to the SDA and SCL lines on the RaspberryLatte main board.

Problem Summary

There are no external pull resisters on any of the main board's output signals (include the I2C bus as stated in #3). This can lead to dangerous situations where a crashed program and floating output can cause one of the AC components (heater, pump, solenoid) to get stuck in the on position.

Proposed Solution

Add 4.7KΩ pull up resisters to all the output signal lines on the RaspberryLatte main board.

There are occasional spikes (positive or negative) in the temperature. I have only noticed them for a single time step, but they should be addressed.

It could be replaced with something like this. However, this will require retuning everything, but this is probably okay since the flow control never worked great anyway.

Currently, once you are don't changing a setting using the local_ui, you have to return to root before changing another setting. This is very annoying and would be better replaced with just going up a single level to the parent folder.

The temperature at the sensor and the temperature at the show screen may have a slight offset. This offset should be added to the firmware as either a constant value (configured based on the machine being used) or a user configurable value. Then, the temperature set point would just be offset by this amount internally.

I have observed occasional erratic behavior in the boiler. I'm not sure if it's software (sensor driver, PID implementation, etc) or hardware (sensor failure). Best guess is an overflow error somewhere in the PID controller, but I need to do more tests.

The control board was designed for 3.3V flow sensors. Turns out, they are almost exclusively 5V. To get around this with the current design, a jumper has to be soldered on and a voltage divider used to drop the 5V signal down to 3V. This should be updated in the next version of the board so no jumpers are needed. This is also related to issue #8 discussing cleaning the power to the flow sensor.