Yes. I’m having some problems using DateTime because of some zones handling. So, I changed back do String (Remaining and Delay) then should be OK for no.
However you have to remove completely the itens linked to the channels, remove the device and discovery again.
Let me know if its OK right now.
This new version:
Fixes:
Hi @nemer ,
could you please update your github repo with the latest version, so I can check for needed changes.
I have updated my development environment, so ready for action 
seems ok now if i see something strange i ll report back
Nice ! I updated the repo. I’m using 3.4.X branch.
Hi folks. I released a new version of the binding with various fixes for Washer V1 (with binary data).
RemoteStart for this version implemented and tested with my mock. But, as the command is a quite complex bitmap to read and write, I don’t know if it works with the real device. So… if someone has this version of Washer, let me know if it’s working.
Regards.
@nemer Good News from here, I successfully built a Binding version running at openHAB 4.0
There are just a couple of files which need a one-time change, afterwards you can build versions for openHAB 3.4.x and for openHAB 4.0 which just 2 different maven commands.
I will send you the details via DM.
Unfortunately using oh4.0 and the org.openhab.binding.lgthinq-4.0.0-SNAPSHOT.jar the Washer Thing is running offline after 10s by the message: COMMUNICATION_ERROR Error parsing capability registry:
2023-07-27 20:04:35.784 [ERROR] [ices.LGThinQAbstractApiClientService] - Error reading resource from URI:
java.net.MalformedURLException: no protocol:
at java.net.URL.(URL.java:674) ~[?:?]
at java.net.URL.(URL.java:569) ~[?:?]
at java.net.URL.(URL.java:516) ~[?:?]
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiClientService.loadDeviceCapability(LGThinQAbstractApiClientService.java:118) ~[?:?]
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiClientService.getCapability(LGThinQAbstractApiClientService.java:268) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.getCapabilities(LGThinQAbstractDeviceHandler.java:258) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.updateThingStateFromLG(LGThinQAbstractDeviceHandler.java:452) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler$UpdateThingStateFromLG.run(LGThinQAbstractDeviceHandler.java:445) ~[?:?]
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) ~[?:?]
2023-07-27 20:04:35.787 [ERROR] [al.handler.LGThinQWasherDryerHandler] - Error updating thing /undef from LG API. Thing goes OFFLINE until next retry: Error parsing capability registry
org.openhab.binding.lgthinq.internal.errors.LGThinqApiException: Error parsing capability registry
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiClientService.getCapability(LGThinQAbstractApiClientService.java:274) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.getCapabilities(LGThinQAbstractDeviceHandler.java:258) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler.updateThingStateFromLG(LGThinQAbstractDeviceHandler.java:452) ~[?:?]
at org.openhab.binding.lgthinq.internal.handler.LGThinQAbstractDeviceHandler$UpdateThingStateFromLG.run(LGThinQAbstractDeviceHandler.java:445) ~[?:?]
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: org.openhab.binding.lgthinq.internal.errors.LGThinqApiException: Error reading IO interface
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiClientService.loadDeviceCapability(LGThinQAbstractApiClientService.java:124) ~[?:?]
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiClientService.getCapability(LGThinQAbstractApiClientService.java:268) ~[?:?]
… 9 more
Caused by: java.net.MalformedURLException: no protocol:
at java.net.URL.(URL.java:674) ~[?:?]
at java.net.URL.(URL.java:569) ~[?:?]
at java.net.URL.(URL.java:516) ~[?:?]
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiClientService.loadDeviceCapability(LGThinQAbstractApiClientService.java:118) ~[?:?]
at org.openhab.binding.lgthinq.lgservices.LGThinQAbstractApiClientService.getCapability(LGThinQAbstractApiClientService.java:268) ~[?:?]
The posted log entries are coming every 10 seconds. The Bridge itself is running perfectly and is still online.
Anybody involved in such behaviour issues so far?
Hi, @Josef
The URL registered to the device in the Thing can’t be parsed. Very strange since this URL is filled automatically in the discovery process.
Please, refer to this post:
In order to get the URL registered for your device. Than I cant check what’s wrong.
Regards.
Hi @Nemer, unfortunately there is no URL behind the info tab, only the Thing Type “LG ThinQ Washing Machine”.
The json data is not UTF-8 but asci indeed by a lot of invalid content, no way to remove it by convert step.
Can you attach the file here ?
I suggest you to remove the Thing and rediscovery again (disabling and reenabling the bridge) to see if its something corrupted in the openhab registry.
Removing the Thing and rediscovery again (disabling and reenabling the bridge) is creating a new Thing with a similar behaviour, no change.
The json file is quit big (2.361kb), we seem to have a limitation by 1 mb.
This was the source I was using for the file:
Problem is solved. After a couple of days being on the road I’ve just deinstalled the binding, items, things and reinstalled everything. It’s runnig quite stable now, seems to be ok.
Thank you Nemer anyway for your great binding and contribution!
Hello. I was having some issues with my Washing machine thing, but a download of the 4.1.0 SNAPSHOT binding seems to have resolved that (bravo!).
However I have for sometime had two duplicate things for each my dryer and washing machine. For example with the washing machine there is:
lgthinq:201:LG_Thinq_Binding:6c26b34b-95b8-1fbd-88e0-dc0398c41e84
and
lgthinq:201:LG_Thinq_Bridge:6c26b34b-95b8-1fbd-88e0-dc0398c41e84
(Thinq_Binding and Thinq_Bridge). The two bridge items are always in a state of UNINITIALIZED and I cannot remove them.
I don’t know if I can help you in this specific scenario. You can’t delete the thing if it entered in some states (UNINITIALIZED/Disabled, for example). Try to enable the thing (even in UNINTIALIZED state) and try to remove in the sequence.
Thanks @nemer, these things are totally unresponsive. I am open to removing all things, deleting and reinstalling the binding and trying again (I have after all only two things to install). If I do is there data somewhere that I need to purge so it isn’t brought forward?
You should be able to force-remove an unresponsive item, but I can’t remember what exactly you have to do. I think a dialog might pop up if you press the “Delete Thing” button a few times.
If that doesn’t work, you can delete unresponsive things directly from the JSONDB file. You just have to be careful to do it properly, so you don’t break your system on restart.
org.openhab.core.thing.Thing.json file in your userdata folderBe sure to delete the entire thing entry, from bracket to bracket and the comma that follows: { and },
Thanks @rpwong, I went with the nuclear option and edited the jsondb directly. That fixed the issue (and reminded me that this is a good option for a few other troublesome things…) 
Good stuff. I generally try to make the nuclear option sound scarier than it really is, so that people approach it with due caution. Mistakes happen when people are told that something’s easy and get overconfident. And I am not immune to those kinds of careless mistakes.