I bought an excellent MCL02M induction cooker, and I am still very happy with it. The best thing about it is that at low power it still regulates power smoothly instead of using on/off intervals. Of its 99 levels, only level 1 uses three-second intervals. Starting from level 2, the heating is genuinely smooth. And that is really cool.
The source code, documentation and flashing instructions are published in the repository: VlasovLabTech/mcl02m-custom-firmware.
There was one problem, though: the cooling fan did not work out of the box. Up to 8 V it rotated slowly, but at higher voltage it only twitched. The cooker overheated the IGBT — the Chinese engineers fitted a temperature sensor, which is great. The seller refunded the money and let me keep the cooker. I eventually replaced the fan with a radial (centrifugal) blower of the kind used in a 3D printer and ordered a C1015B1 replacement part.
The printer blower is very loud, but it does its job. It is rated for 12 V, while the cooker supplies the fan with 18 V, so it was only a temporary option. I tested it at 24 V beforehand.
The interface was also exclusively in Chinese. Since I had already opened the cooker, I looked at the interface board and found that it used an ordinary ESP32. The interface between that board and the power section was I²C, clearly labelled on the PCB. So I made a strategic decision: download the existing firmware, try to find something in it, listen to the I²C bus and write my own firmware. Fortunately, the stock firmware was readable — thanks to the Chinese engineers for that.
I had to bring in GPT. It handled the decompilation task very well from the start. It recovered almost everything: the pins in use, the interfaces, the LUT tables for the temperature sensors, how the I²C data is transferred, what exactly is transferred, and much more — all from a binary firmware image.
We then wrote test firmware to identify the controls and interface more precisely: the buttons, LEDs, buzzer and display. We also connected a Kingst LA2016 logic analyser and used another project of mine, OpenBench, where I connect all my instruments — measurement and otherwise — to one environment and web interface for data collection and automated testing. GPT captured the bus itself, communicated with the power board itself and, after about an hour, we had recovered the protocol sufficiently to control the power board.
Next, we outlined how I wanted the cooker controls to work and started implementing them. Most of the time went into the interface so that it would look normal, remain readable and be convenient to use. That really took almost one long evening.
Of the implemented features, the one I particularly like is the PI controller in temperature-maintenance mode. It begins with fast heating, while the final stage maintains temperature without going above power level 35 so that it does not cross a relay-switching boundary: regulation is done only with the IGBT. The transitions occur between levels 35–36 and 55–56. This cooker has two rings, so depending on power it switches on the inner ring, the outer ring and then both. I also arranged the display so that power mode can show the current temperature, and temperature mode can show the current power.
The other improvements are mostly for convenience and appearance: images, sounds, a clock, delayed start, start at a set time, Wi-Fi connectivity, settings through a web interface, internet time and so on. I also implemented custom profiles with up to five sequential stages per profile. This is for cases where you first need to stew something, then simmer it, apply a little more heat and simmer again. But I suspect nobody will use it.
A little information from GPT — I naturally use Codex for all of this:
The new firmware replaces only the application on the interface ESP32. Every 500 ms it exchanges commands and telemetry with the power MCU, which still controls the heating rings, relays, fan and hardware protection. The working part of the protocol has been recovered sufficiently for control and diagnostics, but some service registers and the power controller’s internal logic remain unknown.
Manual POWER covers 0…99. TEMPERATURE covers 40…190 °C, with a separate 210 °C interface emergency limit for the lower sensor; operation at 190 °C has not yet completed full hardware validation. The algorithm has PREHEAT, APPROACH and HOLD phases: PI is used only in HOLD, braking adapts to the temperature rise rate, and APPROACH/HOLD are capped at 35. Automatic control crosses directly between 35 and 56 without using 36…55; manual POWER retains the full range. Reaching the setpoint enters active zero.
POWER 0 and Pause retain the power session through active zero; Resume recomputes the output without a full Stop/re-arm. Start, Stop, Pause, Resume and active zero are confirmed transactions. Stop repeats the zero command until two fresh R26=00 samples arrive. The cooking timer and profiles are limited to five hours, the retained session to eight hours, manual Pause to two hours, and the cooking lease to three seconds. E09 follows six consecutive failed 500-ms I²C cycles.
R26=01 means small or restricted cookware, not an error: real output is capped at 35/A1, POWER reports the honest value and shows the SMALL picture with P<36; power may be reduced but not raised above 35. In the current source, NoPan enters active zero, plays the complete 128-second Nutcracker melody and only then latches E02. Returning cookware cancels the melody and starts two-stage recovery; another removal restarts it from the beginning.
The OLED pack contains 19 full-screen frames: three alternating Ready pictures plus Time, Small, Wi-Fi, Hot and a large error code. Hot appears after five idle seconds above 60 °C, blinks for 2 s on / 1 s off and blocks Sleep until cooling. Timer entry proceeds through seconds, minutes and hours; Set/Disable is synchronous, START AT is blocked without valid time, and Delayed Start is RAM-only. Public and private sound builds share one codebase: the public build contains the NoPan melody, while the private build changes only Wake/Sleep. Private MIDI files and binaries are not published. Project code is MIT-licensed with the notice retained and no warranty; excluded private melodies are outside that licence.
After power-up the cooker is always in Stop, and heating requires a physical Start press. Wi-Fi is off by default, and the local web interface has no heating commands. Before development, the complete 16 MiB flash was read twice and compared by SHA-256. Normal writing touches only ota_1 at 0x170000; the bootloader, partition table, ota_0, eFuse and power MCU are not reflashed. A separately authorised NVS erase of 0x9000…0xCFFF was performed once later, so the settings cannot be described as never touched. Recovery depends on the unit’s verified full backup. Current-source features that have not received a separate cooker test are not presented as hardware-validated.
In the end, I am happy with it: the cooker works the way I want, the display and language are now excellent, and so is the functionality. I removed the useless Mi Home connection and all those recipes that nobody ever uses. To be honest, Wi-Fi is convenient, especially for the clock, but I suspect I will not use that either. It is just a cooker, not a spaceship. Everyone has gone mad already.)))