Remotely controllable resistors

Today some new potentiometers arrived – digital potentiometers in Plastic DIP (PDIP) package. I ordered some MCP41010 and MCP41100’s with a value of 10 kΩ and 100 kΩ respectively.

These potentiometers operate with a 2.7-5.5V supply, consume <1 µA and have a SPI interface to control the wiper position. The maximum wiper current can be 1 mA and its position varies linearly according to the 256 positions (steps) to which it can be set. Well, if you need to know more, all info can be found here. And they’re not expensive; <2 Euro each.

The first thing I tried was controlling one of those potentiometers with a spare Arduino and see if I could dim a LED with it.

Digital potentiometer

An Arduino, an MCP41010, a resistor, LED and some wires were put on a breadboard and I started reading the datasheet to find out how I could control the wiper resistance.

There are 3 commands available to control the DigiPot: one to write a new value (to set the wiper position), a shutdown command and a NOP command. After this command byte follows a data byte. For example, to set the wiper position to 25%, 2 bytes have to be sent: 0x11, 0x40. And for 50% it’s 0x11, 0x80. Let’s write some code now…

The Arduino (1.0) SPI library comes with a Digital potentiometer example, so with some  modifications not worth mentioning I came up with this:

#include <SPI.h>

const int slaveSelectPin = 10;

void setup()
{
  pinMode (slaveSelectPin, OUTPUT);
  SPI.begin();
}

void loop()
{
    for (int level = 0; level <= 255; level++)
    {
      digitalPotWrite(level);
      delay(10);
    }
    delay(1000);

    for (int level = 255; level >= 0; level--)
    {
      digitalPotWrite(level);
      delay(10);
    }
}

int digitalPotWrite(int value)
{
  digitalWrite(slaveSelectPin, LOW);
  SPI.transfer(0x11);
  SPI.transfer(value);
  digitalWrite(slaveSelectPin, HIGH);
}

This sketch will continuously brighten and dim the LED each 6 seconds – that’s all there is to it!

Some details that can be important to know is that these digipots have a minimum resistance – for example, the 10 kΩ version I used here has a minimum resistance of 52 Ω. Another thing to keep in mind is that the wiper position goes to the mid-scale position upon power-up, so it doesn’t remember the position it had before the last shutdown.

Why did I buy these digital potentiometers? Well, not to SPI-enable the volume knob on our AV receiver, but to fool our room thermostat and make it believe it’s colder than it really is – either by putting a 10 kΩ version in series with the external NTC sensor or totally replacing it by 2 x 100k parallel, which gives me a range of ≈50 kΩ.

But before I get there, I’ll have to find a more suitable digipot – non-volatile, available in a size I can easily handle (DIP) and as much steps as I will need.

To be continued…

Still not satisfied

After monitoring the temperatures in our house for a week with the new external sensor attached to the room thermostat, I’ve seen improvements and some things I didn’t expect.

The good thing is that the temperatures upstairs went up with approx. 2°C in the rooms upstairs, much closer to what they should be. What worried me was that the temperature in the living-room still got too high sometimes – the floor heating just produced too much heat under certain circumstances.

And the fact that the door between living-room and hallway being open for about 10 cm. still had a lot of influence on the external thermostat sensor in the hallway is something I didn’t expect – I’ll have to do something about that. Keeping that door closed is not a real option – our 3 cats (and hence the rest of the family) wouldn’t like that…

So what are the plans for next week?

Capping the floor heating

It sounds like a good idea to ‘cap’ the floor heating – why should I keep the floor heating pump running when the temperature in the living-room is equal to or higher than the temperature setpoint over there? I can’t think of any reason why I should, so I created a time-triggered event that periodically checks the measured temperature in the living-room, compares it to the room setpoint and shuts down the pump if the temperature is OK.

Creating my own reference temperature

Although the idea of an external temperature sensor already improved things a lot, I’m still not satisfied. What I’d really like to do is ‘feed’ the thermostat with a self-made reference temperature, i.e. a temperature value other than just the temperature of the living-room, hallway or any other individual location in our house. That self-made reference should somehow reflect ‘the need for heat’ throughout the whole house, no matter where that need comes from: living, office, bathroom, bedrooms – wherever.

 

The first one is simple; an appliance module is all that’s needed. The second one needs some more work, namely:

1. How to calculate this reference temperature

