Hacking af en LG Ducted Split til hjemmeautomatisering: 8 trin (med billeder)

2024 Forfatter: John Day | [email protected]. Sidst ændret: 2024-01-30 08:28

Først og fremmest - Dette er ikke et andet infrarødt fjernbetjeningsemuleringshack. Min særlige AC har ingen brugbar grænseflade designet til andre former for kontrol end de medfølgende vægmonterede smarte kontroller.

Jeg har et LG Ducted reverse split system i mit hus. Desværre blev det lavet på et tidspunkt, hvor IoT ikke var højt på nogen producentliste. Jeg opdagede, at den havde nogle muligheder for 'master' kontrol, men selvom enheden kun var 2 år gammel på det tidspunkt, da jeg første gang forsøgte dette, var udvidelseskortene unobtanium, og priserne var alligevel astronomiske. Ligesom tilføjelsen 'Wireless RF Remote', som ville have gjort tingene meget lettere, men umulige at købe.

Havde det været mit valg, ville det ikke være en LG, men da det blev installeret i huset, da jeg købte det (og dets udskiftningsomkostninger sandsynligvis ville overstige $ 10k) er det, hvad jeg skulle håndtere.

Formål - At kunne styre AC via MQTT med henblik på automatisering via OpenHAB og IFTTT/Google Assistant

Trin 1: Afkodning af dataformatet

Jeg startede denne proces for 4 år siden, men kom ikke særlig langt og ville ikke risikere at beskadige enheden - Især da dele til den virker næsten umulige at finde.

Ved at rive controlleren af væggen fandt jeg 3 ledninger, som jeg besluttede at være jord, 12v og 'signal'

Signalspændingen på datalinjen var på 12v, men jeg lagde mærke til, at det syntes at svinge på multimeteret (en slags pulser på linjen).

Jeg brød ombord på et grundlæggende kredsløb for at drive en opto -isolator via datapinden og tilsluttede den anden side af opto -isolatoren som et input på min pc's lydkort og fik en dårlig version af et omfangsudgang (Pic 1).

Dette er omtrent så langt som jeg kom på det tidspunkt - jeg kunne se, at der var noget der, men vidste ikke rigtig, hvordan jeg skulle 'afkode' det.

Siden jeg fik aktiveret min kaffemaskine IoT, havde jeg en fornyet interesse i at prøve dette igen med lidt mere beslutsomhed denne gang.

Jeg lagde mine fund ud på EEVBlog -fora for at se, om nogen måske kunne kaste lys og en stor fyr ved navn Ian kom mig til undsætning - Han lagde det ud på en måde, det var helt fornuftigt (Pic 2)

Grundlæggende er datastrømmen 13 bytes 'standardseriel' - 8 databit, en startbit og en stopbit (ingen paritet), men med en MEGET lav baudhastighed på 104bps.

Trin 2: Ser dybere ud

Så nu hvor jeg havde en idé om, hvordan dataene blev formateret, havde jeg brug for en måde, hvorpå jeg kunne læse dataene på en mere dynamisk måde.

Jeg trak en af mine controllere fra væggen og tilsluttede den via en logisk niveauskifter til en Arduino med en simpel skitse for at læse 13 bytes data via software seriel port konfigureret til 104bps og udskrive 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, ** Faktisk 12 bytes her

Vi havde handling!

Ved derefter at ændre de forskellige indstillinger på controlleren, var jeg i stand til at regne ud de bytes, der ændres:

168, 3, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, blæser LOW168, 35, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, Fan MED 168, 67, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 152, Fan 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, 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 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

Tallene giver meget mere mening, når du ser på dem i binært format, men hvad er der med den 13. byte ?? Det er over det hele…

Trin 3: Kortlægning af det

Gennem trial and error kunne jeg bestemme de relevante bits i de 13 byte data, som jeg skulle bruge for at kunne transmittere.

Trin 4: Brick Wall Ahead

Det er her det blev kompliceret. Jeg havde to forhindringer at overvinde

