The aim of the project is to implement digital control for temperature regulation. My radiator is a cheap old pure resistive device. It has internal probe.

Problems I want to solve:
- internal probe has a large tolerance (big interval between the ON and OFF temps)
- internal probe is too close to the resistor, thus, as the resistor heats, the probe get's hot
- when the is a log of wind, the probe get heated by the resistor, while the rest of the room cools down. The more wind, the colder.

I know the root problem is the design of the building. But, in this paper, we will focus on the electronic solution. What I want is a digital sensor with less than 0.1° tolerance, that will be "far from the radiator" so that it will sens the average temp of the room. Not sens the resistor itself ^^ .

The second aim of the product is to perform quick hash of power in order to:
- have an homogeneous temperature over time (not wait 10mn for temp to go down 0.1° before we put heat again)
- average the current from wirering (thus power absorbed by the electric installation)
- reduce the risk of over-current and avoid getting the "electric provider disrupter" jump over. My disrupter performs an average over about 10s: I can use way more (10%) current than I *should* as long as the average current over 10s is what I pay for. By hashing at high speed (1 to 5s periodicity) we avoid many problems that happen when radiators work 10mn per hour.

The product also should be extensible:
- LCD itnerface to show set temp, actual temp, average variage of measured temp, and power ratio (as we will use )
- support several probes, so that we can sens several places at a time (floor, roof, middle of room, close to window)

= First prot =

My first prototy was in fact way more efficient than I expected :)

But before going further, I will detail a bit my first external I2C probe.

I use an I2C probe by Microchip. My initial idea was to use the conventional 4 wire I2C bus, but, on the day I soldered the external probe (I had one probe onboard, then, I wanted to have an off-board one), I only found 3 wire ribbons in my bin.

So, I just made up a 3w I2C devide. The trick is to remove the Vcc line. Put a capacitor on the slave side between Vcc and Vss, and two diodes from the data and clock lines to Vss. It is also advisable to use 1kR pull-ups on master side (instead of traditionnal 10kR). My first 100nF capa was way too small; voltage went below slave minimum before it could even receive it's adress; this broke up the whole bus (even the onboard device was unusable). I found a 10uF CMS electro capa (4mm high, 3mm diametre); does the job. Data frames have to be send as much spaced as possible. If too close, the capa cant recharge; dont remember the capa can only recharge when lines are left high. Clock speed can't be too high (higher noise => data loss), nor too low (frames too long => Vss get's low)

My initial idea, was to compute an average temperature of all connected probes in the room, and, estimate the lost power (heat lost throught walls), and, balance it by applying hashed power to the radiator: to avoid noise problems of halogene that cut the "main sin" in the middle, use full sin, and put power only 1s every 2 or 3s. Ideally, work on a 10s period, compute required percentage, and alias 1%=0.1s. Then, when the temp goes below the set value, we increment the ratio (percentage), or decrement when the temp rises up. A clever algo should be able to smooth ratio changes, and avoid large temp variations.

The first version of my software used the internal probe. Informations sent over serial line shown that the probe was very precise, and stable at the 0.1° scale without any problem. When using the external probe, serial data shown that read value was unstable, with 0.3 to 0.4° rapid variations (in less than 1s). I did not stuck on this problem, and, went forward to compleet other aspects of the proto before studying if this was really a problem. For example, by that day, I had not yet solder the triac to control mains to radiator.

I think that variations of the value read on external probe are due to voltage variations: all digital probes rely on some kind of voltage reference, or, at least, any kind of voltage stability. I think that bus frames that flow at random frequency produce small and large variations to Vss of the probe, so that, as Vss remains higher (4.3V) than recommended minimum (2.5V for the device), it keeps working, but, with small errors. The value read is "reasonnable": always 0.5° around the value given by first probe. But, not stable.

When i ran the proto for the first time, with the external probe, I was happy to see that it behaves exactly how I needed:
- because of the small error in reads, when the temperature is low, all values are below the SET value, and, radiator is fully ON.
- when the temperature is close to SET, let say, 0.2 below, some errornous read will state it is higher than SET; let say 15% will be wrong in this way. Thus, after each of those read, the radiator will be OFF for 1/4s (duration of my loop). What replicates, somehow, 15% less used power on an average over 10s.
- when the room temp is exactly the SET value, the software reads half values too low, half too high; it will work, usually, 1/4s every half second.

So, if I accept a room temperature variation of + or - 0.4° around the SET value, this proto is already 80% of the objective. I just changed the loop duration to 1s, to reduce the noise in mains. When the probe is located at an apropriate place in the room, the temperature is just exactly the right one every where all the time.

In theory, if the radiator is powerfull enough, the real temperature of room should not go below SET-0.5°,  and never above SET+0.5°.

If a better external probe ever returns a stable value in the future, instead of writing a complex algo using percentages, I will just introduce a software way a random error in the read value.

Problem solved.