Contribution - LG Thinq [Air Conditioner/Heat Pump] [WIP]

I’ve performed the steps you described but adter a few hours later it started to throw errors again. It’s begun with this:

2024-03-18 18:43:23.482 [WARN ] [nding.lgthinq.internal.api.RestUtils] - Timeout reading post call result from LG API

After 3 of the above this came to logs repeated every 30 second or so:

2024-03-18 18:41:05.859 [ERROR] [handler.LGThinQAirConditionerHandler] - Error updating thing Garázs/d27bb3f0-7149-11d3-80af-a06faae627a8 from LG API. Thing goes OFFLINE until next retry: Error starting device monitor in LG API for the device:d27bb3f0-7149-11d3-80af-a06faae627a8
org.openhab.binding.lgthinq.internal.errors.LGThinqApiException: Error starting device monitor in LG API for the device:d27bb3f0-7149-11d3-80af-a06faae627a8
	at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.getSnapshotDeviceAdapter(LGThinQAbstractDeviceHandler.java:667) ~[bundleFile:?]
	at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.updateThingStateFromLG(LGThinQAbstractDeviceHandler.java:465) [bundleFile:?]
	at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler$UpdateThingStateFromLG.run(LGThinQAbstractDeviceHandler.java:458) [bundleFile:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
	at java.lang.Thread.run(Thread.java:840) [?:?]
Caused by: java.lang.NullPointerException: Unexpected StartMonitor json result. Node 'workId' not present
	at java.util.Objects.requireNonNull(Objects.java:235) ~[?:?]
	at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiClientService.startMonitor(LGThinQAbstractApiClientService.java:433) ~[bundleFile:?]
	at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.getSnapshotDeviceAdapter(LGThinQAbstractDeviceHandler.java:656) ~[bundleFile:?]
	... 8 more

There was no activity on LG app since I forcefully terminated it so there is a very little chance to a race condition. Any chance to solve this?

I found no other software connection issues nor network downtimes or dns/dhcp dropouts. Can you give me the server address that timeouts in the binding to actively monitor it? There might be some routing ipv4/ipv6 issues that I don’t see yet.

If I disable only my V1 things there is no error/warning messages in the logs. Which means that all my v2 devices can communicate through the binding.

No, it’s not the same issue. And I don’t know if one is correlated to the other. First time, you send me log pointing to erros in the host server (LG). Know, the result is unexpected to start monitor API method.
I upload a new version with more verbose. Can you install it and send me the log again ?

Thanks.

Thank you for your quick answer!
I’ve downloaded and installed it. It needed some time after it started to throw errors. I’ll report back if it occurs again. Do you need DEBUG mode o TRACE?

You can put in debug mode. That’s enough

Hi! Just a quick feedback: since installing your yesterday version there is no error in logs. I’ll check periodically.

1 Like

Hi, is the air flow direction now implemented?

Thanks !

Amin

Hello, Tizen. To be honest, I was not planning to implement more features for now. My plan is to finish the documentations and test and send the binding to review to finally be released in the main adds-on branch. But I will take a look in this feature. If it’s not so much work, I can do it before close this release.
I let you know.

Thanks!

Hi @nemer

is Dishwasher supported in 4.1.0 binding? I can see the option but in logs I can see this error when I try to add the Dishwasher thing

2024-05-07 23:57:22.742 [WARN ] [g.discovery.internal.PersistentInbox] - Cannot create thing. No binding found that supports creating a thing of type lgthinq:204.

Hi @nemer,
Thank for your contribution on the LG ThinQ Binding that worked for me on LG AC (WiFi) model. I have used to automate LG ACs in my family. When any of my family member turn on the LG AC, openHAB will auto set high fan speed and auto set low fan speed when current temperature reached the target temperature. Whenever openHAB triggering the LG AC, there will be beep sound from the LG AC that will disturb my family sleep. Is there any way to disable the beep sound?

From the youtube link below, the LG AC do have a feature to mute the AC beep sound:

And from the file thinq-xxxxxxxx-xxxxx-cap.json… it mentioned bellSound or @BUZZER

“airState.bellSound.appControl”:“data_type”:“enum”,“default”:“0”,“value_mapping”:“0”:“@ON”,“1”:“@OFF”}},
“airState.bellSound.control”:{“data_type”:“enum”,“default”:“0”,“value_mapping”:“0”:“@BUZZER_ON”,“1”:“@BUZZER_OFF”,“100”:“@BUZZER_OFF”,“120”:“@BUZZER_VOLUME_20”…

Your kind reply would be much appreciated.

I don’t think it’s possible to handle this through the binding. This binding was projected to implement the same functions and features of the LG Thinq App. So, I did some reverse engineering and protocol sniff to interact with the LG API in order to the API though this binding is the LG App. There is no function to turn on/off the beep int the LG App. So, I don’t believe the API implements this kind of feature.
Look, the json metadata model that describe the device is an abstraction of it, but doesn’t mean that the API will implement all the features described in this json.

But I will do some test to see if it would work and let you know.

Hi @nemer,
Thank for your kind help and looking forward to hear good news from you… Many thanks.

I uploaded a new version that supports DishWasher V2. It’s a very simple support that show some basic channels but without commands, since I don’t have physically this device to test. Honestly, I don’t know if DishWasher supports command through LG App.
I had some help from @Rickytr and could dig into the DishWasher protocol to parse the data coming from LG API for this specific device.
Let me know if it works for you and if you see something missing (based on the LG App), please let me know.

1 Like

I saw… only some model support mute the bell/sound. I have 3 different Thinq AC and both don’t support the mute function, i.e., by the remote control, trying to following the guide you shown in the video, in the end nothing happen

Even so, I tried to send direct to LG API the command. Nothing happens as well.
Look, at the session “ControlDevice” of the thinq-xxxxxxxx-xxxxx-cap.json describes the commands that the device recognize. Even having the feature airState.bellSound.control describe in my json as well, I have no option to send it as a command

Can you send me your json file to check if is different from the mine ?