Näytetään tekstit, joissa on tunniste lämpöpumppu. Näytä kaikki tekstit
Näytetään tekstit, joissa on tunniste lämpöpumppu. Näytä kaikki tekstit

sunnuntai 7. tammikuuta 2024

Danfoss sisälämpotilasensorin protokollan ja ThermIQ-ROOM2 toiminnallisuuden emulointi - Part 1/2

Danfoss ja Thermia pyytää jälleenmyyjästä riippuen DHP-pumppujen sisätilan lämpötilasensorista 150-250e (ja ThermIQ-ROOM2 laiteestakin saa maksaa 190e), joten otin projektiksi katsoa, että jospa saisin sen toteutettua itse koodaamalla edullisemmin ESP32-raudalla ja omalla piirilevyllä. Ja kyllähän protokolla ruutupaperin avulla lopulta avautui ja ESP32:ssa riittää tehoja yhtäaikaiseen pumpun ohjaukseen ja emuloituun lämpötila arvojen päivitykseen (ESP32 on dual core, joten pistin lämpötilalogiikan toiseen säikeeseen).

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).

tiistai 1. maaliskuuta 2016

Hiiret vs minä 2 - 1

Kävi tuossa muutama viikko sitten niin, että Danfossin lämpöpumppu lopetta tuottamasta lämmintä käyttövettä, ja pumpussa luki "Virhe: Ulkol.Sensori". Siinä mielessäni kiroilin, että taasko Danfossin pumppu reistailee. Sain sitten sähkärin kutsuttua paikalle, ja hän hetken pähkäiltyään toteaa, että hiiret on nakertaneet johdon poikki välikatossa ulos menevään lämpötilasensoriin. Ja hän veti sitten uuden vedon ja taas alkoi hommat pelittämään.

Samalla kävin Biltemasta hakemassa kasan hiiren ja rotan loukkuja joita ripottelin välikatolle. Seuraavana päivänä minä yhden hiiren jo sainkin poistettua roskikeen. Mutta kostoksi jäljelle jääneet(?) purivat uudenkin vedon poikki ja taas rupesi vesi kylmäämään. Tällä kertaa sain houkuteltua naapurin, joka on sähkäri vetämään uuden vedon ja tuomaan vielä suojaputkenkin mukanaan, niin nytten pitäisi ainakin toistaiseksi kestää, jollei hiiret mene putkenkin läpi :)

Tässä on täysi sota julistettu päälle, jossa hiiret vielä toistaiseksi ovat 2-1 johdossa. Kuvittelen kyllä, että ajan kanssa loukkumäärää kasvattamalla minä lopulta selviän voittajana....

tiistai 9. helmikuuta 2016

Danfoss datakaapeli part II

Olinko jo aikaisemmassa postauksessa rakennellut noita datakaapeleita muutaman (http://omakotikotitalomme.blogspot.fi/2015/03/danfoss-lampopumpun-salaisuudet.html). Noissa Arduino Nanoissa on raudassa oikeasti vain yksi sarjaportti ja muut on emuloituja, joten jos haluaa useammalla laitteella yhtä aikaa pumppua lukea tai ohjata, niin saattaa joskus lukeminen vähän bugata. Joten päätin päivittää projektini käyttämään Arduino Mega2560:siä, koska niissä raudoissa on neljä sarjaporttia sisäänrakennettuna, joten data liikkuu paljon varmemmin.

Samoin noihin saa varsin mukavia muoviplexikotelointeja halvalla, joten hintakaan ei montaa euroa ole kalliimpi. Rakensin heti neljän sarjaportin version itselleni (jos joku muu haluaa vastaavan, niin porttien määrää voi tietenkin vähentää jollei ole tarvetta neljälle). Tässä kuvia rakentelun etenemisestä.

Samalla väänsin Raspberrylle imagen, jossa on esiasennettuna ThermIQ- ja taloLogger-softat, niin pystyn tarjomaan myös esiasennetun vaihtoehdon niille, joille Linuxin säätö ei ole niin tuttua tai niille, jotka haluavat säästää asentamiseen menevää aikaa :)

Kiinnitin Mega2650 kaksipuoleisella teipillä kiinni ja kuvasta huomaa myös miten custom kaapelini kiinnitetään Danfossiin, eli kaapelin ylin piuha on katkaistu / ei käytössä. Sarjaportteihin pistin kiinni mini-usb kaapelit jotka menee sitten Danfossin ulkopuolella odottavaan Rapsberryyn (jossa pyörii ThermIQ ja taloLogger webbikäyttöliittymät) ja Macciin, jossa mulla on Arduino yms kehitys/debug työkalut (voin lennossa päivittää koodia ilman, että tarvii ruveta irroittelemaan johtoja).

