W1209 Data Logging Thermostat

This project builds a scripting language for W1209 thermostats. The scripting language is Forth based, but that doesn't mean that you need to know much Forth to get something done (the goal is that you don't need to know it's Forth).

To do achieve this, I'm experimenting with a simple "processing" pattern: chained steps.

\ background task with temperature control
: task ( -- )
  measure            \ measure temperature
  control            \ temperature control
  logger             \ data logging
  menu               \ menu and display code
;

The trick is that, like in jQuery, one can chain "filters" if the data type of "output" matches the "input". In the case of a thermostat that's easy: it's all about temperature.

The other part is that chainable filters are self-contained units. To do this I use basic modular programming techniques, and a chained init function:

\ chained init - starting point
: init ( -- )
;
#include measure.fs
#include control.fs
#include logger.fs
#include menu.fs

In a module, e.g. measure, the initialization looks like this:

\ chained init
: init ( -- ) init
  \ init LPF state with max. value
  dig2temp2 DUP @ 1- 2* 1+ + @ LPFDIG !
;

The word init first calls the init word of the previous module, and the complicated part, e.g. filter initialization, is nicely hidden.

The next thing is the file include hierarchy, a design feature of e4thcom. The file search path is: "cwd:cwd/mcu:cwd/target:cwd/lib" (cwd = current working directory). The standard filter words for an application are in the target folder. In an application, library words can be transparently replaced with a modified version without the need to change the library.

I made a first write-up about some findings on the NTC and the W1209 sensor input. The datasheet referenced by @jeff1937 doesn't match, and it would be nice to learn more about the particular NTC used for Chinese thermostats!

Edit: I updated the Wiki page above: Chinese NTC sensors sometimes have the tag MFA52AT. I found a datasheet that that describes a typical W1209 sensor pretty well (error within 3%).

Grades of 1%, 2%, and 5% of such sensors are common which means that you one should be careful when commissioning a thermostat for applications where keeping a precise temperature is necessary (e.g. chicken incubator, sous-vide cooking).

The repository on GitHub now contains a very simple thermostat for a chicken incubator (apparently that's a very popular application for the W1209).

The core of the program is really simple:

\ background task with temperature control
: btask ( -- )
  measure            \ measure temperature
  DUP .0 CR          \ print it
  TEMPLIMIT < OUT!   \ keep temperature stable
;

The word btask runs in the 5ms background cycle. Forth transfers most data through the data stack (just like a RPN calculator), which is great for concatenating commands! measure performs sensor reading and linearization, leaving a temperature value on the stack (in units of 0.1 °C). DUP duplicates the value for .0 which prints it as ##.#, ###, or -##. CR is just a newline. For the thermostat function the remaining value on stack needs to be compared with TEMPLIMIT (e.g. 375 for 37.5°C). If the 1st value on the stack is smaller than the 2nd, < results in -1 (0b1111111111111111), or else 0. OUT! copies "all ones" or "all zeros" to all the available outputs (which happens to be just one relay). That's all, no condition structure (e.g. IF..THEN) was required. Check out incubator.fs, measure.fs, and inter.fs on GitHub. The whole program consists of just 113 lines of code including linearization, two level filtering, and formatted output.

Of course, one would should probably add some kind hysteresis. But then again, why not go for a PID controller? Yes, that's possible with a relay as the control output.

As for the "definition of done" of the initial user story:

• ☑ Thermostat function with programmable, but fixed temperature threshold
• ☑ 3 digit temperature display
• ☑ bonus: key can be operated while the serial connection works
• how-to instructions, and a ready to use binary
• data logging every 10 minutes

Data logging will be next. Of course without a RTC "10 minutes" will be "about 10 minutes", but I'm sure that it won't be too difficult to work around this on the PC side.