Contribution - LG ThinQ Binding

This is an important thing that @Marty pointed. The LG API is a little bit boring. Different from LG WEBOS binding, that you connect direct to the device to grab information and control some functions, the LG API scheme consist in a kind of triangulation of communication:

  • LG Device registry itself to LG API Server and keep alive the connection
  • LG Server keeps information about connectivity and ask periodically for new status of the monitored properties, that depends on the kind o the device (e.g. temperature, wash cycle, target temperature, energy consumption, etc.)
  • The Binding collects monitored and kept data from the LG API Server, just like the LG App do.

Summarizing, you will never connect direct to you device ! It’s not possible ! Because this, to you have this ecosystem properly working, I suggest to pay attention in some tips:

  1. The LG Devices must be near to the WiFi source, and having a good signal. To check this, close all the doors between your device and the wifi-router and test the strength of the signal (by the cellphone) in the device position. The signal must to be strong, because probably the antena from your phone is better then the LG Device
  2. Your internet must be up and running. If not, it wont collect new informations, and it will seams to be “freezed”
  3. The same about your OH server! It must be with good wifi signal coverage. If not, you wont collect new informations, and will seams to be “freezed”.
  4. If the binding seams to be not running, access the LG App (registered with the same account you filled in the Binding Configuration) and see if it will show you up some new agreements to accept. It’s happens frequently, at least for me. I think it could change by region/country.
  5. Consult the log of the OH to see if the LG Thinq Things report some error and if they are reporting the changes in the channels values. For this, your OH3 must be in debug mode. Another interest thing it to consult OH_USERDATA/thinq directory. There, the binding will put the datatraces, that is the files containing the snapshots data collected per device from LG API. If this files has been updated frequently (i.e, every 15 seconds at most), the collection of that is OK. You can visualize this file to see if the information (e.g. temperature) reported by the binding in the OH pages is the same as the file.

What is the type of AC you are using @tizen ?
Maybe its a specific problem between the LG cloud and your device type. If someone else has the same type and is running it without issue’s it might point you into a direction to investigate your issues.

Im running 3 AC’s identified (by the binding) as : thinq1 / RAC_056905_WW without any issues. (Cant thank @nemer enough for this binding :+1:)

@nemer In your experience reverse engineering the LG cloud connection. How long does the binding have “a lock” on the devices it controls. If OH sends a command thru the binding the LG App indicates the device to be “Controller by another user” and it can no longer be controller by the LG app for an x amount of time. Not a big problem, but sometimes family members fall back to the app and im wondering what time needs to pass before the app can be used again.


This is my model details in binding

  • platform_type : thinq2

  • modelId: RAC_056905_WW


This is a very important question. Thanks for ask ! Will enrich this topic.
The LG API V1 has a different approach to delivery devices monitoring information. For the V2, you only have to ask for a snapshot of the device, and the API send to you, simple like that. But, for the V1, you first need to ask for a worker monitor. The API sends the worker for you and lock the monitoring for you for 1 hour. After that, the worker expires and you have to ask for a new one. You can following this behavior in the OH log by the following message:

[WARN ] [ices.LGThinQAbstractApiClientService] - Monitor for device d27bdb00-7149-11d3-80b0-7440be92ac08 has expired. Please, refresh the monitor.

This warning is the normal behavior, regardless the “warn”.
Well, as you can see, when the binding get the worker monitor, nobody else can access this monitor at the same time, i.e., the LG App. Then, the result is the message you told “Controller by another user” in the LG App. To remediate this behavior, you have to inactivate the Device Thinq in OH. The binding will immediately stop the monitor and then you can access by the app again. hence, It’s not possible, in V1 API, to access by OH/Bindig and LG App at the same time.