Vanhan mallisista kaapeleista hp on 40e (hyviä jos ajaa vain yhtä softaa eli ThermIQ tai talologger). Näistä uusista mega2560 pohjaisista (joista tosiaan voi kytkeä useamman usb sarjaportin ulos, ja jolla voi ajaa useampaa softaa yhtä aikaa) hp on 47e. Optioina 8GB esiasennetun Raspbian muistikorttti +6e, 220V->5V poweri (vain mega2560 pohjaisille, jos ei ole esim raspberryssä neljää usb tökkeliä) +5e.

maanantai 9. maaliskuuta 2015

Danfoss-lämpöpumpun salaisuudet

Olinkin jo edellisissä postauksissa maininnut, että haluaisin automaatioprojektissani myös ohjata maalämpöpumppuani. Mutta Danfossin edustaja ei halunnut kertoa, miten heidän nelipinninen liitin ulkoisille laitteille toimii. Niinpä totesin:

Jos ei muu auta, niin TermIQ:lla tuota tulen ohjaamaan, mutta olisihan sen lisäksi kiva tietää, mitä pinnit oikeasti tekee. Joten otin yleismittarin ja ekana katsoin TermIQ:n puolelta statistiikkaa. Neljäs pinni (alin) on GND, ja kolmessa muussa pinnissa oli 2.45V kun USB-piuha on kytkettynä sisään (ilman että on Danfossissa kiinni).

Ekana luulin, että liittimessä kulkisi serial TTL liikennettä 9600 8N1, kun Talologger projektin sorsissa vähän niin annettiin ymmärtää. Joten ekana kun ThermiQ:n pistin laitteeseen kiinni, niin minulla oli signaalianalysaattorit pistetty sarjaliikenne muotoon. Ja ekana luulin että pinnit olisi tx,rx,vcc,gnd järjestyksessä, joten olin analysaattoriin pistänyt tallennuksen alkuun pulssin triggeriksi ekaan pinnin. Se olikin väärä arvaus ja sitä triggeriä ei laukaistu missään vaiheessa. Joten siirsin triggerin sitten toiseen ja kolmanteen pinniin. Johan alkoi lyyti kirjoittamaan, mutta eipä analysaattori tunnistanut sitä sarjaliikenteeksi. Joten päättelin (olammin kommentin perusteella, kiitos siitä) sitten, että talologgerin sorsien ThermiaSerial koodi käyttää "Husdata"-kaapelin StatLink.exen formaattia ja kyseistä kaapelia ei enään voi ostaa mistään uutena.

