Okos otthon is fókuszban

Arduino kalandok

Arduino kalandok

Computherm Q8RF - rádiózzunk - part 2

2019. április 24. - denx

Az előző részben sikerült odáig eljutni, hogy magam kell visszafejtsem a rádiós kommunikációt a termosztát okosításához. Az is valószínűnek tűnik, hogy 868.35 MHz lesz a frekvencia, amin üzenget egyik készülék a másiknak. Hogy megfejtsem az üzeneteket rádióznom kell. Említettem, hogy az RTL-SDR lesz erre a megfelelő eszköz, amiből találtam is egyet a szekrény mélyén.

Most megpróbálom rekonstruálni hogyan és mit is sikerült elérnem a rádiózás megfejtésében.

Szósöl média

Első körben megpróbáltam a manapság divatos módon elkezdeni a visszafejtést. Fészbukon van egy magyar ardu csopi, feldobtam oda a kérdést, hátha. Sok sikerrel nem jártam, a következő válaszok jöttek:

  1. Ez bonyolultabb, mint gondolod, felejtsd el!
  2. A biztonsági kód miatt úgy sem fog menni...
  3. Miért így akarod megoldani? Miért nem cseréled le a vevővel együtt az egész kócerájt

1: Nos, a bonyolultság relatív dolog. Nem érzem magam profinak rádióhekkelés terén, de ezt azért egy megugorható szintek ítéltem, nem szegte kedvem ez a hozzászólás. (Természetesen azt sem tudom, hogy aki írta mennyire van ott a témában...)

2: A biztonsági kód kérdését szerintem sikerült ott a hozzászólásokban tisztáznom. A gyári rendszer a leírása alapján használ egy úgynevezett biztonsági kódot. Én ezt nem nevezném igazából biztonsági kódnak, csupán arról van szó, hogy az adó az üzenetben elküld egy kódot, a vevő meg (az összepárosítás után) csak ezt a kódot figyeli. A dolognak akkor van jelentősége, ha egy egész lakótelepet ugyanilyen rendszerekkel akar az ember felszerelni és van egy olyan igény, hogy az emberek ne egymás fűtését kapcsolgassák. Ezt a kódot újra lehet generáltatni az adó oldalon, ha netán előállna ez a nem túl valószínű helyzet, ezután a vevőt be kell tanítani az új kódra. Ez nekem igazság szerint kapóra is fog jönni, ugyanis ha sikerül a jelenlegi kódot megfejteni, akkor utána elkezdek új kódokat generáltatni az adóval és így rá fogok majd jönni, hogy az üzenetben melyik rész mit jelent.

3: A "miért nem cseréled le az egészet" hozzászólást is próbáltam letisztázni. 2 okból látom értelmét ezt a rendszert hekkelni:

  1. A vevő oldalon erősáramú kapcsolgatás megy végbe. Ezt nem annyira okos ötlet házilag kókányolni. Ha neadj' Isten leég a kecó és a biztosító talál ilyesmire utaló jeleket, akkor szívás van.
  2. Mivel itt a ház fűtéséről van szó, ezért nem lenne rossz, ha egy back-up rendszer is lenne. Ha mondjuk a Home Assistant valamiért letérdel, vagy az azt futtató raspi adja meg magát, akkor nem örülnék egy kihűlt háznak. Ha sikerül a tervem, akkor a termosztátok maradnak a helyükön, fel lesznek programozva, csak manuálisan alacsony hőfokra lesznek állítva. Ha bármi balul ütne ki elég a termosztátokon megnyomni egy gombot és átveszik a központ szerepét, megy tovább minden úgy, mint most - okosítás előtt.

SDR

Szóval nem találtam kész megoldást, továbbra is a saját út maradt az egyetlen. Ehhez első körben elkezdtem utánaolvasni hogyan lehet munkára fogni az említett RTL-SDR cuccot.

sencor522.jpg

Nekem egy ilyen eszközöm van, gyors keresés után kiderült, hogy ez tökéletesen alkalmas lesz a feladatra.

Az RTL-SDR oldalán annyi anyag van, hogy nehéz belekezdeni is a dologba, én először is az SDR# nevű programot próbáltam ki. Ez egy ingyenes cross-platform program, nagyon sok minden tud. A csomag, amiben letöltöttem tartalmazott mindent, bár nem volt túldokumentálva. A lényeg, hogy egy install-rtlsdr.bat fájl segítségével letöltötte magának a legfrissebb alternatív drájvert, majd egy zadig.exe nevű programocska futtatásával rá lehet venni a Windowst, hogy az alternatív drájvert használja inkább. Ha ezzel megvagyunk, akkor indulhat a móka!

