Datorurķēšana LG vadītajā sadalījumā mājas automatizācijai: 8 soļi (ar attēliem)

2024 Autors: John Day | [email protected]. Pēdējoreiz modificēts: 2024-01-30 10:56

Pirmkārt - tas nav vēl viens infrasarkanās tālvadības pults emulācijas uzlaušana. Manā konkrētajā maiņstrāvā nav lietojama saskarne, kas paredzēta jebkāda veida vadībai, izņemot komplektā iekļautās viedās vadības ierīces pie sienas.

Manā mājā ir LG Ducted reversās sadalīšanas sistēma. Diemžēl tas tika izgatavots laikā, kad IoT nevienā ražotāja sarakstā nebija augsts. Es atklāju, ka tai ir dažas galvenās vadības iespējas, bet, lai gan ierīcei bija tikai 2 gadi, kad es pirmo reizi mēģināju to izdarīt, paplašināšanas plates bija unbtanium un cenas tik un tā bija astronomiskas. Tāpat kā papildinājums “Bezvadu RF tālvadība”, kas būtu padarījis lietas daudz vieglākas, bet neiespējamas.

Ja tā būtu mana izvēle, tas nebūtu LG, bet, tā kā tas tika uzstādīts mājā, kad es to iegādājos (un tā nomaiņas izmaksas, visticamāk, pārsniegs 10 000 USD), man tas bija jārisina.

Mērķis - Spēt kontrolēt maiņstrāvu, izmantojot MQTT automatizācijas nolūkos, izmantojot OpenHAB un IFTTT/Google palīgu

1. darbība. Datu formāta atšifrēšana

Es sāku šo procesu pirms 4 gadiem, bet netiku ļoti tālu un negribēju riskēt sabojāt ierīci - jo īpaši tāpēc, ka tās daļas šķiet gandrīz neiespējami atrast.

Noraujot kontrolieri no sienas, es atradu 3 vadus, kurus es noteicu par zemējumu, 12 V un “signālu”

Signalizācijas spriegums datu līnijā bija 12 V, bet es pamanīju, ka tas, šķiet, svārstās multimetrā (daži impulsi uz līnijas).

Es maize iekāpusi pamata shēmā, lai vadītu opto izolatoru, izmantojot datu tapu, un pievienoju opto izolatora otru pusi kā ieeju datora skaņas kartē, un es saņēmu sliktu skalas izvades versiju (1. attēls).

Tas ir apmēram tik tālu, cik es tobrīd nonācu - es redzēju, ka tur kaut kas ir, bet īsti nezināju, kā to “atšifrēt”.

Kopš kafijas automāta IoT iespējošanas man bija atsvaidzināta interese šoreiz mēģināt vēlreiz ar nelielu apņēmību.

Es ievietoju savus secinājumus EEVBlog forumos, lai noskaidrotu, vai kāds varētu kaut ko apgaismot, un man palīdzēja lielisks puisis vārdā Īans - Viņš to izklāstīja tā, lai tam būtu pilnīga jēga (2. attēls)

Būtībā datu plūsma ir 13 baiti “standarta sērijas” - 8 datu biti, viens sākuma bits un viens pieturas bits (bez paritātes), bet ar ĻOTI zemu pārraides ātrumu - 104 bps.

2. solis: skatieties dziļāk

Tāpēc tagad, kad man bija priekšstats par to, kā dati tika formatēti, man vajadzēja veidu, kā varētu dinamiskāk nolasīt datus.

Es izvilku vienu no saviem kontrolieriem no sienas un, izmantojot loģikas līmeņa pārslēdzēju, pievienoju to Arduino ar vienkāršu skici, lai nolasītu 13 baitus datu, izmantojot programmatūras seriālo portu, kas konfigurēts ar 104 bps, un izdrukātu to:

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, ** Patiesībā šeit ir 12 baiti

Mums bija darbība!

Pēc tam mainot dažādus kontroliera iestatījumus, es varēju noskaidrot mainītos baitus:

168, 3, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, ventilators LOW168, 35, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, ventilators MED 168, 67, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 152, ventilators 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, režīms FAN 168, 79, 0, 0, 0, 136, 10, 35, 0, 0, 0, 0, 249, režīms AUTO 168, 67, 0, 0, 0, 136, 3, 35, 0, 0, 0, 0, 204, režīms COOL 168, 83, 0, 0, 0, 136, 15, 34, 0, 0, 0, 0, 225, HEAT režīms 168, 7, 0, 0, 0, 136, 15, 34, 0, 0, 0, 0, 61, DH režīms

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, temperatūra 30

Skaitļiem ir daudz lielāka jēga, ja tos aplūkojat binārā formātā, bet kas ir ar 13. baitu ?? Tas ir visur …

3. darbība: kartējiet to

