Another thermostat on Arduino, but with OpenTherm

Reading the first part of the heading, many of you probably thought - another thermostat on the long-suffering Arduino. And ... It's true - yes, this is another thermostat for the next boiler, the next house, but the truth is only partly - in the article I don’t want to concentrate on the device itself - there are really plenty of them (articles). Undoubtedly, I will describe the thermostat, but I would like to tell you more about how I connected the microcontroller with the boiler itself. So, who cares - please ...

How it all began

First of all, I want to say that I am not a programmer at all and have not dealt with this microcontroller before. My first acquaintance with AVR MK (and indeed with MK) was still in high school when I wanted to find out how this mysterious thing still works. I read several articles and since then I have only fragments left in my memory that could be described in just two words - DDR and PORT - and this was where my knowledge ended. Then there was the university, the 5th year - “Programming microcontrollers” where we all met MSC51 in a virtual environment. There were already interrupts, timers, and everything else. Well, with such a baggage of knowledge I came to the problem. Let's finish on this autobiographical note and move on to the more interesting part.

So, actually, how did the creation of the thermostat begin - after installing the autonomous heating with a gas boiler, I, like many, faced the usual problems - the temperature in the house was very dependent on the weather outside - frost - it was cold in the apartment, you need to increase the coolant temperature in battery powered, warmer - on the contrary. Such dances with a tambourine did not suit me much, because the adjustment of the boiler was complicated by the fact that it was installed behind the door, and the door was backed by a microwave, on which lay a pile of junk. Well, you understand - a needle in an egg, an egg in a duck, etc.
')
This problem was solved very simply - with an OTC sensor (Outside Temperature Compensation), which connects to the boiler and allows it to automatically adjust the temperature of the heat carrier depending on the outdoor temperature. The problem seemed to be solved, but reading the service manual on the boiler (Ferolli Domiproject C24D) quickly crushed my hope - the connection of the external temperature sensor in this model is not provided. Everything? Everything. So, probably, it would be possible to finish it, but in the summer, in a thunderstorm, the control board is still burning in an unintelligible way to me, and talking to the service man (the board was subsequently repaired), I asked if it was possible to connect the OTC to my boiler? He replied that they were connecting using external thermostats. This was deposited in my memory, but I didn’t really concentrate on it until the onset of cold weather, and then the exact same problem.

Leafing through the same service manual, but with the aim of seeing how the thermostat is connected, I noticed that the “OpenTherm controller” is connected to the same terminals. Here I understood - this is IT! Google search "OpenTherm Arduino" also disappointed me again - nothing particularly sensible. There was a message monitor, but this is not the case - I’m listening to, there’s nothing - the thermostat is needed.

Then I stumbled upon an article habrahabr.ru/post/214257 , the end of which upset me - the author without an oscilloscope could not connect the boiler with a microcontroller. And here, if a person’s acquaintance with MK didn’t work out, what should I try? A full description of the Opentherm v2.2 protocol was found on the Internet, which further cooled my heat - the physical level of the protocol was somewhat complicated - a current loop in which data from the boiler is transmitted by the current level (5-7mA - low, 17-23mA - high) , and from the thermostat to the boiler the voltage level (<7V - low level, 15-18V - high), which in turn will require a pairing circuit, and I am very close to electronics. Plus, the data was transmitted by the Manchester code, that ... well, you understand.

Only one conclusion - do not bother - just move the microwave and norms. But I have one peculiarity in character - if you put a certain idea in your head, then sooner or later it will come true - yes, I will forget about it (this idea), but still it’s not going anywhere (it turned out to be the case with home). media center on XBMC, satellite to it, on a DVB card, and many, many other things). You sleep, and the plan is already turning in your head, how to accept the Manchester code.

So, I will briefly describe how the OT / + protocol works (in the article above, OT types are described). Communication between devices takes place in a request-response format. The initiator can only be a thermostat. It sends a request at least 1 time per second and waits for a response from 20 to 800 ms. The messages themselves are 32-bit with one start and one stop bit:

