Hacka en LG Ducted Split för hemautomation: 8 steg (med bilder)

2024 Författare: John Day | [email protected]. Senast ändrad: 2024-01-30 12:44

Först och främst - Det här är inte ett annat infrarött fjärrkontrollemuleringshack. Min speciella AC har inget användbart gränssnitt utformat för någon annan typ av kontroll än de medföljande väggmonterade smarta kontrollerna.

Jag har ett LG Ducted reverse split system i mitt hus. Tyvärr gjordes det vid en tidpunkt då IoT inte stod högt på någon tillverkarlista. Jag upptäckte att den hade några alternativ för "master" -kontroll, men även om enheten bara var 2 år gammal när jag först försökte detta, var expansionsbrädorna unobtaniska och priserna var astronomiska ändå. Liksom tillägget 'Wireless RF Remote' som skulle ha gjort saker mycket enklare men omöjliga att köpa.

Hade det varit mitt val, skulle det inte vara en LG men eftersom det installerades i huset när jag köpte det (och det är sannolikt att ersättningskostnaden skulle överstiga $ 10k) är det vad jag måste hantera.

Syfte - Att kunna styra AC via MQTT för automatisering via OpenHAB och IFTTT/Google Assistant

Steg 1: Avkodning av dataformat

Jag startade den här processen för 4 år sedan men kom inte särskilt långt och ville inte riskera att skada enheten - Speciellt eftersom delar verkar nästan omöjliga att hitta.

När jag slet kontrollen från väggen hittade jag tre ledningar som jag bestämde mig för att vara jord, 12v och 'signal'

Signalspänningen på datalinjen var vid 12v, men jag märkte att det verkade svänga på multimetern (någon form av pulser på linjen).

Jag brödde ombord på en en grundläggande krets för att driva en opto -isolator via datapinnen och kopplade den andra sidan av opto -isolatorn som en ingång på min PC: s ljudkort och fick en dålig version av en utgång (Pic 1).

Det här är ungefär så långt jag kom då - jag kunde se att det var något där men visste inte riktigt hur jag skulle”avkoda” det.

Sedan jag fick min kaffemaskin IoT aktiverad hade jag ett uppfriskat intresse av att försöka igen med lite mer beslutsamhet den här gången.

Jag lade upp mina fynd på EEVBlog -forumet för att se om någon kanske kunde kasta lite ljus och en fantastisk kille vid namn Ian kom till min räddning - Han lade upp det på ett sätt som det var helt meningsfullt (bild 2)

I grund och botten är dataströmmen 13 byte med 'standardseriell' - 8 databitar, en startbit och en stoppbit (ingen paritet) men med en MYCKET låg baudhastighet på 104bps.

Steg 2: Ser djupare ut

Så nu när jag hade en uppfattning om hur data formaterades, behövde jag ett sätt att kunna läsa data på ett mer dynamiskt sätt.

Jag drog en av mina kontroller från väggen och kopplade den via en logisk nivåväxel till en Arduino med en enkel skiss för att läsa 13 byte data via programvarans seriella port konfigurerad vid 104bps och skriva ut den:

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, ** Faktiskt 12 byte här

Vi hade action!

Genom att sedan ändra de olika inställningarna på styrenheten kunde jag räkna ut byte som ändras:

168, 3, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, fläkt LOW168, 35, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, Fläkt MED 168, 67, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 152, Fläkt HÖG

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

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

Siffrorna är mycket mer meningsfulla när du tittar på dem i binär men vad är det med 13: e byte ?? Det är överallt …

Steg 3: Kartlägga det

Genom försök och fel kunde jag bestämma de relevanta bitarna i de 13 byte med data som jag skulle behöva för att kunna överföra.

Steg 4: Tegelvägg framåt

Det var här det blev komplicerat. Jag hade två hinder att övervinna

a) Den 13: e byten verkade vara en kontrollsumma för de data som jag behövde för att på något sätt räkna ut. b) Hur överför jag data då? Det är bara en tråd.

Frågan 'a' visade sig vara RIKTIGT enkel, men det var av en ren slump att jag lyckades komma förbi den.

I mina tester tittade jag på data som: A802000000040F61000000004B A81200004004169A00000000FB A81200004004159A00000000F8 A81200004004149A00000000E5 A81200084000149C00000000E7 A83200084000149C0000000087 A85200084000

Detta är 13bytes data inklusive kontrollsumman (här i HEX istället för DEC).

När jag sökte i oraklet som är google om 'hur man omvandlar en kontrollsumma' stötte jag på den här sidan på stackutbyte med någon annan som hette Nick och frågade i stort sett samma sak som mig men inte bara det, de pratade om en luftkonditionering och deras data var nästan identiskt format som mitt - Kan det vara ??? Under alla mina sökningar (om 4 år) hade inte en person lagt ut någon information om hur man hackar protokollet på dessa luftkonditioneringsapparater och jag råkar bara stöta på att någon gör samma sak genom att söka efter något som nästan är helt oberoende? Det var en välsignelse - Han skrev till och med att han räknade ut det och lösningen var: Lägg ihop alla bytes med data och sedan XOR med "U".

Med det i handen lade jag till det i min kod för att beräkna vad jag tyckte att kontrollsumman skulle vara vs vad det faktiskt var men det var helt FEL !!

Som det visar sig var det lite fel. När jag började titta på siffrorna i binär var det helt meningsfullt.

Svaret från 'XOR med U' returnerade alltid 9 bitar data (den 9: e bit alltid en) men de andra bitarna hade rätt. Jag tog helt enkelt bort den 9: e biten genom att ta 256 från det resulterande numret och sedan matchade det !!

Hade det inte varit för den här individen kan jag fortfarande klia mig i huvudet. Hatten av för honom också men jag kan inte kontakta honom - Det var i princip hans enda inlägg på stackexchange -forumet. Tack, främling:)

