Hacking LG Ducted Split pro domácí automatizaci: 8 kroků (s obrázky)

2024 Autor: John Day | [email protected]. Naposledy změněno: 2024-01-30 08:22

Za prvé - toto není další hack emulace infračerveného dálkového ovládání. Můj konkrétní AC nemá použitelné rozhraní určené pro jakýkoli druh ovládání kromě přiložených nástěnných chytrých ovladačů.

Mám doma reverzní split systém LG Ducted. Bohužel byl vyroben v době, kdy IoT nebyl na žádném seznamu výrobců. Zjistil jsem, že má nějaké možnosti pro „hlavní“ovládání, ale přestože byla jednotka v době, kdy jsem se o to poprvé pokoušel, jen 2 roky stará, rozšiřující desky byly unobtanium a ceny byly astronomické. Stejně jako doplněk „Wireless RF Remote“, který by věci hodně usnadnil, ale nekoupil.

Kdyby to byla moje volba, nebylo by to LG, ale protože to bylo nainstalováno v domě, když jsem ho koupil (a jeho náklady na výměnu by pravděpodobně přesahovaly 10 000 $), musel jsem se s tím vypořádat.

Cíl - Umět ovládat AC přes MQTT pro účely automatizace přes OpenHAB a IFTTT/Google Assistant

Krok 1: Dekódování formátu dat

Začal jsem s tímto procesem před 4 lety, ale nedostal jsem se příliš daleko a nechtěl jsem riskovat poškození jednotky - zejména proto, že díly pro ni se zdají být téměř nemožné najít.

Když jsem strhl ovladač ze zdi, našel jsem 3 vodiče, které jsem určil jako uzemnění, 12 V a „signál“

Signálové napětí na datové lince bylo 12 V, ale všiml jsem si, že se zdá, že kolísá na multimetru (nějaké pulsy na lince).

Chlebem jsem nastoupil do základního obvodu pro řízení opto izolátoru přes datový pin a připojil jsem druhou stranu opto izolátoru jako vstup na zvukovou kartu svého počítače a dostal špatnou verzi výstupu rozsahu (obr. 1).

To je asi tak daleko, jak jsem se tehdy dostal - viděl jsem, že tam něco je, ale vlastně jsem nevěděl, jak to ‚dekódovat‘.

Vzhledem k tomu, že jsem aktivoval svůj IoT kávovaru, měl jsem obnovený zájem to zkusit znovu s trochou odhodlání tentokrát.

Zveřejnil jsem své poznatky na fórech EEVBlog, abych zjistil, jestli by někdo mohl vrhnout nějaké světlo a zachránil mě skvělý chlap jménem Ian - vyložil to tak, aby to dávalo smysl (obrázek 2)

Datový tok je v zásadě 13 bytů „standardního sériového“- 8 datových bitů, jeden počáteční bit a jeden stop bit (bez parity), ale s VELMI nízkou přenosovou rychlostí 104bps.

Krok 2: Hledáte hlouběji

Takže teď, když jsem měl představu o tom, jak byla data formátována, potřeboval jsem způsob, jak data číst dynamičtěji.

Vytáhl jsem jeden ze svých ovladačů ze zdi a připojil jej přes logický řadič úrovně k Arduinu pomocí jednoduchého náčrtu, který přečte 13 bytů dat přes softwarový sériový port nakonfigurovaný na 104bps a vytiskne 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, ** Ve skutečnosti zde 12 bajtů

Měli jsme akci!

Poté, co jsem změnil různá nastavení na ovladači, jsem byl schopen zjistit bajty, které se mění:

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 18168, 15, 0, 0, 0, 136, 4, 34, 0, 0, 0, 0, 48, teplota 19168, 15, 0, 0, 0, 136, 5, 34, 0, 0, 0, 0, 51, teplota 20168, 15, 0, 0, 0, 136, 15, 34, 0, 0, 0, 0, 37, teplota 30

Čísla dávají mnohem větší smysl, když se na ně podíváte binárně, ale co je s 13. bytem ?? Je to všude kolem…

Krok 3: Mapování

Prostřednictvím pokusů a omylů jsem byl schopen určit příslušné bity ve 13 bajtech dat, které bych potřeboval k přenosu.

Krok 4: Cihlová zeď dopředu

