Add support for LG ThinQ washing machines

[moutasem1989]

Currently, the project seems focused on wall-mounted AC units. A lot of ThinQ users (myself included) have washing machines, so supporting them would greatly increase the project’s usefulness.

I do own an LG ThinQ washing machine, so I’m happy to help with testing, or reverse-engineering any needed network packets or TLV data.

Also, are there any plans to support other ThinQ appliances in the future (dryers, fridges, etc.)?
Thank you again for all the effort you're putting in — this community work is super valuable.

[stef-bulteel]

I'm working on (my) fridge support.
However, it seems the data send by the appliance is very different from what the author of this repo's appliance sends.
I'm interested to see if your washing machine provisions correctly, and what kind of data it outputs.

[moutasem1989]

I have little experience with middle-man data capturing. I would love to help if someone can provide a short how-to-guid and I will gladly provide all information needed.
I had an internet outage the other week and I found out some functionalities are only accessble through the App; For example tub cleaning cycle.
This is the only appliance I have at home that requires internet access to work with its application.

[anszom]

Hi @moutasem1989, thank you for your interest!

This is a strictly hobby project, mostly a one-man effort. I have only a single ThinQ appliance (the AC unit), so this is what I can support personally. But I'd be happy to work with contributors to get other devices to run.

---

If you're willing to help, the first step would be to test if the provisioning procedure works. You would need to follow the procedure outlined here up to step 5. NOTE that this process will de-associate the appliance from the official LG cloud. It should be possible to re-associate it back by removing any network redirects and following the official pairing procedure - it worked without issues on my AC, but I provide no guarantees.
Also, I'd advise you to start with the experimental branch I've created for stef-bulteel's fridge. That branch uses more flexible matching on MQTT topics.
Please send your logs here whether the provisioning process works or not.

Assuming that provisioning is successful, the next step would be to monitor the MQTT messages sent by the appliance. These will appear on the output of rethink-cloud, in a format similar to this:

clip/message/devices/xxxxxxxxxxxxxxxxxxxxxxx {"mid":351064511,"did":"xxxxxxxxxxxxxxxxxxxxxxx","kind":"RAC_056905_WW","cmd":"device_packet","rssi":-58,"fs":"idle","data":"00000400000087020475038A50572C34","type":1}

You would need to collect a variety of these messages and correlate these to any changes happening on the appliance. I assume that starting the cycle or opening the door would trigger some events that can be observed. The devices also seem to send out a long "state dump" after connecting. Having these logs would hopefully allow us to decode the outputs. It would be interesting to see if the format is similar to the AC or fridge (not yet decoded) protocol.

The final, and most troublesome part is determining the "commands" that can be sent to the device. There are two approaches possible here:

1. Guessing.
   In the case of my AC, the command to set the operating mode is very similar to a notification about the change in operating mode.
2. Sniffing the commands sent by the official cloud.
   This is the best way to learn them, but also the most troublesome. We can't easily intercept the communications between the appliance and the cloud because it's TLS-encrypted.

It's possible to perform a "man in the middle" attack during the provisioning process, allowing an intermediate server to serve as a proxy. I've tried this and it works, but I don't have any ready-to-use code available (there was a lot of manual work involved in the process).
Another way is to connect to the official cloud pretending to be an appliance - then one can simply check what are the effects of triggering various functions in the official app. I've tried this too, but I'm reluctant to publish this tool, because LG might not be too happy with people putting fake devices on their network :)

[dermotos]

You can use something like Proxyman (free version available) to setup an http(s) proxy and essentially do a man in the middle attack and observe the communications.

[anszom]

You can use something like Proxyman (free version available) to setup an http(s) proxy and essentially do a man in the middle attack and observe the communications.

This still requires you to install a special root certificate on the client device. ThinQ devices receive the root certificate from the app during provisioning, so this approach is more-or-less what I've described as the "mitm attack during the provisioning process".

[moutasem1989]

Thank you very much for your help.
I managed to get a laptop, and I’m currently using an Ubuntu live boot from a USB stick for testing. I don’t want to use “rethink” to start the provisioning process yet, because I want to avoid causing problems or potentially bricking the device.

What I’m trying to do is use the laptop as a middle point—between the device and the app during provisioning, and later between the device and the cloud—to capture all data packets. I don’t have much experience with this, so I’m using it as a learning opportunity. Still research how it can be done exactly. Wireshark and proxyman are mentioned but not clear how to use them during provisioning process.

[anszom]

I'm afraid that it's not possible to obtain any useful information without triggering the provisioning process. If your device was set up using the official app, then it's using the official root certificate. We don't have the private key for that certificate, and without it it's not possible to decrypt or meaningfully intercept the communications.

