Hacking d'una divisió de conductes LG per a la domòtica: 8 passos (amb imatges)

2024 Autora: John Day | [email protected]. Última modificació: 2024-01-30 08:14

Primer de tot: no es tracta d’un altre hack d’emulació per control remot per infraroig. La meva CA particular no té cap interfície utilitzable dissenyada per a cap tipus de control que no sigui els controls intel·ligents muntats a la paret inclosos.

Tinc un sistema de divisió inversa LG Ducted a casa meva. Malauradament, es va fer en un moment en què l'IoT no figurava en cap llista de fabricants. Vaig descobrir que tenia algunes opcions per al control "mestre", però tot i que la unitat tenia només 2 anys en el moment en què vaig intentar-ho per primera vegada, les plaques d'expansió eren unobtani i els preus eren astronòmics. Igual que el complement "Wireless RF Remote", que hauria fet les coses molt més fàcils però impossibles de comprar.

Si hagués estat la meva elecció, no seria un LG, però, ja que es va instal·lar a la casa quan el vaig comprar (i el seu cost de reemplaçament superava els 10.000 dòlars), és el que m’havia d’ocupar.

Objectiu: poder controlar el CA mitjançant MQTT a efectes d'automatització mitjançant OpenHAB i IFTTT / Assistent de Google

Pas 1: descodificació del format de dades

Vaig començar aquest procés fa 4 anys, però no vaig arribar gaire lluny i no volia arriscar-me a fer malbé la unitat, sobretot perquè les parts que semblen gairebé impossibles de trobar.

Arrencant el controlador de la paret, vaig trobar 3 cables que vaig determinar que eren terra, 12v i "senyal".

La tensió de senyalització a la línia de dades era de 12v, però em vaig adonar que semblava fluctuar al multímetre (una mena de polsos a la línia).

Em vaig embarcar en un circuit bàsic per conduir un aïllador opto mitjançant el pin de dades i vaig connectar l’altre costat de l’aïllador opto com a entrada a la targeta de so del meu PC i vaig obtenir una versió pobra d’una sortida d’objectiu (foto 1).

Això és gairebé el que vaig aconseguir en aquell moment: vaig poder veure que hi havia alguna cosa, però no sabia com "descodificar-ho".

Des que vaig activar la meva màquina de cafè IoT, vaig tenir un interès renovat en provar-ho de nou amb una mica més de determinació aquesta vegada.

Vaig publicar els meus descobriments als fòrums d'EEVBlog per veure si algú podria donar llum i un gran tipus anomenat Ian va venir al meu rescat. Ho va exposar d'una manera que tenia completament sentit (foto 2)

Bàsicament, el flux de dades és de 13 bytes de "sèrie estàndard": 8 bits de dades, un bit d'inici i un bit d'aturada (sense paritat), però a una velocitat de transmissió MOLT baixa de 104bps.

Pas 2: mirar més a fons

Per tant, ara que tenia una idea de com es formataven les dades, necessitava una manera de poder llegir-les d’una manera més dinàmica.

Vaig treure un dels meus controladors de la paret i el vaig connectar mitjançant un canvi de nivell lògic a un Arduino amb un esbós senzill per llegir 13 bytes de dades mitjançant un port sèrie del programari configurat a 104bps i imprimir-lo:

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, ** En realitat, aquí hi ha 12 bytes

Vam tenir acció!

Aleshores, canviant els diversos paràmetres del controlador, vaig poder treballar els bytes que canviaven:

168, 3, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, Ventilador BAIX 168, 35, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, Ventilador MED 168, 67, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 152, Ventilador ALT

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, temperatura 30

Els números tenen molt més sentit quan els mireu en binari, però què hi ha amb el 13è byte ?? És per tot arreu …

Pas 3: mapeu-lo

Mitjançant proves i errors, vaig poder determinar els bits rellevants dels 13 bytes de dades que hauria de poder transmetre.

Pas 4: Muro de maó per davant

Aquí es va complicar. Tenia dos obstacles a superar

