Running rethink for LG ThinQ2 window ACs on Synology Docker/Portainer (WIN_056905_WW)

[Technickly90]

Running anszom/rethink for LG ThinQ2 ACs on Synology Docker/Portainer

This writeup documents the process used to get anszom/rethink working locally for LG ThinQ2 window air conditioners using a Synology NAS, Docker/Portainer, OpenWrt DNS overrides, Synology iptables redirects, and the official LG ThinQ app for pairing.

The working test units were LG dual-inverter window air conditioners. They identified in rethink logs as:

Physical models: LG LW6023IVSM (6,000 BTU), LG LW1522IVSM (14,000 BTU)
ThinQ/rethink model: WIN_056905_WW
Software version: 352200
Firmware/app version: clip_hna_v1.9.229
Platform: clip_v2.00.15.05-SDK-8-RELEASE
Wi-Fi/modem: RTK_RTL8711am / LCW-007 class module

The key discovery was that direct provisioning through rethink was not the working path for these ThinQ2 units. The AC would contact rethink at /route, then stop. The working method was to start pairing through the official LG ThinQ app, temporarily redirect the LG common endpoint during the actual provisioning step, and have rethink route the device to a local rethink.lgthinq.com hostname.

The official-app pairing method was based on this GitHub comment:

#25 (comment)

The key idea from that comment is that ThinQ2 devices do not necessarily need to be provisioned directly through rethink. Instead, begin setup in the official LG ThinQ app, temporarily redirect the LG common endpoint during provisioning, and let the appliance receive a rethink route that points it to the local rethink server.

---

Example environment

Replace these addresses with your own.

Synology / Docker host: 192.168.0.200
OpenWrt router / DNS: 192.168.0.2

LG AC 1: 192.168.0.115
LG AC 2: 192.168.0.193
LG AC 3: 192.168.0.206

The final working network path is:

LG AC -> rethink.lgthinq.com:443
DNS -> 192.168.0.200
Synology iptables redirect -> 443 to 4433
Docker port map -> host 4433 to container 443
rethink listens inside container on 443

The reason for the Synology redirect is that the LG AC expects HTTPS on standard port 443, but Synology DSM commonly already uses host port 443. Instead of binding Docker directly to host port 443, Docker exposes rethink on host port 4433, and an iptables redirect sends only the ACs HTTPS traffic from 443 to 4433. This avoids interfering with DSM HTTPS access.

---

Portainer stack / Docker Compose

services:
  rethink:
    container_name: rethink
    image: ghcr.io/anszom/rethink:dev
    restart: unless-stopped
    ports:
      - "4433:443/tcp"
      - "8884:8884/tcp"
      - "1884:1884/tcp"
      - "46030:46030/tcp"
      - "47878:47878/tcp"
      - "44401:44401/tcp"
    environment:
      - OPENSSL_CONF=/etc/ssl/openssl-legacy.cnf
    volumes:
      - /volume2/NVME-Docker/rethink/data:/app/data
      - /volume2/NVME-Docker/rethink/openssl-legacy.cnf:/etc/ssl/openssl-legacy.cnf:ro

Do not use network_mode: host and do not publish directly as 443:443/tcp unless you know DSM is not using host port 443.

---

rethink config.json

Mounted at /volume2/NVME-Docker/rethink/data/config.json:

{
  "hostname": "rethink.lgthinq.com",
  "homeassistant": {
    "mqtt_url": "mqtt://192.168.0.200:1883",
    "discovery_prefix": "homeassistant",
    "rethink_prefix": "rethink"
  },
  "ca_key_file": "ca.key",
  "ca_cert_file": "ca.cert",
  "https_port": 443,
  "mqtts_port": 8884,
  "mqtt_port": 1884,
  "thinq1_https_port": 46030,
  "thinq1_port": 47878,
  "management_port": 44401,
  "bridge": { "storage_path": "./state" },
  "log": [ "status", "incoming", "HTTPS", "publish", "MGMT" ]
}

Verify the /route response advertises port 443:

curl -sk https://rethink.lgthinq.com:4433/route | jq
# Expected: apiServer: https://rethink.lgthinq.com:443
#           mqttServer: ssl://rethink.lgthinq.com:8884

---

OpenWrt DNS entries

Permanent (always active):

/rethink.lgthinq.com/192.168.0.200

Temporary (during pairing only):

/common.lgthinq.com/192.168.0.200
/common.thinq.com/192.168.0.200

The critical entry observed in packet captures was /common.lgthinq.com/192.168.0.200. Remove temporary entries after pairing so the official LG app can reach the real LG cloud again.

---

Correct pairing order with the official LG ThinQ app

The order matters. Adding common.lgthinq.com too early breaks the official app.

