ThinQ1 ducted AC (DUCT_626301_AU) loses control authority after ~10–15 minutes (returnCd 9000)

[pete4435552]

Issue Description

I am experiencing a persistent control issue with a ThinQ1 ducted air conditioner (model DUCT_626301_AU) using SmartThinQ Sensors 0.41.2 on Home Assistant OS 17.0 (Core 2026.2.1).

The device works correctly immediately after a full Home Assistant restart. However, after approximately 10–15 minutes, control stops working while state updates continue to function normally.

When control fails:

• The entity does not become unavailable.

• State (temperature, operation, etc.) continues updating.

• Any control command (e.g. climate.turn_on, set_hvac_mode) fails.

• HA shows either:

  • “Not logged in”
  • or “No control authority”
  • or validation errors.

The LG ThinQ mobile app continues to control the device normally at all times.

Reloading the integration does not restore control.
Only a full Home Assistant restart restores control (temporarily).

Debug Log Evidence

Debug logging enabled for SmartThinQ Sensors.

The failing control sequence shows:

lgedm2_post before: https://kic.lgthinq.com:46030/api/rti/rtiControl
lgedm2_post after: {
'lgedmRoot': {
'returnCd': 9000,
'returnMsg': '잘못된 요청',
'deviceId': ''deviceId': 'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX',
'stateCode': 'S',
'deviceState': 'E'
}
}

returnCd: 9000
returnMsg: 잘못된 요청 (Korean: “Invalid request”)

Immediately afterwards:

lgedm2_post before: https://kic.lgthinq.com:46030/api/rti/delControlPermission
lgedm2_post after: {
'lgedmRoot': {
'returnCd': '0000',
'returnMsg': 'OK'
}
}

After this sequence, further control commands fail with “No control authority”.

State polling (rtiMon, rtiResult) continues to succeed.

Device Details

• Model: DUCT_626301_AU
• platformType: thinq1
• modelProtocol: STANDARD
• Firmware: 1.1.12
• Country: AU
• ThinQ app works correctly at all times

For comparison:

A second split system unit (ThinQ2) under the same account continues to function normally with no control loss.

Behaviour Summary

1. HA restart → control works normally.
2. After ~10–15 minutes → first control attempt returns returnCd 9000.
3. Integration calls delControlPermission.
4. Control authority is lost.
5. Device becomes effectively read-only until HA is restarted.

This behaviour is reproducible with:

• SmartThinQ Sensors 0.41.2
• Home Assistant Core 2026.2.1
• Also observed with the built-in LG ThinQ integration (similar loss of control authority)

Suspected Cause

This appears to be related specifically to ThinQ1 RTI control (/rti/rtiControl) validation for ducted AU models.

It seems that after initial operation, the payload sent by the integration is rejected by LG backend validation (returnCd 9000), and the server then revokes control permission.

Possibly:

• LG backend validation rules for ThinQ1 ducted models changed recently.
• A required control parameter is now missing or invalid.
• A state-dependent ordering requirement has changed.

[srrsparky]

I have this same issue with the same device. Except the HA builtin integration (LG ThinQ) continues to work fine, however it doesn't have zone controls like this integration does.

[pete4435552]

Additional Findings / Workaround

After further testing, I discovered the following:

The LG ThinQ iOS app was prompting me to register the ducted unit, even though it was installed in 2018 and had been operating normally in the iOS app for years and HA for the last year+.

Before registering the unit in the LG ThinQ iOS app:
• The only way to restore control was a full Home Assistant restart.
• Reloading the integration did not restore control.

After registering the unit in the LG ThinQ iOS app (using serial number and install details):
• Control can now be temporarily restored by reloading the integration.
• A full HA restart is no longer required.

However, the control issue still occurs after approximately 10–15 minutes.

Polling Interaction

If polling is enabled in the SmartThinQ Sensors integration:
• Control fails with “Not logged in”.
• Reloading the integration does not restore control.

If polling is disabled:
• Control still eventually fails.
• However, reloading the integration restores control reliably.

Current Temporary Workaround

The only workaround I have found that keeps the entity operational is:
1. Disable polling in the integration.
2. Create an automation that reloads the integration every 10 minutes.

This keeps the air conditioner entity functional, with the only side effect being:
• The climate entity becomes briefly unavailable for approximately 5–10 seconds during each reload.
• The dashboard temporarily blanks during that time.

This workaround has been stable so far.

For comparison:
• A ThinQ2 split system unit under the same account does not exhibit this behaviour.
• The issue appears specific to ThinQ1 ducted models (DUCT_626301_AU).

alias: "SmartThinQ - reload every 10 minutes (workaround)"
mode: single
triggers:

• trigger: time_pattern
  minutes: "/10"
  actions:
• action: homeassistant.reload_config_entry
  data: {}
  target:
  entity_id: climate.house_air_conditioner

[srrsparky]

Mine appears to have stabilised overnight. I have kept the "LG Thinq" built-in integration disabled, and made sure I wasn't in the phone app. Many hours later, this integration is working correctly again.

[pete4435552]

Thanks for the update srrsparky, I just tried disabling my automation that resets the integration every 10 minutes and within half an hour I got the "not logged in" error again. I then reset the integration and re-enabled my reset automation and it works again.