Contribution - LG Thinq [WasherDryer & DishWasher]

Hi @nemer, is the dishwasher thing still in development or you abandoned the project?

It’s supposed to be finished Ricky. Let me check if I updated it in the repo and I let you know.
Actually now I’m only writing the binding documentation and after send to revision to be released in the main OH branch.

It’s supposed to be finished. Let me verify if I updated it in the repo.

Thanks @nemer can you tell me where I can download the binding to test it?

Hi, Ricky. Sorry, I’m in debt with you :-(. I found some issues in some parts of the binding and had to refactor some parts. I gonna delivery these feature to you test in the next days. I’m only finishing some tests.

Thanks @nemer. I’ll wait for something to test.

Hi Ricky. Finally I uploaded a test version for DW.
It’s very basic, because I don’t know all the functions its supports from LG App. Let me know about the tests and if you missing some feature.

1 Like

Hi @nemer,

I tried the new binding. Dishwasher is dicovered and added correctly but never goes online. I have the following error:

2024-05-16 22:04:17.930 [ERROR] [nal.handler.LGThinQDishWasherHandler] - Error updating thing Lavastoviglie/40c06592-e5f0-1b3b-b8cd-b8165fcae1da from LG API. Thing goes OFFLINE until next retry: Error reading IO interface
org.openhab.binding.lgthinq.internal.errors.LGThinqApiException: Error reading IO interface
	at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiClientService.getCapability(LGThinQAbstractApiClientService.java:272) ~[bundleFile:?]
	at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.getCapabilities(LGThinQAbstractDeviceHandler.java:271) ~[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: com.fasterxml.jackson.core.JsonParseException: Invalid UTF-8 start byte 0xb0
 at [Source: (File); line: 419, column: 22]
	at com.fasterxml.jackson.core.JsonParser._constructError(JsonParser.java:2477) ~[bundleFile:?]
	at com.fasterxml.jackson.core.base.ParserMinimalBase._reportError(ParserMinimalBase.java:750) ~[bundleFile:?]
	at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._reportInvalidInitial(UTF8StreamJsonParser.java:3712) ~[bundleFile:?]
	at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._reportInvalidChar(UTF8StreamJsonParser.java:3708) ~[bundleFile:?]
	at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._finishString2(UTF8StreamJsonParser.java:2634) ~[bundleFile:?]
	at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._finishAndReturnString(UTF8StreamJsonParser.java:2560) ~[bundleFile:?]
	at com.fasterxml.jackson.core.json.UTF8StreamJsonParser.getText(UTF8StreamJsonParser.java:335) ~[bundleFile:?]
	at com.fasterxml.jackson.databind.deser.std.BaseNodeDeserializer._deserializeContainerNoRecursion(JsonNodeDeserializer.java:572) ~[bundleFile:?]
	at com.fasterxml.jackson.databind.deser.std.JsonNodeDeserializer.deserialize(JsonNodeDeserializer.java:100) ~[bundleFile:?]
	at com.fasterxml.jackson.databind.deser.std.JsonNodeDeserializer.deserialize(JsonNodeDeserializer.java:25) ~[bundleFile:?]
	at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:323) ~[bundleFile:?]
	at com.fasterxml.jackson.databind.ObjectMapper._readTreeAndClose(ObjectMapper.java:4867) ~[bundleFile:?]
	at com.fasterxml.jackson.databind.ObjectMapper.readTree(ObjectMapper.java:3252) ~[bundleFile:?]
	at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiClientService.getCapability(LGThinQAbstractApiClientService.java:269) ~[bundleFile:?]
	... 9 more

The encode of the your cap file is not UTF-8. This file is downloaded in backgroud by the binding to get the meta-model of the device. This file is structured as JSON format, and it’s based on the JSON RFC:

Blockquote 1. Encoding - JSON text SHALL be encoded in Unicode. The default encoding is
UTF-8.

So, it’s mostly like a mistake in the file from LG API than this binding. But, regardless this issue, I must to do some “magic” to fix the file because the LG team will not care about us :smiley:

Can you please send me your thinq-xxxxx-xxxx-cap.json file ?

Hi @nemer

an important update…
Looking for the files you asked I found that I had an old version. I deleted it and after adding again the thing it seems that the problem is gone!

I’ll check the other funztions and let you know if everything works as expected.

Thanks a lot.

OK.
Let me know !

Hi, @tizen

About issues you mentioned here:

  1. Power State: actually, your machine is suppose to be ON even after complete the cycle. The Power goes to OFF when the state goes to POWEROFF (and you can see in the picture the state is Complete/END).
  2. 00:01 - apparently, when the cycle finish, the DW stop to send state changes to the API and sometimes the last snapshot remains 00:01. I changed the logic for this to force the remaining goes to 00:00 when state is complete. I think it will fix this issue;

Wrapping all these up, this scenario appears to me as the DW is missing to send the last event to the LG API. I really don’t know, but we can do some tests to undertand better this behavior.

I gonna ask you to:

  1. Put the binding in debug mode
  2. run a washing cycle and in the end, see if the result is the same (00:01 & Power not go to OFF even after power off physically)
  3. collect the in the userdata folter (mine is in /srv/openhab-userdata/thinq) the thinq-XXXXX-datatrace.json related to your DishWasher and attach here.
  4. Tell me the last update date for this file and if is the same as the the near current time.

Hi @nemer, firstly thank you for your great work on this!

Everything is working with my Washer (WV5-1410W) except that “process state” got stuck on “Detecting” even though the thinq app showed it had moved on to “Washing”. The remaining time was updating properly, and when the cycle ended it updated to “End”. I could see the same in the trace (showing “preState”:“DETECTING” while washing).
It’s not a big deal for me but thought you might like to know. I will check what happens with the next cycle also to see if it’s the same.

Could I please request that you add the “how to enable debug” information and the repository link to the first post? They are difficult to find in the thread for anyone coming in new :slight_smile:

Hello, Matt. Thx for the report! Actually I don’t have this machine. I developed a simulator to support me in the implementation, but i depend of guys like you to fine tune the Binding. I will take a look on preState.

Hi @nemer, I’ve checked again and can confirm that it’s only the “Washing” state that is missed. It successfully updated from: Detecting → Rinsing → End. It just missed the Washing between the Detecting and Rinsing.

Actually I also noticed that when the washer state went to “Spinning” the process state when to “Rising” (missing the “n”).

I’ve attached the capabilities output of that helps.
thinq-###-cap.json (78.8 KB)