Hacking LG Ducted Split pre domácu automatizáciu: 8 krokov (s obrázkami)

2024 Autor: John Day | [email protected]. Naposledy zmenené: 2024-01-30 11:58

Po prvé - toto nie je ďalší hack emulácie infračerveného diaľkového ovládania. Môj konkrétny AC nemá žiadne použiteľné rozhranie navrhnuté pre akýkoľvek iný druh ovládania ako pribalené nástenné inteligentné ovládače.

Mám doma reverzný delený systém LG Ducted. Bohužiaľ to bolo vyrobené v čase, keď IoT nebol na zozname žiadnych výrobcov. Zistil som, že má nejaké možnosti „hlavného“ovládania, ale aj keď bola jednotka v čase, keď som sa o to prvýkrát pokúšal, iba 2 roky stará, rozširujúce dosky boli unobtanium a ceny boli aj tak astronomické. Rovnako ako doplnok „Bezdrôtový RF diaľkový ovládač“, ktorý by veci veľmi zjednodušil, ale nedal sa kúpiť.

Keby to bola moja voľba, nebolo by to LG, ale pretože to bolo nainštalované v dome, keď som ho kúpil (a náklady na jeho výmenu by pravdepodobne presiahli 10 000 dolárov), musel som sa s tým vyrovnať.

Cieľ - Byť schopný ovládať AC cez MQTT na účely automatizácie cez OpenHAB a IFTTT/Google Assistant

Krok 1: Dekódovanie formátu údajov

Začal som s týmto procesom pred 4 rokmi, ale nedostal som sa príliš ďaleko a nechcel som riskovať poškodenie jednotky - Najmä preto, že diely pre ňu je takmer nemožné nájsť.

Po odtrhnutí ovládača zo steny som našiel 3 vodiče, ktoré som určil ako uzemnenie, 12 V a „signál“.

Signalizačné napätie na dátovom vedení bolo 12 V, ale všimol som si, že sa zdá, že kolíše na multimetri (nejaký druh impulzov na vedení).

Chlieb som nasadol na základný obvod na poháňanie optoizolátora cez dátový pin a druhú stranu optoizolátora som zapojil ako vstup na zvukovú kartu svojho počítača a dostal som zlú verziu výstupu rozsahu (obr. 1).

To je asi tak ďaleko, ako som sa vtedy dostal - videl som, že tam niečo je, ale v skutočnosti som nevedel, ako to „dekódovať“.

Keďže som povolil svoj IoT kávovaru, obnovil som záujem to skúsiť znova s trochou odhodlania tentokrát.

Zverejnil som svoje zistenia na fórach EEVBlog, aby som zistil, či by niekto mohol vrhnúť nejaké svetlo a zachránil ma skvelý chlapík menom Ian - položil to spôsobom, ktorý úplne dával zmysel (obrázok 2)

V zásade je dátový tok 13 bajtov „štandardných sériových“- 8 dátových bitov, jeden štartovací bit a jeden stop bit (bez parity), ale s VELMI nízkou prenosovou rýchlosťou 104bps.

Krok 2: Vyzerajte hlbšie

Teraz, keď som mal predstavu o tom, ako sú údaje formátované, potreboval som spôsob, ako by som mohol dáta čítať dynamickejším spôsobom.

Vytiahol som jeden zo svojich ovládačov zo steny a pomocou logického posúvača úrovní ho pripojil k Arduinu pomocou jednoduchého náčrtu, aby som pomocou softvérového sériového portu nakonfigurovaného na 104bps načítal 13 bajtov údajov a vytlačil ho:

