Sommario:

Hacking di uno split canalizzato LG per l'automazione domestica: 8 passaggi (con immagini)
Hacking di uno split canalizzato LG per l'automazione domestica: 8 passaggi (con immagini)

Video: Hacking di uno split canalizzato LG per l'automazione domestica: 8 passaggi (con immagini)

Video: Hacking di uno split canalizzato LG per l'automazione domestica: 8 passaggi (con immagini)
Video: LG Electronics - Soluzioni di controllo LG per la climatizzazione e integrazione BMS 2024, Novembre
Anonim
Hacking di uno split canalizzato LG per l'automazione domestica
Hacking di uno split canalizzato LG per l'automazione domestica

Prima di tutto - Questo non è un altro hack di emulazione del telecomando a infrarossi. Il mio particolare AC non ha un'interfaccia utilizzabile progettata per alcun tipo di controllo diverso dai controlli intelligenti montati a parete inclusi.

Ho un sistema di split inverso LG Ducted a casa mia. Sfortunatamente è stato realizzato in un momento in cui l'IoT non era in cima a nessun elenco di produttori. Ho scoperto che aveva alcune opzioni per il controllo "master" ma anche se l'unità aveva solo 2 anni al momento del mio primo tentativo, le schede di espansione erano in unobtanium e i prezzi erano comunque astronomici. Così come l'add-on "Wireless RF Remote" che avrebbe reso le cose molto più semplici ma impossibili da acquistare.

Se fosse stata una mia scelta, non sarebbe un LG, ma dal momento che è stato installato in casa quando l'ho acquistato (e il suo costo di sostituzione sarebbe probabilmente superiore a $ 10k) è quello che ho dovuto affrontare.

Obiettivo - Essere in grado di controllare l'AC tramite MQTT ai fini dell'automazione tramite OpenHAB e IFTTT/Google Assistant

Passaggio 1: decodifica del formato dei dati

Decodifica del formato dei dati
Decodifica del formato dei dati
Decodifica del formato dei dati
Decodifica del formato dei dati

Ho iniziato questo processo 4 anni fa, ma non sono andato molto lontano e non volevo rischiare di danneggiare l'unità, soprattutto perché le parti sembrano quasi impossibili da trovare.

Strappando il controller dal muro ho trovato 3 fili che ho determinato essere terra, 12v e "segnale"

La tensione di segnalazione sulla linea dati era a 12v, ma ho notato che sembrava fluttuare sul multimetro (una sorta di impulsi sulla linea).

Ho imbarcato un circuito di base per pilotare un isolatore ottico tramite il pin dati e ho collegato l'altro lato dell'isolatore ottico come ingresso sulla scheda audio del mio PC e ho ottenuto una versione scadente di un'uscita oscilloscopio (foto 1).

Questo è quanto sono arrivato in quel momento: potevo vedere che c'era qualcosa lì ma non sapevo davvero come 'decodificarlo'.

Da quando ho abilitato l'IoT della mia macchina da caffè, questa volta ho avuto un rinnovato interesse a riprovare con un po' più di determinazione.

Ho pubblicato le mie scoperte sui forum di EEVBlog per vedere se qualcuno potesse essere in grado di far luce e un bravo ragazzo di nome Ian è venuto in mio soccorso - L'ha esposto in un modo completamente logico (foto 2)

Fondamentalmente, il flusso di dati è di 13 byte di "seriale standard" - 8 bit di dati, un bit di avvio e un bit di stop (nessuna parità) ma a una velocità di trasmissione MOLTO bassa di 104 bps.

Passaggio 2: guardare più in profondità

Guardando più in profondità
Guardando più in profondità

Quindi, ora che avevo un'idea di come erano formattati i dati, avevo bisogno di un modo per poter leggere i dati in modo più dinamico.

Ho staccato uno dei miei controller dal muro e l'ho collegato tramite un traslatore di livello logico a un Arduino con un semplice schizzo per leggere 13 byte di dati tramite la porta seriale del software configurata a 104 bps e stamparlo:

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, **In realtà qui 12 byte

Abbiamo avuto azione!

Modificando quindi le varie impostazioni sul controller, sono stato in grado di elaborare i byte che cambiano:

168, 3, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, ventola LOW168, 35, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, Ventola MED 168, 67, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 152, Ventola ALTA

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

I numeri hanno molto più senso quando li guardi in binario, ma cos'è il 13° byte? È dappertutto…

Passaggio 3: mapparlo

