Ik wilde de CV-aanvoertemperatuur van mijn al wat oudere Remeha-ketel, de W21/28 ECO, op een lagere temperatuur instellen. Ik hád de instelling 60° al gekozen met behulp van het “gewone” bedieningspaneel, maar ik wilde lager. Dat kan, maar je hebt er een “servicedisplay” voor nodig.
Gelukkig vond ik op internet verschillende afbeeldingen van de Remeha “Print Display”, “S54802” of “S42754” – en wie weet ook nog onder andere namen of typenummers te koop. Met behulp van de volgende twee afbeeldingen bleek het vrij eenvoudig om de aansluitingen van de serviceconnector thuis te brengen:
De chip is een echte Philips, een SAA1064 “4-digit LED driver with I²C-bus interface”, een chip uit 1991 of daaromtrent. Nog even de printbanen volgen en voilà: na een uurtje studeren had ik de informatie die ruim tien jaar geleden hier https://www.domoticaforum.eu/viewtopic.php?f=17&t=5595&start=15 door gebruiker Spierie gevonden werd, ook nog eens he-le-maal zelf uitgezocht. (Chapeau).
Dat kunnen we met modernere middelen best nadoen. Ik bezit nog wel wat 5V-compatible Arduino’s; ook een 5V-compatible LED-display lag in de onderdelendoos. Die laatste was gebaseerd op een TM1637 en eigenlijk is de opzet met een microcontroller dan volkomen idioot: de aansturing van de TM1637 verloopt namelijk óók via een two-wire-interface; het enige echt belangrijke verschil is dat de SAA1064 alleen naar “adres” 0x70 luistert; de TM1637 kent geen addressering en interpreteert gewoon alles wat je aanbiedt. Onze Arduino-interface met de Remeha is dus, als je het heel kaal bekijkt, eigenlijk een heel erg ingewikkelde manier om een I²C-slave-adres uit de bus te pikken.
En zelfs dát doe ik niet goed: de SAA1064 heeft in zichzelf nog een relatief complexe logica, waarbij je achtereenvolgens een instructie-byte verzendt; deze kan 0, 1, 2, 3 of 4 zijn; na een “0” volgt eerst nog een control-byte, daarna pas volgen een of meer digits.
Van al die mogelijkheden maakt mijn Remeha gelukkig helemaal geen gebruik. Deze zendt gewoon altijd een 0, daarna een control-byte met in elk geval de instelling “gebruik 4 digits” en tenslotte de vier bytes die elk een 7-segments-display symboliseren.
Nóg een voordeel is, dat Philips bij het ontwerp van de I²C-bus blijkbaar zo’n standaardiserende werking heeft gehad, dat de bits van de LED-segmenten in de datastroom bij de TM1637 op precies dezelfde plek zitten als bij de SAA1064. Oftewel: je kunt de datastroom één-op-een doorsturen vanuit de Remeha naar de TM1637.
Al met al wordt het uitlezen dus best gemakkelijk. Ik hing er nog even een voeding aan, (met simpele transistor en zenerdiode) en het resultaat was dit:
De TM1637 is in het schema niet zichtbaar – die hang je eenvoudig aan de pennen 8 en 9 – let op de pull-up-weerstanden.
De code is zo goed als triviaal, als volgt:
#include <wire.h>
#include <TM1637Display.h>
#define CLK 8
#define DIO 9
static volatile byte i2ccomm[6];
TM1637Display display(CLK, DIO);
void setup() {
display.setBrightness(0x01);
// Start the I2C Bus as Slave on address 0x70/0x71.
// the Wire library uses 7 bit addressing, with
// the last bit interpreted as read/write:
// hence we listen to 0x70>>2 which is 0x38
Wire.begin(0x38);
// Attach a receiver function
Wire.onReceive(receiveEvent);
}
void receiveEvent(int bytes) {
if (bytes <= 6) {
int a;
for (a=0; a<bytes; a++) {
if (Wire.available()) i2ccomm[a]=Wire.read();
}
}
}
void loop() {
uint8_t segments[] = {
i2ccomm[2],i2ccomm[3],
i2ccomm[4],i2ccomm[5]
};
display.setSegments(segments);
delay(500);
}
Het resultaat is een Remeha service-display. Op latere ketels is dit ding gewoon onderdeel van de ketel zelf, wel zo handig trouwens. In een volgend artikel zoek ik uit wat de andere I²C-berichten op de bus betekenen, want nu we toch bezig zijn, is dat eigenlijk net zo interessant.