Contribution - LG ThinQ Binding

Guys,
I released a new version of the binding, with some fixes in WM & Dryer and the merge with Fridge improvements provided by @seime.

OBS: It’s always a good practice to processed with a security backup before updating the binding, because it’s still WIP.

Regards.

Hi, @jpalo. I fixed textual configuration missing in the binding. Now you can configure it textually. An example:

Bridge lgthinq:bridge:WiremockThinqBridge-text [ username="fakeusers", password="fakepassword", language="--", country="--", manualLanguage="PT", manualCountry="pt-BR", poolingIntervalSec=600 ] {
 Thing 201 washer [ model_url_info="https://objectcontent.lgthinq.com/f0f433e7-4f52-459c-b91f-505ca46ff84f?hdnts=exp=1729667409~hmac=c87b9a3e030e499d977e58ae57b02dc4fb656afb046ae39341e974d60cad6e49a", 
                                device_id="washer-0002-5772", platform_type="thinq2" ]

But look, as I said, some needed information is not public. It’s discovered after you get the bridge configured, and the bridge access LG API and get hidden information of the device, like model_url_info and device_id. I really don’t know that textually configure is viable or useful.

Regards.

1 Like

Hi, folks. I provided the current WIP binding for the OH4 & OH3 versions in my workspace (thanks @hmerk). Currently I’m still testing with OH3, because in my environment I have custom automations that uses blockly, javascript and… the worst… it’s a 32bits raspeberian and currently has no java17 version available for it. But, in a near future I will reinstall and upgrade to OH4, but still providing distributions for OH3&4.

Regards

1 Like

If I rember correct, adoptopenJDK is available as 32bit for raspbian and confirmed working for openHAB.

Thanks, I will look into it.

Sorry, it is Zulu17

There was a 32bits version of adoptopenJDK available for arm as well. I installed it, upgrade to OH4 and it’s working like a charm. I don’t know if Zulu is better or not… but for now, it’s working. Txs.

1 Like

If it works, don’t change it :wink:

1 Like

I used this binding for a long time without any problem. Today after an unexpected shutdown of my openhabian I had an error with the bridge thing telling me I have to remove the token to generate another one. I deleted the files in userdata/thinq but now I have the following error:
Generic Error in the LG API communication process

Tried almost everything (restart, delete of the bridge etc) without success.
Any suggestion?

I need more detail about the error (generally, aggregated messages in the log) to determine the real situation. But, based what you said, the exception should be:

  • Error Openning LGThinq Token File. Try to delete it (in data directory) to the bridge automatically recreate it.
  • Error Handling Token Configuration File.
  • or, Error refreshing LGThinq Token. Try to delete it (in data directory) to the bridge automatically recreate it.

Generally, the binding will complain about Token when its try to open the file, but it’s corrupted, or if LG API return an error code saying the token is invalid. For this cases, you must to:

  1. disable the bridge
  2. go to OH_USERDATE/thinq
  3. remove thinqbridge-<BRIDGE_NAME>.json
  4. enable the bridge

The file should be created again with a valid token.
Try it out and let me know if it works.

It was a time problem. After the restart the clock was not synchronized. I discovered the problem by putting the logs in TRACE mode. I had also to delete the dryer thing and rediscover it after I created a new thing for the bridge.
Thanks a lot

Hi, folks ! I have good news !
I finally implemented some very cool features in this binding. I will summarize here these features and in the specific device channels (AC/HP, Fridges/Freezer, WM/DR/Tower) I will give more details about the changes specific for the devices.

– Addeded new “More Information” Channels Group:

  • Enable Extended Info Collector - You can enable or disable the polling collector for extra-info. Notice that this channels was created to automate the collector buy rule and/or scheduler system.
  • Current Power - The binding is supporting right now power consumption monitor. For now, only AC has it’s full mapped in channels. For the other devices, I will implement in a sequence if it supports: Fridges/Freezer apparently doesn’t support. WM V1/V2 supports, but not the instant power. They supports historical energy (by day, week, month, etc.) and I’m still thinking how to put this information in channels.
  • Remaining Filter - analyses the condition of the device’s filter for some models that supports it like: AC/HP and Fridges. For now, only AC/HP was implemented. Fridges are coming in the row.

– Fine tuning binding polling system:

  • Polling period when device if off - The default (and min) value is 10s, but you can change for any value you desired to reduce the band and cpu consumed to get status from LG API when the binding is turned off. Notice this is very usefull when you centralize the control of the device in OH.
  • Polling period when device if on: The default (and min) value is 10s, but you can change for any value you desired to reduce the band and cpu consumed to get status from LG API when the binding is turned on. Notice that when the device in ON, is not a good practice to set up this config with higher values (more than 60s p. exemplo), because when the device is running, sensor reported from it could change dinamically.
  • Enable Extra Info on power off - this config disable the extra-info (filter, power consumption, etc) when the device is turned off. Notice that to pull the extra-info data, the binding needs to call different endpoints compared to the Dashboard information. Then, when enabled, you will increase 2x the requests to LG API. So, it’s reasonable to keep this flag off because when the device is turned off, no changes will occur in extra-info.

You already know, but it doesn’t hurt to remember that it’s a good practice to backup the configuration and the current binding to prevent undesirable situations. After the backup and installation of the new binding, remove the Thing and discovery it again. It’s not necessary to delete the itens and links, because when you recreate the Thing, the OH will remember the old links if you keep the same name/id of the thing.

Enjoy and Cheers.

2 Likes

is it possible to read the current (not the setpoint) temperature for fridge/freezer with Extended Info Collector?

I don’t think so, @Constantinos_Contis. Normally, if LG App doesn’t have the information, the device doesn’t provide it. But, if you believe your Fridge provides this information by LG App or other way, let me know then I can try to get it.
By the way, it’s unbelievable LG Fridge doesn’t providing current temperatura. Figuring out that the Fridge must control the current temperature to know the time to stop cooling, it would be the very first sensor available to export, but the models of Fridge I tested didn’t provide the current temperatura by LG API.

Hello, @nemer. Very happy with the binding overall. I had a similar problem to one earlier, the binding went offline. As you suggested to another user, I:

  1. Disabled the binding,
  2. Deleted the thinqbridge-LG_Thinq_Bridge.json file
  3. Enabled the binding

I first receive the error “Generic Error in the LG API communication process” and within the logs:

2023-06-09 16:24:13.938 [INFO ] [openhab.event.ThingStatusInfoEvent  ] - Thing 'lgthinq:201:LG_Thinq_Bridge:6c26b34b-95b8-1fbd-88e0-dc0398c41e84' updated: UNINITIALIZED
2023-06-09 16:24:13.938 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:201:LG_Thinq_Bridge:6c26b34b-95b8-1fbd-88e0-dc0398c41e84' changed from OFFLINE (BRIDGE_OFFLINE) to UNINITIALIZED
2023-06-09 16:24:13.943 [INFO ] [openhab.event.ThingStatusInfoEvent  ] - Thing 'lgthinq:201:LG_Thinq_Bridge:6c26b34b-95b8-1fbd-88e0-dc0398c41e84' updated: UNINITIALIZED (HANDLER_MISSING_ERROR)
2023-06-09 16:24:13.944 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:201:LG_Thinq_Bridge:6c26b34b-95b8-1fbd-88e0-dc0398c41e84' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
2023-06-09 16:24:13.944 [INFO ] [openhab.event.ThingStatusInfoEvent  ] - Thing 'lgthinq:202:LG_Thinq_Bridge:262b3076-9bf2-1ac1-9fcc-64cbe926776a' updated: UNINITIALIZED
2023-06-09 16:24:13.945 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:202:LG_Thinq_Bridge:262b3076-9bf2-1ac1-9fcc-64cbe926776a' changed from OFFLINE (BRIDGE_OFFLINE) to UNINITIALIZED
2023-06-09 16:24:13.950 [INFO ] [openhab.event.ThingStatusInfoEvent  ] - Thing 'lgthinq:202:LG_Thinq_Bridge:262b3076-9bf2-1ac1-9fcc-64cbe926776a' updated: UNINITIALIZED (HANDLER_MISSING_ERROR)
2023-06-09 16:24:13.950 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:202:LG_Thinq_Bridge:262b3076-9bf2-1ac1-9fcc-64cbe926776a' changed from UNINITIALIZED to UNINITIALIZED (HANDLER_MISSING_ERROR)
2023-06-09 16:24:13.950 [INFO ] [openhab.event.ThingStatusInfoEvent  ] - Thing 'lgthinq:bridge:LG_Thinq_Bridge' updated: UNINITIALIZED
2023-06-09 16:24:13.950 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:bridge:LG_Thinq_Bridge' changed from OFFLINE (HANDLER_INITIALIZING_ERROR): Error refreshing LGThinq Token. Try to delete it (in data directory) to the bridge automatically recreate it. to UNINITIALIZED
2023-06-09 16:24:13.954 [INFO ] [openhab.event.ThingStatusInfoEvent  ] - Thing 'lgthinq:bridge:LG_Thinq_Bridge' updated: UNINITIALIZED (DISABLED)
2023-06-09 16:24:13.954 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:bridge:LG_Thinq_Bridge' changed from UNINITIALIZED to UNINITIALIZED (DISABLED)
2023-06-09 16:24:13.955 [INFO ] [openhab.event.ThingStatusInfoEvent  ] - Thing 'lgthinq:201:LG_Thinq_Bridge:6c26b34b-95b8-1fbd-88e0-dc0398c41e84' updated: UNINITIALIZED (BRIDGE_UNINITIALIZED)
2023-06-09 16:24:13.955 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:201:LG_Thinq_Bridge:6c26b34b-95b8-1fbd-88e0-dc0398c41e84' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to UNINITIALIZED (BRIDGE_UNINITIALIZED)
2023-06-09 16:24:13.955 [INFO ] [openhab.event.ThingStatusInfoEvent  ] - Thing 'lgthinq:202:LG_Thinq_Bridge:262b3076-9bf2-1ac1-9fcc-64cbe926776a' updated: UNINITIALIZED (BRIDGE_UNINITIALIZED)
2023-06-09 16:24:13.955 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:202:LG_Thinq_Bridge:262b3076-9bf2-1ac1-9fcc-64cbe926776a' changed from UNINITIALIZED (HANDLER_MISSING_ERROR) to UNINITIALIZED (BRIDGE_UNINITIALIZED)

After again disabling and reenabling the binding (without deleting the json file), the error “Error refreshing LGThinq Token. Try to delete it (in data directory) to the bridge automatically recreate it.”
Thoughts on this issue?

my LG App does not provide door info for my fridge but through the binding i can get the door open/close info just fine.So i though maybe there are some more “hiden” info inside api that we can use…

I updated to the 3.5.0-SNAPSHOT, created a new thing then the bridge began working. I had to relink my things (only a washer and dryer, so not many items created).

1 Like

Hummm… I will try to handle better in the binding this kind of situation in order to the binding fix itself.

Yes, but in this case, I’ve already sniffed the data exchange through the LG API and Fridge V2. There is no current temperature exchanged. These are the information Fridge expose:
“refState”:{
“atLeastOneDoorOpen”:“CLOSE”,
“displayLock”:“UNLOCK”,
“freezerTemp”:5.0,
“fridgeTemp”:3.0,
“tempUnit”:“CELSIUS”,
“expressMode”:“OFF”,
“activeSaving”:“OFF”,
“freshAirFilter”:“IGNORE”,
“monStatus”:“NORMAL”,
“smartSavingMode”:“SMARTGRID_DD_ON”,
“smartSavingRun”:“STOP”,
“waterFilter”:“0_MONTH”
}

Some of them are not handled by the LG App, like atLeastOneDoorOpen (as you montioned), smartSavingMode, displayLock and smartSavingRun. But the only temperature exposed are freezerTemp and fridgeTemp that is the setpoint.

Hi @nemer, awesome new features. Amazing job, congrats!

I was running a forked version from your binding since a while, but now I had to replace it with your latest version.
It took me sometime to realize that the channels now have a prefix (‘dashboard#’), but after that everything seems to be working fine besides one small issue I remember having fixed in my old fork.

I’m going to throw away my fork, it will be a hell to merge all changes you have made over it.
So I am trying to make a new fork to try copying whatever fix or improvement I have made and then submit a PR to you.
However I couldn’t find these latest features in your repo, I could notice you have now two branches, but none of them seems to have anything related to the “extended information”.
Could you please share some information about where are the latest version?

I also would like to help making this binding “official” and available on the OpenHab library.
Let me know if you are looking for help on that.