LG App and OH have different approach to manage the devices. OH was design to monitor sensors/things in general, control and automate tasks as well. Because this, it must be always connected and aware about changes in the things it controls, regardless you are using it or not at the moment. In another side, LG App is used only to follow and control the devices. Then the App will only open a monitor to watch the device only when you access it in the App. After that, it closes de worker monitor and release it for the others. I can’t follow the same design in the OH because first OH doesn’t know when you are “watching” some thing in the page, and second, because if so, it can’t automate tasks based on changes in the thing that can happen any time, not only when you are watching.

In my house, I teach people to use the OH page I create to control the AC’s. Indeed, we don’t use the App anymore. But, to handle with this situation, what I can do is to create a channel that you can control the start/stop of the monitor for specific V1 device by command, and automate when the OH will monitor the device, and when it will be opened for the LG App.

I hope it helps.


Wouldn‘t it be better to start the monitor just for the polling job and command handling and stop it immediately after result was received. IMHO, this would be a better fit into openHAB design and what is done in other bindings. You can also include a retry if polling or sending a commend fails.

I agree with you @hmerk. Could be better to give chances to the App get the control and will not change the behavior of the Binding. I gonna fix it !

1 Like

Good news, guys !
@tizen , I can’t reproduce your problem, but doing some research some models has the default monitoring sensors timeout is 0 (zero) that means… do not update. This property is related the update period the device will ask for changes in their sensor (i.e - power/energy, temperature and humidity). I introduced a command that will setup to a short period (less then 1 minute). I hope this can fix your case.
@hmerk and @Marty, I fixed the monitor for V1 to do not lock until expire the worker. It will only lock the worker during the monitoring data acquisition. For me… this solve the problem to coexist with LG App. Thanks for the suggestion, @hmerk :wink:

I pushed the modification to the PR and put the .jar in my personal repository to you try guys.



1 Like

Hi Nemer.
Very nice binding. Using tado controllers for three ac’s but i am not happy with this. I have installed the jar file and it works directly. My question, is it possible to change the target temperature in future and something like swing position or energy safe function like in the app?
And i have the same situation like cinadr with missing heat option. Perhaps it comes after time.
Greetings and thanks,

Hi, @Master79. What do you mean with “change temperature in the future”? Is something like a scheduler ? If so, the binding doesn’t have support for it. I know the app has some cool features to turn on/off the device after some time, etc, but I don’t have plans to implement this in the biding because this kind os schedule/automation you have native in the OH.

About Heat Option, It must be available for you (for the AC devices that support this). Some people notice that first time you register the Thing, the options is not fully available. Only after a while and I think it’s because all the channel options is populated dynamically, only some options are default, because is common for all models. This dynamic population take some time (not so much) to be processed at first time, because depends on the fetch of this information from LG API. If you have Heat option in your AC, it will looks like this:

If you still have problems to see the Heat option, send here the *-cap.json file here to have a look in your device’s capabilities.
About swing position / energy safe & energy monitoring are in the roadmap ! I’m finishing the Fridge & Dishwasher support and after that, I will come back to the AC and implement these more “advanced” functions.

I will leaving news in this topic as soon as I release the chances.



HI @nemer, thank you very much for developing this awesome binding! Another cool options that will be great to see implemented is the “auto cleaning”. I have this function in my artcool AC so when it’s enabled and I turn off the AC it will continue to run the fan in order to dry the AC and avoid bacteria proliferation on the wet surfaces.

Thank you again for this binding.

1 Like

Hi Nemer.
Sorry for the missunderstanding and thanks for yor quick answer. I meen no future action. I don’t know whre i can set the target temperature and thought it will be on your roadmap for the future.:blush:
Greetings Markus

Of course you can, @Master79 ! AC has the following writable channels:

  • Target temperature
  • Operation mode
  • Fan Speed
  • Power
  • Cool Jet

The documentation for this binding is still under construction. But if you have some experience on OH, i think you won’t have difficults to control your AC
Another cool thing… There is a very nice widget developed by @hmerk to control AC. I did some adaptations to fit better to this binding. If you need it, let me now i can put here

