Hacking van 'n LG Ducted Split vir tuisautomatisering: 8 stappe (met foto's)

2024 Outeur: John Day | [email protected]. Laas verander: 2024-01-30 07:26

In die eerste plek - dit is nie nog 'n infrarooi afstandbeheer -emulasie -hack nie. My spesifieke AC het geen bruikbare koppelvlak wat ontwerp is vir enige ander beheer as die meegeleverde muurkontroles nie.

Ek het 'n LG Ducted reverse split -stelsel in my huis. Ongelukkig is dit gemaak in 'n tyd waarin IoT nie hoog op die lys van vervaardigers was nie. Ek het ontdek dat dit 'n paar opsies vir 'meester' -beheer het, maar alhoewel die eenheid slegs 2 jaar oud was toe ek dit die eerste keer probeer het, was die uitbreidingsborde unobtanium en die pryse was in elk geval astronomies. Net soos die 'Wireless RF Remote' -byvoeging, wat dinge baie makliker sou gemaak het, maar onmoontlik was om te koop.

As dit my keuse was, sou dit nie 'n LG wees nie, maar aangesien dit in die huis geïnstalleer is toe ek dit gekoop het (en die vervangingskoste daarvan waarskynlik meer as $ 10k sou wees), moes ek dit hanteer.

Doel - Om die wisselstroom via MQTT te beheer vir outomatisering via OpenHAB en IFTTT/Google Assistant

Stap 1: Dekodeer die dataformaat

Ek het 4 jaar gelede met hierdie proses begin, maar ek het nie ver gekom nie en wou nie die eenheid beskadig nie - veral omdat dit amper onmoontlik is om onderdele daarvoor te vind.

Toe ek die kontroleerder van die muur verwyder het, het ek drie drade gevind wat ek as grond, 12v en 'sein' sou bepaal.

Die seinspanning op die data lyn was 12v, maar ek het opgemerk dat dit skynbaar op die multimeter skommel ('n soort pulse op die lyn).

Ek het aan boord gegaan op 'n basiese stroombaan om 'n opto -isolator via die datapen te bestuur en die ander kant van die opto -isolator as 'n ingang op die geluidskaart van my rekenaar aangeskakel, en ek het 'n swak weergawe van 'n scope -uitset (Pic 1).

Dit is omtrent so ver as wat ek destyds gekom het - ek kon sien dat daar iets was, maar ek het nie regtig geweet hoe om dit te 'dekodeer' nie.

Sedert ek my koffiemasjien IoT aangeskakel het, het ek hierdie keer 'n hernieude belangstelling gehad om dit weer met 'n bietjie meer vasberadenheid te probeer.

Ek het my bevindings op die EEVBlog -forums geplaas om te sien of iemand dalk lig kan werp, en 'n wonderlike man met die naam Ian het tot my redding gekom - Hy het dit op 'n manier uiteengesit wat heeltemal sinvol was (prent 2)

Die datastroom is basies 13 grepe 'standaard seriële' - 8 databits, een beginbit en een stopbit (geen pariteit), maar met 'n BAIE lae baud -tempo van 104bps.

Stap 2: Dieper lyk

Noudat ek 'n idee gehad het van hoe die data geformateer word, het ek 'n manier nodig om die data op 'n meer dinamiese manier te kan lees.

Ek het een van my beheerders van die muur af gehaal en dit via 'n logiese vlakverskakelaar aan 'n Arduino vasgemaak met 'n eenvoudige skets om 13 grepe data te lees via die seriële poort van die sagteware wat op 104bps gekonfigureer is en dit uit te druk:

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, ** Eintlik 12 grepe hier

Ons het aksie gehad!

Deur die verskillende instellings op die beheerder dan te verander, kon ek die grepe wat verander verander:

168, 3, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, waaier 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, 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

Die getalle maak baie meer sin as u dit in binêre kyk, maar wat het dit met die 13de greep? Dit is oral …

Stap 3: karteer dit uit

Deur proef en fout kon ek die relevante stukkies in die 13 grepe data bepaal wat ek sou moes oordra.

Stap 4: Baksteenmuur vorentoe

Dit is waar dit ingewikkeld geraak het. Ek moes twee struikelblokke oorkom

a) Die 13de byte was 'n kontrolesom van die data wat ek nodig gehad het om op een of ander manier uit te werk. b) Hoe stuur ek die data dan oor? Dit is net een draad.