Where MSG-TYPE is the message type for the thermostat:
0x0 - READ-DATA — read data;
0x1 - WRITE-DATA - write;
for the boiler:
0x4 - READ-ACK - confirm reading (it comes the answer);
0x5 - WRITE-ACK - confirm the record;
0x6 - DATA-INVALID - the data is incorrect;
0x7 - UNKNOWN-DATAID - there is no such DATA-ID.

DATA-ID - parameter identifier. The first 128 are reserved and most are already spelled out in the specification, the other 128 are each vendor using at their discretion.

DATA-VALUE - actually, the value of the parameter itself. It may be in a different format, depending on the parameter itself. Two 8-bit flag values, an unsigned 16-bit integer, a fixed-point fractional, etc. For each parameter, a value type is defined.

For each FROM device, a set of parameters is defined, which it must support without fail:

Data id	Description	Thermostat	Boiler
0	Device Status Flags	Must send a read request, with the required functions set in the high byte of the DATA-VALUE field	Must respond to a request with status bits set in the low byte of the DATA-VALUE field
one	Setting the required temperature of the coolant	Must send a write request with the required temperature value	Must respond with confirmation that the required temperature is set.
3	Boiler configuration	Must read parameter	Must respond to the request and support all functions transferred in response
14	Maximum modulation level of the flame	Optional parameter	Must be implemented
17	Current flame modulation level	Optional parameter	Must be implemented
25	Coolant temperature	Optional parameter	Must be implemented

The answer to all other parameters is at the request of the boiler manufacturer.

I will explain a little what flame modulation is for those who do not know. All modern gas boilers are able to regulate the level of flame in the firebox - this is called modulation. The greater the power of the burner, the faster the coolant heats up, too much power leads to constant on / off of the boiler (clocking), too low - to the inability to achieve the desired temperature. The best is the mode of operation in which the boiler does not turn off and burns with an intensity that is sufficient to maintain a given level of coolant.

As you can see - everything is extremely simple - write the implementation and get control of the boiler. But the devil, as they say, lies in the details. Remember the physical level - the data from the boiler is transmitted by the current level, to the boiler by the voltage level - a person new to electronics is confused. Food from the boiler? So how to control the voltage? You can not just connect the wires from the boiler to the Arduino. For those who know, the answer is obvious - this is the current loop and the interface circuit is quite simple. I’m somewhere in the middle, so I’m looking in the Internet and quickly found the otgw.tclcode.com site where enthusiasts made OpenTherm Gateway, however, on PIC. There was a pairing scheme. It would seem - take PIC, yes, please - a good attempt, laziness, but no - I want my own, not that.

That's all - take it, collect it. Then I began to ask the price for details and the set as a whole, but still there was an obstacle in the form of the Manchester code - I simply did not know which way to approach it in order to accept it. Here begins the next part of my story.

Manchester code

In the Opentherm protocol, the Manchester code is used for the physical presentation of data, or, as it is called in the Bi-Phase L specification.

Actually, here it is:



The whole point is that the bits are not encoded by the signal level, but by a transition between the levels in the middle of the period:



In addition, this very transition does not occur exactly in the middle of the period, but somewhere around:



As you can see, the period itself is 1ms -10% + 15% and the transition is somewhere in the middle.

This is where I stopped for a long time. There was no desire to copy something from the Internet, since each project has its own stumbling block, deciding which one feels not just a mindless copy-pasteur of libraries, but a developer who does this very project. This, in fact, is the heart of the thermostat - working with OT, copying it means simply collecting another toy from the designer, and not creating something of your own.

It was here that I wanted to apply all my poor knowledge of the MC - and interrupts and timers, etc. Yes, delay () is much simpler, but firstly the transmission is too slow to receive with delay (), but I wanted to perform other actions in parallel during the reception / transmission, secondly I wanted everything looked decent, and not as an odd student.

I thought I thought how beautifully to catch that transition, and even if it was a front or a decline, and when I looked at it from a different angle, everything became crystal clear why there was a transition at all! After all, the level of the first half of the period is the desired value of the bit:



There is a first step - to take the level of the first half of the period (somewhere after 250 μs after the start) - that’s all the decoding. But here I was waited by the following disappointment - it is not always possible to catch the beginning of the period: if a combination of 01 or 10 is on, then nothing remarkable happens between the periods, because It is obvious that the level does not change - you need to look further. And here the second revelation - in the middle of the period there is ALWAYS a transition - they are coded with 0 and 1. So you can attach to it, and the value of the next bit will be in half the period! It was here that everything finally became clear.