As far as I know, the only way to replace the certificate is to walk through the provisioning steps. It doesn't really matter if you do it "by hand" or using the scripts supplied with rethink, the effect on the appliance will be mostly the same - it will be configured to connect to your "fake" cloud service instead of the official one.

In my case, this process was easily reversible by simply doing the provisioning again from the official app. I can't make any promises though.

[moutasem1989]

Luckily, UniFi gateways have DNS function so I simply used it to rout common.lgthinq.com to the server running Rethink. It is not easy creating a re-rout DNS entry to the server host name.
The Washer WiFi has been changed to LG_Smart_Laundry2_open so no password was needed.
Running rethink-setup.js was successful. The WiFi symbol on the machine kept blinking and then went off but communication with the cloud kept going.
The MQTT server only received a single messege "availability: Offline".

I am not sure if this is was successful considering no output was triggered playing with the washer buttons and programs.

I assume LG changed the way their devices communicate with their servers. the only option now is find an easy way to rout all trafic of the washer modem through WireShark; provisioning and normal operation.

[anszom]

Thanks for the update!

The provisioning didn't complete successfully. It looks a bit similar to #9. Can you confirm that you have used the provisioning-experiment branch of rethink?

[moutasem1989]

lg-washer-rethink-cloud-wireshark-2.zip

lg-washer-rethink-cloud-2.txt

certs.zip

Apologies !!
I was in the wrong folder
Yes now this is the provisioning-experiment branch

[anszom]

Ok, this looks much better. The device is communicating.

The messages look a bit similar to the ones used by @stef-bulteel's fridge, but it's not an exact match. The second byte is always 0xff, while the fridge sent the packet length at this location.

"AAFF200A0039000300000100EB0027000001033103310100030A0401000000000000000300001100710000040000000000000000C00026BDBB"
"AAFF200A0039000304000100EB0027000001032603260400030A040100000000000000030000110071000002000000000000000000009547BB"
"AAFF200A00390002FC000100EB0027000001003B003B3A00030A04010000000000010002000011007100000400000000000000000000BDD9BB"
"AAFF200A0039000300000100EB0027000001033103310100030A0401000000000000000300001100710000040000000000000000C00026BDBB"
"AAFF200A0039000304000100EB0027000001032603260400030A040100000000000000030000110071000002000000000000000000009547BB"

You can try to observe if the content of these packets correlates in any way to your actions on the appliance.

[moutasem1989]

washer-14-min-program.txt

washer-fine wash-program.txt

washer- tub cleaning.txt

Testing Washer Functions.txt

I ran the machine with 14 min program and the output had many unique values.

I also wrote a script that collects all values under designated files named after the action taken: data-value.zip; it collects unique values in a file until a name is given then renames the file and starts over. I would do changes to the washer like open door change program and that was all collected in the folder attached.
Since there are many codes for each action some of them might be duplicated but then I also numbered the files in order to see which is from the action before.

When running a full cycle the cloud server crash when the cycle ends shortly before shutting off:

node:events:495
      throw er; // Unhandled 'error' event
      ^

Error: write EPIPE
    at afterWriteDispatched (node:internal/stream_base_commons:160:15)
    at writeGeneric (node:internal/stream_base_commons:151:3)
    at Socket._writeGeneric (node:net:963:11)
    at Socket._write (node:net:975:8)
    at writeOrBuffer (node:internal/streams/writable:392:12)
    at _write (node:internal/streams/writable:333:10)
    at Writable.write (node:internal/streams/writable:337:10)
    at console.value (node:internal/console/constructor:305:16)
    at console.log (node:internal/console/constructor:380:26)
    at DeviceManager.<anonymous> (/home/user/rethink/rethink/cloud/devmgr.js:37:12)
Emitted 'error' event on Socket instance at:
    at emitErrorNT (node:internal/streams/destroy:151:8)
    at emitErrorCloseNT (node:internal/streams/destroy:116:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:82:21) {
  errno: -32,
  code: 'EPIPE',
  syscall: 'write'
}

Node.js v18.20.4

This is the script I used. it is far from perfect but it works:
rethink_save.sh
I hope those were useful information. i tried using ai to create a byte map:
byte-map.txt

[anszom]

Hi. Thanks for the info. I've made some quite some progress with decoding the protocol. It will take some time before anything usable comes out of it, but I've got some interesting ideas. I'll post some updates in a few days.

Below are some of my findings.

All packets - both for the washer and fridge, follow a basic format like:
AA ... checksum BB

The checksum is computed as (sum(all previous bytes, starting with AA) & 0xff) ^ 0x55.

