5.4 KiB
| title | date | author | categories | tags | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Smart Rice Cooker Conversion | 2018-06-18 | William Floyd |
|
|
The "why" isn't important (read "doesn't exist"), but I want to take a regular old "dumb" rice cooker, and convert it into a "smart" rice cooker.
So, a whim and a few minutes on Aliexpress later, my pint sized rice cooker and an assortment of electronics are on the slow boat from China.
Having no real clue what I'm doing, here's what I've ordered thus far:
Main list of things:
- Rice cooker ($26.40 + $3.16 S&H - The star of the show.)
- Thermistors ($2.97 - 100pcs, for temperature readings)
- NodeMCU ($2.47 - To, hopefully, allow me to WiFi control the whole thing)
- Relay ($0.76 - To switch power on and off.)
- ESP8266 Relay ($2.91 + $0.14 S&H - Alternative to the NodeMCU + Relay pairing I'm planning on using)
While I have dabbled with Arduino before, this is a far more ambitious project than I have yet done. Ideally, I will have the rice cooker serve an API, which my Orange Pi will bounce requests across to as dictated by a frontend hosted on the same machine (this resolves CORS, while still allowing options to control the rice cooker by other devices).
For now though, I am away from home, working, so I can't do anything on this for at least another 2 weeks, probably 3. Many of my parts have arrived (rice cooker, thermistors, relay, and NodeMCU), so once I get home, I can hit the ground running.
Terminology
Directive
A directive is an instruction for the rice cooker. User facing directives have, at most, a single input.
Internally, directives chain each other with conditions to achieve their given goal.
Thoughts
Having received shipment of the rice cooker, and beginning to use it, I realize there's nothing about it that makes it fit only for rice, if I can control the heating myself. Everything about it is like any other hot pot, it's just tuned for cooking rice.
Thus, once I convert the thing to being smart, I will be able to use it for, say, ramen, or any number of other things. The possibility of steaming things only furthers this goal.
Recipes
Recipes should be submitted as simple JSON structures. These may be linted, and will contain no logic. All calculations are to be done when producing the recipe. This is done so as to ease the technical burden on the cooker.
Heating / Cooling
Active cooling is not something worth designing for, as it is not an issue to begin with.
Coding
Internally, a temperature kill switch should be enacted, which will kick in if the
API
I tentatively (with no real experience designing them) plan on my API being something like the following.
/action/light/kill- Kill all light activity/action/light/set- Change lighting mode, with optional duration/action/temperature/kill- Stops all heating/action/temperature/set- Heat/cool to given temperature./routine/cook/kill- Kill any current running routine/routine/cook/list- List known cooking routines/routine/cook/schedule/list- List any scheduled routines/routine/cook/schedule/set- Submit/modify/delete a scheduled routine/routine/cook/start- Start a routine/sensor/temperature- Returns temperature/settings/cook/recipe/list- List known cooking routines/settings/cook/recipe/set- Submit/modify/delete a cooking routine/settings/lighting/list- List lighting modes/settings/lighting/set- Submit/modify/delete a lighting mode/settings/time/set- Set/read date and time
Cooking recipe definition specifications
They may be categorized as follows:
Primary Directives
- Heat
- Sleep
Secondary Directives
- Lighting Change
- Lighting Kill
- Temperature Change
- Temperature Hold
- Temperature Kill
Definitions
These are defined as such:
Sleep
Wait for a given duration.
No need to expose to recipes directly, see Kill, Temperature Change, and Temperature Hold instead.
Will keep things like LED lights going still.
Heat
Takes a bool, turns the heating element on or off.
Non-blocking so that conditions may be checked without unnecessarily cycling the relay.
Dangerous to expose to recipes directly, see Kill
Lighting Change
Change lighting mode.
Lighting Kill
Kill any running lighting mode.
Temperature Change
Heat/cool to given temperature.
This should just be a proxy directive to Heat and Sleep.
That is, Heat if under temp, Sleep if over temp.
As heating during cooking tends to be a matter of getting to temperature as quickly as possible, there is no need for a duration setting.
Temperature Hold
Hold at current temperature for given duration.
This should just be a proxy directive to Heat and Sleep.
That is, Heat if under temp, Sleep if over temp, until an internal clock has ticked over the time required.
Temperature Kill
Turns off heat, cancels any running recipe.
Takes no input.
Just a proxy to Heat, but only as a false bool.
Might be used at the end of a recipe, unnecessary though. Mostly to be used as a soft kill switch, invoked from a physical button or via API. Examples might be canceling an infinite temperature holding cycle (e.g rice warming).