Uitgawe 'a' blyk baie eenvoudig te wees, maar dit was toevallig dat ek dit reggekry het.

In my toetse het ek na data gekyk soos: A802000000040F61000000004B A81200004004169A00000000FB A81200004004159A00000000F8 A81200004004149A00000000E5 A81200084000149C00000000E7 A83200084000149C0000000087 A85200084000

Dit is die 13 grepe data, insluitend die kontrolesom (hier in HEX in plaas van DEC).

Toe ek in die orakel soek wat Google is oor 'hoe om 'n kontrolesom te omskep', het ek op 'n stapeluitruil op hierdie bladsy afgekom met iemand anders met die naam Nick, en vra ongeveer dieselfde as ek, maar nie net dit nie, hulle het gepraat oor 'n lugversorger en hul data was byna dieselfde as myne - kan dit wees ??? Tydens al my soektogte (in ongeveer 4 jaar), het nie een persoon inligting geplaas oor hoe om die protokol op hierdie lugversorgers te hack nie, en ek val toevallig op iemand wat dieselfde doen deur te soek na iets wat amper heeltemal onverwant is? Dit was 'n seën - Hy het selfs geplaas dat hy dit uitgewerk het en die oplossing was: Tel al die Bytes data op en dan XOR met 'U'.

Met dit in die hand het ek dit by my kode gevoeg om te bereken wat ek gedink het die kontrolesom moet wees teenoor wat dit eintlik was, maar dit was alles verkeerd !!

Soos dit blyk, was dit 'n bietjie verkeerd. Toe ek na die getalle in binêre begin kyk, het dit heeltemal sin gemaak.

Die reaksie van die 'XOR met U' het altyd 9 stukkies data (die 9de bisse altyd een) gelewer, maar die ander stukkies was reg. Ek het eenvoudig die 9de bietjie verwyder deur 256 van die gevolglike getal te neem, en dan pas dit !!

As dit nie vir hierdie persoon was nie, kon ek nog steeds in my kop krap. Hoed ook vir hom af, maar ek kan hom nie kontak nie - dit was basies sy enigste pos op die stackexchange forum. Dankie, vreemdeling:)

Die volgende uitdaging was om 'n stroombaan te maak waarmee ek die bestaande beheerder kon simuleer. Ek het die skema vir die dryfbaan (Pic1 en Pic 2) in kaart gebring, maar dit was te ingewikkeld vir my om dit weer te gee om te kry wat ek wou hê. Ek het immers al die sein gelees. Ek het gekies vir 'n baie eenvoudiger metode - om die arduino te gebruik om 'n opto -isolator aan te dryf om die 12v seinlyn laag te trek soos benodig.

Ek het ook 'n eenvoudiger stroombaan vir die Rx ontwerp, maar dit is ongetoets, maar ek het by die vlakomskakelaar gehou vir eenvoud.

Stap 5: Laat dit werk

Sodra ek die stuurkring op die bord geborduur het, en met 'n vinnige hart, het ek 'n (statiese) string van 12 grepe opgebou, die kontrolesom bereken en die arduino die opdrag laat stuur - ongelooflik, die skerm is opgedateer !!! Wen!

Die laaste werklike toets was om my arduino by die BUS te voeg met die 2 ander beheerders vir 'n regte lewendige toets, en dit het gewerk.

So nou kon ek vir die bus lees en skryf, maar ek het net nie die vermoë gehad om dit eenvoudig te kon doen nie.

Aangesien ek MQTT byna uitsluitlik vir al my tuisautomatisering gebruik, was dit natuurlik dat dit dieselfde sou wees. Ek het die kode oor 'n paar dae geskryf om die 4 hoofelemente van die AC te beheer, en ek het ook die bestaande status (uit die ander modules op die BUS) gelees

Die bedoeling was om die kode op 'n ESP8266 -module te laat werk, maar dit wil voorkom asof die ESP8266 nie 'n baud -tempo van so laag as 104bps kan lewer nie. Ek moes terugkeer na 'n generiese Arduino Uno met Wiznet -ethernet, maar dit was nie moeilik nie, want my kommasierek was letterlik aan die ander kant van die muur van een van die AC -beheerders.