Mapparlo
Mapparlo

Attraverso tentativi ed errori, sono stato in grado di determinare i bit rilevanti nei 13 byte di dati che avrei dovuto essere in grado di trasmettere.

Passaggio 4: muro di mattoni avanti

muro di mattoni avanti!
muro di mattoni avanti!
muro di mattoni avanti!
muro di mattoni avanti!
muro di mattoni avanti!
muro di mattoni avanti!

È qui che si è complicato. Avevo due ostacoli da superare

a) Il 13° byte sembrava essere un checksum dei dati di cui avevo bisogno per elaborare in qualche modo.b) Come faccio a trasmettere i dati allora? È solo un filo.

Il problema "a" si è rivelato DAVVERO facile, ma è stato per pura coincidenza che sono riuscito a superarlo.

Nei miei test, stavo guardando dati come: A802000000040F61000000004B A81200004004169A00000000FB A81200004004159A00000000F8 A81200004004149A00000000E5 A81200084000149C00000000E7 A83200084000149C0000000087 A85200084000149C00000000A7

Questi sono i 13 byte di dati incluso il checksum (qui in HEX invece di DEC).

Quando stavo cercando l'oracolo che è google su "come decodificare un checksum" mi sono imbattuto in questa pagina sullo scambio di stack con qualcun altro che si chiamava Nick chiedendo più o meno la stessa cosa di me, ma non solo, hanno parlato su un condizionatore d'aria e i loro dati erano in formato quasi identico al mio - Potrebbe essere??? In tutte le mie ricerche (in circa 4 anni), nessuna persona aveva pubblicato alcuna informazione su come hackerare il protocollo su questi condizionatori d'aria e mi è capitato di imbattermi in qualcuno che fa la stessa cosa cercando qualcosa di quasi completamente estraneo? È stata una benedizione: ha persino pubblicato che ha risolto il problema e la soluzione è stata: sommare tutti i byte di dati e quindi XOR con "U".

Con quello in mano l'ho aggiunto al mio codice per calcolare quello che pensavo dovesse essere il checksum rispetto a quello che era in realtà, ma era tutto SBAGLIATO!!

A quanto pare, era un po' sbagliato. Quando ho iniziato a guardare i numeri in binario, aveva perfettamente senso.

La risposta dallo 'XOR con U' ha sempre restituito 9 bit di dati (il 9° bit sempre uno) ma gli altri bit erano corretti. Ho semplicemente rimosso il nono bit prendendo 256 dal numero risultante e poi ha trovato la corrispondenza!!

Se non fosse stato per questo individuo, potrei ancora grattarmi la testa. Tanto di cappello anche a lui, ma non riesco a contattarlo - Questo era fondamentalmente il suo unico post sul forum stackexchange. Bene, grazie straniero:)

La sfida successiva è stata realizzare un circuito che mi permettesse di simulare il controller esistente. Ho tracciato lo schema per il circuito di azionamento (Pic1 e Pic 2) ma mi sembrava troppo complicato doverlo riprodurre per ottenere ciò che volevo. Dopotutto stavo già leggendo il segnale. Ho optato per un metodo molto più semplice: utilizzare l'arduino per pilotare un isolatore ottico per abbassare la linea del segnale 12v come richiesto.

Ho anche progettato un circuito più semplice per l'Rx ma questo non è stato testato, ho finito per attenermi al convertitore di livello per semplicità.

Passaggio 5: farlo funzionare

Una volta che ho fatto il breadboard del circuito di trasmissione, e con il cuore in gola, ho storpiato una stringa (statica) di 12 byte, ho calcolato il checksum e ho fatto inviare il comando all'arduino - Sorprendentemente, il display si è aggiornato!!! Vincita!

Il test finale effettivo è stato quello di aggiungere il mio arduino al BUS con gli altri 2 controller per un vero test dal vivo e, in effetti, ha funzionato.

Quindi ora potevo leggere e scrivere sull'autobus, ma mi mancava solo la capacità di farlo semplicemente.

Dato che uso MQTT quasi esclusivamente per tutta la mia automazione domestica, era naturale che fosse lo stesso. Ho scritto il codice per più giorni per controllare i 4 elementi principali dell'AC, rileggendo anche lo stato esistente (dagli altri moduli sul BUS)