Joten tämänhetkinen arvaukseni on 5V logiikalla toimiva I2C seriaali (8-bittinen signalointi). Vaihtoehtoisesti liikenne olisi voinut olla COMLI-protokolla (eräs ruotsalainen sivusto näin väittää) joka myös on I2C:n päällä. Ja voihan se ollakin COMLI:n joku variaatio, jossa komennot on yleensä 12-bittisiä, voi olla että analysaattori pilkkoo ne vain 8-bittiseen formaattiin (COMLI:stä esimerkki c-toteutusta löytyy esim.: http://fossies.org/linux/nut/drivers/al175.c ja Java referenssi toteutus: http://www.avineas.org/index.php?page=abb-comli). Itse kyllä I2C seriaalina tuota tällähetkellä kohtelen koodissani (ja sillä myös tuntuu toimivan).

Eli nykyinen arvaukseni (tai siis tieto mittausten jälkeen kytkettynä Danfossiin) pinnien järjestyksestä on:



VCC 5V
SCL
SDA
GND

Ja totta tosiaan, tuolla oletuksella kun conffaa analysaattorin kiinni pinneihin, niin logeihin jää oikean näköistä dataa, joka matchaa ThermIQ terminaalin AT-komentojen tuottamaan dataa. Eli kuka vain voisi ottaa sopivan edullisen 5V Arduinon tai Raspberryn (kunhan käyttää 3.3V<->5V bidirectional level convertteria.) ja rakentaa I2C:n päälle oman kaapelin ihan murto-osalla kaupallisten vaihtoehtojen hinnasta. Itse asiassa normaalit Raspberryt ei tue I2C slave modea, joten Raspberry käyttö menee vaikeaksi. Uusimmissa B+ malleissa GPIO19 (CLK) on jo saatavilla, mutta edelleen se taitaa vaatia omaa I2C koodia, kun normaali I2C kirjasto tukee vain master modea. Tässä pistän mietintämyssyn päähän, että jos minulla olisi tarpeeksi vapaa-aikaa, niin voisin rakentaa ja myydä omia custom kaapeleita tuohon. Katsotaan mitä saan tämän kanssa aikaiseksi (jos haluat ostaa minulta custom Thermia/Danfoss-kaapelin, niin blogin sähköpostiosoitteeseen vain yhteydenottoja. Lupaan olla yli puolet halvempi kuin ThermIQ. Tällähetkellä työn alla on kaapeli joka emuloi suoraan ThermIQ sarjaportin AT-komentoja (jolloin voi olemassa olevia softia käyttää suoraan). Osien tilaus Kiinasta saattaa kestää muutaman viikon, jos minulla ei juuri sillähetkellä ole osia hyllyssä.).

Mutta tässä nykyinen tilanneraportti, ThermIQ toimii hienosti Danfossin lämpöpumpun kanssa, tuossa ylenpänä on piuhan pinnijärjestys kirjattuna. Ja tässä screenshotti analysaattorin maagisesta toiminnasta:

Tuon kun zoomaa auki, niin näkee, että Danfoss masterin ja I2C slaven välisessä liikenteessä kulkee neljä tavua 0x5C, 0x06, 0x18, 0x0 ([7-bittinen osoite + read|write bitti], rekisterin osoite, rekisterin arvo vähiten merkitsevät bitit, rekisterin arvo eniten merkitsevät bitit(yleensä 0x0 koska arvot on < 256)) eli tuossa tapauksessa Danfossin rekisterin nro 6 arvo on 0x18. Ja esim. Talologgerista tai googlaamalla löytää mitä eri rekisterin arvot tarkoittaa. Samantyylisiä arvauksia dataformaatissa on myös maalämpöfoorumissa, vaikkakin olettavat datan olevan 9600 serial muodossa (tai sitten ovat mitanneet ThermiQ/Husdata:n usb puolen sarjaliikennettä, joka on 9600 8n1 seriaali), vaikka oikeasti se on I2C kortin ja pumpun välillä. Tässä tapauksessa "['return line temp', 6, TYPE_INT16]," -> paluuveden lämpötila on 24C.

Avataan I2C protokollan ensimmäistä tavua vielä hieman lisää, tässä vaiheessa on hyvä olla calculaattori joka osaa näyttää hex-numerot myös binaarina.

0x5C = 0b01011100 -> I2C 7-bit osoite desimaalina on 46 (0b00101110 -> 0x2e)
0x5D = 0b01011101 -> I2C 7-bit osoite desimaalina on 46 (0b00101110 -> 0x2e)

Eli viimeinen bitti punaisella merkittynä on 1=read 0=write, ja 7 ensimmäistä bittiä on itse I2C osoite. Tuon perusteella pitäisi jo pystyä koodaamaan oma kaapeli :-)

Mutta ihan vaan akateemisessa mielessä avataanpas tätä viestiliikennettä hieman enemmänkin, ettei tule semmoista mielikuvaa, että pitäisin osan salassa omaa kaapelitoteutusta varten. Eli kun rekisterin luku on edellä käsitelty (ATR), niin pitäähän sitä varmaan rekisteriin kirjoituskin käsitellä, että voi etänä ohjata haluttuja arvoja.

Analysaattori kiinni ja katsotaan mitä write (ATW370001) pitää sisällään (Tällä kertaa ajoin analysaattoria Macissä):

0x5D = 0b01011101 Setup Read to [] (0x5D] + ACK
0xB7 = 0b10110111 Red == Write/Set Value, Blue (0x00110111 == 0x37 == 55 == ['curve +5', 55, TYPE_INT16])
0x01 = 0b00000001 Vähiten merkitsevä tavu (low byte)
0x00 = 0b00000000 Eniten merkitsevä tavu (high byte)

Joten rekisteriin kirjoitus on aika suoraviivaista; 0x5D, kohde rekisteri|0x80 ja seuraavat on vähiten merkiksevä tavu ja sitten eniten merkitsevä tavu.

Ainiin ja menee tuolla linjalla myös jotain keepalive/ping tyylisiä viestejä, 11111111(0xFF) && 11111110(0xFE), villi arvaus että noi on jotain propriatary broadcast tyylisiä pollaus viestejä read/write lipuilla (koodasin kaapelin vastaamaan pong(FF) noihin ping(FE) viesteihin, jos jonossa ei ole komentoja).