168, 18, 0, 8, 0, 192, 6, 22, 0, 0, 0, 0, 168, 18, 0, 8, 0, 192, 6, 22, 0, 0, 0, 0, 40, 19, 0, 8, 0, 200, 6, 31, 0, 0, 0, 0, 40, 19, 0, 8, 0, 200, 6, 31, 0, 0, 0, 0, 200, 18, 0, 8, 64, 0, 6, 25, 0, 0, 0, 0, 200, 18, 0, 8, 64, 0, 6, 25, 0, 0, 0, 0, 168, 18, 0, 8, 0, 200, 6, 22, 0, 0, 0, 0, 168, 18, 0, 8, 0, 200, 6, 22, 0, 0, 0, 0, 168, 18, 0, 8, 0, 200, 6, 22, 0, 0, 0, 0, ** V skutočnosti tu je 12 bytov

Mali sme akciu!

Potom, čo som zmenil rôzne nastavenia na ovládači, som dokázal zistiť bajty, ktoré sa zmenili:

168, 3, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, ventilátor LOW168, 35, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, ventilátor MED 168, 67, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 152, ventilátor VYSOKÝ

168, 67, 0, 0, 0, 248, 3, 33, 0, 0, 0, 0, 82, Z1234 168, 67, 0, 0, 0, 192, 3, 34, 0, 0, 0, 0, 133, Z1 168, 67, 0, 0, 0, 160, 3, 34, 0, 0, 0, 0, 229, Z2 168, 67, 0, 0, 0, 144, 3, 34, 0, 0, 0, 0, 245, Z3 168, 67, 0, 0, 0, 136, 3, 35, 0, 0, 0, 0, 204, Z4

168, 75, 0, 0, 0, 136, 3, 35, 0, 0, 0, 0, 244, režim VENTILÁTOR 168, 79, 0, 0, 0, 136, 10, 35, 0, 0, 0, 0, 249, režim AUTO 168, 67, 0, 0, 0, 136, 3, 35, 0, 0, 0, 0, 204, režim COOL 168, 83, 0, 0, 0, 136, 15, 34, 0, 0, 0, 0, 225, režim HEAT 168, 7, 0, 0, 0, 136, 15, 34, 0, 0, 0, 0, 61, režim DH

168, 15, 0, 0, 0, 136, 3, 34, 0, 0, 0, 0, 49, teplota 18 168, 15, 0, 0, 0, 136, 4, 34, 0, 0, 0, 0, 48, teplota 19 168, 15, 0, 0, 0, 136, 5, 34, 0, 0, 0, 0, 51, teplota 20 168, 15, 0, 0, 0, 136, 15, 34, 0, 0, 0, 0, 37, teplota 30

Čísla majú oveľa väčší zmysel, keď sa na ne pozriete binárne, ale čo je s 13. bajtom ?? Je to všade…

Krok 3: Mapovanie

Prostredníctvom pokusu a omylu som bol schopný určiť príslušné bity v 13 bajtoch údajov, ktoré by som potreboval na prenos.

Krok 4: Tehlová stena dopredu

Tu sa to skomplikovalo. Musel som prekonať dve prekážky

a) 13. bajt sa zdal byť kontrolným súčtom údajov, ktoré som potreboval nejako vypracovať. b) Ako potom prenesiem údaje? Je to len jeden drôt.

Problém „a“sa ukázal byť skutočne ľahký, ale čistou náhodou sa mi ho podarilo prekonať.

Pri svojich testoch som sa pozeral na údaje ako: A802000000040F61000000004B A81200004004169A00000000FB A81200004004159A00000000F8 A81200004004149A00000000E5 A81200084000149C00000000E7 A832000840000090000000000000000000000

Toto je 13 bajtov údajov vrátane kontrolného súčtu (tu v HEXe namiesto DEC).