Izmantojot izmēģinājumus un kļūdas, man izdevās noteikt attiecīgos bitus 13 datu baitos, kas man būtu jāspēj pārsūtīt.

4. solis: ķieģeļu siena priekšā

Lūk, kur tas kļuva sarežģīti. Man bija jāpārvar divi šķēršļi

a) Šķita, ka 13. baits ir datu kontrolsumma, kas man bija kaut kā jāizstrādā. b) Kā tad pārsūtīt datus? Tas ir tikai viens vads.

Jautājums “a” izrādījās TIEŠĀM viegls, taču tīras nejaušības dēļ man izdevās tikt tam pāri.

Savos testos es aplūkoju šādus datus:

Tie ir 13 baiti datu, ieskaitot kontrolsummu (šeit HEX, nevis DEC).

Kad es meklēju orākulā, kas ir Google par to, kā mainīt inženiertehnisko kontrolsummu, es atklāju šo lapu steku apmaiņā ar kādu citu, vārdā Niks, jautājot gandrīz to pašu, ko es, bet ne tikai to, ka viņi runāja par gaisa kondicionieri un viņu dati bija gandrīz identiski manam formātam - Vai tas varētu būt ??? Visā manā meklēšanā (apmēram četru gadu laikā) neviena persona nebija ievietojusi nekādu informāciju par to, kā uzlauzt šo gaisa kondicionētāju protokolu, un es vienkārši nejauši uzdūros kādam, kurš dara to pašu, meklējot kaut ko gandrīz pilnīgi nesaistītu? Tā bija svētība - viņš pat publicēja, ka ir to izstrādājis, un risinājums bija šāds: saskaitiet visus datu baitus un pēc tam XOR ar “U”.

Ar to rokā es to pievienoju savam kodam, lai aprēķinātu, kādai, manuprāt, vajadzētu būt kontrolsummai, salīdzinot ar to, kāda tā patiesībā bija, bet tas viss bija nepareizi !!

Kā izrādās, tas bija kaut kas nepareizs. Kad es sāku aplūkot skaitļus binārā formātā, tam bija pilnīga jēga.

Atbilde no “XOR ar U” vienmēr atdeva 9 datu bitus (9. bits vienmēr bija viens), bet pārējiem bitiem bija taisnība. Es vienkārši noņēmu 9. bitu, no iegūtā skaitļa paņemot 256 un tad tas sakrita !!

Ja nebūtu šī indivīda, es, iespējams, joprojām skrāpētu galvu. Cepuri nost arī viņam, bet es nevaru ar viņu sazināties - būtībā tā bija viņa vienīgā ziņa stackexchange forumā. Nu paldies svešiniekam:)

Nākamais izaicinājums bija izveidot ķēdi, kas ļautu man simulēt esošo kontrolieri. Es izveidoju piedziņas ķēdes shēmu (Pic1 un Pic 2), bet man šķita pārāk sarežģīti, ka man vajadzēja to reproducēt, lai iegūtu to, ko vēlējos. Galu galā es jau lasīju signālu. Es izvēlējos daudz vienkāršāku metodi - izmantojot arduino, lai vadītu opto izolatoru, lai pēc vajadzības novilktu 12 V signāla līniju zemu.

Es arī izstrādāju vienkāršāku ķēdi Rx, taču tas nav pārbaudīts, un vienkāršības labad es pielipu ar līmeņa pārveidotāju.

5. solis: lai tas darbotos

Kad man bija pārsūtīšanas ķēde ar maizi, un ar sacīkšu sirdi es sakopoju (statisku) 12 baitu virkni, aprēķināju kontrolsummu un liku arduino nosūtīt komandu - Pārsteidzoši, displejs ir atjaunināts !!! Uzvarēt!

Pēdējais reālais tests bija pievienot manu arduino BUS kopā ar 2 citiem kontrolieriem, lai veiktu reālu tiešraides pārbaudi, un tas tiešām darbojās.

Tāpēc tagad es varēju lasīt un rakstīt autobusā, bet man vienkārši trūka iespēju to izdarīt vienkārši.

Tā kā es izmantoju MQTT gandrīz tikai savai mājas automatizācijai, bija likumsakarīgi, ka tas būs tas pats. Es vairākas dienas izrakstīju kodu, lai kontrolētu četrus galvenos maiņstrāvas elementus, kā arī nolasītu esošo statusu (no citiem BUS moduļiem)

Mērķis bija, lai kods darbotos ESP8266 modulī, tomēr šķiet, ka ESP8266 nespēj radīt tik zemu pārraides ātrumu kā 104 bps. Man bija jāatgriežas pie vispārēja Arduino Uno ar Wiznet Ethernet, taču tas nebija grūti, jo mans komiksu plaukts burtiski atradās sienas otrā pusē no viena maiņstrāvas kontroliera.

