william/blog
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

rice: More planning.

Browse source
This commit is contained in:
William Floyd 2018-07-04 15:50:10 -05:00
parent 01107f17ff
commit 4e805873a5
Signed by untrusted user who does not match committer: william
GPG key ID: B3EEEDD81893CAF9
1 changed files with 30 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

32
content/post/smart-rice-cooker.md
View file

@ -44,6 +44,22 @@ 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
The question is raised, how should I deal with parametric recipes, and more specifically, internally governed parametric recipes.
That is, recipes that have no prior knowledge of the volume of rice and water added, but infer it from the time it takes to reach temperature.
This value, that is, the duration taken to reach temperature, only holds value when a set heating cycle is used, such as full heat, or constant PWM.
Typically however, no PWM is required during initial heat, only once at heat.
As such, a value that any directive may rely upon should be the duration taken by some prior directive.
This then leads me to say that each and every step in a recipe must have a unique identity, so that later directives may rely on them.
This, then, immediately appears to be far more complicated than I should worry about, instead, this behaviour aught to be offloaded to Lua or some other scripting system.
As such, the NodeMCU should be ideal, as it supports a variation of Lua.
Ideally, this will allow branching logic also, and storing of values, simplifying my technical burden.
Alternatively, it does not sound impossible to write a simple translator to emit both a Lua scripted version of a recipe, and a version that may be embedded directly into the compiled code (so that non-Lua boards may be used).
## Heating
The contents of the rice cooker should be considered when heating/cooling, as they will absorb the heat and thermal lag will be an issue.
@ -92,7 +108,19 @@ I tentatively (with no real experience designing them) plan on my API being some
Directives are distinct actions to be taken.
They include:
They may be catagorised as follows:
#### Primary Directives
* Sleep
* Heat
* Cooling
#### Secondary Directives
* Temperature
These are defined as such:
### Sleep
Just wait for given duration, or until a given condition is met.
@ -106,7 +134,7 @@ If I someday choose to use a fan, this should be an active feature.
Instead, it's the same as `Sleep` for now.
### Temperature
Heat/cool to given temperature, optionally at a given rate of change (may be difficult for cooling if no fan is included).
Heat/cool to given temperature, optionally at a given rate of change (may be difficult for cooling if no fan is included), or percentage load (which will set a PWM rate, or if full, run constant).
This should just be a proxy directive to `Heat`, `Cool`, and `Sleep`.
For now that should work, but in due course, with tuning and benchmarks, this should run cooling at a variable rate (using a fan, I wouldn't want to cut on and off all the time).
Heating should be fine be fine with fairly large PWM, as the thermal lag I expect to be significant, and we want to try to hit our deadline as quickly as possible.