Keď som hľadal orákulum, ktoré je google, „ako spätne analyzovať kontrolný súčet“, narazil som na túto stránku na výmene zásobníka s niekým iným, kto chodil pod menom Nick a pýtal sa skoro to isté ako ja, ale nielen to, hovorili o klimatizácii a ich údaje mali takmer identický formát ako ja - môže byť ??? Za celé moje hľadanie (asi 4 roky) ani jedna osoba nezverejnila žiadne informácie o tom, ako hacknúť protokol o týchto klimatizáciách, a ja som náhodou narazil na niekoho, kto robí to isté tým, že hľadá niečo takmer úplne nesúvisiace? Bolo to požehnanie - Dokonca zverejnil, že to vypracoval a riešenie bolo: Zrátajte všetky bajty údajov a potom XOR s „U“.

S tým v ruke som to pridal do svojho kódu, aby som vypočítal, čo si myslím, že by mal byť kontrolný súčet verzus to, čo v skutočnosti bolo, ale bolo to všetko ZLE !!

Ako sa ukázalo, bolo to trochu nesprávne. Keď som sa začal pozerať na čísla binárne, dávalo to úplný zmysel.

Odpoveď z 'XOR s U' vždy vrátila 9 bitov údajov (9. bit vždy jeden), ale ostatné bity boli správne. Jednoducho som odstránil 9. bit odobratím 256 z výsledného čísla a potom sa zhodovalo !!

Nebyť tohto jedinca, možno by som si stále škriabal hlavu. Klobúk dole aj pred ním, ale nemôžem ho kontaktovať - To bol v podstate jeho jediný príspevok na fóre stackexchange. Ďakujem, cudzinec:)

Ďalšou výzvou bolo vytvoriť obvod, ktorý by mi umožnil simulovať existujúci ovládač. Zmapoval som schému pre obvod pohonu (Obr. 1 a Obr. 2), ale zdalo sa mi to príliš komplikované na to, aby som to potreboval reprodukovať, aby som dosiahol to, čo som chcel. Už som predsa len čítal signál. Rozhodol som sa pre oveľa jednoduchšiu metódu - Použitie arduina na pohon optoizolátora, aby sa podľa potreby znížilo signálne vedenie 12 V.

Tiež som navrhol jednoduchší obvod pre Rx, ale toto nie je testované, pre jednoduchosť som skončil s prevodníkom úrovní.

Krok 5: Aby to fungovalo.

Hneď ako som dostal do chodu prenosový obvod a so závodným srdcom som pokazil (statický) reťazec 12 bajtov, vypočítal som kontrolný súčet a arduino poslal príkaz - Úžasne, displej sa aktualizoval !!! Vyhrať!

Posledným skutočným testom bolo pridanie môjho arduina do BUS s 2 ďalšími ovládačmi na skutočný živý test a určite to fungovalo.

Teraz som mohol čítať a písať do autobusu, ale chýbala mi schopnosť jednoducho to urobiť.

Keďže MQTT používam takmer výlučne na všetku domácu automatizáciu, bolo prirodzené, že to bude rovnaké. Niekoľko dní som vypísal kód na ovládanie 4 hlavných prvkov klimatizácie a tiež prečítal existujúci stav (z ostatných modulov na zbernici)

Zámerom bolo nechať kód bežať na module ESP8266, zdá sa však, že ESP8266 nie je schopný produkovať prenosovú rýchlosť až 104bps. Musel som sa vrátiť k všeobecnému Arduino Uno s ethernetom Wiznet, ale nebolo to ťažké, pretože môj komunikačný stojan bol doslova na druhej strane steny od jedného z regulátorov striedavého prúdu.

Kód je trochu všade, ale mal by byť čitateľný. Mal som veľa problémov s zabránením regulátoru čítať jeho vlastný výstup, ale aj opakovaním kódu, ktorý publikoval, jeho vlastné témy prijaté z MQTT späť do klimatizácie. V zásade by to vytvorilo nekonečnú slučku. Nakoniec sa podarilo vyčistiť vyrovnávaciu pamäť a oneskorenia pri spracovaní kódu po publikovaní na serveri MQTT.

Kolíky Rx, Tx k AC sú kódované ako 3, 4, ale ak chcete, zmeňte ich

