Innholdsfortegnelse:
2025 Forfatter: John Day | [email protected]. Sist endret: 2025-01-13 06:58
Først av alt - Dette er ikke et annet infrarødt fjernkontrollemuleringshack. Min spesielle AC har ikke noe brukbart grensesnitt designet for noen form for kontroll enn de medfølgende veggmonterte smarte kontrollene.
Jeg har et LG Ducted reverse split system i huset mitt. Dessverre ble det laget på et tidspunkt der IoT ikke var høyt på noen produsentliste. Jeg oppdaget at den hadde noen alternativer for "master" -kontroll, men selv om enheten bare var 2 år gammel da jeg først prøvde dette, var ekspansjonskortene unobtanium og prisene var astronomiske uansett. Som var tilleggsprogrammet for "Wireless RF Remote" som ville ha gjort ting mye enklere, men umulig å kjøpe.
Hadde det vært mitt valg, ville det ikke være en LG, men siden det ble installert i huset da jeg kjøpte det (og det er sannsynligvis erstatningskostnad på over $ 10k) er det det jeg måtte forholde meg til.
Mål - Å kunne kontrollere AC via MQTT for automatisering med OpenHAB og IFTTT/Google Assistant
Trinn 1: Dekoding av dataformatet
Jeg startet denne prosessen for 4 år siden, men kom ikke veldig langt og ville ikke risikere å skade enheten - Spesielt siden deler til den virker nesten umulige å finne.
Etter å ha fjernet kontrolleren fra veggen fant jeg tre ledninger som jeg bestemte meg for å være Ground, 12v og 'signal'
Signalspenningen på datalinjen var på 12v, men jeg la merke til at det syntes å svinge på multimeteret (en slags pulser på linjen).
Jeg brød ombord på en grunnleggende krets for å drive en opto -isolator via datapinnen og koblet den andre siden av opto -isolatoren som en inngang på PC -ens lydkort og fikk en dårlig versjon av en omfangsutgang (Pic 1).
Dette er omtrent så langt jeg kom den gangen - jeg kunne se at det var noe der, men visste ikke helt hvordan jeg skulle "dekode" det.
Siden jeg fikk kaffemaskinen IoT aktivert, hadde jeg en fornyet interesse for å prøve dette igjen med litt mer besluttsomhet denne gangen.
Jeg la ut funnene mine på EEVBlog -forumene for å se om noen kan kaste lys og en flott fyr ved navn Ian kom meg til unnsetning - Han la det ut på en måte det var helt fornuftig (bilde 2)
I utgangspunktet er datastrømmen 13 byte med 'standard seriell' - 8 databiter, en startbit og en stoppbit (ingen paritet), men med en MEGET lav baudhastighet på 104bps.
Trinn 2: Ser dypere ut
Så nå som jeg hadde en ide om hvordan dataene ble formatert, trengte jeg en måte å kunne lese dataene på en mer dynamisk måte.
Jeg dro en av kontrollerne mine fra veggen og koblet den til via en logisk nivåskifter til en Arduino med en enkel skisse for å lese 13 byte med data via programvare seriell port konfigurert på 104bps og skrive den ut:
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, ** Egentlig 12 byte her
Vi hadde handling!
Ved å deretter endre de forskjellige innstillingene på kontrolleren, kunne jeg regne ut byte som endret:
168, 3, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, vifte LOW168, 35, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 248, vifte MED 168, 67, 0, 0, 0, 192, 3, 31, 0, 0, 0, 0, 152, vifte HØY
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, modusvifte 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
Tallene gir mye mer mening når du ser på dem i binær, men hva er det med den 13. byte ?? Det er over alt …
Trinn 3: Kartlegge det
Gjennom prøving og feiling var jeg i stand til å bestemme de relevante bitene i de 13 byte med data som jeg ville trenge for å kunne overføre.
Trinn 4: Murstein foran
Det er her det ble komplisert. Jeg hadde to hindringer å overvinne
a) Den 13. byten så ut til å være en kontrollsum av dataene jeg trengte for å finne ut av det. b) Hvordan overfører jeg dataene da? Det er bare en ledning.
Problem 'a' viste seg å være VIRKELIG enkelt, men det var ved et tilfeldig tilfelle at jeg klarte å komme forbi det.
I testene mine så jeg på data som: A802000000040F61000000004B A81200004004169A00000000FB A81200004004159A00000000F8 A81200004004149A00000000E5 A81200084000149C00000000E7 A83200084000149C0000000087 A85200084000
Dette er 13byte med data inkludert kontrollsummen (her i HEX i stedet for DEC).
Da jeg søkte i oraklet som er google om 'how to reverse engineer a checksum', kom jeg over denne siden på stack exchange med noen andre som het Nick og spurte stort sett det samme som meg, men ikke bare det, de snakket om et klimaanlegg og dataene deres var nesten identiske formatet til mitt - Kan det være ??? I alle mine søk (om 4 år) hadde ikke én person lagt ut informasjon om hvordan man kan hacke protokollen på disse klimaanleggene, og jeg snubler tilfeldigvis over at noen gjorde det samme ved å lete etter noe som er nesten helt uten sammenheng? Det var en velsignelse - Han skrev til og med at han fant det ut, og løsningen var: Legg sammen alle Bytes med data og deretter XOR med "U".
Med det i hånden la jeg det til koden min for å beregne hva jeg syntes sjekksummen skulle være mot hva det faktisk var, men det var alt FEIL !!
Som det viser seg, var det litt feil. Da jeg begynte å se på tallene i binær, var det fullstendig fornuftig.
Svaret fra 'XOR med U' returnerte alltid 9 bits data (den 9. bit alltid en), men de andre bitene var riktige. Jeg fjernet ganske enkelt den 9. biten ved å ta 256 fra det resulterende tallet, og så passet det !!
Hadde det ikke vært for denne personen, kan jeg fortsatt klø meg i hodet. Hatten av for ham også, men jeg kan ikke kontakte ham - Det var i utgangspunktet hans eneste innlegg på stackexchange -forumet. Tusen takk, fremmede:)
Den neste utfordringen var å lage en krets som ville tillate meg å simulere den eksisterende kontrolleren. Jeg kartla skjemaet for drivkretsen (Pic1 og Pic 2), men det virket altfor komplisert for meg å trenge å reprodusere det for å få det jeg ønsket. Jeg leste tross alt allerede signalet. Jeg valgte en mye enklere metode - Bruke arduinoen til å drive en opto -isolator for å trekke 12v -signallinjen lavt etter behov.
Jeg designet også en enklere krets for Rx, men dette er uprøvd, jeg endte med å holde meg til nivåomformeren for enkelhet.
Trinn 5: Få det til å fungere
Når jeg hadde sendekretsen breddet, og med et rennende hjerte, manglet jeg opp en (statisk) streng på 12 byte, beregnet kontrollsummen og fikk arduinoen til å sende kommandoen - Utrolig nok, skjermen ble oppdatert !!! Vinne!
Den siste faktiske testen var å legge min arduino til bussen med de 2 andre kontrollerne for en ekte live test, og det fungerte.
Så nå kunne jeg lese og skrive til bussen, men manglet bare evnen til å klare det enkelt.
Siden jeg bruker MQTT nesten utelukkende for all hjemmeautomatisering, var det naturlig at dette ville være det samme. Jeg skrev ut koden over flere dager for å kontrollere de fire hovedelementene i AC, og leste også tilbake den eksisterende statusen (fra de andre modulene på BUSS)
Intensjonen var å ha koden på en ESP8266 -modul, men det ser ut til at ESP8266 ikke er i stand til å produsere en baudhastighet så lav som 104bps. Jeg måtte gå tilbake til en generisk Arduino Uno med Wiznet ethernet, men det var ikke vanskelig, ettersom kommandostativet mitt bokstavelig talt var på den andre siden av veggen fra en av AC -kontrollerne.
Koden er litt over alt, men bør være leselig. Jeg hadde mange problemer med å forhindre kontrolleren i å lese sin egen utgang, men også å gjenta koden, det er egne publiserte emner mottatt fra MQTT tilbake til aircon. I utgangspunktet ville det skape en uendelig sløyfe. Til slutt fikk noen buffertømming og forsinkelser i behandling av kode etter publisering til MQTT det sortert.
Rx, Tx pins til AC er kodet som 3, 4, men endre hvis du vil
Koden er konfigurert til å publisere og godta kommandoer som sådan:
ha/mod/5557/P 0/1 - Powerha/mod/5557/M 0/1/2/3/4 - Mode Cool, Avfukting, Fan, Auto, Heatha/mod/5557/F 0/1/2 - Vifte lav, med, høyha/mod/5557/Z dvs. 1111 for alle soner på 1000 for bare sone 1 på.
** Fra kontrolleren kan soner ikke settes til '0000', men det ser ut til at hvis du utsteder verdien, vil den gå tilbake til '1000'.
Den siste versjonen av koden er tilgjengelig fra min GitHub Repo:
Trinn 6: Noe mer permanent
Jeg samlet et arduino -prototypebrett og installerte alle delene ettersom jeg fikk dem brødbrettet.
Trinn 7: OpenHAB Config
Se vedlagte fil for OpenHAB -elementer, nettstedskart og regler
Kombiner dette med IFTTT OpenHab -bindingen og Google Assistant/Home, og du har en veldig kraftig stemmestyrt og/eller "smart" aircon som overgår nesten alle kommersielt tilgjengelige produkter!
Trinn 8: Oppsummering
Avslutningsvis - Hvis du er en av de stakkars sjelene med et litt eldre LG -kanalisert delt klimaanlegg, er du ikke alene. Det er fortsatt håp for oss!
Jeg håper denne lærerike finner noen som trenger det like mye som jeg gjorde. Det er i utgangspunktet ingen informasjon jeg kunne finne (annet enn kontrollsummen fra 'Nick'). Jeg måtte starte fra bunnen av, men jeg er ekstatisk med resultatet.
Informasjonen er litt vag jeg vet, men hvis du er i samme situasjon som jeg var, vil jeg være mer enn villig til å hjelpe.
- Forsiktig / oppdatering --- Selv om det er mulig å endre innstillingene på vekselstrømmen med enheten Av, har jeg funnet ut at det ser ut til å rote med det når det gjelder sonekontrollen. Jeg testet mye med enheten av, og jeg fant at sonene ville vise seg som inaktive, men når enheten er i drift, ser det ut til at spjeldene ikke er helt lukket (men ikke helt åpne heller). Jeg tilbakestilte enheten på hovedbryteren, og dette løste problemet. Siden det bare var å endre soner når enheten er på, har dette ikke vært et problem
Jeg har også oppdatert koden for kun å publisere (til MQTT) endringer som kommer fra hovedkontrolleren og ikke hovedenheten. Nok en gang kan dette forårsake problemer fordi hovedenheten sender '0000' for sonene (som også kunne ha vært problemet)
Oppdatert kode introduserer også noen tidsbegrensninger for å prøve å forhindre at arduinoen sender samtidig på master og hovedenhet. Jeg er sikker på at det sannsynligvis er en metode som kontrolleren bruker for å starte en datasending som å trekke linjen lavt for Xms før du sender, men jeg har ikke oppdaget det ennå hvis det er det
Jeg oppdaget at hovedenheten sender data hvert 60. sekund og hovedkontrolleren sender hvert 20. sekund. Koden prøver å stoppe sending av data innen 2 sekunder etter mottak av datapakke. Noen ganger sender imidlertid master og hovedenhet veldig nær hverandre. Dette vil trolig bli forbedret mer snart.----------------------------
** Kan fungere på nyere enheter
*** Noe informasjon som er funnet i mine forskningsreiser indikerte at Panasonic ducted split kan bruke den samme protokollen. YMMV.