Nyt kun on read ja write komentojen salat kaivettu esille, niin seuraavaksi katsotaan ja varmistetaan, että liikenne tosiaan on I2C:tä, eli pistetään linjan perään Raspberry Pi tai Arduino ja tehdään I2C scanni ja katsotaan montako laitetta vastaa linjan perästä.... ja eikun tuumasta toimeen. Rakensin 3.3V <-> 5V bidirectional level converter piuhan ja kytkin sen Raspberryyn kiinni: i2cdetect ei löydä mitään, joten taisi sittenkin tulla väärä arvaus protokollan suhteen tai vaatii jonkun salaisen kättelyn linjan herättämiseksi. Nostan hetkeksi kädet pystyyn, kunnes ehdin taas jatkamaan debuggausta eli to be continued. Toistaiseksi ohjailen tuota ThermiQ:n läpi, kunnes keksin miten tuo ThermiQ laittaa tuon väylän I2C tilaan.

Päivän verran olin lannistuneena tuosta ekan yrityksen epäonnistumisesta, mutta sitten pistin mietintämyssyn päähän ja päätin aloittaa debuggauksen uudestaan eri näkökulmasta. Rakensin ethernet-kaapelista splitterin, jonka pistin pumpun ja näytön väliin, yleismittarilla kun mittaa signaalintasot niin 12V näyttää olevan ainakin kahdessa johtimessa, ja minun halpa signaalianalysaattori on max 5V jännitteille, joten jätin ethernet portin tutkimisen toistaiseksi jäähylle. Otin uudeksi lähestymistavaksi mitata ensimmäiset 10 sekunttia laitteen käynnistymisestä, joten pistin TermiQ:n kiinni analysaattorin ja käynnistin laitteen, kiva logi tuli. Sitten päätin vielä ottaa toisen boottilogin ilman TerhmiQ:ta, sillä oletuksella että linjan pitäisi olla hiljainen. Mutta eipä ollutkaan, joten bingo välähti mielessäni.

