Contribution - LG ThinQ Binding

Please, don’t forget after registry your WM, it will not have any channel working, right ? Is just to produce an output file containing monitoring data I need to map values into the Channels. Then, after Online status, please get the file: $OH3_USERDATA/thinq/thinq-*-datatrace.json and attach here. Thanks

Please don‘t publish it under that link. With your latest commit, you added the binary to your PR.

Ops… sorry. I will get rid of it and put in my personal area.

Installed the new binding. And now the bridge got online… But it reported and error… Even though, it actually found my washing maschine automaticly :smiley:

( I have the washing maschine in the inbox now. I have not added yet).

Will provide the json as soon as I find the file.

2022-02-08 21:42:56.012 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:bridge:4bb559ca4d' changed from UNINITIALIZED to INITIALIZING
2022-02-08 21:42:56.019 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:bridge:4bb559ca4d' changed from INITIALIZING to UNKNOWN
2022-02-08 21:42:59.791 [INFO ] [ab.event.ThingStatusInfoChangedEvent] - Thing 'lgthinq:bridge:4bb559ca4d' changed from UNKNOWN to ONLINE
==> /var/log/openhab/openhab.log <==
2022-02-08 21:43:00.832 [ERROR] [al.discovery.LGThinqDiscoveryService] - Error trying to get device capabilities in discovery service. Fallback to the defaults values
java.lang.ClassCastException: Cannot cast org.openhab.binding.lgthinq.lgservices.model.washer.WMCapability to org.openhab.binding.lgthinq.lgservices.model.ac.ACCapability
	at java.lang.Class.cast(Class.java:3605) ~[?:?]
	at org.openhab.binding.lgthinq.lgservices.model.CapabilityFactory.create(CapabilityFactory.java:52) ~[bundleFile:?]
	at org.openhab.binding.lgthinq.lgservices.LGThinqApiClientServiceImpl.getCapability(LGThinqApiClientServiceImpl.java:211) ~[bundleFile:?]
	at org.openhab.binding.lgthinq.internal.discovery.LGThinqDiscoveryService.addLgDeviceDiscovery(LGThinqDiscoveryService.java:128) [bundleFile:?]
	at org.openhab.binding.lgthinq.internal.handler.LGThinqBridgeHandler$LGDevicePollingRunnable.doConnectedRun(LGThinqBridgeHandler.java:209) [bundleFile:?]
	at org.openhab.binding.lgthinq.internal.handler.LGThinqBridgeHandler$PollingRunnable.run(LGThinqBridgeHandler.java:140) [bundleFile:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
	at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
	at java.lang.Thread.run(Thread.java:829) [?:?]
2022-02-08 21:43:00.840 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'lgthinq:201:4bb559ca4d:592bd2a4-d3e7-16e9-a69f-44cb8b2e0c43' to inbox.
==> /var/log/openhab/events.log <==
2022-02-08 21:43:00.839 [INFO ] [openhab.event.InboxAddedEvent       ] - Discovery Result with UID 'lgthinq:201:4bb559ca4d:592bd2a4-d3e7-16e9-a69f-44cb8b2e0c43' has been added.

Here is the json data for my WM. (renamed the file to .txt to be able to upload here).

I cant get the bridge to discover my Dryer… How to do that?

thinq-592bd2a4-d3e7-16e9-a69f-44cb8b2e0c43-cap.json.txt (77.7 KB)

It’s not this file. First, you need to put the binding in debug mode, if isn’t , datatrace will not be created. To do so, proceed in this way:

  1. Stop the openhab service:
sudo service openhab stop
  1. Wait while, then start openhab in console mode (if ask for openhab password, the default is habopen):
sudo openhab-cli start --debug
  1. inside the text console, enable debug mode of the binding:
log:set DEBUG org.openhab.binding.lgthinq
  1. you can use the own console to tail the log:
log:tail
  1. disable and enable the bridge through UI interface and go again to the $OH3_USERDATA/thinq/. The file thinq-*-datatrace.json must be there.

By the way, I fixed the typecast error and pushed a new version. You can try this new one.

Great! The bridge works now. OH found my device and I added it as new thing. The added thing shows one channel for Power switch, however OH shows error in communication.

COMMUNICATION_ERROR

Erros list account devices from LG Server API

Arrgh forgot to disable/enable the brigde after debug mode :frowning:

Here you go…

thinq-592bd2a4-d3e7-16e9-a69f-44cb8b2e0c43-datatrace.json.txt (2.4 KB)

Great, Kim ! Tx ! It’s what i was looking for :slight_smile:.

It’s matter. The bridge and Thing must be running Online without error. It’s means the WM Thing is connected to LG API. If you have some error, please, send me here the stacktrace to troubleshoot.

For now, I gonna dig into this file to map the values to the channels. I think till tomorrow I can release an update with channels mapped for read and after, we can try to send some commands.

Cheers.

Nemer.

2 Likes

I dont see any errors, except for tke polling interval value… But thats just an info, going back to default.

Just let me know when you´re ready, and I´ll be here to test :slight_smile:

A small Sidenote…
I noticed the LG Thinq App also discovers and control my LG OLED TV. There is already a LG WebOS binding for openHAB. But would the ThinQ binding be any better?

I noticed the LG Thinq App also discovers and control my LG OLED TV. There is already a LG WebOS binding for openHAB. But would the ThinQ binding be any better?

Depends what you want. LG WebOS is more responsive, because it connects direct to your TV without pass through LG API Server. It means… you don’t need internet or have delay to control your TV with WebOS Binding. The only advantage I see is that with LG Thinq API you can control your device though internet (i.e. remotely) but, if you have your OpenHab connected with MyOpenHab cloud, then… the effect is the same.
In my house all TV’s are LG and supports WebOS. I’ve never felt n need os features that I didn’t find in the LG WebOS Binding.

To sum it up, IMO I don’t think it’s worth to use LG Thinq to control LG TVs.

That makes sense… I also use the WebOS binding… I just wondered if the ThinQ would be better… But like you said, there is no reason to :slight_smile:

I’ve mapped channels: Power and State.

The better is to delete the thing and recreate it again, because some property keys was changed. If you guys could test (plays your Washers and following the Thing) and tell me if is everything OK.

Cheers,

Nemer.

Files uploaded here

Thank you, @hmerk. I updated the PR with the channels (readonly):

  • Power
  • State
  • Course
  • Smart Course

Can you check it out please ? Preferable changing Washer state and verifying channel’s sync…

Great work!

Will give it a try when I get back home in a few hours.

Hi @nemer,
I just installed the new version in my environment and will do some tests…

Hm, channels are not really in sync, see following pictures


Switch and Smart Course are not in sync….

Hummm… Because of these tests, I increase the pooling to 30 seconds. Then, the synchronization can take some time. I created a proxy mock to simulate LG API and to produce data to validate the channels since I don’t have (unfortunately) this Washer and for me it’s been synced.
To be in the same page, I back the pooling period to 10s and I’ve included Temp Level and Door Lock to Washer channels. To proceed with the test, can you:

  1. Delete de current Washer Thing
  2. Update the Binding
  3. Create Washer Thing again (to force re-discovery, you can disable-enable the bridge) linking the new channels
  4. Setup your Washer machine, wait 10s and see if the Washer Thing has been synced.

If not, please, update the datatrace file in your git area to help me to troubleshoot.

Thanks.

Will do tomorrow morning.