Wat er in de Haddon M1.1 & T1.1 zit

Kort samengevat

M1.1 (IC1) praat via een met Timer1 getimede bit-bang-UART op 666 baud met de buitenunit (PC3 = TX, PC4 = RX; DIP28-pin 26/27, exact wat WIRING.md zegt). Het ontleedt de binnenkomende telegrammen: uit bericht-ID 2 haalt het drie temperaturen — aanvoer, retour en buitentemperatuur — die het door 10 deelt en als hele graden opslaat.

T1.1 (IC2) is geen simpel bedieningspaneel maar een tweezijdige OpenTherm-brug: slave richting de Anna-thermostaat, master richting de CV-ketel. Het laat OpenTherm-frames tussen beide door en herschrijft onderweg specifieke Data-ID's. Dáár zit de bijstook-beslissing.

Op hardware bevestigd gemeten

Na dit verslag is de brug nagebouwd: een eigen ATmega328P in de IC2-socket en een ESP32 in de IC1-socket, die via de 9600-baud-sporen op de print met elkaar praten. Daarmee is een aantal conclusies hieronder niet langer afgeleid maar gemeten.

De print doorgemeten gemeten

Alles hieronder is met de meter vastgesteld, met beide chips uit de voet en op doorbel/weerstand, zodat geen halfgeleider de meting kon vervuilen. Waar een conclusie uit de firmware kwam en het koper die bevestigt of tegenspreekt, staat dat erbij.

IC2-socket, alle 28 pinnen

Van de IC1-socket is tot nu toe alleen pin 14 (PB0) doorgemeten: R21 (10k) naar de status-LED.

Onderdelen

Dat de LM7805 gevoed wordt uit de LM7818 heeft een prettig gevolg: leeft de 5 V, dan leeft de 18 V ook. Een dode OpenTherm-bus bij een werkende chip kan dus nooit een voedingsprobleem in de 18 V-tak zijn.

De drie relais — en waarom er maar één tegelijk mag

+18 V --+-- R27 (100 ohm) --+-- spoel K1 --+
        |                    +-- spoel K2 --+-- collector T3 -- basis: PB2 (pin 16) via diode + R26 (10k)
        |                    |
        |                    +-- spoel K3 ----- collector T4 -- basis: PC5 (pin 28) via R
        |                                       emitter T4 ---- frontschakelaar -- massa
        |
        +-- emitter Q1 / emitter Q4 -- de 18 V-bus naar de thermostaat

Alle drie de spoelen hangen achter dezelfde voorschakelweerstand R27 van 100 Ω. Dat is geen detail: trekken K1+K2 en K3 tegelijk aan, dan zakt de spoelspanning tot een niveau waarop niets meer betrouwbaar schakelt. Atlantic heeft die combinatie ook nooit bedoeld — het is óf een OpenTherm-ketel óf een aan/uit-ketel. Wie deze print nabouwt moet die vergrendeling zelf in de firmware zetten.

De twee OT-interfaces zijn niet symmetrisch gebouwd

Dit is de belangrijkste vondst voor iedereen die deze print aanstuurt. De firmware behandelt beide kanten als spiegelbeeld, maar het koper doet dat niet.

De ketelkant is een keurige optocoupler-interface. De thermostaatkant is een discrete hoogzijdedriver: T1 in gemeenschappelijke basis stuurt Q4 aan, die de 18 V op de bus zet. Bewust ontworpen, geen bijzaak — en met de omgekeerde zendpolariteit ten opzichte van de ketelkant. PD4 moet laag om spanning op de thermostaatbus te zetten, PD3 moet hoog om de opto-LED te laten branden.

Die twee tegengestelde leesinstructies in de originele firmware zijn dus geen slordigheid maar de exacte weerslag van deze asymmetrie. Wie ze gelijktrekt "omdat het toch hetzelfde protocol is", krijgt een kant die zwijgt.

De dipswitches

Wat de nabouw leerde

De brug draait inmiddels: een eigen ATmega328P in de IC2-voet, een ESP32 in de IC1-voet, met een echte OpenTherm-thermostaat aan de ene kant en een CV-ketel aan de andere. Beide kanten decoderen frames zonder pariteitsfouten. Vijf dingen die daarbij naar boven kwamen en die niet uit de disassembly alleen af te leiden waren:

