Final Project...

Software Defined Cooking with ESP8266

There is an idiom: the proof of the pudding is in eating it. Same applies to the successful implementation of Software Defined Cooking with ESP8266; the proof is in the egg and eating it.

The objective of this final project to be submitted in due course for completion of Fab Academy 2016 is to design and fabricate an apparatus that display & control the temperature of a heated water bath (Sous Vide) over the Internet. DS18B20 acquire the temperature of the water bath, ESP8266 send this data via HTTP to thingspeak, and via MQTT to Node-Red server hosted on Cloud or VM. PID controller is defined in Node-Red with a set point. Output of PID is send via MQTT to ESP8266 to control the CPC1966B connected with heater.

Project Trivia

Back in week2 defining the concept & idea of final project, I have defined the motivation for such apparatus to be made, for more info click here. At week 17, I have answered the necessary questions posed by neil, such that the final project can be carry out as planned.

Background

Ever since humans discovered fire to cook food. The desire to have tasty food hot, and ready to serve without significant labour contributed to the preparation is insatiable. Progressively over different period of time, the labour required to prepare food is contracted to another person whether specialized or otherwise. By logical extension of the idea of the labour is contracted out to prepare food for humans, here comes the robot cook. Hence the notion of Software Defined Cooking meant for robots or home appliances have to be defined. An industry framework is needed to define protocols, communication standards, recipe, dispensing of food items, quality assurance and etc for Software Defined Cooking. Through observations on demonstrations in CES over the years, the software defined cooking appliances meant for smart kitchens are implemented in product silos by the respective vendors. Appliances that do not interact with other makes of smart appliances, and human owners are nothing close to the ideals of a Software Defined Cooking.

Some vendors have disrupted the market by inventing heating mechanism meant for cooking that is controllable by software. FreeScale have invented a “solid-state, high-power output, high-operating temperature radio frequency (RF) transmitter technology” to address software defined cooking. This articlehere explains the FreeScale RF solution and addresses the following issues:
1. “Heating is difficult to control with both thermal (heat) and temporal (time) precision. Heating elements take time to heat, are frequently not calibrated to a precisely measured numeric temperature scale, and then take time to cool to lower temperatures.”;
2. “It is extremely difficult to track the “doneness” state of the inside of food with precision.”
3. “The feedback loop between sensing doneness and adjusting temperature has been performed mostly by human observation, judgement and labor throughout recorded human history.”

The article above also outline three features of a Software Defined products
A. “Gather and analyze sensor data.”
B. ”Maintain peak performance and health based on sensor data analysis (feedback loop).”
C. “Communicate their analysis with other software-define products and cloud services for continuous improvement.” Besides the highlights of the 3 issues and 3 features, the article mentioned above and the product video of RFSage, an innovative appliance utilizing the FreeScale RF technology did not communicate enough details for a layman to deduce whether the RF mentioned is used for both transferring heat and communicating cooking data between different make of smart appliances in the category of software defined cooking.

Proposal

A little more historical background. Back in 2011, I chanced upon sous vide while clicking away on cooking videos over the Internet, and saw a demo of thermal circulator in a chemistry lab, I have never looked back since. The essence of sous vide cooking is to maintain a water bath at precise temperature, with food placed in food safe bags submerged into this precise temperature controlled water bath. We started off with a store bought DIY kit that cost quite an arm and leg. We even went to the extent to make sous vide shield for Arduino. At that point in time, a dedicated sous vide supreme is out of the equation, it has to give way to tuition fee, rent, transport, and food.

Sous vide solved two out of the three issues highlighted earlier. Doneness of the inside of the food is precise with sous vide, thus the inexperienced novice is spared from the labourious sensing doneness and adjusting temperature to prevent overcooking; hopefully stop food wasting from bad cooks. The other pressing issue is the calibration between heat transfer and time needed for heat to transfer is solved partially with some sous vide implementations. Some amateurish sous vide controller uses “bang-bang” algorithm for open feedback loop system, which is bad, really bad and hardly precise at the required set point. Some comes with PID controller, in which a controller for continuously adjusting the heat and time components in a closed feedback loop system.

The three features mentioned above speaks of the cloud computing itself without mentioning the name. A server in the cloud will collect and collate information send by the sensors, perform computations on the data collected, transmit control to the actuators, and lastly communicate to user through the use of visualizations.

Methodology

My proposal to implement the aforementioned Software Defined Cooking will consist of a purpose built microcontroller unit that is capable of connecting to the Internet via WiFi, attached with a temperature probe, and a heater as the actuator. Command and control is done by transmitting data to a logical server resides in the cloud/VM to process the temperature data, and send commands from the cloud over the Internet back to the microcontroller to control the actuator. Visualizations performed over the Internet, such that any user with a devices connected to the Internet is able to view it at anytime, anywhere.