Látszólag egyszerű felület mögött rengeteg funkció van, enélkül a program nélkül nem is jutottam volna sokra. Amikor beállítottam a kívánt frekvenciát (868.350.000 Hz) és rányomtam a lejátszás gombra, akkor fent egy folyamatosan ugráló EKG-hoz hasonló dolog kezdett mocorogni, alul meg... talán a leginkább egy földrengésjelző szeizmográf hasonlít a leginkább erre: mintha fentről lefelé folyamatosan mozogna egy végtelen papírtekercs és amint a felső részen valami megjelenik, az lenyomatot hagy a mozgó papíron. (Mint megtudtam ezt waterfall-nak nevezik, találóan.) Ez különösen hasznos akkor ha nem vagyunk biztosak benne, hogy mi is a pontos frekvencia. Ugyanis ahogy a képen is látszik, egy beállított nem túl szűk tartományon belül látni fogjuk az érkező rádiójeleket.

Amikor beindul a vétel, akkor a termosztáton manuálisan be kell állítani egy, a jelenleginél magasabb hőmérsékletet, majd 2-3 mp múlva a kijelzőjén megjelenik egy piktogram, ami arra utal, hogy a fűtés megy. Na ezzel egyszerre küldi ki az RF csomagot az éterbe, vagyis ilyenkor kell figyelni a vevőnket, mert a "bekapcsoló" üzenetet láthatjuk ilyenkor.

Ennél a pontnál derült ki, hogy a gyárilag tervezett 868,35 MHz helyett a vevőm 868,307 MHz-nál találja a jelet. Ennek 2 oka is lehet: vagy az adó nem pontos, vagy a vevő. Én inkább az utóbbira gyanakszom, de ez nem vet vissza semmiben! Azért nem tartom ezt akkora gondnak, mert egy olyan, kifejezetten olcsó vevőről van szó, ami 0.5 és 1750 MHz között képes jeleket venni. A legtöbb RF vevőt ennél nagyságrendekkel kisebb tartományra szokták hangolni (pl egy kocsiba szerelt autórádió 85 és 108 MHz közötti tartományt képes venni). A másik oka hogy nem aggódok az az, hogy úgymond megbízhatóan csal: ha napokkal később, több újraindítás után, akár másik gépbe bedugva is próbáljuk használni, akkor is pont ugyanezen a frekvencián fogjuk venni a jelet.

Moduláció

Ha megvan a vivő frekvencia, akkor érdemes 1-1 csomagot felvenni, majd később elemezgetni. Ezen a ponton rengeted időt el lehet szórakozni, mert az SDR# programban is rengeteg beállítási lehetőség van, én is sokat tököltem vele. A konklúzió az lett, hogy a legfontosabb a frekvencia jó megtalálása. Nekem a 868,500 MHz-nál jött a legjobban értelmezhető eredmény:

Amikor egy másik, látszólag erős frekvencián próbáltam rögzíteni az adást, akkor ilyesmit kaptam:

Persze ez sem teljesen használhatatlan, de ebből nem lehet egy könnyen kivenni a magas és alacsony jelszinteket, vagyis a morzejel megfejtése elég nagy kihívás így!

Az RF jel rögzítése elég bonyolult dolog tud lenni, komoly fizika és matematika van mögött, nem mennék bele a részletekbe, de ezen az oldalon elég jól le van írva ez is, meg még pár hasznos dolog: link. (Figyelem! Spoiler Alert!)

A képeket egy Audacity nevű ingyenes hangszerkesztő programból vágtam ki. Ezt eredetileg hangfájlok editálására fejlesztették, de nekem most hatalmas segítséget adott, sikerült eldöntenem, hogy milyen modulációval is van dolgom.

Hekkerkedés

Először kézi módszerrel estem neki az adások és szünetek méricskélésének, tanultam ebből is. Miután rengeteg kézi munkával sikerült létrehoznom egy nagy Excel táblázatot a magas és alacsony sorozatok hosszáról, megpróbáltam logikát találni a dologban. Mint kiderült ez az ASK nevű OOK moduláció azon fajtája, amikor is egy adott ütemen belül az dönti el, hogy 0 vagy 1 érkezett, hogy 2/3 rész alacsony jelet követ 1/3 rész magas, vagy fordítva. Ezt hívják PWM-nek, azaz pulse width modulation-nek.

Az igazi hekkrekedés ezután jött csak: rátaláltam egy Universal Radio Hacker nevű szintén ingyenes programra, ami pont olyan céllal készült, hogy ehhez hasonló (és ennél is sokkal bonyolultabb) rádióüzeneteket lehessen vele megfejteni és egy megfelelő eszközzel újra lejátszani, esetleg módosított tartalommal is.

Ez a program is ismeri az RTS-SDR eszközöket, képes is adást rögzíteni, de nem sikerült rájönnöm, hogy hogyan lehet rávenni, hogy megfelelő anyagot vegyen fel. Szóval az lett a megoldás, hogy az SDR# programmal csináltam egy olyan felvételt, amin egy bekapcsolás üzenet után jön egy kikapcsolás is, ez egy wav fájl lett. Ezt betöltöttem az URH-ba és elkezdtem próbálkozni benne. (itt eltelt jó pár óra, nap) Végül sikerült olyan eredményre jutnom, ami megegyezett az Excel-ben kézzel készült kódfejtésemmel, de már a program számolta ki az 1-eseket és 0-kat.

