Contribution - LG ThinQ Binding

I did some changes in the AC V1 monitoring data polling to handle better situations when you are using concurrently de LG App and/or when no data is returned from the monitor (LG API delays to produce data).
Hope this reduce the error logs and stop with the intermittent Offiline status in V1 devices.

1 Like

That’s great! I’ll be able to update in the weekend and I’ll let you know! Thanks for all your efforts!

Looking further these files may hold more information about my washer and fridge
thinq-331511cb-a542-1332-9ca8-4cbce9ca91d5-cap.json (34.9 KB)
thinq-e4ce4562-d254-11ae-b1d8-402f86e594f8-cap.json (78.7 KB)

Indeed “Reverse” reported was a typo in the constants mapping. I fixed it.
Thanks for the report.

1 Like

Updated today and will monitor the logs for the next few days.
EDIT: No more errors in the last 24Hrs

Something i noticed that isn’t functioning (for me atleast).
In regards to my AC’s Fan Speed the binding seems to correctly read the channel, but is unable to post data and change the setting. The Channel is :

  • Fan Speed
    Air Conditioner Fan Speed

When i change the setting either via the App or remote, the change is updated and reflected in the channel / Openhab. When i try to change the fan Speed thru the binding it is not updated. The following log is created:

2022-06-14 14:40:10.418 [INFO ] [openhab.event.ItemCommandEvent      ] - Item 'LGThinQ_ACCHILD2_FAN' received command 2

2022-06-14 14:40:10.422 [INFO ] [penhab.event.ItemStatePredictedEvent] - Item 'LGThinQ_ACCHILD2_FAN' predicted to become 2

2022-06-14 14:40:10.428 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'LGThinQ_ACCHILD2_FAN' changed from 8 to 2

==> /var/log/openhab/openhab.log <==

2022-06-14 14:40:10.430 [WARN ] [handler.LGThinQAirConditionerHandler] - Received command different of Numeric in FanSpeed Channel. Ignoring

There seems to be a discrepancy between the value posted /vs accepted by the binding. Im using the predifined options (eg low / med / high). Furthermore the binding has a channel setting called “nature” wich seems to reflect the Apps / remote setting of “Auto”.

In Regards to the binding “locking” the app from use with the “Device in use by other User” notification. This lockout still seems to be arround 10 minutes after OH has issued a command to a ThinQ device.

Hi, @Marty. Sorry for the delay.

I think you created a Non-Integer Item linked to the “Fan Speed” channel. Translations between values and labels are done transparently by Binding and OH. Even with the item as an Integer, the UI will present you with the labels associated with it by the binding.

I think that when the App try to get the Monitor, and the Monitor is held by the Binding (even for a short period) the LG App enter in a kind of device quarentene for 10 minutes, regardless the binding release or not the Monitor of the device. To test it, if you catch this scenario again, try to stop the App by force and start again to see if the device is released in the dashboard of the App.

No problem at all. Thanks for your insight. It seemed for the fan speed the item was a number - dimensionless item. No idea why. Changed it and now works like a charm.

Hi @nemer, a cool options that would be great to see implemented (air cooler) is the “auto cleaning”. I have this function in my LG 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. Also the energy saving option enabler would be a great one.

I have a question. When you share a new version of the binding, what is the correct procedure to delete the previous version and use the newest in OH3?

Thank you very much for great work on this binding and for the help.

1 Like

You only have to copy the jar file over the previous one. The OH3 will automatically refresh the binding with the new version.

There is a lot of different kind of LG AC’s available in the market with different kind of capabilities/functions. In the binding I try to implement the common ones, that is available for the major of the models. I don’t know, actually how to handle with “auto cleaning” function because I don’t have any AC device compatible with this one, to test and to do reverse engineer. If you provide me your *-cap.json file and *-datatrace.json files before and after you turn on the auto cleaning feature, then I can see if there is enough information to implement it.

OH shows a different temperature compared to the ThinQ App.
The fridge is correct, but the freezer is wrong.

Any idea how to fix this?

Very strange behavior. Your temperature Itens are showing the raw values of the channels, not the translated labels itselves. 3 are the real temperature code value sent by LG API, but it must be translated to 5 C based on the translations table in the capability file of the device. If it is not translating, could be some configuration problem of the thing, corrupted cap file, the item was not created correctly or you are checking the value outside OH default UI.

I suggest you to do the following:

  1. enter in the OH userdata diretory and inside the thinq folter, remove all *-cap.json file.
  2. In OH, remove your Refrigerator and all items linked to the channels (do not reuse them)
  3. stop & start the LG Thinq Bridge in order to force the discovery process.
  4. At the discovery inbox, recreate your refrigerator Thing
  5. Inside your refrigerator Thing, go to the channels and create new itens linked to them.

Save and try to see in the model if the values was translated to the correct temperature values.

Question: Where is the place you are checking the temperature values ? Is direct at the default OH UI our some other ? (sitemap, habpanel, etc, ?)

I am checking the temperature at the openhab items page. No Sitemaps or anything elsa.
The item was created via the inbox adding.
No manual adding.

Are my other devices affected when deleting the cap.json files? Every other device is working properly.