Nästa utmaning var att skapa en krets som skulle tillåta mig att simulera den befintliga styrenheten. Jag kartlade schemat för drivkretsen (Pic1 och Pic 2) men det verkade alldeles för komplicerat för att jag skulle behöva reproducera det för att få det jag ville ha. Jag läste trots allt redan signalen. Jag valde en mycket enklare metod - Att använda arduino för att driva en opto -isolator för att dra 12v -signallinjen lågt efter behov.

Jag konstruerade också en enklare krets för Rx men detta är otestat, jag slutade att hålla fast vid nivåomvandlaren för enkelhet.

Steg 5: Få det att fungera.

När jag väl hade sändkretsen breddad, och med ett tävlingshjärta, jagade jag upp en (statisk) sträng på 12 byte, beräknade kontrollsumman och fick arduino att skicka kommandot - Otroligt nog, displayen uppdaterades !!! Vinna!

Det sista faktiska testet var att lägga till min arduino till BUS med de 2 andra kontrollerna för ett riktigt live test och visst fungerade det.

Så nu kunde jag läsa och skriva till bussen men saknade bara förmågan att kunna göra det helt enkelt.

Eftersom jag använder MQTT nästan uteslutande för all min hemautomation var det naturligt att detta skulle vara detsamma. Jag skrev ut koden under flera dagar för att styra de fyra huvudelementen i AC, läser också tillbaka den befintliga statusen (från de andra modulerna på BUS)

Avsikten var att koden ska köras på en ESP8266 -modul men det verkar som att ESP8266 inte kan producera en baudhastighet så låg som 104bps. Jag var tvungen att återgå till en generisk Arduino Uno med Wiznet -ethernet, men det var inte svårt eftersom mitt comms -rack bokstavligen låg på andra sidan väggen från en av AC -kontrollerna.

Koden är lite överallt men bör vara läsbar. Jag hade många problem med att hindra regulatorn från att läsa sin egen utdata men också upprepa koden, det är egna publicerade ämnen som mottagits från MQTT tillbaka till luftkonditioneringen. I grund och botten skulle det skapa en oändlig slinga. I slutändan sorterades en del buffertrensning och förseningar i bearbetningen av kod efter publicering till MQTT.

Rx, Tx -stiften till AC är kodade som 3, 4 men ändras om du vill

Koden är konfigurerad för att publicera och acceptera kommandon som sådana:

ha/mod/5557/P 0/1 - Powerha/mod/5557/M 0/1/2/3/4 - Läge Cool, Avfuktning, Fläkt, Auto, Heatha/mod/5557/F 0/1/2 - Fläkt låg, med, högha/mod/5557/Z dvs 1111 för alla zoner på 1000 för bara zon 1 på.

** Från handkontrollen kan zoner inte ställas in på '0000' men det verkar som om du utfärdar värdet kommer det att återgå till '1000'.

Den senaste versionen av koden är tillgänglig från min GitHub Repo:

Steg 6: Något mer permanent

Jag samlade ihop en arduino -prototypbräda och installerade alla delar när jag fick dem brödbrädda.

Steg 7: OpenHAB Config

Se bifogad fil för OpenHAB -objekt, webbplatskarta och regler

Kombinera detta med IFTTT OpenHab -bindningen och Google Assistant/Home och du har en mycket kraftfull röststyrd och/eller "smart" luftkonditionering som överträffar nästan alla kommersiellt tillgängliga produkter!

Steg 8: Sammanfattning

Sammanfattningsvis - Om du är en av de fattiga själarna med en lite äldre delad luftkonditionering av LG, är du inte ensam. Det finns fortfarande hopp för oss!

Jag hoppas att denna instruerbara hittar någon som behöver det lika mycket som jag gjorde. Det finns i princip INGEN information som jag kunde hitta (förutom kontrollsummen från "Nick"). Jag var tvungen att börja om från början men jag är extatisk över resultatet.

Informationen är lite vag jag vet, men om du befinner dig i samma situation som jag var, är jag mer än villig att hjälpa till.

-- Varning / uppdatering --- Även om det är möjligt att ändra inställningarna på växelströmmen med enheten Av, har jag funnit att när det gäller zonkontrollen verkar det röra med det. Jag testade mycket med enheten avstängd och jag fann att zonerna skulle visa sig vara inaktiva men när enheten är i drift verkar det som att spjällen inte är helt stängda (men inte helt öppna heller). Jag återställde enheten vid huvudbrytaren och detta löste problemet. Eftersom endast byte av zoner när enheten är på har detta inte varit ett problem

Jag har också uppdaterat koden för att bara publicera (till MQTT) ändringar som kommer från huvudkontrollen och inte huvudenheten. Återigen kan detta orsaka problem eftersom huvudenheten skickar '0000' för zonerna (vilket också kan ha varit problemet)

Uppdaterad kod introducerar också vissa tidsbegränsningar för att försöka förhindra att arduino sänder samtidigt av master och huvudenhet. Jag är säker på att det förmodligen finns en metod som styrenheten använder för att initiera en datasändning som att dra linjen för Xms innan den skickas, men jag har inte upptäckt den ännu om det finns

Jag upptäckte att huvudenheten kommer att skicka data var 60: e sekund och huvudkontrollen skickar var 20: e sekund. Koden försöker stoppa sändningsdata inom 2 sekunder efter mottagandet av datapaketet. Ibland sänder dock master och huvudenhet mycket nära varandra. Detta kommer förmodligen att förfinas mer snart.----------------------------

** Kan fungera på nyare enheter

*** Viss information som hittades i mina forskningsresor indikerade att Panasonics kanaliserade split kan använda samma protokoll. YMMV.