1 Like

Great you like my widget @nemer.

If you can send me your improvements, I can try to implement them into the marketplace version.

Sounds good ! I put it here:
openhab-thinq-stuff/AirConditionedWidget.yaml at main · nemerdaud/openhab-thinq-stuff · GitHub.

I did some punctual changes:

  1. New configuration property to set the sequence of Operation Modes (same as showed in the channel). The operation modes must be places comma separated and in the sequence:
    • Oracle - f7-icon “arrow_2_circlepath” normally for AI mode
    • Red - f7-icon “thermometer_sun” normally for Heat mode
    • Yellow - f7-icon “drop” normally for Dry mode
    • White - f7-icon “wind” normally for Fan mode
  2. Fix the bottom part to indicate the label of the mode, instead of the code number.
  3. Removed the Window icon in the top of the widget.

This changes was done because it fit better for me, of course. Feel free to accept/reject any change or make other changes. Maybe the addition of another property to list the sequence of the icons could be cool for the user choose the better representation of their modes.

Thanks, I will have a look at it……

Ive been getting errors in my logs after i implemented the recent update @nemer .
Looks like te update regarding the polling interval / lock issue is causing my logs to be flooded with errors like:

2022-05-20 11:13:59.153 [ERROR] [handler.LGThinQAirConditionerHandler] - Error updating thing ACMBR/d27b8ce0-7149-11d3-80ae-xxxxxxxxxx from LG API. Thing goes OFFLINE until next retry.

org.openhab.binding.lgthinq.internal.errors.LGThinqApiException: Exhausted trying to get monitor data for the device:d27b8ce0-7149-11d3-80ae-xxxxxxxxxxx

	at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.getSnapshotDeviceAdapter( ~[?:?]

	at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.updateThingStateFromLG( ~[?:?]

	at java.util.concurrent.Executors$ Source) [?:?]

	at java.util.concurrent.FutureTask.runAndReset(Unknown Source) [?:?]

	at java.util.concurrent.ScheduledThreadPoolExecutor$ Source) [?:?]

	at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:?]

	at java.util.concurrent.ThreadPoolExecutor$ Source) [?:?]

	at Source) [?:?]

Device does go online after a short period (next retry?)

2022-05-20 11:14:49.232 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:401:af26aa09a9:d27b8ce0-7149-11d3-80ae-xxxxxxxx' changed from OFFLINE (COMMUNICATION_ERROR): Exhausted trying to get monitor data for the device:d27b8ce0-7149-11d3-80ae-xxxxxxxxto ONLINE

This behavior is not a problem itself. For the V1, when you ask LG API to get a Monitor and receive it, you can start to get data from this monitor. But, some times, the monitor take time to start to receive data from the device (data come null) and this Info is presented after some retries. At the previous version, the Binding get the Monitor and lock it until expiration (1hr). During this time, the device continuously send monitor data to LG API, and we have a guarantee of a monitored data flow.
At this new version, for the Binding give chances to LG App get the monitor, it starts and stop the monitor each cycle (10 s). Then… the frequency of this info tends to increase. The problem, I see, is that the Thing could go OFFLINE frequently for an behavior that is not OFFLINE itself. I will think in a better approach for this handleling.

About the LG App… did you test it concurrently with OH to see if it’s working better right now ?


I live in Greece and the goverment is ready to start a sponsor program for us to change the old AC’s with new technology ones.I want to get 2 LG Libero Plus S09EQ and 1 LG Libero Plus S18EQ for my home, and use this binding.They state that both support LG Smart ThinQ (Wi-Fi App.) .Is that ok?Is it something else that i need to control them through the LG ThinQ binding?

That’s enough (Smart ThinQ™ (Wi-Fi) Ready)

1 Like

Thanks for update! It is updating indoor tempurature now. Will do more testing.

Thank you!!

1 Like