a) Den 13. byte syntes at være en kontrolsum af de data, som jeg på en eller anden måde skulle udarbejde. b) Hvordan overfører jeg dataene derefter? Det er kun en ledning.

Problem 'a' viste sig at være VIRKELIG let, men det var ved et tilfældigt tilfælde, at jeg formåede at komme forbi det.

I mine test kiggede jeg på data som: A802000000040F61000000004B A81200004004169A00000000FB A81200004004159A00000000F8 A81200004004149A00000000E5 A81200084000149C00000000E7 A83200084000149C0000000087 A85200084000

Dette er 13bytes data inklusive kontrolsummen (her i HEX i stedet for DEC).

Da jeg søgte i oraklet, der er google om 'hvordan man ombygger en checksum', stødte jeg på denne side på stack exchange med en anden, der hedder Nick og spurgte stort set det samme som mig, men ikke kun det, de talte om et klimaanlæg og deres data var næsten identisk format til mit - Kan det være ??? I alle mine søgninger (i 4 eller deromkring år) var der ikke én person, der havde postet nogen oplysninger om, hvordan man kan hacke protokollen på disse klimaanlæg, og jeg faldt tilfældigvis over, at nogen gjorde det samme ved at søge efter noget, der næsten ikke er relateret? Det var en velsignelse - Han skrev endda, at han fandt ud af det, og løsningen var: Tilføj alle Bytes med data og derefter XOR med "U".

Med det i hånden tilføjede jeg det til min kode for at beregne, hvad jeg syntes, kontrolsummen skulle være vs hvad det faktisk var, men det var alt forkert !!

Som det viser sig, var det lidt forkert. Da jeg begyndte at se på tallene i binært, gav det fuldstændig mening.

Svaret fra 'XOR med U' returnerede altid 9 bits data (den 9. bit altid en), men de andre bits var rigtige. Jeg fjernede simpelthen den 9. bit ved at tage 256 fra det resulterende nummer, og så matchede det !!

Havde det ikke været for denne person, kunne jeg stadig ridse i hovedet. Hatten af for ham også, men jeg kan ikke kontakte ham - Det var dybest set hans eneste indlæg på stackexchange forum. Tak, tak, fremmede:)

Den næste udfordring var at lave et kredsløb, der ville tillade mig at simulere den eksisterende controller. Jeg kortlagde skematikken for drivkredsløbet (Pic1 og Pic 2), men det virkede alt for kompliceret til, at jeg skulle reproducere det for at få det, jeg ønskede. Jeg læste jo allerede signalet. Jeg valgte en meget enklere metode - Brug af arduinoen til at drive en opto -isolator til at trække 12v -signallinjen lavt efter behov.

Jeg har også designet et enklere kredsløb til Rx, men dette er ikke testet, jeg endte med at holde fast ved niveauomformeren for enkelhed.

Trin 5: Få det til at fungere

Når jeg havde transmitteret kredsløb, og med et racerhjerte, manglede jeg en (statisk) streng på 12 bytes, beregnede kontrolsummen og fik arduinoen til at sende kommandoen - Utroligt nok blev displayet opdateret !!! Vinde!

Den sidste faktiske test var at tilføje min arduino til BUS med de 2 andre controllere til en rigtig live test og det fungerede sikkert.

Så nu kunne jeg læse og skrive til bussen, men manglede bare evnen til at kunne gøre det ganske enkelt.

Da jeg næsten udelukkende bruger MQTT til al min hjemmeautomatisering, var det naturligt, at dette ville være det samme. Jeg skrev koden ud over flere dage for at styre de 4 hovedelementer i AC'en og læste også den eksisterende status tilbage (fra de andre moduler på BUS)

Hensigten var at have koden kørende på et ESP8266 -modul, men det ser ud til, at ESP8266 ikke er i stand til at producere en baudhastighed så lav som 104bps. Jeg var nødt til at vende tilbage til en generisk Arduino Uno med Wiznet -ethernet, men det var ikke svært, da mit comms -rack bogstaveligt talt var på den anden side af væggen fra en af AC -controllerne.