Methode — en twee bugs in het gereedschap

Er was geen AVR-toolchain beschikbaar, dus is een eigen recursive-descent disassembler geschreven (avrdis.py) die de controlflow volgt vanaf de reset- en interrupt-vectoren, zodat datatabellen niet als instructies worden gelezen. Onderweg zijn twee fouten in dát gereedschap gevonden en hersteld — beide hadden gevolgen voor de analyse:

Waar een conclusie voor de hand ligt maar niet klopt, staat dat er expliciet bij. Een verslag dat alleen het eindantwoord geeft, laat de volgende in dezelfde valkuil lopen.

Topologie

Dit is het punt waar de meeste analyses de mist in gaan: T1.1 hangt tussen Anna en de CV-ketel in, niet als eindpunt eraan. Alle warmtevraag loopt dus fysiek door T1.1 heen, en die kan per OpenTherm-bericht besluiten of de vraag naar de ketel gaat of (via M1.1) naar de warmtepomp.

M1.1 (IC1) — de warmtepomp-link

Architectuur bevestigd

Stack-init op 0x045F (RAMEND van een ATmega8), BSS-clear bij boot, vijf init-routines, dan een oneindige superloop van negen taken. Drie van de 19 interrupt-vectoren zijn actief:

Pin-toewijzing bevestigd

De temperatuur-parser bevestigd

In sub_0308 vanaf 0x03dc controleert M1.1 of het ontvangen bericht ID 2 is (CPI r18, 0x02) en haalt er vervolgens drie 16-bits waarden uit, elk gedeeld door 10 via een aftrek-lus:

Dat alléén de derde waarde een tekenafhandeling heeft is het beslissende bewijs dat dit de buitentemperatuur is — dat is de enige van de drie die onder nul komt. De ontvangbuffer begint op 0x7b met de 0x91-header, dus 0x7c = ID, 0x7d = lengte, daarna de payload: precies de indeling uit het bekende Chofu-protocol.

De 5°C-uitschakeling bevestigd

SRAM 0x65 functioneert als een gezondheids-aftelteller. De Timer1-ISR telt hem elke 60 ticks (~15 ms) met 1 omlaag; de regellogica laadt hem telkens terug op 180 zolang alles goed gaat. Zakt hij onder 60, dan schakelt sub_062e het vraagrelais uit (0x06d0: CPI r16,0x3c → CBI PORTB,0).

De buitentemperatuur-check staat op 0x069c:

069c  LDI r30, 0x73        ; laad buitentemperatuur
06a0  LD  r16, Z
06a4  CPI r21, 0xc8        ; >= 200 ?  (= negatieve temperatuur)
06a6  BRCC 0x06b0          ;   ja -> koud
06a8  CPI r21, 0x05        ; <  5 ?
06aa  BRCS 0x06b0          ;   ja -> koud
06ac  ANDI r23, 0x7f       ; nee: "koud"-vlag wissen, klaar
...
06b0  ORI  r23, 0x80       ; "koud"-vlag zetten
...
06c2  LDI r16, 0x3c        ; 60
06c4  DEC r16              ; -> 59
06ca  ST  [0x65], r16      ; teller HARD onder de drempel

Knoppen en schakelaar bevestigd

• PC0 — CV-only-schakelaar (sub_02ae, SBIS → actie bij HOOG): zet het vraagrelais uit en reset de tellers. Met de pull-up op PORTC betekent dit dat de open stand "alleen CV" is; sluiten geeft de warmtepomp vrij. Dat is een verstandige fail-safe: valt de bedrading weg, dan stookt de ketel door.
• PC1 — Test-knop (sub_02d2, SBIC → actie bij LAAG): zet het vraagrelais weer aan en herlaadt alle tellers, mits de laatst gerapporteerde snelheid ≥ 20 was en er geen communicatiestoring geregistreerd staat. Dit is precies de handmatige tegenhanger van de automatische uitschakeling hierboven — wat verklaart waarom deze knop werkte om de unit terug te dwingen naar warmtepompbedrijf.
• Reset-knop: komt nergens in de code voor, dus vrijwel zeker direct op de AVR-RESET-pin bedraad.
• Let op waar het voorpaneel-lampje zit. Beide chips hebben een storingsuitgang, en dat is verwarrend. M1.1's PB1 (socket-pin 15) is een simpele aan/uit die "foutcode is niet nul" volgt (0x04b6). Maar het lampje op de voorkant is de knippercode van T1.1 op PC4, socket-pin 27 — in de praktijk bevestigd: dat lampje stopte met werken zodra de originele T1.1 uit de socket ging, terwijl de ESP32 in IC1 gewoon doordraaide. gemeten