Should it be a value calculated based on an accumulation of all errors (measured temperature minus setpoint) of the rooms involved? Or the average error? Should a temperature error in the living-room have a bigger impact than the temperature error in the bathroom? And how about automatic ‘room exclusion’ (as in excluding rooms with a door or window open) from the calculated reference temperature?

2.  How to make the thermostats’ external sensor contact ‘sense’ this temperature?

The external sensor is ‘just’ an NTC, a sensor with a resistance that varies with the temperature. Is there  a way to simulate an NTC with hardware & code? With a digital potentiometer perhaps? But will this digital potentiometer be accurate enough, provide enough resolution and will I be able to mimic the nonlinear R/T characteristic of the NTC well enough?

 

A lot of questions, new things to learn, explore and try out; which is just what I like to do most!

 

Eliminating errors in temperature control

Those who have visited my blog more than once, will probably know about my continuous struggle to get a better control of the temperatures throughout the house, both up- and downstairs.

To demonstrate the biggest ‘problem’ we have here regarding temperature control, I made a chart showing 2 different temperatures. The blue line shows the temperature measured in the living-room, by the internal sensor of our thermostat. The red line shows the temperature measured in the hallway, with an RF temperature sensor.

Oh, and the trends in the chart below could well be just like yours, cause it’s a very common phenomenon:

Temperature charts

Most of the days were sunny, but the last 3 weren’t. The peaks in the blue line (i.e. the temperature in the living-room) are caused by the solar radiation, warming up the living-room to almost 23 degrees! That’s OK of course, but the result is that the central heating will not burn from approx. 12:00 till 18:00. And the whole house, except the living-room, is getting colder and colder.. So no matter what I do, this is the first thing I have to fix -I need a different reference temperature. I know that for quite some time, but never did something about it. Not every thermostat has the ability of connecting a remote temperature sensor to it, I didn’t want to move the thermostat to another location and we sure don’t want to block the sun radiation that’s warming up the living-room for free. (oh and btw: no, the thermostat is not ‘hit’ by direct sunlight).

So last Thursday I added another item to my ever growing collection of hardware to control the temperature inside: a remote temperature sensor.

Honeywell F42010972-001

A week ago I stumbled upon this sensor of which I didn’t even know it existed and immediately decided to buy it and give it a try.

I pulled 2 m. of ‘thermostat wire’ through the wall to my Honeywell Chronotherm Touch Modulation, connected the sensor, configured the thermostat and left the remote sensor dangling in the hallway, near the coat rack and started watching the OpenTherm information.

The remote sensor now replaced the internal sensor of the thermostat and I immediately saw the temperature dropping from 20.5 °C to 19 °C, which is the temperature in our hallway. At the same time, the modulation level of the boiler went up to 100% 🙂 Of course, I’ll have to adjust the ‘room’ setpoint … lowered that one with 1.5 °C as well and things seemed to stabilize again.

That’s part 1 of the story. Part 2 is preventing the heat produced by the boiler flowing to the living-room when it’s not needed there (cause the sun radiation is already produces enough). Well, that’s not that hard – I can control the floorheating pump with an appliance module and switch the pump off@setpoint+0.1°C and back on when the temperature reaches setpoint-0.1°C. Done…

Let’s see what this new setup brings in terms of stability…

Opentherm Gateway operational

Opentherm Gateway and SimpleCortex side by sideToday I finished the monitoring part of the OpenTherm Gateway. The code running on the Simplecortex had proven to be reliable enough to start using it, so why not do just that 🙂

The OpenTherm Gateway you see on the right is my older one, built earlier this year and will be replaced by the new one once it’s finished.

Before I could start on the OpenTherm Gateway, I had to fix some issues which were the result of what I did last week. The MQTT driver was not as stable as I hoped; it worked fine for several hours, but it never made it longer than 48 hours, so I rearranged some code and it has been running fine since then.

Another thing I had to fix was that the Touchscreen, which was transformed to an MQTT client, was disconnected from the broker by the time I came home from work. The reason: the Touchscreen goes into hibernation when nobody’s at home to save energy, which leads to the broker closing the connection! Didn’t think of that one.. before, the touchscreen was a UDP listener, in which case there is no real connection… so I added a timer to the Touchscreen application that periodically checks the connection and re-establishes it when needed.

