154 lines
5.4 KiB
Markdown
154 lines
5.4 KiB
Markdown
---
|
|
title: "Smart Rice Cooker Conversion"
|
|
date: "2018-06-18"
|
|
author: "William Floyd"
|
|
categories: [
|
|
"Development",
|
|
"Hardware",
|
|
"Software"
|
|
]
|
|
tags: [
|
|
"Arduino",
|
|
"Rice Cooker",
|
|
"Aliexpress"
|
|
]
|
|
---
|
|
|
|
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](http://ali.onl/128Y) ($26.40 + $3.16 S&H - The star of the show.)
|
|
- [Thermistors](http://ali.onl/128Q) ($2.97 - 100pcs, for temperature readings)
|
|
- [NodeMCU](http://ali.onl/128R) ($2.47 - To, hopefully, allow me to WiFi control the whole thing)
|
|
- [Relay](http://ali.onl/128V) ($0.76 - To switch power on and off.)
|
|
- [ESP8266 Relay](http://ali.onl/128T) ($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).
|
|
|
|
# Dep Graph
|
|
|
|
<img src="/images/rice/connections.svg">
|