Bill Of Materials

The B.O.M for the proposed apparatus is outlined here

Timeline and planning of project

The timeline and planning of the proposed apparatus is outlined here

Technology used

I have accumulated the knowledge and know how in due course of completion of the weekly assignments in FabAcademy. The following outlines the technology used by my final project:
electronics fabrications with PCB milling machine
Electronics Design with Eagle Cad and Fritzing
Embedded programming with C and Arduino IDE
Design, fabricate, and program microcontroller boards for input devices
Design, fabricate, and program microcontroller boards for output devices
Programming microcontroller boards for networking and communications
Interface and Application Programming with Android and Web

System & Setup for Hardware

The proposed system consist of the following hardware: such as the above mentioned microcontroller unit with WiFi enabled, temperature probe, and heater connected to the microcontroller; an access point (AP) that is connected over the internet; a cooking vessel to hold the water bath meant for cooking. The software will consist of custom firmware for the microcontroller unit; a virtualized server installed with Ubuntu, installed with node-red, and PID controller package added to node-red. A web based visualization such as thingspeak, which is available free to the general public.

Microcontroller Unit

The following picture describes the block diagram representation of the microcontroller unit.

The microcontroller unit is made with ESP8266 ESP12E. The boards were the end product milled using a PCB milling machine out of many iterations of electronic design in the week6 of electronics design source files here
Two such specimens were describe in the following pictures.
Boards designed with different flavours, to explore the feasibilities of the different designs. Generally speaking, when design the boards, one important notion is to take into considerations of the pins to be used. From personal experience, one could be overzealous when designing such board, to break out each and every possible pins on a single sided board, in which, can be very challenging. The following board design was found to be a suitable design for the purpose of software defined cooking. Two I/O, GPIO4 and 5 are break out for temperature probe, and solid state relay. With some other useful pins such as GPIO0, TX and RX for debugging purposes.

DS18B20

Prior to this Software Defined Cooking experiment, several sensors such as LM35, K-type thermos couple, and DS18B20 were used in a DIY Arduino sous vide. Through experimentations, it was found out that DS18B20 suits this type of application. The details of the sensors was documented here.

Back in the week 11 input devices source here DS18B20 is used in experimentation for that particular week. The outcome is positive, with temperature data read with DS18B20 and display on the serial monitor. One observation was made during that week of experimentations; the DS18B20 pins and resistor connections were flimsy on the breadboard. A sturdy 3 female pin connector with 5k ohm resistor soldered across the data and VCC pins of the DS1820 was constructed. Hot glue applied to the solder joints for finishing move. The following picture describes it.

Solid State Relay CPC1966C

The solid state relay part listed in fab inventory is CPC1964B, but it was not available locally. The more capable cousin CPC1966B is available. The stark differences? CPC1966B is rated 3A Vrms at output, and CPC1964B is only half of that. For a heating appliances below 700W CPC1966B is suitable.

Back in the week 13 output devices source here A custom PCB part is created for CPC1966B and it is used in experimentation for that particular week. The following diagram describes the design and the PCB milled.





please follow the URL above for the details of fabricating the CPC1966B PCB, and testing it. The following picture describes a UK 13A faceplace is stuffed with the CPC1966B PCB.

WARNING Do not hook up the wiring to the electronics while the AC socket is plugged into the mains or turned on. Always switch off the mains, and then disconnect the AC socket from the mains before working on the boards or wirings.

Heater

A cartridge heater was salvaged from one of the rubbish bins along the corridors outside of the labs. After some probing on the origin of the parts on the internet, it was determined to be a 220V 350W water heating cartridge heater. As for the testing of functionality, it is still operational. The following picture describes the assembled cartridge heater with a UK 13A fused plug that comes with indicator lamp.

WARNING Heater is hot and will take some time to cool down if turned off. Always placed it in a holder for safety, away from accidentally touch by bare skin. Do not hook up the wiring to the electronics while the AC socket is plugged into the mains or turned on. Always switch off the mains, and then disconnect the AC socket from the mains before working on the boards or wirings.

Cooking vessel

A large metal container was bought at the local thrift store. The cartridge heater is kept upright with the use of a magnet. The following picture describes the assembly of cooking vessel.

Enclosure for electronics

Several ideas were toyed in due course of project development. In the earlier days, the line of thoughts was to stuff all the electronics into a store bought multiplug. A detailed step by step guide is available at my instructables on make an IoT enabled multiplug here. unfortunately, the inside space is too small.