Back to the OT Gateway. The largest part of the work that still had to be done was preparing my Domotica system. The MQTT topics were already being received, but I had to do something about the payloads. The Opentherm Gateway produces a lot of bit values like for instance CH mode (Central Heating mode); payload ‘0’ means not active, ‘1’ means active. Well, I’m not going to pester users with terms like ‘ch_mode 1’ or ‘dhw_mode 0′; Central Heating mode active’ or ‘Hot water not active’ sounds more like it, right… But again, one of my goals is not to put texts like those hard-coded in any piece of code – not on the Simplecortex which publishes the information, nor in a Touchscreen app, or webpage or whatever.

So I felt really lucky that I started thinking about those things a long time ago and introduced so-called ‘Informationtypes‘ in my system in a very early stage. In a few words, an informationtype can transform a value that represents whatever to something a human can understand. For example with a door sensor, ‘0’ will be translated to ‘closed’ and 1 becomes ‘open’; but the same ‘0’ becomes ‘off‘ in the case of an appliance module. My Domotica system already does that for me and exposes both the ‘raw’ values (0/1 in case of booleans, unformatted data in case of numeric values, etc.) as the ‘formatted’ values (on/off, open/closed, floats with the right number of decimals). Raw data is nice, for computers. But not for humans! Currently, there are 150 informationtypes in my system (in the database, of course) ranging from on/off for a switch to the selected input on my AV receiver (0=”BD/DVD”, 1=”CBL/SAT”…).

So all I had to do was publishing those formatted values as well and I could present those values on a webpage and display something really meaningful … a new MQTT root hierarchy was born: /value.

And doing things this way, enabled me to reduce the code for the OpenTherm Gateway Device class to (almost) nothing more than this (the rest is all constants and type defs):

  case DataInfo.Format of
    flag8: Pin(iTopic).AsBoolean:=(Payload='1');
    u8,s8,u16,s16: Pin(iTopic).AsInteger:=StrToInt(Payload);
    f8_8: Pin(iTopic).AsFloat:=StrToFloatX(Payload);
    dowtod:begin
      { TODO : Finish }
    end;
  end;  //case

So now, when the central heating starts working, there’s (my system being the point of view) “/sensor/OTGW/flame 1” coming in and “/value/OTGW/flame Yes” going out. Now I can make a webpage without displaying meaningless numbers or having to translate those numbers locally that don’t (have to) mean anything to a human.

And here’s the result, showing parts of the information gathered with the OpenTherm Gateway.

 

Same Opentherm Gateway, different approach

Yep, I’m going to build a 3rd Opentherm Gateway 😉
The first one was built on perfboard and became a mess; I never finished it, because before I could the Opentherm Gateway PCB became available, which looked much better. The first PCB version was built somewhere in February 2012 and is in use since August after I replaced the Proliphix NT20e with a Honeywell modulating thermostat.

There’s only one thing I don’t really like that much about the Opentherm Gateway and that’s the serial interface. I like to have all my hardware network-attached, but I’d also like to keep the number of Serial to Ethernet servers to a minimum – right now, I have 6 Serial ports in the meter cabinet (PLCBUS, X10, GSM modem, etcetera) connected to a Serial to Ethernet server. In total, I think I have around 10 serial devices connected that way.

For the third Opentherm Gateway I’m going to try something else; I’m going to leave the MAX232 IC off the PCB and directly connect a Simplecortex to the TTL level output of the PIC that’s on the OT Gateway PCB. This approach has some benefits, like

  • The Opentherm Gateway becomes Ethernet enabled;
  • Programmable TTL to Ethernet conversion;
  • Less €€€;
  • Big reduction on network traffic;
  • more fun!

Yesterday I started with the Simplecortex firmware for the OT Gateway. I want the firmware to be versatile, meaning that it should not only support the Data ID’s that I see going back and forth between my thermostat and boiler. Fortunately the Opentherm Protocol is documented well enough to be able to write code for Data ID’s I’ve never seen in my life. In fact, the definition of how the firmware should deal with all the Data ID’s found in the OT protocol 2.2, comes down to the following:

typedef enum {Read, Write, Both} CommandType;
typedef enum {both, highbyte, lowbyte} ByteType;
typedef enum {flag8, u8, s8, f8_8, u16, s16, dowtod} PayloadType;

typedef struct{
	uint8_t ID;
	CommandType rw;
	ByteType whichbyte;
	PayloadType format;
	uint8_t bitpos;
	char* topic;

} OTInformation;