a) El 13è byte semblava ser una suma de comprovació de les dades que d'alguna manera necessitava treballar. b) Com puc transmetre les dades aleshores? És només un filferro.

El número "a" va resultar MOLT fàcil, però va ser per pura coincidència que vaig aconseguir superar-lo.

A les meves proves, estava mirant dades com: A802000000040F61000000004B A81200004004169A0000000000FB A81200004004159A00000000F8 A81200004004149A00000000E5E5 A81200084000149C00000000E7 A8320008400000000

Es tracta dels 13 bytes de dades inclosa la suma de comprovació (aquí a HEX en lloc de DEC).

Quan buscava l’oracle de Google sobre “com fer una enginyeria inversa d’una suma de comprovació”, em vaig trobar amb aquesta pàgina en intercanvi de pila amb una altra persona que es deia Nick i em preguntava gairebé el mateix que jo, però no només això, parlaven sobre un aparell d’aire condicionat i les seves dades tenien un format gairebé idèntic a la meva - Podria ser ??? En totes les meves cerques (d'aquí a aproximadament 4 anys), cap persona no havia publicat cap informació sobre com piratejar el protocol d'aquests aparells d'aire condicionat i em trobo amb algú que fa el mateix buscant alguna cosa gairebé completament no relacionada? Va ser una benedicció: fins i tot va publicar que ho va solucionar i la solució va ser: sumar tots els bytes de dades i després XOR amb "U".

Amb això a la mà, l'he afegit al meu codi per calcular el que pensava que hauria de ser la suma de verificació en comparació amb el que realment era, però tot estava malament.

Resulta que estava malament. Quan vaig començar a mirar els números en binari, tenia tot un sentit.

La resposta del "XOR amb U" sempre va retornar 9 bits de dades (el novè bit sempre un), però els altres bits van ser correctes. Simplement he eliminat el novè bit agafant 256 del número resultant i després ha coincidit !!

Si no hagués estat per aquest individu, encara em podria ratllar el cap. També m’agrada molt, però no puc posar-me en contacte amb ell, bàsicament era l’única publicació que hi havia al fòrum stackexchange. Bé, gràcies desconegut:)

El següent repte va ser fer un circuit que em permetés simular el controlador existent. Vaig traçar l’esquema del circuit de la unitat (Pic1 i Pic 2), però em va semblar massa complicat haver de reproduir-lo per obtenir el que volia. Després de tot, ja estava llegint el senyal. Vaig optar per un mètode molt més senzill: fer servir l'arduino per conduir un aïllador opto per baixar la línia de senyal de 12 V segons es requereixi.

També vaig dissenyar un circuit més senzill per al Rx, però això no està provat, vaig acabar quedant amb el convertidor de nivell per simplificar-lo.

Pas 5: fer que funcioni

Una vegada que tenia el circuit de transmissió programat i amb un cor de carrera, vaig manipular una cadena (estàtica) de 12 bytes, vaig calcular la suma de comprovació i vaig fer que l’arduino enviés l’ordre: sorprenentment, la pantalla s’ha actualitzat !!! Guanya!

La prova real final va ser afegir el meu arduino al BUS amb els altres 2 controladors per a una prova real real i, amb tota seguretat, va funcionar.

Ara, doncs, podia llegir i escriure al bus, però simplement no tenia la capacitat de fer-ho simplement.

Com que faig servir MQTT gairebé exclusivament per a tota la meva domòtica, era natural que fos el mateix. Vaig escriure el codi durant diversos dies per controlar els 4 elements principals de la CA, llegint també l'estat existent (des dels altres mòduls del BUS)

La intenció era que el codi s’executés en un mòdul ESP8266, però semblaria que l’ESP8266 no és capaç de produir una velocitat en bauds tan baixa com 104bps. Vaig haver de tornar a un Arduino Uno genèric amb Ethernet Wiznet, però això no va ser difícil, ja que el meu rack de comunicacions estava literalment a l'altre costat de la paret d'un dels controladors de CA.

El codi és una mica arreu, però ha de ser llegible. Vaig tenir molts problemes amb la prevenció de que el controlador no pogués llegir la seva pròpia sortida, però també repetir el codi dels temes publicats rebuts de MQTT a l'aire condicionat. Bàsicament, es crea un bucle infinit. Al final, alguns esborraments de memòria intermèdia i retards en el processament del codi després de publicar-los a MQTT van aconseguir que es resolguessin.

Els pins Rx, Tx a la CA estan codificats com a 3, 4, però canvieu si voleu

El codi està configurat per publicar i acceptar ordres com a tals:

ha / mod / 5557 / P 0/1 - Powerha / mod / 5557 / M 0/1/2/3/4 - Mode Cool, Deshumidify, Fan, Auto, Heatha / mod / 5557 / F 0/1/2 - Ventilador baix, med, highha / mod / 5557 / Z és a dir, 1111 per a totes les zones de 1000 per només la zona 1 de.

** Des del controlador, les zones no es poden configurar a "0000", però sembla que si emeteu el valor, es tornarà a "1000".

L’última versió del codi està disponible al meu repositori de GitHub:

Pas 6: alguna cosa més permanent

Vaig agafar un prototip de placa arduino i vaig instal·lar totes les peces a mesura que els feia pa.

Pas 7: configuració OpenHAB

Vegeu el fitxer adjunt per obtenir articles, mapa del lloc i regles d’OpenHAB

Combineu-ho amb l'enquadernació IFHTT OpenHab i l'Assistent de Google / Home i teniu un control de veu molt potent i / o un aire condicionat "intel·ligent" que supera gairebé tots els productes disponibles al mercat.

Pas 8: resum

En conclusió: si sou una de les ànimes pobres amb un aparell d’aire condicionat dividit per conductes LG una mica més antic, no esteu sols. Encara hi ha esperança per a nosaltres!

Espero que aquest instructiu trobi algú que ho necessiti tant com jo. Bàsicament, no hi ha cap informació que pugui trobar (que no sigui la suma de verificació de "Nick"). Vaig haver de començar de zero, però estic extasiat pel resultat.

La informació és una mica vaga, ho sé, però si us trobeu en la mateixa situació que jo, estaré més que disposat a ajudar-vos.

- Precaució / Actualització --- Tot i que és possible canviar els paràmetres de la CA amb la unitat apagada, he comprovat que quan es tracta del control de la zona sembla que hi ha problemes. Vaig fer moltes proves amb la unitat apagada i vaig trobar que les zones es mostrarien com a inactives, però quan la unitat funciona, sembla que els amortidors no estan completament tancats (però tampoc no estan completament oberts). Vaig restablir la unitat a l'interruptor principal i això va resoldre el problema. Com que només es canvia de zona quan la unitat està encesa, no ha estat un problema

També he actualitzat el codi per publicar només (a MQTT) els canvis que provenen del controlador principal i no de la unitat principal. Una vegada més, això podria causar problemes perquè la unitat principal enviarà "0000" per a les zones (que també podria haver estat el problema)

El codi actualitzat també introdueix algunes restriccions de temps per intentar evitar que l’arduino transmeti al mateix temps de la unitat principal i principal. Estic segur que probablement hi ha un mètode que utilitza el controlador per iniciar un enviament de dades, com ara baixar la línia de Xms abans d’enviar-lo, però encara no l’he descobert

Vaig descobrir que la unitat principal enviarà dades cada 60 segons i que el controlador principal enviarà cada 20 segons. El codi intenta aturar l'enviament de dades en un termini de 2 segons després de rebre el paquet de dades. No obstant això, de vegades la unitat principal i principal transmeten molt a prop els uns dels altres. Probablement es refinarà més aviat. ------------------------------

** Pot funcionar en unitats més noves

*** Alguna informació trobada en els meus viatges d'investigació va indicar que la divisió per conductes de Panasonic podria utilitzar el mateix protocol. YMMV.