Kods ir mazliet visur, bet tam jābūt salasāmam. Man bija daudz problēmu, neļaujot kontrolierim nolasīt savu produkciju, bet arī atkārtot tā paša publicēto tēmu, kas tika saņemta no MQTT atpakaļ gaisa kondicionētājam. Būtībā tas radītu bezgalīgu cilpu. Galu galā daži bufera dzēšanas gadījumi un aizkavēšanās koda apstrādē pēc publicēšanas MQTT to sakārtoja.

Rx, Tx tapas maiņstrāvai tiek kodētas kā 3, 4, bet mainiet, ja vēlaties

Kods ir konfigurēts, lai publicētu un pieņemtu komandas kā tādas:

ha/mod/5557/P 0/1 - Powerha/mod/5557/M 0/1/2/3/4 - režīms Cool, Dehumidify, Fan, Auto, Heatha/mod/5557/F 0/1/2 - Ventilators zems, vidējs, augsts/mod/5557/Z, ti, 1111 visām zonām uz 1000 tikai 1. zonā.

** No kontroliera zonas nevar iestatīt uz “0000”, tomēr šķiet, ka, izsniedzot vērtību, tā atgriezīsies uz “1000”.

Jaunākā koda versija ir pieejama manā GitHub Repo:

6. solis: kaut kas pastāvīgāks

Es savācu arduino prototipa dēli un uzstādīju visas detaļas tā, kā man bija tās.

7. darbība: OpenHAB Config

OpenHAB vienumus, vietnes karti un noteikumus skatiet pievienotajā failā

Apvienojiet to ar IFTTT OpenHab iesiešanu un Google palīgu/sākumlapu, un jums ir ļoti spēcīgs balss vadīts un/vai “vieds” gaisa kondicionieris, kas pārspēj gandrīz katru komerciāli pieejamo produktu!

8. darbība. Kopsavilkums

Noslēgumā - ja jūs esat viena no nabadzīgajām dvēselēm ar nedaudz vecāku LG gaisa vadu sadalītu gaisa kondicionētāju, jūs neesat viens. Mums vēl ir cerība!

Es ceru, ka šī pamācība atradīs kādu, kam tas ir tikpat vajadzīgs kā man. Būtībā NAV informācijas, ko es varētu atrast (izņemot kontrolsummu no 'Nika'). Man bija jāsāk no nulles, bet esmu sajūsmā par rezultātu.

Es zinu, ka informācija ir nedaudz neskaidra, bet, ja jūs esat tādā pašā situācijā kā es, es būšu vairāk nekā gatavs palīdzēt.

- Uzmanību / Atjaunināt --- Lai gan ir iespējams mainīt maiņstrāvas iestatījumus, kad iekārta ir izslēgta, es atklāju, ka, runājot par zonas vadību, šķiet, ka tas ar to sajaucas. Es daudz pārbaudīju, kad iekārta bija izslēgta, un es atklāju, ka zonas tiks rādītas kā neaktīvas, bet, kad ierīce darbojas, šķiet, ka amortizatori nav pilnībā aizvērti (bet arī nav pilnībā atvērti). Es atiestatīju ierīci pie galvenā slēdža, un tas atrisināja problēmu. Tā kā zonas tiek mainītas tikai tad, kad iekārta ir ieslēgta, tā nav bijusi problēma

Esmu arī atjauninājis kodu, lai publicētu (MQTT) tikai izmaiņas, kas nāk no galvenā kontrollera, nevis no galvenās vienības. Tas atkal var radīt problēmas, jo galvenā iekārta nosūtīs '0000' zonām (kas arī varēja būt problēma)

Atjauninātais kods arī ievieš dažus laika ierobežojumus, lai mēģinātu novērst arduino pārraidi vienlaikus ar galveno un galveno ierīci. Es esmu pārliecināts, ka, iespējams, ir kāda metode, ko kontrolieris izmanto, lai sāktu datu nosūtīšanu, piemēram, pirms nosūtīšanas novilkt līniju zemu Xms, bet es to vēl neesmu atklājis, ja tāds ir

Es atklāju, ka galvenā ierīce sūtīs datus ik pēc 60 sekundēm, bet galvenais kontrolieris - ik pēc 20 sekundēm. Kods mēģina apturēt datu nosūtīšanu 2 sekunžu laikā pēc datu paketes saņemšanas. Tomēr dažreiz galvenais un galvenais bloks pārraida ļoti tuvu viens otram. Iespējams, tas drīz tiks precizēts.----------------------------

** Var strādāt ar jaunākām vienībām

*** Daļa manā izpētes ceļojumā atrastās informācijas norādīja, ka Panasonic kanālu sadalījums var izmantot to pašu protokolu. YMMV.