OTInformation OTInfos[] = {
{0x00,	Read, 	highbyte, flag8, 0, "ch_enable"},
{0x00,	Read, 	highbyte, flag8, 1, "dhw_enable"},
{0x00,	Read, 	highbyte, flag8, 2, "cooling_enable"},
{0x00,	Read, 	highbyte, flag8, 3, "otc_active"},
{0x00, 	Read, 	highbyte, flag8, 4, "ch2_enable"},
...
...
{0x7f, 	Read, 	highbyte, u8,    0,  "slaveproducttype"},
{0x7f, 	Read, 	lowbyte,  u8,    0,  "slaveproductversion"}
};

That’s all there is to it… add about 150 lines of code and the complete set of Data ID’s defined in the OT Protocol 2.2 documentation is supported – no more switch (DataID) with a long list of cases and repeating code…

But I wanted more – I really don’t need to be told that CH is still enabled twice a second; just a report of a change will do. For that I’m going to add a filter that will only report changes. That filter will reduce the network traffic immensely. And of course this Opentherm Gateway will be transformed into a MQTT Publisher, just like my smart meter. And last but not least, this implies that the Opentherm Gateway will act as a MQTT subscriber too, so that I can control the behavior of the OT Gateway and override the thermostat’s temperature setpoint.

Right now, I’m watching the OT Gateway information  on my screen as it is being published:

Opentherm Gateway publishing information

There’s still a lot to do, but considering the fact that I managed to get this far in only a few hours makes me confident that I can finish this project before it starts to get really cold.

Another good thing is that once this project is finished I can shut down the Remeha Calenta driver which has been running for 2 years.

The biggest disadvantage of that driver was that I had to constantly poll the Calenta and that it was based on a protocol specifically targeted at Remeha boilers.

So it all gets much, much better this way!

 

Opentherm Gateway statistics

I had a different post in mind (smart meter follow-up) but hey, if questions arise and I’m interested in the answers just as much, I’m flexible 😉

The question to be answered was: how ‘fresh’ is the data that is travelling from the slave (boiler) to the master (thermostat)?

Is it 30 seconds, as suggested in a comment from Maurice? Quick answer: no.

I added some code to my OT_Decoder tool to collect some statistical data about the Opentherm (OT) frames travelling back and forth and I concentrated on a single Message Type, the Read-Ack.

This message type travels from boiler to thermostat and is in fact a response from the slave to a read-request from the master and can contain values for lots of things like status flags, modulation level, return water temperature etcetera. All these different types of values have been given a so-called Data-ID; status flags = 0, modulation level =17 , return water temperature = 28, and so on. The protocol has room for 256 different Data-IDs.

So when the master sends a Read-Data request to the slave for a particular Data-ID, the slave responds with a Read-Ack frame that holds the Data value.

Here are the statistics I collected:

00 :   0,4 seconds, 4678 times,  5 changes, mintime     4
05 :  57,8 seconds,   66 times,  0 changes, mintime
11 :  59,6 seconds,   64 times,  0 changes, mintime
12 :  58,6 seconds,   65 times,  0 changes, mintime
19 :   4,2 seconds,  787 times,195 changes, mintime     3
1C :  59,5 seconds,   63 times, 55 changes, mintime    59
74 : 235,8 seconds,   16 times,  0 changes, mintime
75 : 235,5 seconds,   15 times,  1 changes, mintime
76 : 235,5 seconds,   15 times,  0 changes, mintime
77 : 235,6 seconds,   15 times,  0 changes, mintime
78 : 235,7 seconds,   15 times,  0 changes, mintime
79 : 235,5 seconds,   15 times,  0 changes, mintime
7A : 235,5 seconds,   15 times,  1 changes, mintime
7B : 235,8 seconds,   16 times,  0 changes, mintime

What does this all mean?

00 is the Data-ID in hex and 0,4 seconds is the average interval between 2 frames measured over 4678 ‘captured’ frames for this particuler DataID. In all these 4678 frames the Data-values changed to another value 5 times and the smallest interval between 2 data value changes was 4 seconds (floored).

Conclusions, assumptions?

  1. It’s better to do this analysis during the winter, where the boiler is really doing something and let the data collection run for 24 hours or so.
  2. Data-ID 00 tells me that the boiler must be the limiting factor here, cause the poll rate is much higher then the smallest interval between value changes. But it could also be that the status of the boiler really doesn’t change faster than that; each transition to another phase (going from idle to burning is not just 1 step) will take time; how much?
  3. Data-ID 1C could lead to the assumption that if the master would poll faster,  a lot of data values would show a different value compared to the previous data value.
  4. The master plays the biggest role in the ‘freshness’, cause it’s the master that dictates what data ID’s the slave has to reply with – no matter how often the slave measures its return water temperature, if the master only requests this temperature once a minute than that’s what you get…