Imagine that we have already taken part of the bits and are just in the middle of the first period:



All that needs to be done is to enable the interrupt by changing the signal at the input. As soon as this happens, it means that we are exactly in the middle of the period. Turn off the interrupt by changing the signal, reset the timer, and make the timer interrupt somewhere in the period (which is 750 µs for the OT), when the timer interrupt is triggered, record the input level, turn off the timer interrupt, which is the required bit and repeat all over again for all the remaining bits.

A special case is the first bit, because wait for his level is not ¾ and ¼ period.

Quickly interrupt handlers were thrown and the firmware was assembled, but how could we debug it without an oscilloscope and a signal generator? The knowledge from the university came to the aid - Proteus, in which you could step by step to see what was happening.

Found, installed, and then all the charms of the practice went - it turns out that the interrupt flags must be forcibly removed before interrupts are turned on, and if you load OCR2A / B before changing the timer mode from FastPWM to CTC, then "this cool slurry turned out" in the program, but as it turned out in the gland is still more fun). Well, and other little things that quickly decided. I remind you that at this stage I didn’t have iron yet, and I didn’t have specific requirements for the thermostat.

I quote a code fragment responsible for receiving the Manchester code:

inline void OpenTherm::receive(){ cli(); first=1;//receiving first bit buf=0;//clear buffer rx=1; data_ready=0; length=0; parity=0; PCICR|=bit(rx_pcie); //enabling Pin Change Interrupt for RX port *rx_pcmsk|=rx_bitmask; //enabling Pin Change Interrupt for RX pin of rx Port TCCR2A=bit(WGM21);//mode CTC TCCR2B=0; OCR2A=TICKS_PER_MS*0.75;//interrupt at 0.75ms TCNT2=TICKS_PER_MS*0.5;//preload 0.5ms TIMSK2=bit(OCIE2A);//interrupt on OC0A TIFR2=bit(OCF2A); sei(); bool OpenTherm::extIntHandler(){ *rx_pcmsk&=~rx_bitmask; //Disable PCINT for RX pin if (first) { first=0; } else{ TCNT2=0; } if (length > MSG_LENGTH){ data_ready=1; TCCR2B=0;//disable Timer2 TIMSK2=0; return 1; } else TCCR2B=bit(CS22); //start timer clk/64 return 0; }; void OpenTherm::timer2CompAHandler(){ uint32_t tmp_buf; tmp_buf=buf; tmp_buf=tmp_buf<<1; if (rx) { if (*rx_port & rx_bitmask) { //Reading RX value tmp_buf=tmp_buf | 1; if (length > 1 ) parity^=1; //Don't calculate parity for start bit } *rx_pcmsk|=rx_bitmask; //Re-enabling PCINT for RX pin TCCR2B=0; //stop Timer2 } length++; buf=tmp_buf; }; } 

The transfer, later, perfectly logically and practically fit into the same handlers.

Timer 2 works all in the same CTC mode with zeroing every millisecond. In the zeroing interrupt handler (OC2A in CTC mode), switch the output according to the next bit. Additionally, the OC2B interrupt is enabled, which triggers at exactly half the period (0.5 ms) and the inverting state of the output. That's the whole wisdom of the transfer.

Here I collected the pairing scheme and in 3 hours I figured out the principle of its operation, which turned out to be quite simple, changed the scheme a little to transfer data in a direct, not inverted form, as in the original:



In addition, I had to write (well, how to write, take from the Internet and change for myself) the signal generator to HDL, because Manually type 34 bits in the Manchester code, this is not 4 or 5.

In the end, reception / transmission were established, and it was time to decide on the necessary equipment.

Equipment

So, I had a boiler (Ferolli Domiproject C24D) and the firmware for receiving / transmitting OT messages in the Manchester code in the emulator. It's time to move on.

What, above all, is necessary for almost every device on the Arduino? Arduino itself? Wrong! Enkoder, and certainly with a button, how is it different? It's just that I was always attracted to this type of input device - you have to try it.

Next, the thermostat needs to get the temperature in the room and outside - for this purpose, 2 DS18B20 sensors will work, one will be filled with hot melt and put on the street, the second will be on the board. Naturally, a display is needed - without it, you can simply put radio components in a jar, wrap it in Silpo bag and prevent it - the effect is identical. I decided to take a standard sign-generating LCD 20 * 4 - it would have been enough, I2C port extender for LCD. The controller itself - quite enough Arduino Nano (now I would take the Pro Mini with a programmer, then I will tell you why). Well, a handful of details for the pairing scheme.

As you can see from the photo in the title, something went wrong. The seller had very attractive prices for everything, so I decided to change the list a little. Instead of two DS18B20, I took one in a waterproof case + DHT22, so now you can get more humidity in the room. LCD 20 * 4 was not available, and I took the display from Nokia 5110, there were no encoders with a button, so the usual + 2 buttons were taken.

After receiving everything was soldered and tested on test examples. The first thing we blink is the LED (as I understood when the Arduino board was first turned on, this is sacred). Everything worked as expected, so you can start to improve.
Despite the presence of hardware SPI on the Atmega 328, I decided to give it up, because the restrictions imposed by him did not make me very happy - MISO automatically adjusts to the input, and SS must be the output - minus two outputs, and therefore we leave the software SPI. I remove the CE display output control from the library and immediately connect it to the GND on the LCD. I get - something like:



I expand the pairing scheme into Proteus and try to repeat something similar on the breadboard:



At the end of the wire you can see the standard terminal strip of the boiler, which turned out to be quite convenient - it is connected and disconnected without the use of tools and removing the cover.

Well, now you can write a primitive firmware and try to communicate with the boiler. I am writing, stitching, connecting, and ...

The boiler works as needed, the article can be closed.
Trollface.jpg

Naturally nothing works.
I poke the tester into the pairing board - it does not work - the input is always 20V. I make out, look, smile. I paid the payment from a friend. Immediately I remembered the dialogue.

-Well, a lot more?
No, almost done. Now this long path to solder and that's it. The main thing is not to forget to connect these two nearby contacts.

Guess from the first time that I forgot?

So the "Product" is fixed, I connect, I check. The levels are normal, you can connect the controller. Connect - silence. All - arrived. Further without an oscillograph there is nothing to do. I will finish as the author of the first article. But there is still a little hope.

We recall the part about receiving, and specifically resetting the timer on the level change in the middle of the period. I thought, you never know, suddenly zeroing is not enough and with the timings of the incoming signal is in general trouble, it means I will turn it off before that at the time of reading the level for a quarter of a period, and turn it on from zero to change - strangely, it helped. It was the same victory - without communicating with MK never before, write a library from scratch, which I did not find on the Internet, and even make it work the second time without an oscilloscope. My joy knew no bounds.

A little away from the feeling of euphoria, I realized that I needed to continue, because flashing the controller every time I needed to read a new parameter (the test firmware read the same parameter once a second), probably not much user-friendly.

I learned to get the values ​​of the parameters, only in this form it is not a thermostat, but a remote display. In order for this to become what is required, you need to learn how to operate the boiler, and here surprises also awaited me.

Debugging and working with OpenTherm

So, the first value - the status of the boiler - received. The only thing that immediately embarrassed me - the DHW temperature when connecting the microcontroller immediately became the maximum allowable, regardless of the setting on the boiler panel, as I later read in the manual to the standard OT thermostat from the manufacturer (Ferolli Romeo W): when it is connected, the knobs serve only enable / disable the relevant functions, and no longer affect anything. It was logical to assume that the value of the DHW temperature parameter will remain as it was before connecting to OT, but Honeywell programmers (board manufacturer and the rest of the automation for the boiler) have their own opinion on this matter.

The control of the boiler was complicated by the fact that I didn’t have a sample thermostat on my hands to see the correct sequence of messages, so it was akin to being blindfolded. In the specification, the DHW Setpoint parameter was found (hereinafter, in parentheses, I will give the DATA-ID of the called parameters, in this case 56), which, apparently, was responsible for the DHW temperature. I rented, stitched - now when the button was pressed, the desired temperature was sent. Checking it is. The water temperature immediately became normal, it is time to start adjusting the CH Setpoint (1) - the temperature of the heating circuit - for which reason everything was started. Here I was stuck for a long time, for three days. No matter how hard I tried, whatever the desired temperature I set, the boiler still kept it around 30 degrees. I already had the idea that the manufacturer was protected from connecting other people's thermostats - the only obvious solution was to consider Member-ID (3) from the boiler and answer it the same (2). And this also did not help, briefly outlined the situation to a friend, and he had an assumption:
- Listen, what if one vendor for the master (thermostat) and slave (boiler) devices uses different Member-IDs. Count how the boiler automation is surprised when it realizes that another boiler controls it?

But everything turned out to be much simpler. It was in the parameter Max CH Setpoint (57) - the maximum temperature of the heating circuit. After the events with the DHW circuit, it was logical to assume that the maximum value is there, but no, the value was set at 30 degrees. After that, things went noticeably more fun.
Here begins the story of the thermostat.

Thermostat

It is obvious that he should give out a bunch of boiler parameters, and be able to change them, without this there would be no point in creating another thermostat at all. As I said, each request must be sent approximately once a second, the most logical was to write a finite state machine that will go from one state to another once per cycle, and its states will respond to the current requested parameters. In the end, the branches of the machine turned out 3:
1. A working branch in which the current state of the boiler is polled, temperature, modulation level. In short, it can be represented as follows:



2. The branch of receiving information and the boiler: additional temperature sensors, flow sensors, etc. When you exit the "Info" menu, we return to the first branch.
3. The statistics receiving branch: burner operation time, number of fan / pump starts, etc. When exiting is identical to p.2.

For all this work, the function call update (), without parameters. It is enough to call it approximately 1 time per second. It receives the result of the previous query and sends a new one based on it. To switch between branches, you need to call a function with a parameter that is equal to the first parameter of the desired branch. For example, update (0) goes to the main branch (0 - request status of the boiler), update (18) - the second branch, which begins with a request for parameter 18 (pressure request in the heating circuit), branch 3 - parameter 116 (number of burner starts).

There are also other argument values:
1 - record the new temperature of the heating circuit;
56 - record the new temperature of the DHW circuit, etc.

All possible arguments can be seen at the end of the update function.

So, all the required parameters are obtained, but it was not done without a fly in the ointment - remember, I wrote after the table - all other parameters as desired by the boiler manufacturer? So - half of them in my boiler are zero, half are not known at all. Only wrote in vain, although it may even be useful to someone.

The most routine and boring task, quite obviously, was writing the menu. As promised, I will not go into details about the thermostat itself, everything can be seen in the final firmware
The last thing I decided to add at the time of writing this article is that instead of a boring screen with “many letters”, I made a semblance of a graphic display (something similar to a sample - factory Romeo W). Well, the clock - there are not many of them in the apartment, only the RTC DS323x is missing - when you turn off the power, you have to set the time again. To do this, I had to manually draw a few characters and add them to the font. The result can be seen in the photo in the title and below.




-, , , . . , , , , -. -, .

:

1) CH Setpoint – ( / ).
2) OTC.

, ( (settings.indoor_target_temp-ext_temp)), .

OTC. , , , MIDI . (.. ). , .

, , , Power. . , delay(1000) , 1. , , Timer2 / OpenTherm , , . , Proteus Sleep, . , millis() ( watchdog-), . Pro Mini ( ) – + 3.3, . Power, , :



, – , , :



– . , :



– , . , 3D-, , , . , :

— , ?
— ?
— , , , – .

:




, , , update(), , communicate() — complete() —

Links

github.com/gavrilov-i/OpenTherm
habrahabr.ru/post/214257
otgw.tclcode.com
www.domoticaforum.eu/uploaded/Ard%20M/Opentherm%20Protocol%20v2-2.pdf

PS , , – — , . , .. , OpenTherm, .
PPS , . , — +5, TX ( ), RX ( ) — 1,5, GND.
:

— , . RX ( . ) TX ( R3) +5. 20. R3 — 7 ( 5). , . .