I spent a couple of hours reverse engineering the recipe storage format a couple of months ago, but haven't had time to write anything up. My notes are a bit inscrutable to me, but I'll post them here in case it helps anyone develop some way to share recipes. It's very minimal, with each recipe taking only 36 bytes. The recipes are written in a continuous span in the file and overwritten without nulling out the underlying bytes first.
Here is my understanding of the recipe structure, italicised text representing uncertainties.
- Bytes 1-20 are reserved for the name, each byte corresponding to the ASCII value of the letter or character, with the hex sequence `00 30 31` denoting early return.
- Bytes 21-30 are empty.
- Byte 31 corresponds to the temperature in Fahrenheit. If the temperature is above the max decimal value expressible by a byte (255), the high bit on the next byte, 32, is high (e.g has a value of `1` rather than `0`), indicating that `255` is to be added to the integer value represented by byte.
- Byte 32's 4 minor bits represents some sort of bitmask corresponding to the power level, I believe. 0000 = 1, 0010 = 2, 1000 = 3, 1100 = 4
- Byte 33 corresponds to the hour timer value.
- Byte 34 corresponds to the minute timer value.
- Byte 35 corresponds to the second timer value.
- Byte 36 possibly corresponds to the action(s) to take after the timer ends and/or when to start the timer? Possibly a split byte like 32.
Provided the uncertainties are done a way with, it should be a trivial matter to write a small piece of software (a web service, perhaps?) to generate these files from shared recipes.