By the way, for those who have their OT Gateway hooked up to a serial port of a Windows PC, have a look at this!

Exit Proliphix Thermostat

Time for something new…

Proliphix NT20eThe Proliphix NT20e has been in use for almost 3 years now. The Proliphix thermostat has brought me a lot of fun (integrating it into my Domotica system, working on the Homeseer Proliphix Plugin to add Celsius support) and comfort. But it’s time for a change!

Last year I built a Opentherm Gateway, because we noticed that a modulating boiler performed much better than a on/off controlled boiler -modulation made the “up’s and down’s” in temperatures disappear – the temperature became much more constant, which also made the floor heating much more comfortable than before.

However, the Honeywell Evohome set I used last year didn’t work well with the Opentherm Gateway; I could not override the temperature setpoint with the Gateway, which was the primary reason why I built it 🙁

I don’t know why it didn’t work, but it may have something to do with the EvoHome RF communication being not 100% 2-way?

Honeywell Chronotherm

So yesterday I dismantled the Proliphix and replaced it with a Honeywell Chronotherm Modulation (wired version). The thermostat cable running from the boiler to this new thermostat has been extended so I can give the Opentherm Gateway a place out of sight, connect a Serial to Ethernet server to it and remotely monitor the OpenTherm traffic as well as override the room setpoint.

To be continued…

Opentherm Monitor finished

This post will be the last one about the Opentherm Monitor. OTOH, when is something really completely finished…

Arduino Serial Monitor

I could spend some more hours on the Opentherm (OT) Monitor and in particular the sketch, but for now it’s good enough. I should add some extra code to validate the OT frame but that would also mean I won’t be able to analyze ‘strange’ frames with unknown Data ID etcetera on my PC. So I’ll leave it as-is for  now. The Opentherm Gateway is waiting 😉

From what I’ve seen during the last 24 hours, the ‘quality’ of the frames I receive is quite good; somehow there seems to be an invalid frame on the wires every minute or so, and I can’t find out what it is. This same thing happens with the Opentherm Gateway Monitor, so I think both are having the same problem. The Data ID tells me it’s probably an OEM frame…?

OpenTherm Decoder

The Opentherm Decoder running on my PC receives the 4 OT bytes from a serial port and decodes those bytes to something human readable: whether the frame came from the Thermostat or the Boiler, Message type and the meaning of the Data ID. The 16-bit data value (there where you can find the temperatures, pressure and status bits) is not decoded yet; well, it’s all in the Opentherm Protocol documentation, so that should be no problem.

Now I can use this Opentherm Monitor as an additional display near the boiler! The Remeha Calenta already has a rather large display showing stuff like status, water pressure, whether the pump is running, but it doesn’t display flow- and return temperature, control setpoint and I’m sure I can think of some more interesting stuff I wanna see – that’s what the Opentherm Monitor is going to do for me. I already have a 16×4 LCD, so all I have left to do is finding a suitable enclosure, build everything in there and I’m done!

I really liked getting this Opentherm Monitor to work without errors; in fact, getting it to work was more exciting than building it. Learning on the job about ATMega timers, Manchester decoding and programming the whole thing in C from scratch was one big adventure.

The most important references I used were:

And here‘s the sketch- no additional libraries needed, free to use and no guarantees that it will work for you just as well as it does for me. Have fun!

 

Getting closer

Yesterday the last parts for the OpenTherm Monitor arrived, so I could finish that part last evening:

– Adding the last part to the PCB (a 4.7 Ω resistor);
– Removing a diode that was there to power the PCB from the RS232 port that I won’t use;
– Replace the 2nd “RS232 power” diode with a wire;
– Cut away the unused headers.

And this is the end result:

OpenTherm Monitor PCB finished So the OT Monitor part is finished now. As you can see the DTR connection is now unused and the DSR connection doesn’t have a diode anymore.

Next step was to have a close look at the additional parts that are needed to connect it all to a JeeNode:

Additional parts

On this part of the schematic (here’s the complete original), 5 new parts are being used:

  • 2 resistors of 1 kΩ;
  • 2 * 2N7000 MOSFET (available here)
7N2000 MOSFET

7N2000 MOSFETThese 2 pictures and the the datasheet saying that

pin 1 = Source
pin 2 = Gate
pin 3 = Drain