Kód je nakonfigurovaný na publikovanie a prijímanie príkazov ako takých:

ha/mod/5557/P 0/1 - Powerha/mod/5557/M 0/1/2/3/4 - režim Cool, odvlhčovanie, ventilátor, auto, Heatha/mod/5557/F 0/1/2 - Ventilátor nízky, stredný, vysoký/mod/5557/Z tj. 1111 pre všetky zóny na 1000 pre iba zónu 1 zapnutú.

** Z ovládača nie je možné nastaviť zóny na „0000“, ale zdá sa, že ak zadáte hodnotu, vráti sa na „1000“.

Najnovšia verzia kódu je k dispozícii na mojom GitHub Repo:

Krok 6: Niečo trvalejšie

Zhromaždil som prototypovú dosku arduino a nainštaloval všetky diely tak, ako som ich nechal vyložiť chlebom.

Krok 7: OpenHAB Config

Položky, mapu webu a pravidlá OpenHAB nájdete v priloženom súbore

Skombinujte to s väzbou IFTTT OpenHab a Google Assistant/Home a máte veľmi výkonnú hlasom ovládanú a/alebo „inteligentnú“klimatizáciu, ktorá prekoná takmer každý komerčne dostupný produkt!

Krok 8: Zhrnutie

Na záver - Ak patríte k chudobným dušiam s o niečo starším deleným klimatizačným potrubím LG, nie ste sami. Stále je tu pre nás nádej!

Dúfam, že tento návod nájde niekoho, kto to potrebuje rovnako ako ja. V zásade neexistuje žiadna informácia, ktorú by som mohol nájsť (okrem kontrolného súčtu od 'Nicka'). Musel som začať od nuly, ale z výsledku som nadšený.

Informácie sú trochu vágne, ja viem, ale ak ste v rovnakej situácii ako ja, rád vám pomôžem.

-- Výstraha / Aktualizácia --- Aj keď je možné zmeniť nastavenia na AC pri vypnutej jednotke, zistil som, že pokiaľ ide o ovládanie zóny, zdá sa, že sa s ním pohráva. Vykonal som veľa testovaní s vypnutou jednotkou a zistil som, že zóny sa budú javiť ako neaktívne, ale keď je jednotka v prevádzke, zdá sa, že tlmiče nie sú úplne zatvorené (ale ani úplne otvorené). Resetoval som jednotku na hlavnom ističi a tým sa problém vyriešil. Pretože zmena zón iba vtedy, keď je jednotka zapnutá, nebol to problém

Tiež som aktualizoval kód, aby publikoval iba zmeny (do MQTT), ktoré pochádzajú z hlavného ovládača, a nie z hlavnej jednotky. Opäť to môže spôsobiť problémy, pretože hlavná jednotka pošle „0000“pre zóny (čo tiež mohol byť problém)

Aktualizovaný kód tiež zavádza niektoré časové obmedzenia, aby sa pokúsil zabrániť arduino vysielať súčasne z hlavnej a hlavnej jednotky. Som si istý, že pravdepodobne existuje metóda, ktorú regulátor používa na inicializáciu odoslania údajov, ako je vytiahnutie linky nízko pre Xms pred odoslaním, ale zatiaľ som to neobjavil, ak existuje

Zistil som, že hlavná jednotka bude odosielať údaje každých 60 sekúnd a hlavný ovládač odosiela každých 20 sekúnd. Kód sa pokúša zastaviť odosielanie údajov do 2 sekúnd od prijatia dátového paketu. Niekedy však hlavná a hlavná jednotka vysielajú veľmi blízko seba. Toto bude pravdepodobne čoskoro spresnené.----------------------------

** Môže fungovať na novších jednotkách

*** Niektoré informácie nájdené v mojich výskumných cestách naznačujú, že potrubné rozdelenie Panasonic môže používať rovnaký protokol. YMMV.