1. Start with only /rethink.lgthinq.com/192.168.0.200 active.
2. Open the LG ThinQ app and start adding the AC normally.
3. Proceed until the actual provisioning / Wi-Fi credential handoff step.
4. Immediately before pressing the final Continue/Next button, add the temporary DNS entries and save/apply.
5. Continue in the app and watch rethink logs.
6. After the AC is online, remove the temporary entries.

---

Expected successful rethink logs

Failing pattern (stops here):

HTTPS common.lgthinq.com /route

Successful pattern:

HTTPS common.lgthinq.com /route
HTTPS rethink.lgthinq.com /route/certificate
HTTPS rethink.lgthinq.com /route/certificate?name=common-server
HTTPS rethink.lgthinq.com /device/<device-id>/certificate
HTTPS rethink.lgthinq.com /route/certificate?name=aws-iot
incoming ... preDeploy
incoming ... completeProvisioning
incoming ... completeProvisioning_ack
publish ... availability online
publish ... LG Air Conditioner

---

Synology iptables redirect rules

Each AC source IP needs a redirect rule from 443 to 4433:

sudo iptables -t nat -L PREROUTING -n -v --line-numbers | grep 4433

Expected:

REDIRECT tcp -- * * 192.168.0.193 0.0.0.0/0 tcp dpt:443 redir ports 4433
REDIRECT tcp -- * * 192.168.0.206 0.0.0.0/0 tcp dpt:443 redir ports 4433
REDIRECT tcp -- * * 192.168.0.115 0.0.0.0/0 tcp dpt:443 redir ports 4433

Scope rules to known AC IPs only.

Persistent redirect script

sudo tee /volume2/NVME-Docker/rethink/scripts/rethink-redirects.sh >/dev/null <<'EOF'
#!/bin/sh
IPTABLES="/usr/sbin/iptables"
[ -x "$IPTABLES" ] || IPTABLES="$(command -v iptables)"
TARGET_PORT="4433"
add_redirect() {
    SRC_IP="$1"
    $IPTABLES -t nat -C PREROUTING -s "$SRC_IP" -p tcp --dport 443 -j REDIRECT --to-ports "$TARGET_PORT" 2>/dev/null || \
    $IPTABLES -t nat -I PREROUTING 1 -s "$SRC_IP" -p tcp --dport 443 -j REDIRECT --to-ports "$TARGET_PORT"
}
add_redirect 192.168.0.193
add_redirect 192.168.0.206
add_redirect 192.168.0.115
exit 0
EOF
sudo chmod +x /volume2/NVME-Docker/rethink/scripts/rethink-redirects.sh

The script is idempotent (safe to run repeatedly). Add it as a Synology Task Scheduler boot-up task under root:

sleep 60
/volume2/NVME-Docker/rethink/scripts/rethink-redirects.sh

A recurring hourly task using the same script also protects against Docker/DSM reloads removing NAT rules.

---

Verification

# Container status
sudo docker ps --filter name=rethink --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"

# Test route endpoint
curl -vk --connect-timeout 5 https://127.0.0.1:4433/route

# Watch logs
sudo docker logs -f rethink

# Watch MQTT
mosquitto_sub -h 192.168.0.200 -t "rethink/#" -v
mosquitto_sub -h 192.168.0.200 -t "homeassistant/#" -v

---

Home Assistant MQTT discovery and WIN_056905_WW model support

After pairing, the devices published Home Assistant MQTT discovery and appeared as climate entities.

PR #73 was submitted to add full climate integration for WIN_056905_WW, confirmed working on LW6023IVSM and LW1522IVSM:

• HVAC modes: off, cool, dry, fan_only
• Fan modes: low, medium, high
• Eco / Energy Saver via HA preset_mode (wire value 8 on tag 0x1f9)
• Sleep timer as a number entity (0-7 hours)
• Current and target temperature

Note: the existing WIN_056905_WW.ts contained an implementation for the LW1823HRSM, which has a different feature set (heat mode, swing, no medium fan, no eco). PR #73 flags this conflict for the maintainer to resolve.

---

Notes

• Each AC should have a static DHCP lease. Redirect rules are source-IP-specific.
• Remove the temporary common.lgthinq.com DNS override after pairing.
• Keep /rethink.lgthinq.com/192.168.0.200 active permanently.
• Validated with WIN_056905_WW (LW6023IVSM, LW1522IVSM). The Synology/Docker/DNS/redirect pattern should apply to other ThinQ2 devices.

[anszom]

Thanks for the guide, I hope it will be helpful for other users.

Provisioning via the official app is not an ideal solution and I'd like to find the root cause, instead of directing users to use
the LG app. I'd be grateful if you could look at #58 and provide me with some captures so that I can pinpoint the cause and develop
a more reliable provisioning process.