is enough to make no mistake with the wiring, even if  you have no clue what the 2N7000 does 😉

 

  • A SN7432N which is a Quadruple 2 input positive OR Gate and can be purchased here

SN7432N

As can be seen in the schematic, a Single 2 input positive OR Gate would suffice just as well; maybe they exist too, but I didn’t bother to search

 

SN7432N powerBesides the 2 inputs and the output signal, the SN7432N als needs to be powered (pin 7 and 14), so the total number of connected pins results in 2+1+2=5.

 

 

 

With a breadboard, a JeeNode, a 4×20 LCD with a JeeLabs LCD Plug on its back, some wires and the SN7432N I mentioned above, this is the end result for now:

 Almost finished

Yep, I’m waiting for the MOSFETs to arrive. As soon as they arrive and I have some time to finish the breadboard, I’m going to put this OT Monitor between the Honeywell Evotouch Wireless OpenTherm RF module and our Remeha Calenta.

Assuming everything keeps working and that I’m not confronted with errors on the display of the boiler, I can try to have a look at the signal on the data pin – and if that looks OK, the next step will be connecting the data pin to the JeeNode and watch the LCD… exciting!

Preparing for OpenTherm Monitoring

More and more my weblog is becoming an ‘archive’ of what I did and, more important, how I did it. I know that I can find that specific picture or other piece of information I’m looking for on my NAS or a local HDD somewhere, but a search on my own weblog is much quicker, and it works too, more and more. So I decided to write down every step I take with this OpenTherm project on my blog and in more detail than I’ve done before – I think I’ll thank myself for that later 😉

Before heating up the soldering iron, I spent some time reading the OT Protocol Specification v2-2. I won’t go into all the details, but here are some important things to know.

OpenTherm is a point-to-point communication system between boilers and room units (the thermostat). The room unit is supposed to calculate a heat demand which is sent to the boiler; the boiler should act on the information provided (more or less heating) and the boiler can also send back various types of information like diagnostics and other useful stuff (to display on the thermostat LCD, for example).

The physical way in which the boiler and thermostat exchange information over the 2 wires is that the boiler transmits a signal by changing the current (high=17 .. 23 mA, low=5 .. 9mA), while a thermostat does this by changing the voltage (high= 15 .. 18V, low = 7V).  The boiler is also supposed to provide the room unit with power, so no batteries should be needed.

The encoding method that’s being used is called Manchester, where a transition from low to high represents a ‘0’ bit value and a transition from high to low is a ‘1’; more about Manchester code here. OpenTherm uses a bitrate of 1000 bits/second.

An OpenTherm frame consists of 32 bits e.g. 4 bytes and those 32 bits are transmitted with a leading start- and a trailing stop-bit. These 32 bits contain information like parity, message type (read, write, read-acknowledge, invalid data), data identifier and 1 or 2 (used) data bytes. In a OpenTherm conversation it’s always the thermostat (room unit) that acts as master; hence, the boiler is the slave. Communication is therefore always initiated by the thermostat, not by the boiler and the latter is supposed to reply within 800 ms. Furthermore, the protocol documentation states that a master must communicate at least every second. (question for myself: how does this relate to a wireless connection between thermostat and boiler?)

That’s enough info for now; lets have a look at the first thing I want to do: monitoring OpenTherm traffic with the Elektor OpenTherm Monitor. Lets have a look at the schematic of the Elektor Opentherm Monitor (OT Monitor) and what has to be done to connect this OT Monitor to an Arduino (or a JeeNode, in my case) – cause that’s the goal of this first step.

 

(the image can be a bit blurry due to the resizing; clicking it will reveal a better image)

The right side is where the builder of the OT Monitor is supposed to hook up his/her RS232 port. But that’s not going to happen – at least not if I can manage to modify the Elektor OT Monitor to this schematic, which I found on a site I mentioned before: http://www.palebluedot.nl/jml/projects/arduino/24-openthermmon.html

I can clearly see the modifications on the right side of the schematic (duh), but to make sure I don’t forget or oversee any of the modifications, I opened the original Elektor schematic in MSPaint and started modifying the original to get to the end result that I need. All modifications were done in red, so that it would become much clearer to me what had to be changed on the original PCB and what additional components had to be added (on a separate piece of perfboard):

 

It might look ugly or silly (or both), but it works for me and that’s all that counts, right? It reduces the labyrinth..

So, 1 diode needs to be replaced by a wire and the other connection with a diode will (must) not be used anymore – that takes care of the PCB-side of what has to be done. That should not be too hard.