And here is a (modified) sample packet from the washer, with most fields decoded. Sorry for the formatting, this is a rough copy&paste from my sources.

                                  ..                                                                                state 01=INITIAL
                                    ....                                                                            time remaining
                                        ....                                                                        initial time HH:MM
                                            ..                                                                      courseFL24inchBaseTitan
                                              ..                                                                    error
                                                ..                                                                  soilWash
                                                  ..                                                                spin
                                                    ..                                                              temp
                                                      ..                                                            rinse
                                                        ..                                                          dryLevel
                                                          ....                                                      reserve time HH:MM
                                                              ..                                                    flags 1=turboWash 2=creaseCare 4=steamSoftener 8=ecoHybrid 10=medicRinse 20=rinseSpin 40=preWash 80=steam
                                                                ..                                                  flags 1=initialBit 2=remoteStart 20=wrinkleCare 40=doorLock 80=childLock
                                                                  ..                                                flags 1=AIDDLed
                                                                    ????
                                                                        ..                                          preState
                                                                          ..                                        smartCourseFL24inchBaseTitan
                                                                            ..                                      cycle count
                                                                              ..                                    
                                                                                ..                                  downloadedCourseFL24inchBaseTitan
                                                                                  ??????
                                                                                        ..                          standby
                                                                                          ????
                                                                                              ..                    ezCSDetergentSetVal
                                                                                                ..                  ezCSSoftenerSetVal
                                                                                                  ..                ezDetergentAmount
                                                                                                    ..              ezSoftenerAmount
                                                                                                      ..            ezDispenseType
                                                                                                        ..          flags 1=ezDetergentEmpty 2=ezSoftenerEmpty 4=ezDispenseDrawerOpen 8=ezDispenseNotationOz 10=ezLinkDetergentEmpty 20=ezDispenseSetting
                                                                                                          ..        mlStep
                                                                                                            ????    likely some kind of checksum, not verified by the backend
??????????????????????????????????
AAFF200A0039000390000100EB0027ee0001002080400500040505000141428002ff00010100230071010101000101010101010100010000BB

[moutasem1989]

I am not sure how accurate the content of this file are but it might be that the beginning are just start signature and ID bytes.
Take it with a grain of salt.
washer_byte_map_full.md

1. Frame Structure Overview
All packets start with:

Bytes	Example	Meaning
0–1	AA FF, AA 07, AA 09, AA 0B	Frame header — 0xAA constant, second byte = frame type category
2–3	20 0A	Protocol Version? Always 200A or 2030, etc. Defines frame family
4–5	varies	Length or message counter
6–…	varies	Frame payload
Last 2 bytes	BB xx or xx BB	Checksum (CRC16, variant), plus trailer BB

Major Frame Types:

Frame Type	Hex	Purpose
0x41 frames	AA FF 20 0A 00 41 …	Status frames: door, power, program, temp, cycle counter
0x39 frames	AA FF 20 0A 00 39 …	Program parameter blocks
0x4C frames	AA FF 20 0A 00 4C …	Power-off state frames
0x8E / 0x8F frames	AA FF 20 0A 00 8E …	Heater/sensor / drum load / motor / current draw
0x89 frames	AA FF 20 0A 00 89 …	Environmental sensor frames (water hardness?, temperature patterns)
0x53 frames	AA FF 20 0A 00 53 …	Cycle progress blocks
0x67 / 0x7D frames	AA FF 20 0A 00 67 …, 7D	Advanced motion/weight blocks
Short frames	AA 07 …	Button press or keep-alive
Mini-frames	AA 09 …, AA 0B …	Ticks / increments, internal clocks

2. BYTE MAP — Family 0x41 (Status Frames)
Format example:

AA FF 20 0A 00 41 00 07 7A 00 02 01 03 00 06 11 0A 01 02 11 04 01 05 
00 25 59 5F 56 38 5F 59 5F 5F 5F 57 2E 42 33 32 51 45 55 4B 00 00 01 02 
C5 F4 E2 C6 0B 04 00 00 00 00 00 00 00 00 00 57 46 BB

Offset	Length	Meaning	Notes / Values
0	1	AA	Header
1	1	FF	Frame category
2–3	2	20 0A	Protocol family
4–5	2	Message length(?)	Changes slightly across 41/39
6–7	2	Device ID partial	e.g., 00 07, increments on state changes
8–9	2	Unknown but stable	High confidence: state version counter
10–11	2	Always 02 01	Fixed flags
12	1	03	State subtype → 03 = main status
13–14	2	00 06	Power flag group
→		Bit 0 = power	0 = off, 1 = on
15	1	11 or 10	Door + lock state
→		Bitfield	0x10 = door closed, 0x11 = door open, 0x0A = standby
16	1	0A	Temperature setting (UI selected)
→		Values:	0A=10°C, 0F=15°C, 12=18°C, 19=25°C, etc.
17	1	01	Unknown small flag
18	1	Program ID high byte	always 0x02
19	1	Program ID	See full table below
20	1	01	Cycle active flag
21	1	05	Always heater/steamer bitmask group
22	1	00	Zero
23–54	32 bytes	Fixed ASCII block (Y_V8_Y___W.B32QEUK)	Identifies machine model/version
55–56	2	00 00	Zero
57–60	4	Counter block A	Monotonic in active cycles
61–64	4	Counter block B	Also monotonic
65	1	Drum sensor	Variants of C3-CC etc
66	1	Temperature sensor #2	Varies during heat
67	1	Vibration/load sensor	Rises with drum motion
68	1	Current draw (?)	Correlates with heater
69–76	8	Zeros	Reserved
77–78	2	CRC16
79	1	BB	Trailer

