Meretas LG Ducted Split untuk Otomatisasi Rumah: 8 Langkah (dengan Gambar)

2024 Pengarang: John Day | [email protected]. Terakhir diubah: 2024-01-30 09:56

Pertama-tama - Ini bukan peretasan emulasi kendali jarak jauh Inframerah lainnya. AC khusus saya tidak memiliki antarmuka yang dapat digunakan yang dirancang untuk kontrol apa pun selain kontrol pintar yang dipasang di dinding.

Saya memiliki sistem split terbalik LG Ducted di rumah saya. Sayangnya itu dibuat pada saat IoT tidak tinggi di daftar produsen mana pun. Saya menemukan itu memiliki beberapa pilihan untuk 'master' kontrol tetapi meskipun unit hanya berusia 2 tahun pada saat saya pertama kali mencoba ini, papan ekspansi unobtanium dan harga tetap astronomi. Seperti addon 'Remote RF Nirkabel' yang akan membuat segalanya lebih mudah tetapi tidak mungkin untuk dibeli.

Jika itu pilihan saya, itu tidak akan menjadi LG tetapi karena dipasang di rumah ketika saya membelinya (dan biaya penggantiannya kemungkinan akan lebih dari $ 10k) itulah yang harus saya tangani.

Tujuan - Untuk dapat mengontrol AC melalui MQTT untuk keperluan otomatisasi melalui OpenHAB dan IFTTT/Google Assistant

Langkah 1: Mendekode Format Data

Saya memulai proses ini 4 tahun yang lalu tetapi tidak terlalu jauh dan tidak ingin mengambil risiko merusak unit - Terutama karena suku cadang untuk itu tampaknya hampir tidak mungkin ditemukan.

Merobek pengontrol dari dinding saya menemukan 3 kabel yang saya tentukan sebagai Ground, 12v dan 'sinyal'

Tegangan pensinyalan pada jalur data berada pada 12v, tetapi saya memperhatikan bahwa voltase itu tampaknya berfluktuasi pada multimeter (semacam pulsa di saluran).

Saya membuat sirkuit dasar untuk menggerakkan isolator opto melalui pin data dan menghubungkan sisi lain isolator opto sebagai input pada kartu suara PC saya dan mendapatkan versi keluaran lingkup yang buruk (Gambar 1).

Ini sejauh yang saya dapatkan saat itu - saya bisa melihat ada sesuatu di sana tetapi tidak benar-benar tahu bagaimana cara 'mendekodekannya'.

Sejak IoT Mesin Kopi saya diaktifkan, saya memiliki minat baru untuk mencoba ini lagi dengan sedikit tekad lagi kali ini.

Saya memposting temuan saya di forum EEVBlog untuk melihat apakah seseorang mungkin dapat menjelaskan dan seorang pria hebat bernama Ian datang untuk menyelamatkan saya - Dia menjelaskannya dengan cara yang benar-benar masuk akal (Gambar 2)

Pada dasarnya, aliran data adalah 13 byte 'seri standar' - 8 bit data, satu bit mulai dan satu bit berhenti (tidak ada paritas) tetapi pada baud rate yang SANGAT rendah 104bps.

Langkah 2: Melihat Lebih Dalam

Jadi sekarang saya memiliki ide tentang bagaimana data diformat, saya membutuhkan cara untuk dapat membaca data dengan cara yang lebih dinamis.

Saya menarik salah satu pengontrol saya dari dinding dan menghubungkannya melalui pemindah level logika ke Arduino dengan sketsa sederhana untuk membaca 13 byte data melalui port serial perangkat lunak yang dikonfigurasi pada 104bps dan mencetaknya:

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, **Sebenarnya 12 byte di sini

Kami memiliki tindakan!

Dengan mengubah berbagai pengaturan pada pengontrol, saya dapat menghitung byte yang berubah:

168, 3, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, Kipas LOW168, 35, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, Kipas MED 168, 67, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 152, Kipas TINGGI

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 PANAS 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, Suhu 30

Angka-angkanya jauh lebih masuk akal ketika Anda melihatnya dalam biner tetapi ada apa dengan byte ke-13?? Itu ada di mana-mana…

Langkah 3: Memetakannya

Melalui trial and error, saya dapat menentukan bit yang relevan dalam 13 byte data yang saya perlukan untuk dapat mengirimkan.

Langkah 4: Tembok Bata di Depan

Di sinilah hal itu menjadi rumit. Saya memiliki dua rintangan untuk diatasi

