Hi @nemer , first thanks for the all the awesome work. Binding is working fine.
I have power outage issue in my area. This turns on the display panel and sometime middle of the night. Is there any way to expose this as channel? I can then add some automation to turn it off if it is between some time range.
You mean… Detect when the device is turned off by outage?
If so… you can do this by watching the thing status. When the device is unresponsive by internet lost or energy, the binding put it in Offline and status detail as Communication Error. But… I’m figuring out… If you use the status offline to trigger some rule to handle outages it’s fare enough.
Hi,
no i mean display panel light on ac unit turn on where current temperature is shown on ac unit.
I can turn it off by remote but state is not saved if there is power outage.
Unfortunately… I think the AC Display light is a feature controlled exclusively by remote control. I’ve never seen this kind of function available in the App/API… So I’m afraid it can be controlled by the binding.
Ok, thanks!
The reason for declarative (file based configuration) for Thinq things not to work with this binding is that it reads configuration values from properties instead of configuration. Not sure if other Bindings just always read config values from configuration property of the thing or if they combine properties and configuration nodes.
In any case, if you wish to add file based configuration support, this is the change needed.
Thanks for you research. For me, doesn’t make sense let the properties information to be changed by configuration. This properties are gotten from your LG Account, and can’t be changed. It’s why they are in the properties session rather than configuration session.
But, I understand you needs to textually setup the thing (as well legacy’s OH configuration), even knowing you have others (and IMO better) approaches to backup your OH configs. So, I think if I move “device_id” from properties to configuration is enough as the others information are automatically filled by the Thing Handler.
I’m doing right now a refactory to get Washing Machine “remote start” comand to work perperly. Than I will take a look at textual configuratiuon as well.
Regards.
I’d personally consider first reading the `configuration´ property for all values, and if it fails, then get everything from ´properties´. That is perhaps how it is done in other bindings, but that’s just a guess. Assuming, that the properties do not change over time.
I don’t think so. If I put this properties in the configurations session, I will be inducing the user that it is possible to configure the device from scratch, which is not true, since not even the device_id is obtained outside the discovery process.
In my understanding about textual configuration, you must know in upfront the values to configure the thing, but it’s not this binding’s case. If I asked you to get these mandatory configuration of the thing: device_id, model_id, model_url_info and platform_type, where would you find these information ? Nowhere, because these information are not exposed for the LG App and LP Account Portal. These are internal and immutable information in the LG API databases. Hence, why we can lead the user to manually configure that if it’s not possible to know this values upfront ?
I know, you can use the LG Thinq Binding discovery process to create things related to your account and than, copy the values of the properties and create your textual file, but look how this doesn’t make sense ! You’ve already created your Thing, and it’s stored in the OH database with properties that can’t be changed. Why will I “force” the properties to be change to “configurations” to induce the user he can configure the thing from the scratch if I know he can’t ?
For your specific backup strategy it could work, but IMO, in the documentation, I have to disincourage the user to try to textually configure the LG Thinq Things.
First, great job @nemer , your contribution is amazing and helped me a lot. I have 5 LG air conditioners, so now I can have the temperature of all my rooms in my dashboard thanks to you.
Regarding the file based configurations, I also have a preference to that, all my other devices are configured this way. So I did a fork your work in my github account and did some changes to make it possible:
I also made few other improvements, I would like to share them with you, But I don’t have much time lately to review and discuss and open a PR, but I can try to give more priority on that if you think it worth.
About the changes to enable file configuration, basically I published all properties. That’s not the ideal, but it is working. The problem is I couldn’t find a way to identify the LG devices from the Thinq APP, so I had to add the devices using the OH UI to grab the properties and then remove them after adding the values to the things file.
Here is how the things file would look like:
Bridge lgthinq:bridge:LGAccount "LG ThinQ Account"
[ username="*****@gmail.com", password="*******", language="pt-BR", country="BR", discoveryPollingIntervalSec=-1, pollingIntervalSec=60 ] {
401 ACEscritorio "Ar Codicionado Escritório" [
device_id="ee3e7f23-dbe3-1111111111-5555555555",
model_name="RAC_123123123_WW",
model_url_info="https://objectcontent.lgthinq.com/123123wersdfg-c977-4599-aab8-888888888888?hdnts=exp=1231235281~hmac=qweasdfc106c11111111111195c16b9385c3e4d87267088888888888888888888888",
platform_type="thinq2",
device_alias="Escritório"
]
}
The only required property for the devices should be device_id, the remaining properties could be retrieved based on that. This would be my next step to improve.
See that I also added a property to configure (and disable: -1) the discovery polling interval (discoveryPollingIntervalSec), once I don’t need have the discovery running constantly as I did the configuration manually.
Thanks, Julio for your contribution. I think will help me to fit the textual configuration needs. However, as the binding is still in development, a lot of things has been changed all day. So… I think a PR at this moment will generate a lot of conflict. So… if you don’t mind, I will take a look at your codebase and “extract” de relevant configurations to my master codebase. Is it ok for you ?
Sure Nemer,
you can see my commits and try to cherrypick them or grab the changes manually.
Feel free to reach me out and discuss if required.
As I mentioned before, the only required property for the devices should be device_id, the remaining properties could be retrieved based on that.
Ideally this value should be obtainable from the Thinq App, but unfortunately it is not.
@kevin, I’m trying to organize the channels in categories and understand some definition of your washer to fit better to remote start function.
So, I saw you can choose one of the Cycles predefined for your washer in the App that are (based on your cap file): Cotton, Easy Care, Cotton+, Duvet, Mix, Sport Wear, Silent Wash, Quick 30, Tub Clean, Wool, Delicate, Allergy SpaSteam and Baby Steam Care. Is that correct ?
But, based on the WashDryer definition, there is another set of cycles, called Smart Course (or Cycle) that for your case are: Baby Care, Hygiene, Small Load, Lingerie, Skin Care and so on.
Do you know about these “Smart Courses”? Do you have access to those in the LG App ? I’m asking because based on the structure of the Remote Start command, I can send a regular cycle to run, but I can send a smart cycle as well.
I need to know about this, because I’m preparing a different channel to choose the Cycle you want to run when you send a command to start remotely. If you can choose between the Smart and Regular courses to run, then I must control it and aggregate all together in this channel.
@nemer On the front of the washer I have this - pic
I also sent you a PM
Seems ok now.
As for Channels missing:
Heat pump acts as boiler(heat) or chiller(cool) and therefore there are sensors for water circuit.
Furthermore there is a mode that you can control heat pump not with desired room temperature but with desired water temperature.
You may catch which mode is selected by “airState.miscFuncState.awhpTempSwitch” I guess.
In water mode thermostat should controlling water out temperature “airState.tempState.outWaterCurrent” I guess.
For logging reasons and also for calculating ΔΤ, Water In temperature should also be visible “airState.tempState.inWaterCurrent” I guess.
In air mode thermostat should control Room Air temperature “airState.tempState.current” I guess.
In both air/water modes it will br preffered to have all above sensors as items.
Then Heat pump can also heat DHW(domestic hot water). This function I guess is controled with “airState.miscFuncState.hotWater”
DHW target temp I guess is “airState.tempState.hotWaterTarget”
and current DHW I guess “airState.tempState.hotWaterCurrent”
Another function is silent mode, I guess this is “airState.miscFuncState.silentAWHP”
Same as for @kevin, this is what I see in my LG android app.
My washer-dryer is LG Vivace F4DV910H2.
Here is the manual
What @nemer is talking about as “smart courses” are specific customized cycles that you can download to your device from the list available in LG app. You can see this option also on the @kevin 's device photo.
By downloading this cycle you overwrite existing cycle. When you explore the cycle, you can view list of parameters that have been preconfigured for this specific type of cycle. You cannot change these settings manually.
Sorry, the parameters you can see on the last picture are in Polish, I couldn’t set it to English in the app approppriately. I guess @kevin will be able to provide full English screenshot.
Any change to get V1 Fridge working?
Have that error after auto add lgthinq things:
HANDLER_INITIALIZING_ERROR
V1_0 not supported by Fridge Thing yet
Thank you!
Can you provide me the thinq-xxxx-cap.json file from your OH3 intallation ? It’s located at $OH_USERDATA/thinq.
Currently the binding has no support for Fridge V1.0, and very simple support for V2.0. With your file, I can implement the support of it as soon as possible.
Regards.
Thank you very much. I can understand right now the mining of this 3 attributes in the API.
sure 
Thank you my friend. here is the json file.
thinq-336db190-82f2-11ec-a8e9-0051edb3bb3c-cap.json (8.7 KB)