2A. Program ID Values (from your testing)

Program	Hex
Fine Wash	00
AI Wash	01
Colour Wash	03
Eco	26
Turbo Wash	27
Mixed	15
Care Wash	16
Allergies	30
New/Download	12
Tub Clean	0C
Beddings	21
Short Cycle	0E
Sportswear	34
Whole	24
"No Program"	00 but with different parameter block

3. BYTE MAP — Family 0x39 (Program Parameter Frames)
Example:
AA FF 20 0A 00 39 00 07 98 00 01 00 EB 00 27 00 00 01 00 ...
These frames describe in detail the program’s characteristics, such as:

• Duration
• Temperature
• Spin speed
• Soil level
• Rinse count
• Steam on/off
• Option flags
• Load estimation

Offset	Meaning
0–5	Header
6–7	Sequence counter
8–9	Program ID reference
10–11	Subtype → 01 00, 01 03, etc.
12	EB
13	00
→
14	Spin speed
15	Rinse count
16	Soil level / intensity
17	Temperature setting
18–...	Flags defining steam, prewash, AI, delay timer
End	Always ends in CRC + BB

These frames are highly program-specific.

4. BYTE MAP — Family 0x4C (Power-off + Idle Frames)
These occur when:

• Door is open/off
• Door is closed/off

They contain reduced info:

AA FF 20 0A 00 4C 00 08 8F ...

Byte	Meaning
10	Door state
14	09 00 = idle
16	08 00 = door closed sensor
20–...	Short diagnostic block
End	CRC, BB

Used to detect “machine is off”.

5. BYTE MAP — Family 0x8E / 0x9E (Advanced Sensor Blocks)
These appear during:

• Drum movement
• Heating
• Load sensing
• Spin cycles

Field	Meaning
Drum inertia values	correlates with load
Motor speed waveform	changes during spin-up
Heater duty cycle	correlates with power draw
Water level pulses	from pressure sensor
Temperature curves	multiple sensors

This is where energy consumption would be encoded, but values are not monotonic across programs, meaning energy is not stored cumulatively.

6. BYTE MAP — Family 0x53 (Cycle Stage Blocks)
These indicate:

• Stage transitions
• Wash → rinse → spin boundaries
• Heat profile
• Water-in / water-out
• Steam on/off instant states

Contains multibyte param set:

Field	Meaning
00 → stage start
01 → stage type
02–03 → temperature
04–05 → time remaining
06–07 → water level
08–15 → pressure / vibration

7. BYTE MAP — Family 0x89 (Environmental / Pattern Frames)
These contain the repeating pattern blocks like:
1F19 1C1C 21 13 16 13 13 13 ...
These encode:

• Ambient temperature
• Water hardness / mineral sensor
• Power line frequency monitoring
• Drum load (static portion)

Repeated multiple times for reliability.

8. SHORT FRAMES (AA07, AA09, AA0B)
These are:

• Button presses
• Rotor position instant samples
• Timer ticks
• Session heartbeat messages

9. Global Elements Used Across All Frames
Door State Codes

Hex	Meaning
10	Door closed
11	Door open
0A	Standby state

Power State Codes

Hex	Meaning
00 06	Off
00 10	On but idle
00 11	On + door open
00 20	Running program

10. Cycle Counter
Where cycle count appears:

• Family 0x41, bytes 57–60 & 61–64
• Two counters always increase during wash run
• Reset to zero after Tub Clean

Thus, tub cleaning resets cycle-related counters.

11. Summary: Highest Confidence Byte Map

Family	Purpose	Confidence
0x41	Main machine status	⭐⭐⭐⭐⭐
0x39	Program definition	⭐⭐⭐⭐
0x4C	Machine off states	⭐⭐⭐⭐
0x53	Cycle stage	⭐⭐⭐
0x8E	Heater/motor/load	⭐⭐⭐
0x89	Environmental block	⭐⭐⭐
0x67 / 7D	Motor waveform	⭐⭐
AA07/AA09/AA0B	Heartbeats & UI	⭐⭐⭐⭐⭐

[anszom]

I know this was meant to be helpful, but the AI-generated "analysis" is clearly wrong.