Tady se to zkomplikovalo. Měl jsem překonat dvě překážky

a) 13. bajt se zdál být kontrolním součtem dat, které jsem potřeboval nějak zpracovat. b) Jak potom data přenesu? Je to jen jeden drát.

Problém „a“se ukázal jako OPRAVDU snadný, ale čistou náhodou se mi ho podařilo překonat.

V mých testech jsem se díval na data jako: A802000000040F61000000004B A81200004004169A00000000FB A81200004004159A00000000F8 A81200004004149A00000000E5 A81200084000149C00000000E7 A832000840000090000000000000000

Jedná se o 13 bajtů dat včetně kontrolního součtu (zde v HEX namísto DEC).

Když jsem hledal věštec, který je google na téma „Jak zpětně analyzovat kontrolní součet“, narazil jsem na tuto stránku při výměně zásobníku s někým jiným, kdo se jmenoval Nick a ptal se téměř na totéž, co já, ale nejen na to, mluvili o klimatizaci a jejich data měla téměř stejný formát jako já - Mohlo by to být ??? Za celé moje hledání (asi za 4 roky) ani jedna osoba nezveřejnila žádné informace o tom, jak hacknout protokol o těchto klimatizacích, a já náhodou narazím na někoho, kdo dělá totéž, když hledá něco téměř zcela nesouvisejícího? Bylo to požehnání - dokonce zveřejnil, že to vypracoval a řešení bylo: Sečtěte všechny bajty dat a poté XOR s „U“.

S tím v ruce jsem to přidal do svého kódu, abych vypočítal, co jsem si myslel, že by měl být kontrolní součet vs to, co ve skutečnosti bylo, ale bylo to všechno ŠPATNĚ !!

Jak se ukázalo, bylo to trochu špatně. Když jsem se začal dívat na čísla binárně, dávalo to naprostý smysl.

Odpověď z 'XOR s U' vždy vrátila 9 bitů dat (9. bit vždy jeden), ale ostatní bity byly správné. Jednoduše jsem odstranil 9. bit odebráním 256 z výsledného čísla a pak to odpovídalo !!

Nebýt tohoto jedince, možná bych si pořád drbal hlavu. Klobouk dolů před ním, ale nemohu ho kontaktovat - to byl v podstatě jeho jediný příspěvek na fóru stackexchange. Díky, cizinci:)

Další výzvou bylo vytvořit obvod, který by mi umožnil simulovat stávající ovladač. Namapoval jsem schéma pro obvod pohonu (Pic1 a Pic 2), ale zdálo se mi to příliš komplikované na to, abych to musel reprodukovat, abych získal to, co jsem chtěl. Přece jen jsem už signál četl. Rozhodl jsem se pro mnohem jednodušší metodu - použít arduino k pohonu optoizolátoru a podle potřeby vytáhnout signální vedení 12 V.

Také jsem navrhl jednodušší obvod pro Rx, ale toto není testováno, pro jednoduchost jsem skončil s převodníkem úrovní.

Krok 5: Aby to fungovalo

Jakmile jsem měl připojený přenosový obvod a se závodním srdcem jsem pokazil (statický) řetězec 12 bajtů, vypočítal kontrolní součet a nechal arduino odeslat příkaz - Úžasně, displej aktualizován !!! Vyhrát!

Posledním skutečným testem bylo přidání mého arduina do sběrnice s dalšími 2 řadiči pro skutečný živý test a určitě to fungovalo.

Takže teď jsem mohl číst a psát do autobusu, ale chyběla mi schopnost jednoduše to udělat.

Protože používám MQTT téměř výhradně pro veškerou svou domácí automatizaci, bylo přirozené, že to bude stejné. Napsal jsem kód několik dní, abych ovládal 4 hlavní prvky AC, a také přečetl stávající stav (z ostatních modulů na sběrnici)

Záměrem bylo nechat kód běžet na modulu ESP8266, ale zdálo by se, že ESP8266 není schopen produkovat přenosovou rychlost tak nízkou jako 104bps. Musel jsem se vrátit k obecnému Arduino Uno s ethernetem Wiznet, ale nebylo to těžké, protože můj komunikační stojan byl doslova na druhé straně zdi od jednoho z AC ovladačů.

Kód je trochu všude, ale měl by být čitelný. Měl jsem spoustu problémů s tím, že jsem regulátoru zabránil číst jeho vlastní výstup, ale také opakovat kód, který publikoval, jeho vlastní témata přijatá z MQTT zpět do klimatizace. V zásadě by to vytvořilo nekonečnou smyčku. Nakonec bylo vyřešeno nějaké vymazání vyrovnávací paměti a zpoždění při zpracování kódu po publikování na MQTT.

Kolíky Rx, Tx k AC jsou kódovány jako 3, 4, ale pokud chcete, změňte

Kód je nakonfigurován tak, aby publikoval a přijímal příkazy jako takové:

ha/mod/5557/P 0/1 - Powerha/mod/5557/M 0/1/2/3/4 - režim Cool, odvlhčování, ventilátor, auto, Heatha/mod/5557/F 0/1/2 - Nízký ventilátor, střední, vysoká/mod/5557/Z tj. 1111 pro všechny zóny na 1000 pro pouze zónu 1 na.

** Z ovladače nelze nastavit zóny na '0000', ale zdá se, že pokud zadáte hodnotu, vrátí se na '1000'.

Nejnovější verze kódu je k dispozici na mém GitHub Repo:

Krok 6: Něco trvalejšího

Shromáždil jsem prototypovou desku arduina a nainstaloval všechny součásti, jak jsem je nechal nalepit na chleba.

Krok 7: OpenHAB Config

Položky, mapu webu a pravidla OpenHAB naleznete v přiloženém souboru

Zkombinujte to s vazbou IFTTT OpenHab a Google Assistant/Home a máte velmi výkonnou hlasem ovládanou a/nebo 'chytrou' klimatizaci, která překoná téměř každý komerčně dostupný produkt!

Krok 8: Shrnutí

Na závěr - Pokud jste jednou z chudých duší s o něco starší rozdělovanou klimatizací od společnosti LG, nejste sami. Stále pro nás existuje naděje!

Doufám, že tento instruktáž najde někoho, kdo to potřebuje stejně jako já. V zásadě neexistuje žádná informace, kterou bych mohl najít (kromě kontrolního součtu od „Nicka“). Musel jsem začít od nuly, ale jsem z výsledku nadšený.

Tyto informace jsou trochu vágní, já vím, ale pokud jste ve stejné situaci jako já, rád vám pomůžu.

- Upozornění / Aktualizace --- Ačkoli je možné změnit nastavení na AC s vypnutou jednotkou, zjistil jsem, že pokud jde o ovládání zóny, zdá se, že se s ním pohrává. Udělal jsem spoustu testů s vypnutou jednotkou a zjistil jsem, že zóny se budou zobrazovat jako neaktivní, ale když jednotka funguje, zdá se, že tlumiče nejsou zcela zavřené (ale ani zcela otevřené). Resetoval jsem jednotku na hlavním jističi a tím byl problém vyřešen. Vzhledem k tomu, že se mění pouze zóny, když je jednotka zapnutá, nebyl to problém

Také jsem aktualizoval kód, aby publikoval pouze (na MQTT) změny, které pocházejí z hlavního ovladače a ne z hlavní jednotky. Opět to může způsobit problémy, protože hlavní jednotka pošle '0000' pro zóny (což také mohl být problém)

Aktualizovaný kód také zavádí některá omezení časování, aby se pokusil zabránit arduinu ve vysílání současně z hlavní a hlavní jednotky. Jsem si jistý, že pravděpodobně existuje metoda, kterou ovladač používá k zahájení odesílání dat, jako je vytažení řádku nízko pro Xms před odesláním, ale zatím jsem to neobjevil, pokud existuje

Zjistil jsem, že hlavní jednotka bude odesílat data každých 60 sekund a hlavní ovladač odesílá každých 20 sekund. Kód se pokusí zastavit odesílání dat do 2 sekund od přijetí datového paketu. Někdy však hlavní a hlavní jednotka vysílají velmi blízko sebe. To bude pravděpodobně brzy upřesněno.----------------------------

** Může fungovat na novějších jednotkách

*** Některé informace nalezené v mých výzkumných cestách naznačovaly, že rozdělované potrubí Panasonic může používat stejný protokol. YMMV.