W1209 Data Logging Thermostat

Getting started with any new technology involves a learning curve. If more than one new concept is involved then the learning curve can appear "steep". A good part of that steepness comes from those talking about the technology: they assume too much about what the non-initiated will understand. That's known as the curse of knowledge.

I got a good demonstration of the curse when helping someone to get started with the W1209 Data Logging Thermostat. Things I took for granted were everything but, and bugs were lurking behind them.

You live and learn: if someone can't use the docs to get started find out why. Refactoring should not only look at the technical side, but also at how accessible the code is. One recent development that made maintaining and using STM8 eForth projects easier is the modular build: it's no longer necessary to develop board-support and core in lockstep since the board support code can be maintained in the application project. The result is easy to use binary releases for applications.

@paulcrawfordgm turned the W1209 Data Logging Thermostat into a cooling controller with a serial interface:

The project started here on HaD, continued with an STM8 eForth issue, and was completed in TG9541/W1209 issue #22.

Paul achieved the following:

• coping with a non-standard W1209 board variant (Nuvoton chip, 5K NTC pull-up)
• set-up of Travis-CI for Paul's fork of the TG9541/W1209 repo
• changed control.fs from heating to cooling
• menu adapted and simplified, logger.fs removed
• serial interface for temperature data with counter and CRC-16

The process of problem resolution and the Forth learning process worth reading!

Among other things, e.g. using the W1209 firmware for cooling, a problem with the menu has been fixed: transmitting characters quite often resulted in erroneous key inputs.

Now that has been fixed in the master branch. The discussion inIssue #22 is also quite interesting!

Solar heating controllers need at least two temperature sensors. Such a thing can be hacked using a W1209, but I decided to design a new PCB (mostly because I try to avoid relays in things that I expect to work for more than 10 years unattended).

To keep a log of my progress I started a HaD project Solar Heating Controller. Maybe it catches your interest!

A GitHub user documented a W1209 clone with a common anode display. This issue describes how to spot such a clone, and it also contains code patched for using the CA display. This board will be supported in the near future.

I found one more clone with a different PCB layout, and I ordered one for examination.

@richard got a couple of W1209 boards, and some of them just couldn't be flashed. It turns out the at least one manufacturer (namely TENSTAR ROBOTS) makes boards with a nearly pin compatible 8051 based µC (a Nuvoton chip in a TSSOP20 package). Details are at the end of the GitHub Issue here.

Mitigation: don't buy boards that look like one of these:

Note that C5, the Vcc capacitor next to the µC, is unpopulated. The backside of the black board is bears the label "TENSTAR ROBOT W1209". The label on the back of the green board is "XH-W1209". The Nuvoton is quite fast, and if you like programming the 8051 it's maybe not the worst choice. However, please don't count on my help for programming it. I'm done with MCS51 ;-)

@BigVulcanDeal let me know that there are boards with a 5k, instead of 20k, reference resistor. That's a good match for measuring temperatures in the range of 30°C to 50°C, but you'll need to replace the linearization table in measure.fs.

I've just release a new, improved version of the W1209 Data Logging Thermostat: now the data logger registers the following data:

• relay activation cycles per log interval
• relay duty cycle
• lowest, and highest temperature in the cycle

Used properly, this data can be used to improve the control behavior (heating power), or for getting clues on the effects of heat flow & thermal mass, sensor location, or quality of the insulation:

Check out the README on Github for features, source, and instructions!

By default, the firmware exploits the fact that the Value Line STM8S003F3 µC is just a STM8S103F3 with relaxed specs, and with only 128 bytes of EEPROM memory specified. All the chips I tested hat the full 640 bytes of the "Access Line - Low Density Devices" available, and I decided to use all but 64 bytes as a ring buffer, enough for more than 24 hours at a rate of 10 samples per second.

The ring buffer requires a single head pointer, which, for practical reasons, must be in the EEPROM. The number of EEPROM write cycles of Value Line devices, however, is specified with 1x10^5, in the full temperature range with nominal data retention, that is. At a rate of 10 log entries per hour a 20ct µC is still good for 10.000 hours, more than a year.

I have little doubt (not "little doubts", like my Indian colleagues usually say when the strongly disagree) that the number of write cycles at room temperature, and with random data, is more in the range of 1x10^6, more than 10 years. The "electrical life" of a Chinese low-end relay in a thermostat application is most likely much shorter.

There is finally the the first (pre-) release of the W1209 $1.50 data logging thermostat!

It's based on the latest STM8 eForth (pre-release 2.2.20.pre.1), and the binary was automatically built in uCsim, and deployed, by Travis-CI.

Features are:

• heating thermostat, e.g. for building chicken egg incubators
• basic sensor failure detection
• parameters for set-point, hysteresis, and trip-delay
• easy to use parameters menu (no need to search for a manual!)
• temperature logger with 0.1h to 10h interval, and a 288 entry ring-buffer
• logger access through a serial console
• fully programmable in Forth, even while the thermostat is running!

Although it's feature-complete, it's work in progress.

For the future, the following feature are planned:

• Improved logger with min/max temperature, and heating duty cycle
• Field-bus feature for thermostats
• more fail-safe features (parameter integrity, maybe a buzzer)

It's been a while since I last worked on this little project. The reason was that I concentrated on the STM8 eForth foundations:

• development framework with a Forth library
• e4thcom support
• codeload.py with emulation of the e4thcom features #include, #require, and \res
• automatic generation of "aliases" for unlinked words in STM8 eForth words
• Continuous Integration/Test/Deployment with Travis-CI

The GitHub W1209 repository now also uses these goodies, and the Makefile automatically installs the specified revision of STM8 eForth from the binary release.