T1.1 (IC2) — de OpenTherm-brug

Waarom het een brug is, geen eindpunt bevestigd

• Twee ontvangstkanalen: de analoge comparator (SBIC/SBIS ACSR,5 = ACO, in sub_0286) en PD5 (sub_0398). ACSR = 0x40 zet bit 6 (ACBG) — de bandgap-referentie — en laat ACD op 0, dus de comparator staat juist aan. Dat is de klassieke OpenTherm-ontvangstschakeling.
• Twee zendkanalen: PD3 (sub_0892) en PD4 (sub_0958).
• Beide richtingen worden gekopieerd: 0x0490 kopieert buffer 0x89 → 0x8d, en 0x053e kopieert 0x8d → 0x89.
• De berichttypes verraden de rollen. In OpenTherm zit het type in bits 6–4 van de eerste byte:

Die laatste is doorslaggevend: een Unknown-DataId als default-tak (0x0850) is leerboek-slavegedrag en komt in geen enkele andere toepassing voor.

Een doorgeefluik met vijf uitzonderingen bevestigd

T1.1 implementeert de OpenTherm-specificatie niet. Beide richtingen hebben dezelfde opbouw: kopieer byte 0 en 1 (berichttype + Data-ID) van bron- naar doelbuffer, vertak op de Data-ID, en val voor al het overige door naar een generiek pad dat byte 2 en 3 ook gewoon overneemt — een compleet ongewijzigd frame. Die paden staan op 0x0532 (richting ketel) en 0x066a (richting Anna) en doen letterlijk niets anders dan twee bytes doorschuiven.

Voor wie T1.1 wil nabouwen is dit de belangrijkste vondst van het hele onderzoek: er is geen OpenTherm-stack nodig, alleen een transparante brug plus vijf onderscheppingspunten. Alles wat je niet kent geef je door, en dat is meteen ook het veiligste gedrag.

De herkende Data-ID's

Pariteit en Manchester bevestigd

sub_0870/sub_0872 is geen BCD-conversie maar de OpenTherm-pariteitsberekening: negen keer roteren door carry, en bij elke gezette bit SWAP r18 (togglet 0x08 ↔ 0x80), waarna ANDI r18,0x80 + ADD r16,r18 het pariteitsbit in bit 7 schuift. Bewijs: dit zijn exact de twee ROL-instructies die T1.1 bezit. Dat sub_0872 ook los wordt aangeroepen — zonder de r18-init — laat zien dat de pariteit over het hele 4-byte frame wordt doorgeteld.

De fysieke laag is Manchester: in sub_0892 wacht de code tot de tick-teller op 4 staat (de helft van 8) en inverteert dan de pin op basis van de teruggelezen stand (SBIC PIND,3). Timing: reload 0xFC3A = 966 cycli plus overhead ≈ 124 µs; 8 ticks per bit ≈ 1,00 ms = 1000 bit/s, precies de OpenTherm-bitrate.

Pin-toewijzing T1.1 bevestigd

Waar de bijstook-beslissing valt interpretatie

Zoek je naar een CV-ketelrelais, dan vind je het niet — en dan is de verleiding groot om te concluderen dat bijstook buiten de firmware om geregeld wordt. Dat klopt niet: de ketel wordt niet via een relais aangestuurd maar via OpenTherm, door T1.1 zelf. De relevante logica staat vanaf 0x0676:

• De van Anna ontvangen Control Setpoint wordt bewaard in 0x6e/0x6f.
• Op 0x0688 wordt die vergeleken met 0x14 (= 20).
• Onder de drempel antwoordt T1.1 met statusdata 0x00 (idle); erboven met 0x02 (CH-modus actief) of 0x0a (CH-modus + vlam).
• Op 0x04be schrijft T1.1 een Write-Data ID1 met waarde 0x0a00 — een Control Setpoint van 10,0 °C richting de ketel, feitelijk "blijf uit".

