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 fully recovered the protocol and brought power-board control to a very capable functional level.
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 full three-stage 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 program on the interface ESP32. We did not reflash the power board: every 500 ms, the ESP32 sends commands to it and receives telemetry over I²C, while the stock controller continues to control the heating rings, relays, fan and hardware protection. Separate test firmware was created for development: one build for checking the panel and another for safely studying and controlling the power section.
Power mode operates from 0 to 99, while temperature mode covers 40 to 175 °C. There is a timer of up to five hours, pause, delayed start within the next 24 hours and five saved profiles with five stages each. The interface works fully in Russian, English and Chinese. Separate state images were prepared for the OLED, together with several buzzer melodies.
Safety received particular attention. After power-up, the cooker is always in the Stop state, and merely turning the encoder cannot start heating — a physical press of the Start button is required. The firmware monitors the NTC and IGBT temperatures, mains voltage, the state of the power board and communication with it. Heating is disabled if communication is lost, overheating occurs or an error is detected. There is also dedicated no-pan detection, a five-hour continuous-operation limit and a watchdog in case the program hangs.
Wi-Fi is disabled by default. The local web interface can change settings and edit profiles, but it deliberately cannot remotely start, stop or change heating. Every command related to cooking is available only through the cooker's physical control panel.
Before experimenting, we read the complete 16 MiB flash twice and verified the copies using SHA-256. We wrote the new program only to one stock OTA partition, without touching the bootloader, factory firmware, settings or power-board firmware. The ability to return the cooker to its original state was therefore preserved.
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.)))