Contribution - LG ThinQ Binding

Add-ons Bindings
362

About to buy a 4split airco and looking for openHab 3.0 integration.
Stumbled upon this topic and looks great, thank you in advance for the hard work.

Does this binding still rely on the cloud or is there a way to do it all locally?
I hate cloud services but there is almost no way around it.

363

Try to do the following steps:

  1. upgrade de system/openhab to the latest stable release (using openhab-config)
  2. put the binding in debug mode.
  3. touch the binding file in the OH_BIDING folder and look to the logs. In my case:
cd /srv/openhab-addons
touch ./org.openhab.binding.lgthinq-3.3.0-SNAPSHOT.jar

If you see nothing in your logs under lgthinq domain, I really don’t know what’s happening in your environment. Probably you should try to save you config files and try a new install from the scratch.

1 Like
364

@Kostas_Injeyan, I found a bug int the operation’s modes mapping for V2 API. I gonna fix it and let you know.

365

I hate as well. But… there’s no way to access the Thinq devices directly/locally. The firmware installed on it will always try to access LG API domain. So… the binding has to rely on the cloud to have access to the devices related to your account.
But… the LG Cloud works very well, at lest in my country. Since you have good internet and signal to your LG devices, I think you will not have problems with the cloud.

366

@nemer

Hi. I was wondering if you were able to fix this issue. I tried the latest snapshot and I am still getting the same error as before (original comment: Contribution - LG ThinQ Binding - #301 by BoomerT)

HANDLER_INITIALIZING_ERROR

Unexpected error. Course not present in capability schema

367

How to define things declaratively? I have the Bridge up and running and can add devices there as things via UI, but would need to add those via things file instead (due to version control/backup purposes). What parameters does the Thing require? I have tried guessing different property names but haven’t beeen able to figure out.

Here’s a working Bridge definition and under that some attempts for the things that do not work.

Bridge lgthinq:bridge:df7c4e9d43 "LG ThingQ Bridge" [ country="--", manualCountry="FI", language="--", manualLanguage="fi-FI", username="xyz@xyz.com", password="zyx" ] 
{
    // Thing 201 WashingMachine "Washing machine" [deviceId="7971c6e1-044a-1a55-9cb4-805b65a18bfc"]
    Thing 202 Dryer "Dryer" [UID="7971c6e8-044a-1a55-9cb4-805b65a16bfc"]
}
368

You are running an older version. I Think it’s already fixes since WM support is working for other users. Can you try to update the binding, remove & add again your device and see if it’s fixed for you.

369

I really don’t know because it’s not related directly with the binding, but with the OpenHab’s core storage.
Hence, If you are intending only to backup your configuration files, I suggest you to take a look at /srv/openhab-userdata/jsondb directory that contains json database files related to the configurations done in the UI. I think you don’t need (since OH3) to create things declaratively anymore since the json database is already a “declarative base”.

370

How come other bindings can provide such details about how to configure Things? E.g., with Hue, the documentation says you need to include lightId in the properties of the thing: Philips Hue - Bindings | openHAB

371

Perhaps because @nemer has spent the past year getting this brand new and unofficial binding to work for as many people as possible, and no one asked about defining things manually in text files.

If you use openhab-cli backup, the JsonDB files are automatically included in your backup files.

372

@jpalo, this binding is still under development. Since I don’t get money for this, I have to priorize the developments over documentation and other peripheral things to delivery new integrations and get others to work properly for this community. Imagine, there are more than 30 LG Thinq’s devices that potentially can be served by this Binding. It’s a lot of work ! Unfortunately, you are the first asked me about textual configuration and I really don’t know how to do this since I’m focused on developing and fixing devices integrations. But, If you have some time, you can contribute researching about how to do this for this binding, since as I said, it’s more related to the way OpenHab configure textually things than about this binding itself. Then I can put into the documentations pointing credits for you !

373

That is indeed what I’m doing and have already figured out and shared how the Bridge should be configured. I just cannot figure out what properties the Thing requires and instead of blindly trying combination of different properties and their values I was hoping you have some idea, as you know what Properties the ThinQ API requires for a device status call.

I’ll go through the binding code, perhaps it’ll give some pointers.

374

That’s the problem. The information you need to fill thing’s textual file are not “public”. In other words, you can’t have this information reading the label or manual of your LG device. It’s provided by the LG API when the Binding do the authentication process and get the information about the devices. Look:

image
image749×327 21.2 KB

This is the informations the thing need to work.

  • Device_Id: This is the identification of your device in the LG’s Thinq databases
  • platform_type: You can predict this value: can be thinq1 or thinq2, based on the age and model of your device, but it’s automatically feed by the binding’s discovery process.
  • model_url_info: This url is important to provide your model definition and capabilities. This URL is provided by the LG API as well at the discovery process as well.
  • modelId: This is the internal identification of the LG’s device model provided by the discovery process as well.

So… even you wanting to create your textual file from the scratch, I think it’s a kind of impossible mission, because you don’t have in your hands the information needed. But… there is a trick: you can follow the UI discovery process to create your thing in OpenHab. Then… copy this property values collected by the binding, and finally, you can try to create your file. Should work.

1 Like
375

Thanks, I’ve done exactly that and will continue until I figure out the correct combination of properties.

376

@jpalo (re-)read the generic information on textual Things definitions at Things | openHAB

Note it’s totally unrelated to the binding and Nemer’s work so please don’t annoy him or anyone with any questions on that part or how to debug proper textual configs.
@nemer it would probably nonetheless be a big win if you could put up some rudimentary documentation in some central location (like Github readme) such as a list of thing types and the list of parameters, to avoid an ever-recurring (and increasing) number of questions on that (ending up with you to answer anyway, slowing down development even more).

Forum users to own thinq devices could then join and help you by completing those docs e.g. by documenting what specific parameters actually do. Or by contributing use cases such as " the wash tower requires you to define parameters X, Y and Z"

3 Likes
377

@jpalo #offtopic I used to do ALL textual configuration files for backup / restore / migrate purposes aswell during the OH2 days. I still do, but only for static devices that have no discovery (eg. my Solar Inverter via Modbus). Especially for cloud services where all the info is retrieved dynamicly from the cloud once valid credentials are entered, i no longer do so. I still however, do put everything in .items files where they are linked to the discoverd “things” that the binding provides from the cloud. They always stay the same (uid), so in case of backup / restore all it takes is to (re)login the binding to the cloud, let is discover the things from the cloud and copy the related .items file. Then everyhting is up and running again. No to go into any discussions in pro/cons for textual configuration but that is what works great for me! #/offtopic

I regards to debugging, what you could do is compare the “Code” tab for a thing that you created manually and a thing that was discovered by the ThingQ Binding and then reverse from there. But since the UID is a piece of information that is coming from the LG Cloud and is not known up front, you would always need to run a discovery first, add the item from the inbox and then replicate it in a text file. Might be double work anyway?

@nemer Still enjoying your work every day!

3 Likes
378

@Kostas_Injeyan, I fixed the mapping problem. Can you try it out and let me know about the results ?

379

Hi, @kevin.
I did a better analises about the WM commands and I think I solved the problem you mentioned to send Wakeup commands. Can you try with the new release in the repo ? I’m still looking to implement the Remote Start. It’s a little bit more complex, but i wold appreciate if you try WakeUp command and let me know about the result.

Regards

380

Sure, I’ll test it right now

381

I’ve loaded the Binding, put something in the washer and selected a program, then closed the washer door and pressed remote start. I have the following item states:
Power ‘ON’
Washer State ‘initial’
Washer Course ‘NULL’
Washer Door Lock ‘DOOR_LOCK_ON’
Remaining Time ‘00:36’
Delay Time ‘00:00’
Standby Mode 'OFF;
Remote Start ‘REMOTE_START_ON’ - this is a string channel, should it be a switch?

The only unlinked items I have are:
Washer Smart Course (String)
Washer Downloaded Course (String)
Temperature Level (String)

Sending ‘START’ to the Remote Start Channel puts this in the log

at java.lang.Thread.run(Thread.java:829) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.lambda$0(LGThinQAbstractDeviceHandler.java:408) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQWasherHandler.processCommand(LGThinQWasherHandler.java:226) ~[?:?]
at org.openhab.binding.lgthinq.lgservices.LGThinQWMApiV2ClientServiceImpl.remoteStart(LGThinQWMApiV2ClientServiceImpl.java:78) ~[?:?]
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiV2ClientService.handleGenericErrorResult(LGThinQAbstractApiV2ClientService.java:74) ~[?:?]
org.openhab.binding.lgthinq.internal.errors.LGThinqApiException: Error returned by LG Server API. The reason is:{"resultCode":"9999","result":""}
2022-12-02 13:37:57.027 [ERROR] [nternal.handler.LGThinQWasherHandler] - Error executing Command START to the channel remote-start. Thing goes offline until retry
2022-12-02 13:37:57.026 [ERROR] [es.LGThinQAbstractApiV2ClientService] - Error returned by LG Server API. The reason is:{"resultCode":"9999","result":""}

On the app after I’d typed this it said the washer was in standby mode which I could turn off with the Standby Mode switch in OH, then I set the program in the Thinq app and could start the washer. The washer reported state than changed to ‘Running’ as expected.

In summary Standby Mode seems like it may work, remote start doesn’t