Die kode is 'n bietjie oral, maar moet leesbaar wees. Ek het baie probleme gehad om te verhoed dat die beheerder sy eie uitset lees, maar ek herhaal die kode, dit is eie gepubliseerde onderwerpe wat van MQTT terug na die aircon ontvang is. Basies sou dit 'n oneindige lus skep. Uiteindelik is 'n bufferopruiming en vertragings in die verwerking van kode nadat dit aan MQTT gepubliseer is, gesorteer.

Rx, Tx -penne na die AC word as 3, 4 gekodeer, maar verander as u wil

Die kode is opgestel om opdragte as sodanig te publiseer en te aanvaar:

ha/mod/5557/P 0/1 - Powerha/mod/5557/M 0/1/2/3/4 - Mode Cool, Ontvochtig, Waaier, Auto, Heatha/mod/5557/F 0/1/2 - Waaier laag, med, hoogha/mod/5557/Z dws 1111 vir alle sones op 1000 vir net sone 1 aan.

** Van die beheerder af kan die sones nie op '0000' ingestel word nie, maar dit wil voorkom asof u die waarde uitgee na '1000'.

Die nuutste weergawe van die kode is beskikbaar by my GitHub Repo:

Stap 6: Iets meer permanent

Ek het 'n arduino -prototipe -bord bymekaargemaak en al die onderdele geïnstalleer terwyl ek dit aan boord gehad het.

Stap 7: OpenHAB Config

Sien aangehegte lêer vir OpenHAB -items, werfkaart en reëls

Kombineer dit met die IFTTT OpenHab -binding en Google Assistant/Home, en u het 'n baie kragtige stembeheerde en/of 'slim' lugversorger wat byna elke produk wat in die handel beskikbaar is, oortref!

Stap 8: Opsomming

Ter afsluiting - As u een van die arme siele is met 'n effens ouer lugversorging met 'n LG, is u nie alleen nie. Daar is nog hoop vir ons!

Ek hoop dat hierdie leerbare iemand iemand vind wat dit so nodig het as ek. Daar is basies GEEN inligting wat ek kon vind nie (behalwe die kontrolesom van 'Nick'). Ek moes van voor af begin, maar ek is in ekstase met die resultaat.

Die inligting is 'n bietjie vaag, maar ek weet, maar as u in dieselfde situasie is as ek, was ek bereid om u te help.

- Let op / bywerk --- Alhoewel dit moontlik is om die instellings op die wisselstroom te verander met die toestel af, het ek gevind dat dit met die sone-beheer verband hou. Ek het baie getoets met die eenheid af en ek het gevind dat die sones as onaktief sou vertoon, maar as die eenheid werk, lyk dit asof die dempers nie heeltemal gesluit is nie (maar ook nie heeltemal oop nie). Ek het die eenheid by die hoofbreker teruggestel, en dit het die probleem opgelos. Aangesien slegs die sone verander is terwyl die eenheid aan is, was dit nie 'n probleem nie

Ek het die kode ook opgedateer om slegs veranderinge wat van die hoofbeheerder afkomstig is, nie die hoofeenheid te publiseer nie (na MQTT). Dit kan weereens probleme veroorsaak omdat die hoof -eenheid '0000' vir die sones stuur (wat ook die probleem kon gewees het)

Opgedateerde kode bevat ook 'n paar tydsbeperkings om te voorkom dat die arduino op dieselfde tyd van die hoof- en hoofeenheid oorgedra word. Ek is seker dat daar waarskynlik 'n metode is wat die beheerder gebruik om 'n datastuur te begin, soos om die lyn vir Xms laag te trek voordat dit gestuur word, maar ek het dit nog nie ontdek as daar is nie

Ek het ontdek dat die hoofeenheid elke 60 sekondes data stuur en die hoofbeheerder elke 20 sekondes. Die kode probeer om die stuur van data binne 2 sekondes na ontvangs van die pakkie te stop. Soms stuur die meester en hoofeenheid egter baie na aan mekaar. Dit sal waarskynlik binnekort meer verfyn word.----------------------------

** Mag op nuwer eenhede werk

*** 'n Paar inligting wat ek tydens my navorsingsreise gevind het, het aangedui dat Panasonic -kanaalsplitsing dieselfde protokol kan gebruik. YMMV.