=== THIS IS FOR WASHER V1 ===
Hi, @djal. This fix took me a lot of time, since for your device’s version, data received from LG API come in binary format, and for some features (eg. RemoteStart) is a bit inside a byte position (yes I know, it’s crazy). I think it’s ok right now. Can you try it out ?
Notice that I hope the channels StandBy and RemoteStart been populated corretly and if StandBy=‘OFF’ and RemoteStart=“ON”, then you can see a new Channel called “LauchRemote”. If you are in the Channels tab, the first time you achieve this combination, I think you must refresh the page (maybe a bug in the channels page?) to see this new Channel. Then you can link an item to it and next time won’t be necessary refresh the page again.
Only send command to StandBy (to ON or OFF) is supposed to work for now. RemoteStart command in the LauchRemote channel is still in progress.
=== THIS IS FOR WASHER V2 === @kevin , do you have opportunity to test the last version of the binding to see if the StandBy and RemoteStart is working on your Washer ?
Notice that I hope the channels StandBy and RemoteStart been populated corretly and if StandBy=‘OFF’ and RemoteStart=“ON”, then you can see a new Channel called “LauchRemote”. If you are in the Channels tab, the first time you achieve this combination, I think you must refresh the page (maybe a bug in the channels page?) to see this new Channel. Then you can link an item to it and next time won’t be necessary refresh the page again.
Hi Nemer,
thanks for your work. I’ve been able to test your latest changes with my V1 Washer.
The StandBy and RemoteStart channels are working correctly, exactly like you described in your post above. Even the new channel appeared.
I was able to send command to StandBy item and was able to wake the washer up from the sleep.
There was just one problem when starting the binding. Probably something wrong with binding channel descriptor - see attached log. 2023-03-15-djal-washerV1.log (25.9 KB)
One more question: was the type of RemainingTime channel changed from String to DateTime? I noticed persistence exception connected to this item (visible also in the log). I should probably link the channel to new item of datetime type.
Jeez ! Are you using JDBC to store OH3 data in a SQL Database ? I’ve never used, because this I’ve never had a error like yours, I think. Yes… a changed from String to DateTime to get easy to handle data values. I think its better to remove the thing and itens associates to it and recreate again. Let me know about this…
About the error in XML descriptor, it’s not related to the resource itself. I think it’s because um reinstall the binding and when you do it, some erros reading resources could happen on-the-fly. I didn’t touch in the channels.xml resource for a while, and I have no issues related with it. Try to restart your OH3 and see if the error persists. If so, let me know.
OK, made a little progress on this in as much as I’ve updated OH and Debian to the latest versions. Fortunately a good backup allowed me to step away from OH 4. Everything seems stable I’ll try the binding soon. As my Linux Knowledge is limited, and OH does many things around here I always take a disk image backup before I do anything.
Binding installed - latest 3.4.3 snapshot - and all items mapped so I can see what’s going on., LaunchRemote appeared after a refresh.but has no updates to its item.
Everytime I start a new program I seem to get this in the logs
2023-03-19 13:06:58.345 [WARN ] [ation.ConfigDescriptionValidatorImpl] - No config description found for URI 'channel-type:lgthinq:LaunchRemote-type'
2023-03-19 13:06:58.346 [WARN ] [ation.ConfigDescriptionValidatorImpl] - Skipping config description validation because no config description found for URI 'channel-type:lgthinq:LaunchRemote-type'
2023-03-19 13:06:58.355 [WARN ] [core.thing.internal.ThingManagerImpl] - No config description for 'channel-type:lgthinq:LaunchRemote-type' found when normalizing configuration for 'lgthinq:201:4599df93bd:e4ce4562-d254-11ae-b1d8-402f86e594f8:launch-remote-start'. This is probably a bug.
I started a downloaded cycle “QUICKTUBCLEAN” from the app and the items changed as expected. However when I started a normal cotton cycle both Washer_Course and Washer_Smart_Course remained blank so there is no indication of what program its running.- is this expected behaviour?
Please, send a command “START” to this new channel. It must start your cycle remotely. You can send text commands in some different ways. But if you don’t know how to do it, i suggest you to create a blockly rule and put a send command action “START” to the utem associated to this new channel (RemoteLauch).
No. next time, if you can, send me the datatrace file generated (you must be in binding’s debug mode) during the cycle and a snapshot of the channels tab.
I loaded the washer, selected Cotton and Rinse+ followed by Remote Start. Then from OH I sent a START command. The washer started. I then discovered the Washer Course was set at a DateTime Type Item. I recreated this manually as a String Item and now it displays correctly.
Attached is the datatrace and cap files, plus a snapshot of the channels tab. thinq-e4ce4562-d254-11ae-b1d8-402f86e594f8-datatrace.json (2.4 KB) thinq-e4ce4562-d254-11ae-b1d8-402f86e594f8-cap.json (78.7 KB)
As this seems to be working is it possible to use OH to set the program and extra rinse (RINSE_PLUS) options? Extra rinse isn’t a channel currently
Good to hear it’s worked ! Yes… i’m implementing right now the remote start custom functions per Course (eg. Rinse, Temperature, etc.). I think next days I can release it to you test.
Hello and thank you @nemer for your work.
I am especially looking forward to the remote start, so OH can then also start my washing machine at a convenient time. However, I have problems with version 3.4.3. As soon as I select a program I get an exception in Java. I have a V2- Washerdryer (LG-Signature/ LSWD100E). Do you know what the problem is? 2023-04-12-washer-debug.log (1.6 KB)
But, is it working right now or you are having the same error ? I have made some tests, but can´t produce the same error as yours.
If you still have errors, I think you can wait for the new version I will release by tomorrow. This version 0.1 is related with the binding device’s implementation, and it is correct for the current binding.