a) Byte ke-13 tampaknya merupakan checksum dari data yang saya perlukan untuk berhasil.b) Bagaimana cara mengirimkan data? Ini hanya satu kawat.

Masalah 'a' ternyata BENAR-BENAR mudah, tetapi murni kebetulan bahwa saya berhasil melewatinya.

Dalam pengujian saya, saya melihat data seperti: A802000000040F61000000004B A81200004004169A00000000FB A81200004004159A00000000F8 A81200004004149A00000000E5 A81200084000149C00000000E7 A832000084000149C0000000087 A85200084000149C00000000A7

Ini adalah 13byte data termasuk checksum (di sini di HEX, bukan DEC).

Ketika saya sedang mencari oracle yaitu google tentang 'cara merekayasa balik checksum' saya menemukan halaman ini di pertukaran tumpukan dengan orang lain bernama Nick menanyakan hal yang hampir sama dengan saya tetapi tidak hanya itu, mereka berbicara tentang AC dan format datanya hampir sama dengan milik saya - Mungkinkah??? Dalam semua pencarian saya (dalam 4 tahun atau lebih), tidak ada satu orang pun yang memposting informasi tentang cara meretas protokol pada AC ini dan saya kebetulan menemukan seseorang melakukan hal yang sama dengan mencari sesuatu yang hampir sama sekali tidak terkait? Itu adalah berkah - Dia bahkan memposting bahwa dia berhasil dan solusinya adalah: Tambahkan semua Bytes data dan kemudian XOR dengan "U".

Dengan itu di tangan saya menambahkannya ke kode saya untuk menghitung apa yang saya pikir seharusnya checksum vs apa yang sebenarnya tetapi itu semua SALAH!!

Ternyata, itu agak salah. Ketika saya mulai melihat angka-angka dalam biner, itu masuk akal.

Respon dari 'XOR with U' selalu mengembalikan 9 bit data (bit ke-9 selalu satu) tetapi bit lainnya benar. Saya cukup menghapus bit ke-9 dengan mengambil 256 dari angka yang dihasilkan dan kemudian cocok!!

Jika bukan karena individu ini, saya mungkin masih menggaruk-garuk kepala. Angkat topi untuknya juga, tetapi saya tidak dapat menghubunginya - Itu pada dasarnya adalah satu-satunya posnya di forum stackexchange. Yah, terima kasih orang asing:)

Tantangan berikutnya adalah membuat sirkuit yang memungkinkan saya untuk mensimulasikan pengontrol yang ada. Saya memetakan skema untuk rangkaian drive (Pic1 dan Pic 2) tetapi tampaknya terlalu rumit bagi saya untuk mereproduksinya untuk mendapatkan apa yang saya inginkan. Lagipula aku sudah membaca sinyalnya. Saya memilih metode yang lebih sederhana - Menggunakan arduino untuk menggerakkan isolator opto untuk menarik garis sinyal 12v rendah sesuai kebutuhan.

Saya juga merancang sirkuit yang lebih sederhana untuk Rx tetapi ini belum teruji, saya akhirnya tetap menggunakan konverter level untuk kesederhanaan.

Langkah 5: Membuatnya Bekerja

Setelah saya membuat sirkuit transmisi papan tempat memotong roti, dan dengan jantung berdebar, saya membuat string (statis) 12 byte, menghitung checksum dan meminta arduino mengirim perintah - Hebatnya, tampilan diperbarui!!! Menang!

Tes aktual terakhir adalah menambahkan Arduino saya ke BUS dengan 2 pengontrol lain untuk tes langsung yang nyata dan tentu saja, itu berhasil.

Jadi sekarang saya dapat Membaca dan Menulis di dalam bus tetapi tidak memiliki kemampuan untuk dapat melakukannya dengan sederhana.

Karena saya menggunakan MQTT hampir secara eksklusif untuk semua otomatisasi rumah saya, wajar jika ini akan sama. Saya menulis kode selama beberapa hari untuk mengontrol 4 elemen utama AC, juga membaca kembali status yang ada (dari modul lain di BUS)

Tujuannya adalah untuk menjalankan kode pada modul ESP8266 namun tampaknya ESP8266 tidak dapat menghasilkan baud rate serendah 104bps. Saya harus kembali ke Arduino Uno generik dengan Wiznet ethernet tapi itu tidak sulit karena rak komunikasi saya benar-benar berada di sisi lain dinding dari salah satu pengontrol AC.