ThermIQ laite ei olekaan masteri vaan se toimii slavena, joten ei olekaan ihme, ettei i2cdetect suoraan portissa löytänyt mitään, kun linjassa ei olekaan muuta kuin pumppu, joka on masteri. Logia kun katsoo, niin se on itse asiassa pumppu, joka lähettää pingia väylälle ja etsii, että onko siellä laitteita. Se etsii 0x2e:tä (jota ThermiQ oikeasti emuloi, joten minun omakin koodin pitää olla 0x2e osoitteessa oleva slave. Samoin se vielä kyselee, että onko 0x2e olemassa, ekana 1.5s bootin kohdalla lähettämällä 0xFD ja 0xFE 7.3s:stä lähtien, johon ThermiQ sitten vastaa 0xFF. Pumppu myös etsii myös 0x32- ja 0x37-laitteita 0x00-viestillä, en sitten ruvennut tutkimaan, että mitä laitteita se etsii: mahdollisesti extra näyttöjä, verkkokortteja, modeemeja tms. Lähinnä akateemisessa mielessä kerron, että pumppu scannaa kolmea eri laitetta väylältä. Meitä lähinnä kiinnostaa matkia ThermiQ:n toimintaa, joten keskityn 0x2e:hen. Joku toinen voi halutessaan koittaa ihmetellä, mitä nuo muut osoitteet ovat.

Tästä sitten syntyi uusi teoria, että I2C:n päällä pumppu on masteri, joka pollaa rekisteriä 0xFE 110millisekunnin välein ja slave vastaa 0xFF, jos jonossa ei ole mitään komentoja. Eli pumppu kysyy, "hei, halutko tietoa mistään?"(0xFE) ja slave vastaa "Moro, en tarvi mitään?"(0xFF), tai sitten se voi vaikka vastata, että "Joo, annappa vaikka rekisterin 50 arvo"(0x32). Näin pollaamalla saa noin 9 rekisterin arvoa sekunnissa. Eli teorian todistaminen todeksi vaatii vain I2C slave devicen koodaamisen noilla oletuksilla. Joten se oli seuraavaksi vuorossa.

Eli otin sopivan 5V logiikalla toimivan mikrokontrollerin ja koodasin sarjapinneihin AT-modeemikomento emulaation ja I2C pinneihin sitten rekisterien luku- ja kirjoituslogiikan, ja tein syntaksin matchaamaan ThermIQ kortin komentoja, jolloin nykyisiä softia pystyy käyttämään halutessaan suoraan. RTC osuuden tein euron patterivarmistetun I2C RTC kellon avulla (Vaihtoehtoisesti voisin suoraan koodata softaemuloinnin Raspberry Pi:llä, jolloin ei tarvittaisi mitään ulkoisia kontrolleja, I2C kaapelin pituudella on vain rajoituksia, eli siinä tapauksessa pitäisi Raspberry jättää Danfossin pumpun sisäpuolelle, ja vaan pistää eetteripiuha ulospäin). Mutta siis koska Raspberry toteutuksen tekeminen on vaivalloista (koska ei ole vielä mitään valmista helppokäyttöistä i2c slave kirjastoa julkaistu), niin keskityin tekemään helpomman serial<->I2C AT modeemi-emuloinnin. Wire I2C kirjasto ei suorilta kyennyt juttelemaan pumpun kanssa, koska pumppu lähettää hieman epästandardin start-bit sequenssin. Mutta muutaman illan koodaus- ja debuggaus-session jälkeen, löytyi oikea paikka Wiren puukotukseen ja nyt näyttää tältä:

Hyvältä näyttää, mokkulani vastaa AT-komentoihin samalla tavalla kuin ThermIQ:n kanssa. Minun moduulissani nostin sarjaliikenteen nopeuden 9600:sta 115200:aan, joten vastailee kyselyihin teoriassa hieman nopeammin kuin ThermIQ. Samoin kun mikrokontrolleri nyt tarjoaa serial pinnit ulospäin, niin siihen voi liittää minkä vaan usb<->serial palikan, ja voi valita käyttöjärjestelmän perusteella sopivimman yhdistelmän (Windows, Linux ja OSX).

Ja nälkähän kasvaa syödessä, joten ajattelin, että mitähän jos pistäisin vielä muutamaan ylimääräiseen pinniin toisen sarjaportin pyörimään, että siihen pääsee käsiksi vaikka kahdella usb<->ttl tikulla, niin silloin tietokoneella olisi esim /dev/ttyUSB0 ja /dev/ttyUSB1, jolloin voi toiseen deviceen pistää kiinni esim ThermIQ:n oman softan ja toisen kiinni vaikka Talologgeri-softaan. Joten ei kun koodausmyssy päähän, ja nyt minulla on myös softaversiot kahden ja kolmen sarjaliikenneportin versiosta (että voin yhtä aikaa pitää ThermIQ:ta ja Talologgeria päällä, ja pystyn vielä kolmannella muuttelemaan arvoja ennakoivasti omasta softasta esim. viiden päivän sääennusteen mukaan, niin voi kokeilla muka säästää sähköä sääennusteilla.

Seuraavaksi kun kaikki omasta mielestäni toimii, on vuoro testata, että toimiiko se nykyisten softien kanssa yhteen. Joten sitten vaan asentelemaan ja testaamaan toimintaa... Olin kakkos-seriaalin pistänyt 9600 nopeuteen ihan vaan yhteensopivuuden vuoksi, ettei tarvi configeja muuttamaan. Asensin ThermIQ-softan Raspberry Pi:hin (asennus käyttää vielä yhtä dokumentoimatonta AT komentoa, mutta sen nopeasti koodasin) ja tämmöiseltä web-liittymä näyttää:

Näyttää toimivan ihan kivasti, vielä pitää testata kuinka kauan toi mokkula toimii ilman, että sitä tarvitsee rebootata. Eli vielä en tiedä, pysyykö toi pystyssä kuukausia ilman ongelmia. Mutta toistaiseksi olen tyytyväinen tämän haasteen lopputulokseen. ;-) Muoviläystäkkeen sain kaksipuoleisella teipillä hyvin kiinni lähelle EXT-liitintä.

PS. Tässä olen kuukauden päivät ajanut ThermIQ softaa raspberryssa tolla mun omalla arduino pohjaisella kaapelilla, ja muutaman oman koodausbugin korjaamisen jälkeen tuntuu toimivan kuin junan vessa. Hyllyssä löytyy osat viiteen kaapeliin, joten nyt on tarvittaessa kaapeleita saatavilla.
PS2. Tässä on kuva uusimmasta kaapeliversiosta, on mukavasti pienemmän kokoinen kuin ensimmäinen versio.

Nytten tuota kaapelia on testattu Raspberryn perässä TaloLoggerilla, ThermIQ ja ThermIQv2 softilla, ja hyvin tuntuu toimivan. Myyntisivu: http://omakotikotitalomme.blogspot.fi/p/myydaan-tavaraa.html
Disclaimer: I2C liikennettä ei ole salattu mitenkään, joten tämä blogipostaus ei pura mitään teknistä suojausta (laitteen valmistajan haluttomuus kertoa liittimen toiminnasta ajaa heidän omia intressejään). I2C specifikaatio on vapaasti luettavissa netissä UM10204.pdf. Samoin en ota mitään vastuuta, jos onnistut hajoittamaan oman pumppusi tämän blogipostauksen johdosta.