Koden er lidt over det hele, men skal være læselig. Jeg havde mange problemer med at forhindre controlleren i at læse sit eget output, men også at gentage koden, det er egne publicerede emner modtaget fra MQTT tilbage til aircon. Grundlæggende ville det skabe en uendelig loop. I sidste ende fik nogle buffer -clearing og forsinkelser i behandlingen af kode efter offentliggørelse til MQTT det sorteret.

Rx, Tx -pins til AC'en er kodet som 3, 4, men skift, hvis du vil

Koden er konfigureret til at publicere og acceptere kommandoer som sådan:

ha/mod/5557/P 0/1 - Powerha/mod/5557/M 0/1/2/3/4 - Mode Cool, Affugtning, Fan, Auto, Heatha/mod/5557/F 0/1/2 - Blæser lav, med, højha/mod/5557/Z dvs. 1111 for alle zoner på 1000 for bare zone 1 på.

** Fra controlleren kan zoner ikke indstilles til '0000', men det ser ud til, at hvis du udsteder værdien, vender den tilbage til '1000'.

Den seneste version af koden er tilgængelig fra min GitHub Repo:

Trin 6: Noget mere permanent

Jeg samlede et arduino -prototypebræt og installerede alle delene, da jeg havde dem brødbrættet.

Trin 7: OpenHAB Config

Se vedhæftede fil for OpenHAB -emner, sitemap og regler

Kombiner dette med IFTTT OpenHab -bindingen og Google Assistant/Home, og du har en meget kraftfuld stemmestyret og/eller 'smart' aircondition, der overgår næsten alle kommercielt tilgængelige produkter!

Trin 8: Resumé

Afslutningsvis - Hvis du er en af de stakkels sjæle med et lidt ældre LG -kanaliseret split -klimaanlæg, er du ikke alene. Der er stadig håb for os!

Jeg håber, at denne instruktive finder nogen, der har brug for det lige så meget som jeg gjorde. Der er stort set ingen oplysninger, som jeg kunne finde (bortset fra kontrolsummen fra 'Nick'). Jeg var nødt til at starte forfra, men jeg er i ekstase med resultatet.

Oplysningerne er lidt vage, jeg ved, men hvis du er i samme situation som jeg var, vil jeg være mere end villig til at hjælpe.

- Forsigtighed / opdatering --- Selvom det er muligt at ændre indstillingerne på AC-enheden med enheden slukket, har jeg fundet ud af, at når det kommer til zonekontrollen, ser det ud til at rode med det. Jeg testede meget med enheden slukket, og jeg fandt ud af, at zonerne ville vise sig at være inaktive, men når enheden er i drift, ser det ud til, at spjældene ikke er helt lukkede (men heller ikke helt åbne). Jeg nulstillede enheden ved hovedafbryderen, og dette løste problemet. Siden det kun var at ændre zoner, når enheden er tændt, har dette ikke været et problem

Jeg har også opdateret koden til kun at offentliggøre (til MQTT) ændringer, der kommer fra master -controlleren og ikke hovedenheden. Dette kan igen forårsage problemer, fordi hovedenheden sender '0000' til zoner (hvilket også kunne have været problemet)

Opdateret kode introducerer også nogle tidsbegrænsninger for at forsøge at forhindre arduinoen i at sende på samme tid som master og hovedenhed. Jeg er sikker på, at der sandsynligvis er en metode, som controlleren bruger til at starte en datasending som at trække linjen lavt for Xms før afsendelse, men jeg har ikke opdaget det endnu, hvis der er

Jeg opdagede, at hovedenheden sender data hvert 60. sekund, og master -controlleren sender hvert 20. sekund. Koden forsøger at standse afsendelse af data inden for 2 sekunder efter modtagelse af datapakke. Nogle gange sender master og hovedenhed imidlertid meget tæt på hinanden. Dette vil sandsynligvis blive raffineret mere snart.----------------------------

** Kan arbejde på nyere enheder

*** Nogle oplysninger, der blev fundet på mine forskningsrejser, indikerede, at Panasonic -kanalopdeling kunne bruge den samme protokol. YMMV.