Kodenya ada di mana-mana tetapi harus dapat dibaca. Saya memiliki banyak masalah dengan mencegah pengontrol membaca outputnya sendiri tetapi juga mengulangi kode topik yang diterbitkannya sendiri yang diterima dari MQTT kembali ke AC. Pada dasarnya, itu akan membuat loop tak terbatas. Pada akhirnya, beberapa pembersihan buffer dan penundaan dalam pemrosesan kode setelah diterbitkan ke MQTT membuatnya diurutkan.

Pin Rx, Tx ke AC berkode 3, 4 tapi ubah sesuka hati

Kode dikonfigurasi untuk menerbitkan dan menerima perintah seperti:

ha/mod/5557/P 0/1 - Powerha/mod/5557/M 0/1/2/3/4 - Mode Keren, Dehumidify, Kipas, Otomatis, Heatha/mod/5557/F 0/1/2 - Kipas rendah, med, highha/mod/5557/Z yaitu 1111 untuk semua zona di 1000 hanya untuk zona 1 aktif.

**Dari pengontrol, zona tidak dapat diatur ke '0000' namun tampaknya jika Anda mengeluarkan nilainya, itu akan kembali ke '1000'.

Versi kode terbaru tersedia dari Repo GitHub saya:

Langkah 6: Sesuatu yang Lebih Permanen

Saya mengumpulkan papan prototipe arduino dan memasang semua bagian saat saya memasangnya dengan roti.

Langkah 7: Konfigurasi OpenHAB

Lihat file terlampir untuk Item OpenHAB, peta situs, dan aturan

Gabungkan ini dengan pengikatan IFTTT OpenHab dan Google Assistant/Home dan Anda memiliki pengontrol suara yang sangat kuat dan/atau AC 'Cerdas' yang melampaui hampir semua produk yang tersedia secara komersial!

Langkah 8: Ringkasan

Kesimpulan - Jika Anda adalah salah satu dari jiwa-jiwa miskin dengan AC split saluran LG sedikit lebih tua, Anda tidak sendirian. Masih ada harapan untuk kita!

Saya harap instruksi ini menemukan seseorang yang membutuhkannya seperti saya. Pada dasarnya TIDAK ada informasi yang dapat saya temukan (selain checksum dari 'Nick'). Saya harus memulai dari awal tetapi saya senang dengan hasilnya.

Informasinya agak kabur, saya tahu, tetapi jika Anda berada dalam situasi yang sama seperti saya, saya akan dengan senang hati membantu.

- Perhatian / Pembaruan --- Meskipun dimungkinkan untuk mengubah pengaturan pada AC dengan unit Mati, saya telah menemukan bahwa ketika datang ke kontrol Zona tampaknya mengacaukannya. Saya melakukan banyak pengujian dengan unit mati dan saya menemukan bahwa zona akan menunjukkan tidak aktif tetapi ketika unit beroperasi, tampaknya peredam tidak sepenuhnya tertutup (tetapi juga tidak sepenuhnya terbuka). Saya mengatur ulang unit di pemutus utama dan ini menyelesaikan masalah. Karena hanya mengubah zona saat unit menyala, ini tidak menjadi masalah

Saya juga telah memperbarui kode untuk hanya mempublikasikan (ke MQTT) perubahan yang berasal dari pengontrol utama dan bukan unit utama. Sekali lagi, ini dapat menyebabkan masalah karena unit utama akan mengirim '0000' untuk zona (yang juga bisa menjadi masalah)

Kode yang diperbarui juga memperkenalkan beberapa batasan waktu untuk mencoba mencegah arduino mentransmisikan master dan unit utama secara bersamaan. Saya yakin mungkin ada metode yang digunakan pengontrol untuk memulai pengiriman data seperti menarik garis rendah untuk Xms sebelum mengirim tetapi saya belum menemukannya jika ada

Saya menemukan bahwa unit utama akan mengirim data setiap 60 detik dan pengontrol utama mengirim setiap 20 detik. Kode mencoba untuk menghentikan pengiriman data dalam waktu 2 detik setelah menerima paket data. Namun, terkadang master dan unit utama mentransmisikan sangat dekat satu sama lain. Ini mungkin akan disempurnakan lebih cepat.----------------------------

**Dapat bekerja pada unit yang lebih baru

*** Beberapa informasi yang ditemukan dalam perjalanan penelitian saya menunjukkan bahwa Panasonic ducted split mungkin menggunakan protokol yang sama. YMMV.