L'intenzione era di far funzionare il codice su un modulo ESP8266, tuttavia sembrerebbe che ESP8266 non sia in grado di produrre una velocità di trasmissione a partire da 104 bps. Ho dovuto ripristinare un Arduino Uno generico con Wiznet ethernet, ma non è stato difficile poiché il mio rack di comunicazione era letteralmente dall'altra parte del muro rispetto a uno dei controller AC.

Il codice è un po' dappertutto ma dovrebbe essere leggibile. Ho avuto molti problemi con l'impedire al controller di leggere il proprio output ma anche di ripetere il codice sui propri argomenti pubblicati ricevuti da MQTT all'aria condizionata. Fondamentalmente, creerebbe un ciclo infinito. Alla fine, alcuni buffer clearing e ritardi nell'elaborazione del codice dopo la pubblicazione su MQTT hanno risolto il problema.

I pin Rx, Tx all'AC sono codificati come 3, 4 ma cambiano se lo si desidera

Il codice è configurato per pubblicare e accettare comandi come tali:

ha/mod/5557/P 0/1 - Powerha/mod/5557/M 0/1/2/3/4 - Modalità Raffreddamento, Deumidificazione, Ventola, Auto, Heatha/mod/5557/F 0/1/2 - Ventilatore basso, medio, altoha/mod/5557/Z cioè 1111 per tutte le zone su 1000 solo per zona 1 su.

**Dal controller, le zone non possono essere impostate su '0000', tuttavia sembrerebbe che se si immette il valore, tornerà a '1000'.

L'ultima versione del codice è disponibile dal mio repository GitHub:

Passaggio 6: qualcosa di più permanente

Qualcosa di più permanente
Qualcosa di più permanente
Qualcosa di più permanente
Qualcosa di più permanente

Ho raccolto una scheda prototipo arduino e ho installato tutte le parti mentre le facevo breadboard.

Passaggio 7: configurazione OpenHAB

Vedere il file allegato per gli articoli OpenHAB, la mappa del sito e le regole

Combina questo con la rilegatura IFTTT OpenHab e Google Assistant/Home e avrai un'aria condizionata molto potente a controllo vocale e/o "intelligente" che supera quasi tutti i prodotti disponibili in commercio!

Passaggio 8: riepilogo

In conclusione - Se sei una delle povere anime con un condizionatore split canalizzato LG leggermente più vecchio, non sei solo. C'è ancora speranza per noi!

Spero che questo istruibile trovi qualcuno che ne abbia bisogno quanto me. Fondamentalmente NON ci sono informazioni che potrei trovare (a parte il checksum di "Nick"). Ho dovuto ricominciare da zero ma sono entusiasta del risultato.

L'informazione è un po' vaga, lo so, ma se ti trovi nella mia stessa situazione, sarò più che disposto ad aiutarti.

- Attenzione/Aggiornamento --- Sebbene sia possibile modificare le impostazioni sull'AC con l'unità spenta, ho scoperto che quando si tratta del controllo di zona sembra che si rompa. Ho fatto molti test con l'unità spenta e ho scoperto che le zone si sarebbero mostrate inattive ma quando l'unità è in funzione, sembra che le serrande non siano completamente chiuse (ma nemmeno completamente aperte). Ho ripristinato l'unità sull'interruttore principale e questo ha risolto il problema. Poiché si cambia solo zona quando l'unità è accesa, questo non è stato un problema

Ho anche aggiornato il codice per pubblicare solo (su MQTT) le modifiche che provengono dal controller master e non dall'unità principale. Ancora una volta, questo potrebbe causare problemi perché l'unità principale invierà '0000' per le zone (che potrebbe anche essere stato il problema)

Il codice aggiornato introduce anche alcuni vincoli di temporizzazione per cercare di impedire che arduino trasmetta contemporaneamente all'unità master e principale. Sono sicuro che probabilmente esiste un metodo che il controller utilizza per avviare un invio di dati come abbassare la linea per Xms prima dell'invio, ma non l'ho ancora scoperto se esiste

Ho scoperto che l'unità principale invierà dati ogni 60 secondi e il controller master invia ogni 20 secondi. Il codice tenta di bloccare l'invio dei dati entro 2 secondi dalla ricezione del pacchetto di dati. Tuttavia, a volte l'unità principale e quella principale trasmettono molto vicine l'una all'altra. Questo sarà probabilmente perfezionato più presto.--------------

**Può funzionare su unità più recenti

*** Alcune informazioni trovate nei miei viaggi di ricerca hanno indicato che lo split canalizzato di Panasonic potrebbe utilizzare lo stesso protocollo. YMMV.

Consigliato: