Az LG csatornás felosztásának feltörése az otthoni automatizáláshoz: 8 lépés (képekkel)

2024 Szerző: John Day | [email protected]. Utoljára módosítva: 2024-01-30 09:41

Először is - Ez nem egy újabb infravörös távirányító emulációs hack. Az én AC -m nem rendelkezik használható interfésszel, amelyet bármilyen más vezérléshez terveztek, kivéve a mellékelt, falra szerelt intelligens vezérlőket.

Van egy LG Ducted fordított osztott rendszer a házamban. Sajnos abban az időben készült, amikor az IoT nem szerepelt a gyártók listáján. Felfedeztem, hogy van néhány opciója a „master” vezérléshez, de annak ellenére, hogy az egység még csak 2 éves volt, amikor először megpróbáltam ezt végrehajtani, a bővítőlapok unibtaniumok voltak, és az árak egyébként csillagászati jellegűek. Akárcsak a „Wireless RF Remote” kiegészítő, amely sokkal könnyebbé, de lehetetlenné tette volna a vásárlást.

Ha én döntöttem volna, nem LG lenne, de mivel a házba telepítették, amikor megvettem (és a csereköltsége valószínűleg meghaladja a 10 000 USD -t), ezzel számolnom kellett.

Cél - Lehetővé kell tenni az AC vezérlését MQTT -n keresztül automatizálás céljából OpenHAB és IFTTT/Google Assistant segítségével

1. lépés: Az adatformátum dekódolása

4 évvel ezelőtt kezdtem el ezt a folyamatot, de nem jutottam túl messzire, és nem akartam kockáztatni a készülék károsodását - Főleg, hogy az alkatrészek szinte lehetetlennek tűnnek.

Letépve a vezérlőt a falról, 3 vezetéket találtam, amelyeket földnek, 12V -nak és "jelnek" határoztam meg

A jelzőfeszültség az adatvezetéken 12 volt, de észrevettem, hogy ingadozni látszik a multiméteren (valamilyen impulzus a vonalon).

Kenyérrel beszálltam egy alapáramkörbe, hogy opto -leválasztót vezessek az adatcsapon keresztül, és csatlakoztattam az opto -leválasztó másik oldalát bemenetként a számítógépem hangkártyájához, és megkaptam a szkóp kimenetének rossz verzióját (1. kép).

Ez körülbelül annyiban van, mint akkoriban - láttam, hogy van ott valami, de nem igazán tudtam, hogyan kell „dekódolni”.

Mivel engedélyeztem a Kávéfőző IoT funkciót, ezúttal felkeltette érdeklődésemet, hogy ezúttal egy kicsit határozottabban próbáljam meg újra.

Az EEVBlog fórumán közzétettem a megállapításaimat, hátha valakinek sikerül megvilágítania, és egy nagyszerű Ian nevű srác jött megmentésemre - úgy fogalmazott, hogy teljesen logikus volt (2. kép)

Alapvetően az adatfolyam 13 bájtos „szabványos soros” - 8 adatbit, egy kezdőbit és egy stopbit (nincs paritás), de NAGYON alacsony, 104 bps átviteli sebességgel.

2. lépés: Nézz mélyebbre

Így most, hogy volt egy elképzelésem az adatok formázásáról, szükségem volt egy módra, hogy dinamikusabban olvashassam az adatokat.

Lehúztam az egyik vezérlőt a falról, és egy logikai szintváltón keresztül csatlakoztattam egy Arduino -hoz, egy egyszerű vázlattal, hogy 13 bájtnyi adatot olvashassak ki a 104 bps sebességű szoftver soros porton keresztül, és kinyomtassam:

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, ** Itt valójában 12 bájt van

Akciónk volt!

A vezérlő különböző beállításainak megváltoztatásával sikerült kiszámítanom a változó bájtokat:

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 HIGH

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, 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, FAN mód 168, 79, 0, 0, 0, 136, 10, 35, 0, 0, 0, 0, 249, AUTO mód 168, 67, 0, 0, 0, 136, 3, 35, 0, 0, 0, 0, 204, COOL mód 168, 83, 0, 0, 0, 136, 15, 34, 0, 0, 0, 0, 225, HEAT mód 168, 7, 0, 0, 0, 136, 15, 34, 0, 0, 0, 0, 61, DH mód

168, 15, 0, 0, 0, 136, 3, 34, 0, 0, 0, 0, 49, hőmérséklet 18 168, 15, 0, 0, 0, 136, 4, 34, 0, 0, 0, 0, 48, 19 168, 15, 0, 0, 0, 136, 5, 34, 0, 0, 0, 0, 51, 20 168, 15, 0, 0, 0, 136, 15, 34 hőmérséklet, 0, 48 0, 0, 0, 0, 37, 30 hőmérséklet

