So, in alot of cases like this, the GO-TO temperature control method is PID. In part its because its very commonly used in industry, its been around for a very very long time and you can get fairly generic modules from a lot of sources with a wide range of capability... and they're cheap!... and alot of other reasons.

In 3d printing, PID has been the mainstay of most FDM printers for controlling temperature in the head and the bed and there's good reasons for that. The premise is that you measure the temperature, check against your target, then use a simple bit of math to figure out how much extra power you need to send to your heating element to get there. I wont go into all the components of what the three bits of PID actually mean, but they're reasonably straight forward and easy enough to implement on even the smallest of MCU's and that was true even 50 years or so back.

However, there are other mechanisms for hitting a temperature that can be a little more solid if you know all the variables. Lets take the example of the 3d printer head and we're trying to hit a temperature of 250c. The variables working against us here are fairly easy to define:

1. Ambient Temperature/humidity
2. Head material
3. Input lag (basically the time it takes for the heating element to heat up PLUS the distance between the heating element and the temperature sensor)
4. Flow rate of our material (varies during the print)
5. Specific heat of our material....
6. How fast the air might be moving over the head (the heads in motion after all)
7. Distance between head and heated bed (closer you are, more heat your getting from the bed against the head).
8. ... the list goes on...

Point is, there's quite a few variables, BUT if you can map them out you can predict in advance exactly what power you need to send to the heater element in order to keep it exactly at temperature. It means doing a tonne of calibration (and would only cover the materials you are using) but its doable.

Our little heated box has fewer variables, which makes them much easier to predict and map against. To begin with its a little sealed box and nothing is in motion, so alot of the variables are gone.

In reality, for the temperatures we're dealing with here and the fact that most people would be using it inside, this is easy enough to ignore.

In my previous life i was chemical engineer in research and keeping things at temperature was often pretty critical to whatever we were doing, PID controllers were too general, we had a lot of computing power available (relatively speaking), we had much better control over the local variables and all the time in the world to calibrate. There were quite a few options on how you then control temperature but one we had invented ourselves was called delta curve tracking with delay compensation. In essence, you go through as many heat-up ramping cycles as you can with as many different power levels as you can. Say for example you start at 10%, you end up with a temperature curve over time like so (and you do it for as many power levels as you can):

The second step is you then take this curve and start at 10%. At the mid-point you change to 20% and you end up with a curve that accelerates slightly, again, you do this for as many points as you can. Ultimately you end up with a situation where you can measure temperature change over time for any given power or current temperature and you also have your power reaction delay for as many points as possible and ultimately you end with a map of power vs temperature vs time and it would look something like this (not my actual plot, just an example)

Once you include input delay to this equation and given we're tying to his a temperature curve profile, as long as our oven can hit them fast enough, we should be able to get a very accurate curve... This should all add up to a superior (though calibration intensive) temperature tracking ability. 

But, its also alot more CPU intensive compared to a PID algorithm, however an ESP32 has a million times more CPU grunt than the MCU's of 50 years ago...

How much of a difference would it be compared to a PID controller? I mean PID controllers, as long as the 3 variables are decent are really good and in truth, I might just end up with a PID controller anyway. Part of me wants to do delta curve tracking because im doing this whole project from green-fields and doing the same thing as others partly defeats the purpose. The tricky part is processing the calibration data. Most 3d printer control boards can develop their PID variables on the board, but trying to map out all those variables and do the math to produce our delta curve may be a bit too much in terms of memory requirements to be able to do on the ESP32 itself. Currently there's a small bit of JS under the test directory that performs some of the calibration and records the data and I haven't done the linear regression I need to calculate the curves yet. While the CPU on the ESP32 will probably easily accommodate doing the math its alot of data to track in the calibration side and store/process.

Maybe PID is v1 and delta curve is v1.1... who knows....

Update: I meant to add originally in case anyone is wondering, delta curve with delay compensation is similar to model predictive control but adds an extra variable.