This is the new configuration added for the Thing. By default, the polling period to the binding fetch the current status of the device when it is turned-off is 600 seconds (10 minutes). Then, if your device is turned-off and you start it by the remote control, the binding will take 5 minutes in average to “discover” it. Based on it, some important considerations:
Why Does The binding have to poll to get the current device’s state ?
Because it’s the way LG API works. It’s a standard client-server communication when the client (binding or LG app) is the active part, and server the passive. Thus, the binding have to poll for the current status of some particular device wherever it wants. Look… if you have 5 LG devices, the binding will do 5 polling.
Why does the default period of the polling is set to 10 minutes when the device is turned off?
There some reasons for that.
Major of the domestic devices work for a short period during the day (maybe week). Then, doesn’t meter the status when it is turned-off, because it won’t change. Thus, you will save up bandwidth and CPU that it’s important if you are working with a raspberry with several Thinq Devices.
If you fetch several times constantly the LG API, your account can go to Blacklist (some people reported this in other thinq projects). They have some cloud capacity and they will not increase it because this opensource project :-). Then, It’s good not to bother them too much even more when your device is turned off.
What can I do to overtake this problem ?
You can reduce the polling period to something shorter, But stay tuned about the care above.
In the next release, I will provide a command channel named “Refresh Status” that you can push to instantly poll the LG API to get the current status. This could be useful in this scenario.
Thank you for the info. The “Polling period in seconds when the device is off” was set to 10 for me (I just changed it to 600 to avoid blacklisting). I tried to put 30 or 600 seconds and wait, but the status is stuck on OFF. I am currently running OH 3.3, could it be the problem?
Hi @nemer, I think I might have found a similar issue from the one described by @Nirtsep1.
I noticed the the extra info polling job was not starting when my AC was turning on no matter which way I was turning it on.
Then looking into the source code I found the cause, there as a condition that was preventing the pooling jobs to start when the polling period was the same for ON and OFF states.
I added a commit to the PR I sent you with the fix:
It is working fine now here with the changes from that PR.
In addition to the latest issue reported (maybe related to it), sometimes I receive the following error message (especially when I send the command off to the power channel of an AC device. The reported log is referred to this specific event):
2023-07-02 19:12:02.877 [ERROR] [handler.LGThinQAirConditionerHandler] - Error executing Command OFF to the channel power. Thing goes offline until retry
org.openhab.binding.lgthinq.internal.errors.LGThinqApiException: Error adjusting device power
at org.openhab.binding.lgthinq.lgservices.LGThinQACApiV1ClientServiceImpl.turnDevicePower(LGThinQACApiV1ClientServiceImpl.java:129) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAirConditionerHandler.processCommand(LGThinQAirConditionerHandler.java:273) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.lambda$0(LGThinQAbstractDeviceHandler.java:671) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
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) [?:?]
Caused by: org.openhab.binding.lgthinq.internal.errors.LGThinqApiException: Null result returned sending command to LG API V1
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiV1ClientService.sendCommand(LGThinQAbstractApiV1ClientService.java:105) ~[?:?]
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiV1ClientService.sendCommand(LGThinQAbstractApiV1ClientService.java:80) ~[?:?]
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiV1ClientService.sendCommand(LGThinQAbstractApiV1ClientService.java:58) ~[?:?]
at org.openhab.binding.lgthinq.lgservices.LGThinQACApiV1ClientServiceImpl.turnDevicePower(LGThinQACApiV1ClientServiceImpl.java:125) ~[?:?]
… 7 more
The A/C does not receive the command from OH so it keeps the power ON.
Hi, @Nirtsep1. The null answers from LG API are most likely related to no response from your AC to LG API.
So, I recommend to you:
See if your AC location has good connection to the internet. You can check it with some speedtest with cellphone near to your AC. The AC antenna is poor than cellphones, so… be aware that you must have good signal (almost 70-80%)
Try to restart your AC and/or restart the WiFi connection using the remote control. Some times I was faced with a kind of stuck in the AC’s wifi when I had poor connection with the router.
If you still have this kind off error after the verification above, try to see if the problems are reproduced in you LG App as well.
Hi @nemer , I just raised another PR with few improvements:
In this PR I made some changes to replace the Apache HttpClient with Jetty which is provided by the OH runtime.
This reduces the footprint of this binding because some dependencies have been removed and it’s also a step further to make this binding part of the OH library.
Let me know if you find any issues, it’s being tested by me for at least 3 weeks, but I only have Air Conditioner devices.
Hi @nemer . I tried several times with all my A/C and i figured out that the issue of “Error executing command” is related to the dashboard#auto_dry channel (there is also another channel call auto_dry that has the same issue). When I try to switch it ON or OFF I receive the following message:
Blockquote
2023-07-20 09:48:38.384 [ERROR] [handler.LGThinQAirConditionerHandler] - Error executing Command OFF to the channel dashboard#auto_dry. Thing goes offline until retry
org.openhab.binding.lgthinq.internal.errors.LGThinqApiException: Error adjusting AutoDry mode
at org.openhab.binding.lgthinq.lgservices.LGThinQACApiV1ClientServiceImpl.turnGenericMode(LGThinQACApiV1ClientServiceImpl.java:156) ~[?:?]
at org.openhab.binding.lgthinq.lgservices.LGThinQACApiV1ClientServiceImpl.turnAutoDryMode(LGThinQACApiV1ClientServiceImpl.java:143) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAirConditionerHandler.processCommand(LGThinQAirConditionerHandler.java:302) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.lambda$0(LGThinQAbstractDeviceHandler.java:671) ~[?:?]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) [?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
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) [?:?]
Caused by: org.openhab.binding.lgthinq.internal.errors.LGThinqApiException: Null result returned sending command to LG API V1
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiV1ClientService.sendCommand(LGThinQAbstractApiV1ClientService.java:105) ~[?:?]
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiV1ClientService.sendCommand(LGThinQAbstractApiV1ClientService.java:80) ~[?:?]
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiV1ClientService.sendCommand(LGThinQAbstractApiV1ClientService.java:58) ~[?:?]
at org.openhab.binding.lgthinq.lgservices.LGThinQACApiV1ClientServiceImpl.turnGenericMode(LGThinQACApiV1ClientServiceImpl.java:153) ~[?:?]
… 8 more
After this the A/C thing goes off for a while and so the other commands are not working anymore. I made a rule in OH that checks if autodry is ON before sending the command OFF to the A/C and if is not it will send ON to the Autodry function before sending OFF to the Power channel.
So I think that the problem is related to the AutoDry Channel.
The other issue that I reported some days ago (If I switch ON the AC with the remote control the channel power keeps the status OFF [but if I activate it from OH everything works fine]) is still there.
Hi @Nirtsep1 , what happens to me sometimes is that the channels that stores the power state, temperature, etc get missing, and in consequence the items associated to them doesn’t update:
If you see, the only available channels are the ones that are created dynamically.
I’m suspecting that it is because of the typeId of the some channels in the air-conditioner.xml does not have a corresponding channel in the the channels.xml. And the cool_jet channel is duplicated.
I will try to do some tests here to see.
Can you check in you end if all channels are available?
@nemer , it is not a new issue, I could notice it even before my first changes. Please let me know if you have any clue on that.
Usually cleaning up the cache and tmp folders and restarting OH fixes the issue.
Command queue stop to work when some error is threw to the Thinq Handler channel. I saw your previous PR and tested it and I think it was fixed.
Duplicated channels. It’s occur at the new release I introduced the extra-info channels that hold some particular features specific for the devices. To organize better the channels, I created 2 groups: Dashboard and Mote Info group, as follow:
The problem is that when you update the binding, the previous channels were not cleaned, even with the channels descriptors changed. To fix this, for this new version, it’s needed to completely remove the Thing, discovery and setup it again otherwise the channels gonna be unstable.
The complete guide to install this new version is in the following post in the end:
I will delivery today a new version with @jgesser PRs and some other fixes that will help to get the binding more stable agains exception scenarios.
Other particular issue that I fixes for the next release is the error trying to get the acces token in LG API and the binding goes OFFLINE and the only way to fix it is remove the thinq connection descriptor file and restart the binding.
@Nirtsep1 , follow the post above to remove and rediscovery your AC thing, and see if the channel you start to work again. Let me know.
Hi @nemer , I removed thing and discovered it again. Now I have the channel list equal to the one attached to your previous post. The issue related to the power channel is now resolved (if I use the remote control, now the power channel goes on after polling). The Autodry issue is still there. I also cleared OH cache and tmp files as suggested by @jgesser but nothing it has not resolved Autodry channel issue.
Hi @nemer !
Thank you for providing the binding! I am from Austria and tried different settings for Country and Language. I also tried “Other” (German/Austria, German (Standard)/Austria…) - no luck so far (“Precondition failed”) - any idea which combination should work (found nothing in the app etc.)?
Hi @nemer !
Another question - I get following error now:
2023-07-23 10:45:00.035 [ERROR] [handler.LGThinQAirConditionerHandler] - System error in pooling thread (UpdateDevice) for device KLIMAANLAGE/d27b65d0-7149-11d3-80ad-203dbd46730b. Filtering to do not stop the thread
at org.openhab.binding.lgthinq.internal.handler.LGThinQAirConditionerHandler.updateDeviceChannels(LGThinQAirConditionerHandler.java:138) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAirConditionerHandler.updateDeviceChannels(LGThinQAirConditionerHandler.java:1) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.updateDeviceChannelsWrapper(LGThinQAbstractDeviceHandler.java:495) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.updateThingStateFromLG(LGThinQAbstractDeviceHandler.java:439) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler$UpdateThingStateFromLG.run(LGThinQAbstractDeviceHandler.java:417) ~[?:?]
Please, send me the complete log (not only the cut exception part) to understand better what could be the issue. The device file (cap) sounds good for me.
The washer is discovered and goes green, properties are present :
but after some second it goes offline and I observe this in the log :
2023-07-24 10:46:13.228 [ERROR] [al.handler.LGThinQWasherDryerHandler] - Error updating channels dynamic options descriptions based on capabilities of the device. Fallback to default values.
org.openhab.binding.lgthinq.internal.errors.LGThinqApiException: Error reading IO interface
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiClientService.getCapability(LGThinQAbstractApiClientService.java:254) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.getCapabilities(LGThinQAbstractDeviceHandler.java:214) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQWasherDryerHandler.updateChannelDynStateDescription(LGThinQWasherDryerHandler.java:134) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.initializeThing(LGThinQAbstractDeviceHandler.java:229) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQWasherDryerHandler.initializeThing(LGThinQWasherDryerHandler.java:118) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQWasherDryerHandler.initialize(LGThinQWasherDryerHandler.java:129) ~[?:?]
at jdk.internal.reflect.GeneratedMethodAccessor36.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:568) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:147) ~[?:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) ~[?:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
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:833) ~[?:?]
Caused by: com.fasterxml.jackson.core.JsonParseException: Invalid UTF-8 start byte 0xb0
at [Source: (File); line: 293, column: 33]
at com.fasterxml.jackson.core.JsonParser._constructError(JsonParser.java:2418) ~[?:?]
at com.fasterxml.jackson.core.base.ParserMinimalBase._reportError(ParserMinimalBase.java:749) ~[?:?]
at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._reportInvalidInitial(UTF8StreamJsonParser.java:3706) ~[?:?]
at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._reportInvalidChar(UTF8StreamJsonParser.java:3702) ~[?:?]
at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._finishString2(UTF8StreamJsonParser.java:2628) ~[?:?]
at com.fasterxml.jackson.core.json.UTF8StreamJsonParser._finishAndReturnString(UTF8StreamJsonParser.java:2554) ~[?:?]
at com.fasterxml.jackson.core.json.UTF8StreamJsonParser.getText(UTF8StreamJsonParser.java:334) ~[?:?]
at com.fasterxml.jackson.databind.deser.std.BaseNodeDeserializer._deserializeContainerNoRecursion(JsonNodeDeserializer.java:570) ~[?:?]
at com.fasterxml.jackson.databind.deser.std.JsonNodeDeserializer.deserialize(JsonNodeDeserializer.java:98) ~[?:?]
at com.fasterxml.jackson.databind.deser.std.JsonNodeDeserializer.deserialize(JsonNodeDeserializer.java:23) ~[?:?]
at com.fasterxml.jackson.databind.deser.DefaultDeserializationContext.readRootValue(DefaultDeserializationContext.java:323) ~[?:?]
at com.fasterxml.jackson.databind.ObjectMapper._readTreeAndClose(ObjectMapper.java:4772) ~[?:?]
at com.fasterxml.jackson.databind.ObjectMapper.readTree(ObjectMapper.java:3157) ~[?:?]
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiClientService.getCapability(LGThinQAbstractApiClientService.java:251) ~[?:?]
... 14 more
2023-07-24 10:46:23.241 [ERROR] [al.handler.LGThinQWasherDryerHandler] - Error updating thing Lave-linge/0aa70645-554f-1b9f-9021-4cbad76ac66b from LG API. Thing goes OFFLINE until next retry.
org.openhab.binding.lgthinq.internal.errors.LGThinqApiException: Error reading IO interface
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiClientService.getCapability(LGThinQAbstractApiClientService.java:254) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.getCapabilities(LGThinQAbstractDeviceHandler.java:214) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.updateThingStateFromLG(LGThinQAbstractDeviceHandler.java:296) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler$UpdateThingStateFromLG.run(LGThinQAbstractDeviceHandler.java:289) ~[?:?]
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:833) ~[?:?]
Caused by: com.fasterxml.jackson.core.JsonParseException: Invalid UTF-8 start byte 0xb0
at [Source: (File); line: 293, column: 33]
This is an I/O exception reading the cap json file and is not related to de binding.
You can try to visualize your Washer capability file to see if it’s readable and accessible though the SO. If you believe it’s not a corrupted file or hardware problem, you can attach the file here than I can take a look.
Hello @nemer , thanks for your quick answer.
The file is ok, owned by openhab:openhab. Opening it, I can read it and from a json syntax point of view it is correct.
Here’s a link to the file
