Ja pihvi, miksi haluaa pumppun ohjautuvan esimerkiksi olohuoneessa olevan bluetooth tai zigbee mqtt lämpömittarin avulla on se, että pumppu osaa lenossa säätää lämmityscurvea niin, että pysytään tavoitelämmössä. Kun esim. ennenkuin lämpömittarin otin käyttöön, niin huoneen lämpö saattoi hyppiä 20-27C:n välillä riippuen ulkolämmöstä ja käyrästä mitä joskus muistin vaihdella. Ja taas mittarin käyttöönoton jälkeen on huoneen lämpötila käytönnössä aina pysynyt puolen asteen tarkkuudella tavoitelämmöstä (itse käytän huonekertoimena nelosta, jolloin mittarin ilmoittamiin arvoihin reagoidaan nopeasti). Samalla säästyy sähköä, kun ei huonetta lämmitetä hellelukemiin.
Danfossin manuaaleissa lukee, että sensori kytketään kahdella johtimella pumpussa 303 ja 304 liittimiin. Ja jos yleismittarilla kyseiset pinnit mittaa, niin huomaa, että sieltä puskee AC:ta, joten lopullisessa toteutuksessa ESP32:sen ja pumpun liittimien logiikan väliin pitää pistää optoerotin. Mutta siis ekana protokollan ihmettely. Pistin logiikka-analysaattorin kiinni DC pinneihin, ja otin signaaleista capturet ihmeteltäväksi eri lämpötila-arvoilla. Ja ensimmäiseen muutamaan tuntiin en keksinyt mitään korrelaatiota tai logiikkaa signaaleissa, kunnes yksi kaverini sanoi, että toihan näyttää Manchester-variantilta.
Tämän pohjalta tuli sitten kaverilta eka ruutupaperiversio, joka oli pohjana protokollan selvittelyssä:
Tuon pohjalta löytyi aluksi helpot patternit kuten kolmen bitin aloitus ja kolmen bitin desimaalipilkku, jotka pysyy aina samoina. Signaalit 1=0 ja 01=1, joka muutin omassa ascii print koodissani I:ksi ja _I:ksi vähän kuvaamaan sitä miltä tolpat signaalianalysaattorissa näyttää. Ja sitten piirustelin pari ruutupaperia eri arvoja, jonka perusteella lopulta keksin tavan laskea jokaiselle lämpötila-arvolle matchaavan datan.
Ohessa vielä esimerkki capturet 20.1C ja 20.2C lämpötiloista:
Sitten tarkemmat raapustelut paperille bitti kerrallaan, jonka perusteella näkee, että viisi bittiä ennen desimaalia määrittää kokonaisluvun ja neljä bittiä pilkun jälkeen määrittää desimaalit, ja loput viisi bittiä on tarkistussumma. Dataformaatti kun rajoittaa kokonaisluvun viiteen bittiin, niin silloin max arvo mitä tuolla voi raportoida on 31.9 astetta. Sinällään ei vaikutusta normaaliin toimintaan kun tavoitelämmöt yleensä on 18-25astetta, lähinnä knoppitietona, että jos on hellettä, niin raportoitu ylälämpö pysähtyy tuonne. LSB bitti ekana vasemmalta oikealle.
Työläin osuus tuosta oli keksiä logiikka tarkistussumman laskemiseen. Viimeinen bitti oli helppo kun se meni 1:1 suurimman databitin kanssa. Mutta neljän muun bitin kanssa sai pari tuntia ruutupaperia tuijottaa, kunnes tajusi mistä biteistä otetaan xor negaatio ja mistä ei. Lopulta koodasin itselleni ESP32 toteutuksen Arduino IDE:llä, joka muodosti samanlaiset signaalit ja sen lisäksi sylki sarjaportiin debug visuaalisoinnin I ja _I merkeillä.
Sitten kun lämpötilaprotokollan logiikka oli ratkottu, niin sitten olikin aika siirtyä ESP32sen puoleen. Mulla oli jo perus Arduinolle aiemmin tehty Thermia/Danfoss I2C puolen ohjauksesta toteutus, jonka julkaisin open sourcena ( https://github.com/rainisto/arduino_i2c_orja/ ), joten otin sen pohjaksi toisen säikeen I2C logiikalle ja toiseen säikeeseen pistin uuden lämpötilasensorin gpio pinnien heiluttelu emuloinnin. Samoin koodasin MQTT logiikan vastaamaan ThermIQ-ROOM2 laitetta, jolloin pystyy hyväksikäyttämään jo olemassa olevia Home Assistant ja ThermIQ-web implementaatioita. Samoin säilytin vielä USB serial rajapinnan, joten WiFin rinnalla on edelleen tuettuna USB:n yli tiedonsiirto legacy AT-komennoilla, jos haluaa esim. USB:n yli kerätä ja visualisoida dataa esim. taloLogger-softalla.
Valitsin toteutuksen raudaksi samantyylisen WROOM32 (https://www.espressif.com/sites/default/files/documentation/esp32-wroom-32_datasheet_en.pdf) pohjaisen Lolin32 OLED näytöllisen raudan kuin ThermIQ:ssakin. Dual core helpottaa elämää, kun silloin voi lämpötilan säie elää omaa elämäänsä. ThermIQ laitteessa on setup prosessi langattoman ja salaamattoman AP:n yli, mutta itse koen sen verrattain turvattomana, joten minun toteutuksessa asetukset, kuten mqtt serverin osoite ja ssid salasana asetetaan terminaaliyhteydellä USB sarjakaapelin yli. OLED näytölle tulostetaan perustietoja kuten dhcp:lla saadun ip numeron, mqtt:n ip:n, ntp:llä haetun kellonajan jne. Jonkin verran sai ihmetellä ArduinoJson kirjaston kanssa, kun se kippasi muistivuotoon, jos timestamppia päivitti tietyllä tapaa. Mutta lopulta keksin tavan joka toimi.
Ensimmäisen toteutuksen testatasin hyppylankaversiolla, jonka jälkeen jo piirsin piirilevyn, jolloin pääsee ylimääräisistä johdoista suurimmaksi osaksi eroon (sarjaportit pitää napata suoraan WROOM32:sta). Eka levy toimi jo oikein, mutta tein siihen vielä muutamia optimointeja sekä tuen vielä optionaaliselle extra usb yhteydelle. I2C Signal lever shifterille 3V3 (ESP32) vs 5V (pumppu) käytin valmista palikkaa, joka helpottaa kolvaustyötä. Oheisessa kuvassa näkyy ekan proton hyppylankaversio ja sitten jo eka piirilevyversio.
Sitten vuorossa vielä kehikon piirtäminen 3D printteriä varten, että tuon saa nätisti kiinnitettyä ilman pelkoa oikosulusta.
Takapuolelle jätin pienen loven, jolloin esp32sen voi resetoida laiteen halutessaan ja voi halutessaan formatoida settings partition (jos haluaa asettaa ssid ja mqtt settingsit uudestaan).