Íme az eredmény:

Mit is látunk? A színes táblázat a bejövő bitek ábrázolása hexadecimális formában. (Lehet bitenként is nézni, de úgy rettentő hosszúak a sorok.) A sárga első oszlopot én szinkronizációs résznek neveztem el (de lehet nem ez a hivatalos neve), a kék/lila (ki minek látja/hívja) valószínűleg az emlegetett biztonsági kód lehet, a zöld/piros rész ami különbözik a be- és kikapcsolások között, a barna részt én padding-nek hívom, 4 db 0 jellel van kiegészítve az üzenet, hogy 7 teljes bájtot tegyen ki a csomag.

Időzítések és üzenetek

Érdekes módon az URH magától felfedezte a rövid és hosszú jelek közötti összefüggést, szinte tökéletesen. Én a következő időket véltem felfedezni:

  • A szinkronizáció során ~650 μs hosszú magas, majd alacsony, majd ismét magas jelsor jelzi, hogy érkezik egy új üzenet. Ez az időtartam nagyjából jelzi, hogy egy-egy bit milyen hosszan fog tartani. (Ezt a magas-alacsony-magas sorozatot SYNC-nek jelölöm lentebb.)
  • Ha a 650 első 2/3-a alacsony, az utolsó 1/3-a magas jelszintet mutat, én azt értelmeztem 0-ként.
  • Ha fordítva, vagyis ~220 μs alacsony után jön ~430 μs magas, akkor az nálam 1-est jelent.
  • Egy-egy csomagot mindig egy nagyobb szünet zár le, ez nálam kb háromszorosa a szinkronizációs jelnek, vagyis ~1750 μs. Ezután mindig újra szinkronizációs jel következik, kivéve a legutolsó adást. (Ezt a hosszabb szünetet STOP-ként jelölöm a továbbiakban.)

Egy bekapcsoláskor rendszerint 2 üzenet érkezik:

  • A üzenet: 0001010000011111101100000000
  • B üzenet: 0001010000011111011100000000

Láthatóan 2 bit eltérés van közöttük és a biztonság kedvéért mindent többször küld át az adó:

SYNC A A STOP
SYNC B B STOP
SYNC A A STOP
SYNC B B STOP
SYNC A A STOP
SYNC B B STOP
SYNC A A STOP
SYNC B B STOP

Megjegyzés: van rá esély, hogy az a 2 bit eltérés amiatt lehetett, mert épp merülőben volt az elem a termosztátban és az pont az a bit. Ez persze egyelőre feltételezés, lehet az elem állapotát nem is üzeni meg a vevőnek, de egy másik mérésből úgy tűnik, hogy nem törvényszerű az az eltérés az ismétlések között.

Mivel sikerült ugyanabban a wav fájlban egy be- és egy kikapcsoló üzenetet is rögzítenem, így az URH dekódolta nekem a kikapcsolást is. 4 bit eltérés van a bekapcsoláshoz képest:

  • A: 0001010000011111101111110000
  • B: 0001010000011111011111110000

Ezt az apró különbséget leszámítva minden más ugyanaz, az időzítések, az ismétlések, minden.

Konkluzsön

A fenti adatok alapján össze lehet állítani egy olyan ASK modulációjú üzenetet, amivel az én kazánomat el lehet indítani, illetve le lehet állítani. Ha több időm lesz, akkor hasonló módszerekkel fel fogom dolgozni a másik rendszerben levő termosztátom üzenetét is, abból derülhetnek ki újabb összefüggések. (Pl. egyedi, változó részek, esetleg ellenőrző összegek, stb.)

Nekszt sztepz

Ami még hátra van az az adó egység megépítése, de arról majd legközelebb...

A bejegyzés trackback címe:

https://ardu.blog.hu/api/trackback/id/tr7614771000

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

szml70 2019.09.06. 10:11:33

Probáltad már ezt : github.com/merbanan/rtl_433 ?
Neve ne tévesszen meg, tudja a 868-at.

denx 2019.12.09. 16:13:12

@szml70: Köszi, igen próbáltam, de volt vele gond. Egyrészt nem nagyon akart nekem fordulni (lehet Visual Studio kellett hozzá Win alatt? Már nem emlékszem tisztán), másrészt a letöltött binárist meg minden alkalommal vírusnak nézte a vírusírtó, mert a netről jött és nagyon friss volt a dátuma.
Az is közrejátszhatott a sikertelenségemben, hogy akkoriban még nem a névleges (és valóban hasznos) frekvencián kerestem a jelet, hanem ott, ahol az SDR a legerősebb jelet mutatta.

Utólag visszatekintve lehet sok időt spóroltam volna meg vele, nem tudom most megítélni hogy működik-e, de annak idején zsákutcának tűnt. Mindenesetre köszönöm az építő kommetnet!
süti beállítások módosítása