Another idea was to 3D design and print a larger multiplug with enough space to be stuffed with the electronics. The following pictures describe the above two ideas, that were abandoned eventually due to the missing feature of perform debugging safely.




A laser cut enclosure is designed with inkscape and fabricated for the sole purpose to hold the electronics and also concurrently to allow for debugging while the software defined cooking is being prototype. Eventually, after a few iterations, the objective is to achieve the sophisticated design for the final prototype to be productized. The lasercut enclosure is available here . The following picture describes the enclosure in use.

Update: Design and 3DP a custom attachment to enclose electronics

I have toyed with the idea of using the 13A face plate and container box as the electronics enclosure for my final project. However, the space inside the store bought 13A face plate and container box is insufficient to be stuffed with the electronics I have fabricated in FabLab@SP. Upon observing the reverse side of the store bought container box, I realised I could apply my newly acquired fablab design and fabrication skills to make an attachment to act as an enclosure to my electronics. The custom part will piggyback on the existing 13A face plate container box.

I have 3D designed with tinkercad and 3D printed the attachment. The following picture described how the original 13A face plate container box to be extended with the custom 3D designed and 3D printed parts. The following pictures describe the prototype of the final project fully stuffed and assembled with the new custom enclosure. The cartridge heater is connected to the 13A faceplat fitted with the custom 3D printed enclosure. The DS18B20 and VCC supply wires extend from the electronics. Now my FabLab final project starts to look like a finished prototype.

The following 3D model describes the custom 3D part as STL.