A számoknak sokkal több értelme van, ha binárisan nézzük őket, de mi a helyzet a 13. bájttal ?? Mindenhol ott van…

3. lépés: Feltérképezése

Próbálgatáson keresztül sikerült meghatároznom a vonatkozó biteket a 13 bájtnyi adatban, amelyeket továbbítani kell.

4. lépés: Téglafal előre

Itt bonyolult. Két akadályt kellett leküzdenem

a) A 13. bájt az adatok ellenőrző összegének tűnt, amelyeket valahogy ki kellett dolgoznom. b) Hogyan továbbíthatom az adatokat? Ez csak egy vezeték.

Az „a” kérdés nagyon könnyűnek bizonyult, de véletlenszerűen sikerült túljutnom rajta.

A tesztek során az alábbi adatokat néztem:

Ez az 13 bájt adat, beleértve az ellenőrző összeget is (itt a HEX -ben a DEC helyett).

Amikor kerestem az orákulumban, amely a google -ban szól arról, hogy "hogyan lehet visszafordítani az ellenőrző összeget", ráakadtam erre az oldalra a veremcserén, és valaki más Nick néven ugyanazt kérdezte, mint én, de nem csak ezt, de beszéltek egy klímaberendezésről, és az adataik majdnem megegyeztek az enyém formátumával - Lehet ??? Minden keresésem során (körülbelül négy év alatt) egyetlen személy sem tett közzé semmilyen információt arról, hogyan lehet feltörni a protokollt ezeken a klímaberendezéseken, és véletlenül ráakadok valakire, aki ugyanezt teszi, és szinte teljesen összefüggéstelen dolgokat keres? Áldás volt - még azt is közzétette, hogy kidolgozta, és a megoldás az volt: Összesítse az összes bájt adatot, majd XOR -t "U" -val.

Ezzel a kezemmel hozzáadtam a kódomhoz, hogy kiszámítsam, mit gondolok az ellenőrző összegről, és hogy valójában mi volt, de minden rossz volt!

Mint kiderült, valahogy rossz volt. Amikor elkezdtem binárisan nézni a számokat, teljesen érthető volt.

Az „XOR U -val” válasz mindig 9 bit adatot adott vissza (a 9. bit mindig egyet), de a többi bitnek igaza volt. Egyszerűen eltávolítottam a 9. bitet úgy, hogy a kapott számból 256 -ot vettem ki, majd megfelelt !!

Ha nem lett volna ez az egyén, lehet, hogy még mindig a fejemet vakarom. Le a kalappal előtte is, de nem tudom felvenni vele a kapcsolatot - alapvetően ez volt az egyetlen bejegyzése a stackexchange fórumon. Nos, köszönöm idegen!:)

A következő kihívás egy olyan áramkör létrehozása volt, amely lehetővé tette számomra a meglévő vezérlő szimulálását. Feltérképeztem a meghajtó áramkörének vázlatát (Pic1 és Pic 2), de túl bonyolultnak tűnt, hogy reprodukálnom kell, hogy megkapjam, amit akartam. Végül is már olvastam a jelet. Sokkal egyszerűbb módszer mellett döntöttem - az arduino segítségével opto -leválasztót vezérelve, hogy szükség szerint lehúzzam a 12 V -os jelvezetéket.

Terveztem egy egyszerűbb áramkört is az Rx -hez, de ez nem tesztelt, végül az egyszerűség kedvéért ragaszkodtam a szintváltóhoz.

5. lépés: Működtesse

Miután az átviteli áramkört kenyérpanelbe helyeztem, és száguldó szívvel, összeállítottam egy 12 bájtos (statikus) karakterláncot, kiszámítottam az ellenőrző összeget, és az arduino -t elküldte a parancsot - Meglepő módon a kijelző frissült !!! Győzelem!

Az utolsó tényleges teszt az volt, hogy hozzáadtam az arduino -t a BUS -hoz a 2 másik vezérlővel egy igazi élő teszthez, és biztosan működött.

Így most tudtam olvasni és írni a buszhoz, de egyszerűen hiányzott a képességem ahhoz, hogy egyszerűen megtehessem.

Mivel az MQTT -t szinte kizárólag az összes otthoni automatizáláshoz használom, természetes volt, hogy ez ugyanaz lesz. Több nap alatt írtam ki a kódot, hogy vezéreljem az AC 4 fő elemét, és visszaolvasom a meglévő állapotot is (a BUS többi moduljából)

A szándék az volt, hogy a kódot egy ESP8266 modulon futtassák, de úgy tűnik, hogy az ESP8266 nem képes 104 bps -os alacsony sebességű adatátvitelt előállítani. Vissza kellett térnem egy általános Arduino Uno -hoz a Wiznet ethernet segítségével, de ez nem volt nehéz, mivel a comms rack szó szerint a fal másik oldalán volt az egyik AC vezérlőtől.