Dat is dus het omschakelpunt: T1.1 bepaalt met een drempel op de warmtevraag of de ketel een reële aanvoertemperatuur krijgt of op een pro-forma 10 °C wordt gezet. De precieze koppeling met M1.1's vraagrelais heb ik niet volledig uitgewerkt.

Protocol M1.1 ↔ T1.1 bevestigd

Hardware-UART, UBRRL = 0x67 met U2X = 1 → 8.000.000 / (8 × 104) ≈ 9615 baud. UCSRC = 0x8E geeft 8 databits, geen pariteit en twee stopbits — eerdere versies van dit verslag zeiden 8N1. Voor een ontvanger maakt dat niets uit, die kijkt alleen naar de eerste stopbit. Beide kanten sturen een 12-byte telegram: een kop-/statusbyte (bij M1.1 vast 0xF0), tien databytes, en als sluitbyte een eenvoudige 8-bits optelsom — geen CRC. T1.1's zendlus loopt van SRAM 0x7C tot 0x88 — precies twaalf — en zijn eerste twee bytes zijn 0x00. M1.1 stuurt hierover onder meer de uit ID2 geparste temperaturen en zijn statuscode; T1.1 gebruikt die statuscode voor zijn foutcode-indicator.

De statuscode zit op telegram-index 10 en belandt in T1.1 op SRAM 0x73. De tabel in sub_0aa0 vertaalt hem naar 1–7 (0x01→1, 0x41→2, 0x46/47/48/52/14/15→3, 0x31→4, 0x45→5, 0x53→6, overig→7), met 0 = alles in orde en 100 = vastgelopen.

Vergelijking met chofu_wp.cpp

De uitgaande telegrammen zijn volledig gedecodeerd opgelost

De flash-tabellen rond 0x0baa–0x0c4f zijn gekraakt. De sleutel zat in sub_083a: de byteteller loopt af van 45, verdeeld over vier segmenten van 15 + 10 + 10 + 10 bytes. Bij 10 bits per byte is dat exact 12 + 8 + 8 + 8 telegrambytes.

De codering is: 8 databits LSB-first, dan een stopbit (1) en meteen de startbit (0) van de volgende byte, aaneengeschakeld en MSB-first in de flash-bytes gepakt. Omdat 10 niet op 8 deelt, schuift de framegrens elke byte 2 bits op — en precies daarom werkt bit-omkering per flash-byte alleen voor de eerste byte (die geeft correct 0x19) en loopt het daarna uit de pas. Met de juiste framing valt alles op zijn plek.

De vier telegrammen, in de volgorde waarin ze per cyclus worden gezonden:

@0x0bbe (15B)  19 01 0c 00 00 00 00 00 00 00 aa 35   ID1, 12 bytes
@0x0be2 (10B)  19 02 08 <modus> <stand> 00 <crc>      ID2, variabel  (zie tabel)
@0x0bce (10B)  19 03 08 b2 02 00 c1 9a               ID3
@0x0bd8 (10B)  19 00 08 00 00 00 d9 b5               ID0

Het variabele ID2-telegram is geen berekening maar een vooraf uitgerekende tabel van elf varianten, geadresseerd als 0x0be2 + 10 × (stand / 4):

Ten slotte staan er op 0x0baa en 0x0bb4 nog twee geldige telegrammen (19 02 08 00 ff 00 9e c9 en 19 03 08 00 00 00 37 67, beide CRC-correct) die door géén enkele adresberekening in de code worden bereikt — restanten van een eerdere firmwareversie, of van een variant met een tweede ID3-vorm.

De eindconclusie. Qua telegraminhoud is er geen gat: de bytes die M1.1 zendt zijn byte-voor-byte dezelfde als die de ESP32 opbouwt, en de live CRC-berekening is zelfs algemener dan Atlantics vooraf uitgerekende tabel. Maar qua bereik zijn er twee echte verschillen, beide in het voordeel van de ESP32 op één punt en in het nadeel op het andere: de 5 °C-lockout is verdwenen (winst), en het standbereik is van 10 naar 7 teruggebracht (verlies).

Dekkingscontrole: zit er nog iets in de chips? volledig geauditeerd

Op de vraag "zit er nog iets in wat we gemist hebben" is het eerlijke antwoord: dat weet je pas als je alles boekt. Daarom is elke byte van beide dumps ingedeeld als code, tabel of leeg. Dat leverde twee nieuwe feiten op en een sluitend bewijs.

