Open no2chem opened 4 years ago
Hm, it seems like the formatter tool (black) I used to fix the flake8 errors makes it hard to compare the PRs. Maybe black should be perhaps added as a precommit hook?
@no2chem just had a play, was hoping to give this a test, unfortunately returning no devices for an Aus account - any ideas?
@no2chem just had a play, was hoping to give this a test, unfortunately returning no devices for an Aus account - any ideas?
Is there any output at all? It doesn't crash but doesn't return any devices either?
I guess it might be useful to try to add some debugging to it, maybe I'll look into adding that in a bit
@no2chem just had a play, was hoping to give this a test, unfortunately returning no devices for an Aus account - any ideas?
Is there any output at all? It doesn't crash but doesn't return any devices either?
I guess it might be useful to try to add some debugging to it, maybe I'll look into adding that in a bit
Correct; just blank - initially thought it might be the country / lang, but still nothing with it corrected - I have managed to get other PR's to list the device succesfully (but they hadn't implemented anything further).
Happy to help in testing - I'm familiar with python, and can hack stuff together, but not always in the most pretty way.
I would like to contribute at least testing it. I even don't know if here it's the right place to comment this, but I've cloned @no2chem repo and I could see both AC units (same model AC RAC_056905_WW)
2020-11-22 14:29:08 INFO [wideq.example] Session expired.
@viniciuscordeiro Thanks. I think for now, this is the right place.
Could you tell me more about your setup? Is your country code US/en-US?
@davewatson91 What devices do you have in your account?
@viniciuscordeiro Thanks. I think for now, this is the right place.
Could you tell me more about your setup? Is your country code US/en-US?
For sure. Actually my country code is BR and language pt-BR (Brazil). I've tried in a proxmox server:
`[~/wideq.no2chem]$ uname -a Linux cordeiro 5.4.65-1-pve #1 SMP PVE 5.4.65-1 (Mon, 21 Sep 2020 15:40:22 +0200) x86_64 GNU/Linux
[~/wideq.no2chem]$ ./example.py ls 2020-11-23 16:45:56 INFO [wideq.example] Session expired. _device1id: Ar Escritorio (AC RAC_056905_WW) _device2id: Ar Suite (AC RAC_056905_WW)
[~/wideq.no2chem]$ ./example.py mon _device1id off; COOL; cur 80°F; cfg 64°F; fan speed HIGH off; COOL; cur 80°F; cfg 64°F; fan speed HIGH off; COOL; cur 80°F; cfg 64°F; fan speed HIGH off; COOL; cur 80°F; cfg 64°F; fan speed HIGH `
@davewatson91 What devices do you have in your account?
@viniciuscordeiro @davewatson91 debugging through this (since you are both on non-us servers), I wonder if this has something to do with the TLSv1 issue. It seems so other forks force TLSv1. I'll try to add that as an option to see if it fixes things.
@viniciuscordeiro Thanks. I think for now, this is the right place.
Could you tell me more about your setup? Is your country code US/en-US?
@davewatson91 What devices do you have in your account?
Thanks so much for getting this going, @no2chem!! I've merged the Black changes, and I'm not sure if I've messed things up somehow, but it seems like that somehow created more conflicts than there were before? Is there any chance there's a way to disentangle the "real" changes you made here from the formatting changes so it's possible to review this diff? (Or was applying Black to the existing code a mistake that we should now back out?)
@sampsyo Yes, I think I just need to rebase this PR, which I'll do in a moment.
@sampsyo The latest force-push should get rid of the formatting diffs (thanks for merging the black PR).
I'd like to pause work until we figure out whether we need to support the v1 API still. Supporting both APIs would take us in a different path than just supporting the v2 API, I think.
Yes, that's a great question. It would obviously be much simpler if we only needed to support the new API. I don't currently know whether there is an issue with that and older devices or older setups. I seem to recall some commentary to the effect that supporting the older API is not necessary, but @craigsheppard might know more… is there any chance you could give this PR a try, @craigsheppard, and verify that all your devices still work via the v2 API?
Yes, that's a great question. It would obviously be much simpler if we only needed to support the new API. I don't currently know whether there is an issue with that and older devices or older setups. I seem to recall some commentary to the effect that supporting the older API is not necessary, but @craigsheppard might know more… is there any chance you could give this PR a try, @craigsheppard, and verify that all your devices still work via the v2 API?
Hi, I was speaking from a place of ignorance - I just assumed v1 devices would not be available. I'll see if I can get this tested with my devices today.
Awesome; thank you so much for looking into it!
I just tested the @no2chem thinq2
branch with no changes, and I can confirm I am still able to list my v1-API device.
I'm unable to control the device, there's a KeyError
for airState.operation
(line 321 of ac.py
):
/wideq/venv/lib/python3.8/site-packages/urllib3/connectionpool.py:1013: InsecureRequestWarning: Unverified HTTPS request is being made to host 'aic.lgthinq.com'. Adding certificate verification is strongly advised. See: https://urllib3.readthedocs.io/en/latest/advanced-usage.html#ssl-warnings
warnings.warn(
Traceback (most recent call last):
File "/wideq/example.py", line 335, in <module>
main()
File "/wideq/example.py", line 331, in main
example(args.country, args.language, args.verbose, args.cmd, args.args)
File "/wideq/example.py", line 259, in example
example_command(client, cmd, args)
File "/wideq/example.py", line 226, in example_command
func(client, *args)
File "/wideq/example.py", line 189, in turn
ac.set_on(on_off == "on")
File "/wideq/wideq/ac.py", line 321, in set_on
op_value = self.model.enum_value("airState.operation", op.value)
File "/wideq/wideq/client.py", line 370, in enum_value
options = self.value(key).options
File "/wideq/wideq/client.py", line 341, in value
d = self.data["Value"][name]
KeyError: 'airState.operation'
Aside: I'm not currently able to see my v2 device, however at the moment it's a hardware issue (I deleted my LG account and created a new one, and during the setup process, my v2 device has gone into a mode where I can't connect to it with the LG app - flashing WiFi light and no AP advertised). Looks like I might be able to reset it by turning the power off for a while, but it's hardwired so maybe tomorrow - but I don't believe you need me to test both.
I just cloned https://github.com/tinkerborg/thinq2-python and my v1 device is not showing up in the list, so perhaps we need to support both APIs?
Oh wow, that's quite confusing!! I wonder what's going on here… I guess it's not surprising that this current branch would crash, but I wonder why @tinkerborg's implementation would not list your device. Mysterious…
@tinkerborg's is v2-only - perhaps my device is stuck in v1 land?
Isn't this @no2chem branch currently supporting both, which explains why I can list it?
@craigsheppard No, the branch currently doesn't support controlling v1 devices. I mainly focused on attempting to produce the minimal changeset to support v2 devices.
I guess one of the reasons for the differences is probably that I get the device list using the old api (via the dashboard) whereas @tinkerborg may be using the v2 enumeration api.
This is too bad... I wonder if you re-pair a v1 device if it'll end up showing as a v2 device? Sort of strange for LG to have a backend the differentiates between the devices.
Real weird. Could we jettison most of the v1 API but just keep around enough to list the devices?
@sampsyo It seems like the v1 API is required to control the v1 devices though.
There is a platformType entry in the json from the device list which seems to list whether the device should use the v1 API or v2 API. Notably, the v2 API has different keys for data and a different mechanism (MQTT) for monitoring devices in real time.
"platformType":"thinq2",
I'll add a quick patch that will at list display that.... I suspect we can keep the v2 login mechanism, but we'll have to check the platformType to determine whether to control a device as v1 or v2.
Of course, if deleting a device and readding it resurrects it as a v2 device, that would be ideal.
@craigsheppard (or anyone else with a v1 device). If you could run ls with the update I just pushed (removing your device ids), I'd appreciate it...
It should produce output like:
...: Dishwasher (DISHWASHER D3210 / thinq2)
...: AC (AC RAC_056905_WW / thinq2)
@viniciuscordeiro Thanks. I think for now, this is the right place. Could you tell me more about your setup? Is your country code US/en-US?
For sure. Actually my country code is BR and language pt-BR (Brazil). I've tried in a proxmox server:
`[~/wideq.no2chem]$ uname -a Linux cordeiro 5.4.65-1-pve #1 SMP PVE 5.4.65-1 (Mon, 21 Sep 2020 15:40:22 +0200) x86_64 GNU/Linux
[~/wideq.no2chem]$ ./example.py ls 2020-11-23 16:45:56 INFO [wideq.example] Session expired. _device1id: Ar Escritorio (AC RAC_056905_WW) _device2id: Ar Suite (AC RAC_056905_WW)
[~/wideq.no2chem]$ ./example.py mon _device1id off; COOL; cur 80°F; cfg 64°F; fan speed HIGH off; COOL; cur 80°F; cfg 64°F; fan speed HIGH off; COOL; cur 80°F; cfg 64°F; fan speed HIGH off; COOL; cur 80°F; cfg 64°F; fan speed HIGH `
@davewatson91 What devices do you have in your account?
Just to contribute, Im from Brazil and have the same output like @viniciuscordeiro country code BR/pt-BR
"mon" is working fine:
on; COOL; cur 77°F; cfg 70°F; fan speed LOW on; COOL; cur 77°F; cfg 74°F; fan speed LOW on; COOL; cur 77°F; cfg 74°F; fan speed LOW on; AI; cur 77°F; cfg 62°F; fan speed LOW on; AI; cur 77°F; cfg 62°F; fan speed LOW on; DRY; cur 77°F; cfg 76°F; fan speed LOW on; FAN; cur 77°F; cfg 76°F; fan speed HIGH on; FAN; cur 77°F; cfg 76°F; fan speed HIGH on; FAN; cur 77°F; cfg 76°F; fan speed HIGH on; FAN; cur 77°F; cfg 76°F; fan speed HIGH
"turn" and "set-temp" INFO [wideq.example] Session expired.
Please let me know if you need help testing. I have a mixed thinq_1 and thinq_2 devices: .. Sala (AC RAC_056905_WW / thinq1) .. Cuarto principal (AC RAC_056905_WW / thinq1) .. Cuarto de Dani (AC RAC_056905_WW / thinq1) .. Oficina (AC RAC_056905_WW / thinq1) .. Cocina (AC RAC_056905_WW / thinq1) .. Cuarto de Santiago (AC RAC_056905_WW / thinq2)
v1 devices non of the functions work. I can monitor thinq2 device.
If LG made a V2 API, you may consider to split also and made a V2 wideq libreary ? I use wideq for a jeedom plugin (jeedom is a french php home assistant soft), and of course, if no other solution works, I will develop a V2 version of the plugin with your V2 wideq lib using the V2 api :) I mean, you should keep V1 API working as long as possible no?
For me the @gladhorn fork works with the ls
command. However when trying to do something else that gives an error.
Traceback (most recent call last):
File "example.py", line 271, in <module>
main()
File "example.py", line 267, in main
example(args.country, args.language, args.cmd, args.args)
File "example.py", line 227, in example
example_command(client, cmd, args)
File "example.py", line 203, in example_command
func(client, *args)
File "example.py", line 117, in ac_mon
ac.monitor_start()
File "/root/wideq/wideq/client.py", line 455, in monitor_start
mon.start()
File "/root/wideq/wideq/client.py", line 33, in start
self.work_id = self.session.monitor_start(self.device_id)
File "/root/wideq/wideq/core_v2.py", line 305, in monitor_start
'workId': gen_uuid(),
File "/root/wideq/wideq/core_v2.py", line 277, in post
return lgedm_post(url, data, self.auth.access_token, self.session_id)
NameError: name 'lgedm_post' is not defined
With this fork I get no output.
This fork:
# python3 example.py ls --verbose
2020-12-12 20:26:08 DEBUG [wideq.example] State file found '/root/wideq/wideq_state.json'
2020-12-12 20:26:08 DEBUG [wideq.example] State file found '/root/wideq/wideq_state.json'
2020-12-12 20:26:10 DEBUG [wideq.example] Wrote state file '/root/wideq/wideq_state.json'
2020-12-12 20:26:10 DEBUG [wideq.example] Wrote state file '/root/wideq/wideq_state.json'
@gladhorn
# python3 example.py
7dd2abad-XXXX-1ed8-ba07-XXXXX: Airco Woonkamer (AC RAC_056905_WW)
8c3fc27e-XXXX-1915-809a-XXXXX: Airco Zolder (AC RAC_056905_WW)
I have the same as @ronaldvdmeer:
This branch:
./example.py ls
./example.py ls --verbose
2020-12-18 20:47:12 DEBUG [wideq.example] State file found '/wideq/wideq-master/wideq_state.json'
2020-12-18 20:47:12 DEBUG [wideq.example] State file found '/wideq/wideq-master/wideq_state.json'
2020-12-18 20:47:12 DEBUG [wideq.example] Wrote state file '/wideq/wideq-master/wideq_state.json'
2020-12-18 20:47:12 DEBUG [wideq.example] Wrote state file '/wideq/wideq-master/wideq_state.json'
While @gladhorn:
./example.py ls
Session expired.
device_id1: Washer (WASHER F_R7_Y___W.A__QEUK)
device_id2: Refrigerator (REFRIGERATOR 2RES1VE600FWC)
device_id3: Dryer (DRYER RC90V9_WW)
However, I cannot list anything with @gladhorn:
./example.py mon device_id1/2/3
Traceback (most recent call last):
File "./example.py", line 237, in <module>
main()
File "./example.py", line 233, in main
example(args.country, args.language, args.cmd, args.args)
File "./example.py", line 193, in example
example_command(client, cmd, args)
File "./example.py", line 169, in example_command
func(client, *args)
File "./example.py", line 40, in mon
with wideq.Monitor(client.session, device_id) as mon:
File "/wideq/wideq-api2_rebased/wideq/client.py", line 66, in __enter__
self.start()
File "/wideq/wideq-api2_rebased/wideq/client.py", line 33, in start
self.work_id = self.session.monitor_start(self.device_id)
File "/wideq/wideq-api2_rebased/wideq/core_v2.py", line 305, in monitor_start
'workId': gen_uuid(),
File "/wideq/wideq-api2_rebased/wideq/core_v2.py", line 277, in post
return lgedm_post(url, data, self.auth.access_token, self.session_id)
NameError: name 'lgedm_post' is not defined
#
@viniciuscordeiro Thanks. I think for now, this is the right place. Could you tell me more about your setup? Is your country code US/en-US?
For sure. Actually my country code is BR and language pt-BR (Brazil). I've tried in a proxmox server:
[~/wideq.no2chem]$ uname -a Linux cordeiro 5.4.65-1-pve #1 SMP PVE 5.4.65-1 (Mon, 21 Sep 2020 15:40:22 +0200) x86_64 GNU/Linux [~/wideq.no2chem]$ ./example.py ls 2020-11-23 16:45:56 INFO [wideq.example] Session expired. _device1_id_: Ar Escritorio (AC RAC_056905_WW) _device2_id_: Ar Suite (AC RAC_056905_WW) [~/wideq.no2chem]$ ./example.py mon _device1_id_ off; COOL; cur 80°F; cfg 64°F; fan speed HIGH off; COOL; cur 80°F; cfg 64°F; fan speed HIGH off; COOL; cur 80°F; cfg 64°F; fan speed HIGH off; COOL; cur 80°F; cfg 64°F; fan speed HIGH
@davewatson91 What devices do you have in your account?
Just to contribute, Im from Brazil and have the same output like @viniciuscordeiro country code BR/pt-BR
"mon" is working fine:
on; COOL; cur 77°F; cfg 70°F; fan speed LOW on; COOL; cur 77°F; cfg 74°F; fan speed LOW on; COOL; cur 77°F; cfg 74°F; fan speed LOW on; AI; cur 77°F; cfg 62°F; fan speed LOW on; AI; cur 77°F; cfg 62°F; fan speed LOW on; DRY; cur 77°F; cfg 76°F; fan speed LOW on; FAN; cur 77°F; cfg 76°F; fan speed HIGH on; FAN; cur 77°F; cfg 76°F; fan speed HIGH on; FAN; cur 77°F; cfg 76°F; fan speed HIGH on; FAN; cur 77°F; cfg 76°F; fan speed HIGH
"turn" and "set-temp" INFO [wideq.example] Session expired.
It's because there is an error in Session.post function of core.py. The code call thinq_request without pass the country and language, and because this, its assumes the default country (US/en). The Session.get function is correct, then the operations like "mon" gonna work in Brazil and other countries.
Changing the post function to:
def post(self, path, data=None):
"""Make a POST request to the API server.
This is like `lgedm_post`, but it pulls the context for the
request from an active Session.
"""
url = urljoin(self.auth.gateway.api_root + "/", path)
return thinq_request(
RequestMethod.POST,
url,
data,
access_token=self.auth.access_token,
user_number=self.auth.user_number,
country=self.auth.gateway.country,
language=self.auth.gateway.language,
)
will fix the issue.
@viniciuscordeiro Thanks. I think for now, this is the right place. Could you tell me more about your setup? Is your country code US/en-US?
For sure. Actually my country code is BR and language pt-BR (Brazil). I've tried in a proxmox server:
[~/wideq.no2chem]$ uname -a Linux cordeiro 5.4.65-1-pve #1 SMP PVE 5.4.65-1 (Mon, 21 Sep 2020 15:40:22 +0200) x86_64 GNU/Linux [~/wideq.no2chem]$ ./example.py ls 2020-11-23 16:45:56 INFO [wideq.example] Session expired. _device1_id_: Ar Escritorio (AC RAC_056905_WW) _device2_id_: Ar Suite (AC RAC_056905_WW) [~/wideq.no2chem]$ ./example.py mon _device1_id_ off; COOL; cur 80°F; cfg 64°F; fan speed HIGH off; COOL; cur 80°F; cfg 64°F; fan speed HIGH off; COOL; cur 80°F; cfg 64°F; fan speed HIGH off; COOL; cur 80°F; cfg 64°F; fan speed HIGH
@davewatson91 What devices do you have in your account?
Just to contribute, Im from Brazil and have the same output like @viniciuscordeiro country code BR/pt-BR "mon" is working fine: on; COOL; cur 77°F; cfg 70°F; fan speed LOW on; COOL; cur 77°F; cfg 74°F; fan speed LOW on; COOL; cur 77°F; cfg 74°F; fan speed LOW on; AI; cur 77°F; cfg 62°F; fan speed LOW on; AI; cur 77°F; cfg 62°F; fan speed LOW on; DRY; cur 77°F; cfg 76°F; fan speed LOW on; FAN; cur 77°F; cfg 76°F; fan speed HIGH on; FAN; cur 77°F; cfg 76°F; fan speed HIGH on; FAN; cur 77°F; cfg 76°F; fan speed HIGH on; FAN; cur 77°F; cfg 76°F; fan speed HIGH "turn" and "set-temp" INFO [wideq.example] Session expired.
It's because there is an error in Session.post function of core.py. The code call thinq_request without pass the country and language, and because this, its assumes the default country (US/en). The Session.get function is correct, then the operations like "mon" gonna work in Brazil and other countries.
Changing the post function to:
def post(self, path, data=None): """Make a POST request to the API server. This is like `lgedm_post`, but it pulls the context for the request from an active Session. """ url = urljoin(self.auth.gateway.api_root + "/", path) return thinq_request( RequestMethod.POST, url, data, access_token=self.auth.access_token, user_number=self.auth.user_number, country=self.auth.gateway.country, language=self.auth.gateway.language, )
will fix the issue.
@nemerdaud I just tested your suggestion and is working flawlessly. I can turn on and set-temp just like normal!
THANK YOU!
@no2chem You know if is a command to change to working type (fan, cool, dry, ai) and the fan speed/orientation ?
Hi all, sorry, end of the year deadlines really kept me from doing anything.
@pifou25
I mean, you should keep V1 API working as long as possible no?
Yes, it seems like we will need to do that
@nemerdaud
Thanks, will fix that
@R00G3R
Yeah, are you using it with HA? I think the fan control works. Otherwise we will have to update example.py to control those functions.
Hi all, sorry, end of the year deadlines really kept me from doing anything.
@pifou25
I mean, you should keep V1 API working as long as possible no?
Yes, it seems like we will need to do that
@nemerdaud
Thanks, will fix that
@R00G3R
Yeah, are you using it with HA? I think the fan control works. Otherwise we will have to update example.py to control those functions.
Hi guys,
@nemerdaud PERFECT!!!! Thank you so much! Will you push this to repository?
@R00G3R and @no2chem did you try it with smarthinq-sensors? I saw that wideq's directory files are different and I'm afraid to break HA setup...
@R00G3R are you on telegram's Brazilian group? my username is the same as here...
Hi all, sorry, end of the year deadlines really kept me from doing anything. @pifou25
I mean, you should keep V1 API working as long as possible no?
Yes, it seems like we will need to do that @nemerdaud Thanks, will fix that @R00G3R Yeah, are you using it with HA? I think the fan control works. Otherwise we will have to update example.py to control those functions.
Hi guys,
@nemerdaud PERFECT!!!! Thank you so much! Will you push this to repository?
@R00G3R and @no2chem did you try it with smarthinq-sensors? I saw that wideq's directory files are different and I'm afraid to break HA setup...
@R00G3R are you on telegram's Brazilian group? my username is the same as here...
@viniciuscordeiro, I don't think I have permissions to do that in this repo. But, @no2chem said he will fix it.
smarthinq-sensors
@viniciuscordeiro Yeah, I already tried smarthinq-sensors, but with no luck, no device is found. I have tried @no2chem smarthinq-sensors fork (https://github.com/no2chem/hass-smartthinq/tree/thinqv2) but HA pull another version of wideq from pip and broke inicial setup.
Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/setup.py", line 213, in _async_setup_component result = await task File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run result = self.fn(*self.args, **self.kwargs) File "/config/custom_components/smartthinq/init.py", line 79, in setup client = wideq.Client.load(state) File "/usr/local/lib/python3.8/site-packages/wideq/client.py", line 148, in load client._gateway = core.Gateway.deserialize(state['gateway']) File "/usr/local/lib/python3.8/site-packages/wideq/core.py", line 337, in deserialize return cls(data['auth_base'], data['api_root'], data['oauth_root'], KeyError: 'oauth_root'
Im new to HA comunity, you can send me the link for telegram group? thank you
smarthinq-sensors
@viniciuscordeiro Yeah, I already tried smarthinq-sensors, but with no luck, no device is found. I have tried @no2chem smarthinq-sensors fork (https://github.com/no2chem/hass-smartthinq/tree/thinqv2) but HA pull another version of wideq from pip and broke inicial setup.
Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/setup.py", line 213, in _async_setup_component result = await task File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run result = self.fn(*self.args, self.kwargs) File "/config/custom_components/smartthinq/init**.py", line 79, in setup client = wideq.Client.load(state) File "/usr/local/lib/python3.8/site-packages/wideq/client.py", line 148, in load client._gateway = core.Gateway.deserialize(state['gateway']) File "/usr/local/lib/python3.8/site-packages/wideq/core.py", line 337, in deserialize return cls(data['auth_base'], data['api_root'], data['oauth_root'], KeyError: 'oauth_root'
Im new to HA comunity, you can send me the link for telegram group? thank you
@R00G3R i've tried just replacing files, I could integrate again on HA but didn't show my ACs...
Use this link: https://t.me/HomeAssistantbrasil and we can chat there.
I've made the change suggested by @nemerdaud https://github.com/puffnfresh/wideq/commit/87822a5d7cc86510c7759fd40a1257fcff209957. I then had to make two manual changes in my state file to get the example.py
working:
- https://us.m.lgaccount.com
+ https://au.m.lgaccount.com
- https://aic-service.lgthinq.com:46030/v1
+ https://kic-service.lgthinq.com:46030/v1
Seems very similar to the original problem in https://github.com/sampsyo/wideq/issues/55.
This makes the example work, but the Home Assistant component doesn't work for me.
I've made the change suggested by @nemerdaud puffnfresh@87822a5. I then had to make two manual changes in my state file to get the
example.py
working:- https://us.m.lgaccount.com + https://au.m.lgaccount.com - https://aic-service.lgthinq.com:46030/v1 + https://kic-service.lgthinq.com:46030/v1
Seems very similar to the original problem in #55.
This makes the example work, but the Home Assistant component doesn't work for me.
Can confirm the same changes work for me too - haven't tried integration into HA, however straight from Python all appears working (albeit with the workarounds from @nemerdaud & @puffnfresh).
Hello,
is there any progress regarding the wideq for APIv2? I tested the current wideq and not able of listing the devices.
I've opened a PR ( https://github.com/no2chem/wideq/pull/1 ) with some fixes that made it work with my AC and Washer/Dryer
@marciogranzotto (above) has another fork which has all-but resolved this.
marciogranzotto/hass-smartthinq
Not sure if we can get it back in here as a PR?
It still needs some work (took me some modifications to get it running with my ducted AC), but it does work, and has a nice flow into HA.
A PR would be awesome if someone can put it together!
Hi all, sorry, I've merged it and currently have some time to push things through to get everything working...
It would be awesome if this PR were merged. What is missing for it to be able to be merged?
After it looked like #100 was in limbo for awhile, I started some work on getting v2 devices working. I only have v2 devices in my home, so it was hard for me to test anything with v1. This PR makes v2 work to make basic queries and control at least the AC unit I have (LA090HSV5), but it also breaks v1 support in the process. I don't think it would be that much work to make v1 and v2 work at the same time, but just haven't had time for it, so I've labeled it WIP. One question is whether v1 devices can run on the v2 api, thus obviating the need to continue supporting the v1 API.
I will disclaim that I'm not really a python expert, so the code is likely not idiomatic python.
The v2 API introduces some considerable changes, I've discovered:
a user number is used in place of a session (the OAuth token remains). The user number is important, because thinq now allows you to control devices that have been shared with you.
while this patch still uses the dashboard view, devices are now organized into homes, and I think you can have multiple homes.
the query APIs have mostly disappeared. the main method of getting data is through snapshots, which you get by polling the dashboard/home. I guess this will require some refactoring of how the
Monitor
works. I sort of hacked around it and just had it pull the entire dashboard, but this seems like it'll result in excessive requests. A caching and timeout mechanism are probably required.it looks like the app has mainly adopted a push notification mechanism via MQTT, so, that should be used instead. To get the MQTT endpoint, which is hosted on amazon, it looks like you have to generate a CSR to send to the API server, which will return a client certificate you're supposed to use to login to the endpoint.
the API errors are definitely different. I have a mapping for those errors and I will add them...
addresses #108