A kód egy kicsit mindenhol megtalálható, de olvashatónak kell lennie. Sok problémám akadt azzal, hogy megakadályoztam, hogy a vezérlő leolvassa saját kimenetét, de megismételjem a saját maga által közzétett kódokat is, amelyeket az MQTT -től kapott vissza a légkondicionálóhoz. Alapvetően végtelen hurkot hozna létre. Végül néhány puffertörlés és a kódok feldolgozásának késedelme az MQTT -hez való közzététel után rendbe hozta azt.

Az Rx, Tx csapok az AC -hez 3, 4 kódolásúak, de ha úgy tetszik, változtasson

A kód úgy van konfigurálva, hogy a következőképpen tegye közzé és fogadja el a parancsokat:

ha/mod/5557/P 0/1 - Powerha/mod/5557/M 0/1/2/3/4 - Hűtés mód, Párátlanítás, Ventilátor, Automatikus, Heatha/mod/5557/F 0/1/2 - Ventilátor alacsony, med, highha/mod/5557/Z, azaz 1111 minden zóna 1000 -en csak 1 -es zóna bekapcsolásakor.

** A vezérlőn a zónák nem állíthatók "0000" -ra, azonban úgy tűnik, hogy ha megadja az értéket, az visszaáll "1000" -re.

A kód legújabb verziója elérhető a GitHub Repo -ból:

6. lépés: Valami tartósabb

Összegyűjtöttem egy arduino prototípus táblát, és az összes alkatrészt úgy telepítettem, ahogy kenyérpadlót kaptam.

7. lépés: OpenHAB Config

Lásd a csatolt fájlt az OpenHAB elemek, webhelytérkép és szabályok tekintetében

Kombinálja ezt az IFTTT OpenHab kötéssel és a Google Assistant/Home alkalmazással, és egy nagyon erőteljes hangvezérelt és/vagy „intelligens” légkondival rendelkezik, amely szinte minden kereskedelmi forgalomban kapható terméket felülmúl!

8. lépés: Összefoglalás

Összefoglalva - Ha Ön a szegény lelkek egyike, akinek valamivel régebbi LG légcsatornás légkondicionálója van, akkor nincs egyedül. Van még remény számunkra!

Remélem, ez az oktatható talál valakit, akinek annyira szüksége van rá, mint nekem. Alapvetően NINCS információ, amit találnék (a „Nick” ellenőrzőösszegén kívül). A nulláról kellett kezdenem, de elragadtatott vagyok az eredménytől.

Tudom, hogy az információ kissé homályos, de ha ugyanabban a helyzetben vagy, mint én, szívesen segítek.

- Vigyázat / Frissítés --- Habár lehetséges az AC beállításainak módosítása kikapcsolt egységgel, azt tapasztaltam, hogy amikor a zóna vezérlésről van szó, úgy tűnik, hogy zavarja azt. Sok tesztet végeztem kikapcsolt egységgel, és azt tapasztaltam, hogy a zónák inaktívnak tűnnek, de amikor az egység működik, úgy tűnik, hogy a csappantyúk nincsenek teljesen bezárva (de nem is teljesen nyitva). Visszaállítottam a készüléket a fő megszakítón, és ez megoldotta a problémát. Mivel a zóna csak a készülék bekapcsolt állapotában változik, ez nem jelentett problémát

Frissítettem a kódot, hogy csak a fővezérlőtől származó módosításokat tegye közzé (az MQTT -hez), és ne a főegységet. Ez ismét problémákat okozhat, mert a fő egység "0000" -ot küld a zónáknak (ami szintén a probléma lehetett)

A frissített kód néhány időzítési korlátozást is bevezet, hogy megakadályozza, hogy az arduino a mester és a fő egység egyidejű átvitelét végezze. Biztos vagyok benne, hogy valószínűleg van olyan módszer, amellyel a vezérlő adatküldést kezdeményez, például az Xms vonalának lehúzása a küldés előtt, de még nem fedeztem fel, ha van

Felfedeztem, hogy a fő egység 60 másodpercenként, a fővezérlő pedig 20 másodpercenként küld adatokat. A kód megpróbálja leállítani az adatok küldését az adatcsomag fogadását követő 2 másodpercen belül. Néha azonban a mester és a fő egység nagyon közel kerül egymáshoz. Ezt valószínűleg hamarosan pontosítják.----------------------------

** Működhet újabb egységeken

*** A kutatási utazásaim során talált néhány információ azt jelezte, hogy a Panasonic légcsatorna felosztása ugyanazt a protokollt használhatja. YMMV.