Vondst 1: M1.1 heeft dode ADC-code

De 12 onverklaarde bytes op 0x0158 zijn twee complete, maar nooit aangeroepen initroutines (geverifieerd: geen enkele sprong of call komt hier uit):

0158  LDI r16, 0x86 / OUT ADCSRA, r16 / RET   <- zet de ADC aan (prescaler /64)
015e  LDI r16, 0x40 / OUT ACSR,   r16 / RET   <- zet de comparator aan (bandgap)

Een eerdere revisie las dus een analoge sensor uit. In deze build is die mogelijkheid bewust uitgeschakeld door de aanroep te verwijderen. Dat bevestigt de eerdere conclusie dat M1.1 geen eigen sensor gebruikt — maar nu met de nuance dat de hardware-voorziening er wel was.

Vondst 2: de "gedeelde firmware"-theorie is nu bewezen

De tweede dode routine in M1.1 is byte voor byte identiek aan sub_015c in T1.1 — waar hij wél wordt aangeroepen, als OpenTherm-ontvangstweg. Omgekeerd bevat T1.1 116 bytes onbereikbare code in drie blokken, waarvan twee onderling identiek. Onder die dode code zit een pad dat het pariteitsbit omklapt en bit 0 van de statusdata zet — in OpenTherm het storingsbit, dus een "meld een fout aan Anna"-route die deze build nooit neemt.

Dat beide chips dode code van elkaar bevatten, maakt van de eerdere veronderstelling een vaststelling: Atlantic compileert één gedeelde codebasis per model en laat de ongebruikte paden in flash staan. Dat verklaart ook waarom T1.1's foutcodetabel veel meer waarden kent dan deze M1.1 ooit kan versturen.

Open vragen

Inmiddels is de brug nagebouwd en op echte hardware gedraaid, dus een deel hiervan is niet meer afgeleid maar gemeten — zie Op hardware bevestigd. Wat resteert:

1. Deels open De rest van de printtopologie. Nog niet doorgemeten: waar de collector van Q4 uitkomt, waar de basis van Q1 vandaan komt, de common van K1, wat K2 precies schakelt, en waar dip-pin 3 en de gelijkrichterbrug op uitkomen. Zie De print doorgemeten voor wat er wél ligt.
2. Onopgelost Wat PB3 doet. Wel scherper in beeld: PC3 draagt de echte telegrammen uit flash (CRC-geverifieerd), terwijl PB3 in hetzelfde tempo bytes uit de RX-buffer op 0x7b uitschuift. Die stroom heeft géén geldige UART-framing, dus PB3 kan geen tweede protocollijn zijn — een diagnose-/echo-uitgang of een niet-bevolkte voorziening in deze printversie is aannemelijker. Voor het nabouwen van M1.1's gedrag maakt het niets uit: het commando zit volledig op PC3.
3. Rest onopgelost Welke storing bij welk foutnummer hoort. Dat de nummers uit de buitenunit komen en in zeven categorieën worden gegroepeerd is nu duidelijk (zie hierboven), maar de betekenis per nummer staat niet in deze firmware. Daarvoor is servicedocumentatie nodig.

Bestanden

Alle bestanden staan naast dit document in dezelfde map. De listings zijn opnieuw gegenereerd met de gecorrigeerde disassembler.

Bronmateriaal

• Haddon M1.1 - ATMEGA8@DIP28.BIN ruwe flash-dump IC1 · 8704 bytes
• Haddon T1.1 - ATMEGA8@DIP28.BIN ruwe flash-dump IC2 · 8704 bytes

Listings

• Haddon_M1.1_disassembly.lst volledige listing IC1 · gecorrigeerd
• Haddon_T1.1_disassembly.lst volledige listing IC2 · gecorrigeerd

Reconstructies

• Haddon_M1.1_reversed.ino C-reconstructie IC1 · verouderd, zie waarschuwing
• Haddon_T1.1_reversed.ino C-reconstructie IC2 · verouderd, zie waarschuwing

De links werken zolang dit document in dezelfde map staat als de bestanden. Bekijk je deze pagina via een gedeelde webversie, dan zijn de bestanden daar niet meegepubliceerd.