It seems you are using an outdated browser that does not support canvas :-(

The following pictures describe the prototype stuffed and awaiting assembly.




The following pictures describe the prototype from different views.




Integrating all hardware

The following picture describes the hardware setup for software defined cooking with ESP8266.

Please note the load is not connected. Later it was found out the metal container is not tall enough for the water level to utilize the heater cartridge fully. An alternative is used during the dry run with load. The following picture describes the setup with my coffee mug as the cooking vessel.


The coffee mug with cartridge heater is too small to put an egg into it. The following picture describes the quick and dirty way to address the design problem.

System & Setup for software

The OS of choice is Ubuntu server, to be installed either on a physical host, a VM, or on Cloud. For MQTT broker, there are several to choose from. This project assumes mosquito mqtt is installed on the Ubuntu server. To install node-red, the following command can be used
git clone https://github.com/node-red/node-red.git
cd node-red
npm install
To install PID controller in node-red, the following commands can be used
npm install node-red-node-pidcontrol
Start the node-red server with the following command
node red
# with browser of choice go to http://server_IP:1880/
The following picture describe the node red at server 192.168.1.104. At the minimum, an injector to handle MQTT publish message, the PID controller, and the output of MQTT subscribe should be deployed in node red. On the debug tab on nodered server, the temperature received from ESP8266 is displayed under the topic "mytopic", pid control debug, and the control sent to ESP8266 under the topic "utopic". I observed the temperature received at 10.10.46AM is 67.75 degC, and the corresponding output of nodered pid is -0.34886. In other words, the PID controller on nodered is functional. On the serial monitor of COM15 is the debug output for ESP8266. The temperature sent and PID control received matched the one on the nodered server.

Firmware

The custom firmware is programmed with Arduino IDE setup-up for ESP8266, used several libraries and also modified the libraries such as https://github.com/Imroy/pubsubclient/blob/master/examples/mqtt_subscriber/mqtt_subscriber.ino that is a fork from https://github.com/knolleary/pubsubclient/blob/master/examples/mqtt_esp8266/mqtt_esp8266.ino

The microcontroller unit will publish temperature data via MQTT to node red. the 0xdeadbeef is at the callback function, where parameter received from a subscribed topic in node red contained the control for the microncontroller unit to act upon the actuator. A positive, larger than zero parameter received will turn on the heater, and conversely, a negative, lesser than zero parameter received will turn off the heater. The time to heating parameters largely dependent on the time of arrival of the parameter. The source code of the custom firware for software defined cooking is available here.



When it comes to debugging such setup, the following fabricated board for USB-TTL for TX and RX pin on ESP8266 is very useful.

Experiments

A raw egg is set to be cooked in this apparatus that implements software define cooking at a temperature of 65degC for 45mins. The PID controller implemented in node red will decide whether to turn on or off the heater via MQTT messages publish across the network. At anytime a different doneness is preferred, the temperature can be changed in the set point of PID controller implemented in node red via the node red web page. The following picture describes the cooking process at the early start.

The following picture describes the visualization on thingspeak on the temperature of cooking, node red server debug output tab, and also on serial monitor of ESP8266 at the early start.

At any point of cooking, it is good to double check or verify the temperature reported by the microcontroller unit is correct. The following picture describes the temperature of 70 degC recorded by a separate digital thermometer. That is a 5degC more than what the setpoint. More info will be available at the conclusions and recommendations area.

Observations

As mentioned at Intro section, the proof is in the egg and eating it. The following picture describes the egg cook at supposedly 65degC for 45min.

As compared to the egg cooking chart by khymos as mentioned in week 17 here , it seems the egg above is close to 67degC in doneness.

There is noticeable lag when the computed PID output data sent back to microcontroller via MQTT based on the temperature data sent from microcontroller unit to node red PID via MQTT. It seems the PID output received by microcontroller is always 1 step behind the one displayed on node-red debug output.

In due course of experimentations, there are several weird software behaviour observed at the serial monitor. Sometimes microcontroller could not connect to MQTT server. Sometimes connected to MQTT server, but did not manage to subscribe to the topic via MQTT. Publish via MQTT works as per defined in code. For the above two cases, several restart of the microcontroller by plugging in and out the USB-TTL works. The callback function supposed to handle data sent by node-red PID via the MQTT subscribed topic, which ranges from positive numbers to negative numbers, up to 15 decimal places. Sometimes the float variable declared in callback function meant for the above would contain the data sent via MQTT publish. The float variable passed by value out of the callback function to another float variable in the main loop, it behaves as if it is an integer variable. This unwanted type casted variable posed not much an issue, because the control is to turn on the heater if the value is larger than zero, or turn off if value is smaller than zero. The following picture describes the observations. Please note the IP address 192.168.1.107 in the debug message in COM15 is IP of ESP8266 ESP12E.



From the observations with the naked eye via the serial monitor, this software define cooking that uses the cloud computing as the brain to compute PID work less elegantly. The behaviour resembles very closely to “bang bang” algorithm, albeit a refined one. One of the consequence of choosing the SSR as the control, it only provides an on/off state until the next command is received, that sometimes can arrive less timely. Having said that, SSR will turn on the heater at full load heating up the water way pass the set point while waiting for the next command to turn it off. Timing of heating up and cooling down cannot be determined due to the time needed for the data transmitting over the network to arrive at the microcontroller.

Conclusions and Recommendations

In short, this implementation of software defined cooking is workable, but still less than ideal as compared to the almost perfect PID close loop control achievable on a local microcontroller with fast rise time, fast settling at the set point, and the rate of error/compensation. Tuning of PID on an Arduino uno by hand is achievable, as documented here. However tuning of PID over the network for such implementation can be a real pain in the ___. A few variables can’t be held constant during tuning, such as round trip time, congestion, collision, etc. These fluctuations affects the stability of the PID close loop control.

In the next iteration, replace the SSR with a triac for a dimming effect instead of an on/off effect, and investigate whether AC phase control is much more useful in such implementation of Software Defined Cooking. The dimming effect will be much more forgiving than turning on at full load for a number of seconds while waiting for the command to turn it off to arrive. Hence the time taken to heat up the thermal capacity of water will be longer but temperature changes remain relatively calm due to the small amount of current but continuously present as compared to the violent changes induced by the SSR. Choose of a better close loop controller for this type of implementations. Perhaps a LQE (linear quadratic estimation) will do? At the minimum, the PID control over the network to include the network traffic condition as an input, to form a complemented PID control.

Before all hell break loose debating on the type of close loop controller to be implemented for software defined cooking. Remember the motivation for such an apparatus? “I have conceptualized and devised an apparatus to keep my sanity in check. ”

bon appetit!



Source files Download

URL to final presentation Final Presentation
URL to presentation video Presentation Video
The source code of the custom firware for software defined cooking is available here
The custom eagle CAD parts library of SMD footprint for CPC1964B or CPC1966B download here
The CPC1964B schematic, board, and gerber download here
ESP8266 ESP12E designed with Eagle Cad using generic parts schematic, board and gerber archived in zip file available here
The lasercut enclosure is available here
The 3D designed and printed enclosure is available here

Ref

http://nodered.org/
http://shin-ajaran.blogspot.sg/
https://github.com/Imroy/pubsubclient/blob/master/examples/mqtt_subscriber/mqtt_subscriber.ino
https://github.com/knolleary/pubsubclient/blob/master/examples/mqtt_esp8266/mqtt_esp8266.ino
http://fabacademy.org/archives/2014/students/shooshtari.ali/week16/images/PID-Without-a-PhD.pdf