Hi @sampsyo!
Thanks for the work on the SmartThinq API. The library doesn't seem to currently work on the v2 API, and until it does, I suggest this small change to the readme so that people aren't creating issues or are confused as to why it doesn't work for them. I was confused for a little bit until I went through the issue tracker to figure out why I wasn't getting any devices.
Of course, happy to help get v2 on track.
Jet mode functionality seems to be known by different name at different models of AC
On my AC it is known as Himalayas mode
Please Add Ankush Dua to Contributors list
Jet mode functionality seems to be known by different name at different models of AC
On my AC it is known as Himalayas mode
Please Add Ankush Dua to Contributors list
Jet mode functionality seems to be known by different name at different models of AC
On my AC it is known as Himalayas mode
Please Add Ankush Dua to Contributors list
This fixes#83 - I have the same LP1419IVSM Air Conditioner model, and it causes an error when turning on using wideq.
I've updated the ACDevice class with two new @properties, which are the list of Operations the device supports, and the best-supported ON operation from that list.
This makes the presumption that if the model reports ALL_ON as available, that it is appropriate to use (as the existing code did), but if ALL_ON is not supported by the particular model, it will fall back to using whichever ON Operation it reports as supporting. In the case of the LP1419, that will be RIGHT_ON.
Additionally, as a backstop, this will raise an error if ALL_ON is not supported but there are still more than one supported ON operation - from reading issues I haven't been able to find any evidence that such a device exists, but if one should pop up it'll likely need handling in some creative way.
These new values are now also reported in the ac-config subcommand of example.py.
Finally, this updates the set_on method to use the resultant operation name. This now means that example.py set [id] on works for my air conditioner again, and just in time for the warmer weather!
My refrigerator (LFXS28566D) supports the three added options as part of it's "smart grid" functionality. None of the initial three options were in my fridge, so I figure they are mutually exclusive modes (although OFF and SMART_GRID_OFF are similar, as is CUSTOM and SMART_GRID_CUSTOM).
As best I can tell, SMART_GRID_OFF is for when the smart grid feature is disabled overall, SMART_GRID_DEMAND_RESPONSE is something certain power companies can do to tell the fridge not to defrost when the power grid is stressed (I cannot test as I am ineligible), and SMART_GRID_CUSTOM is used whenever the button on the fridge is pushed or "Seasonal Energy Saver" is enabled in the app.
For reference, here is an excerpt from my model's JSON dump:
```json5
{
...
"SmartSavingMode": {
"type": "Enum",
"default": "0",
"option": {
"0": "@CP_OFF_EN_W",
"2": "@RE_TERM_DELAY_DEFROST_CAPABILITY_W",
"3": "@RE_TERM_DEMAND_RESPONSE_FUNCTIONALITY_W"
}
}
...
}
```
Instead of using print, let's use Python's logging framework. That
allows switching verbosity easily and filtering out unwanted messages.
Some of the setup code is inspired by what Home Assistant does.
The only instance where this is used is a comment,
see issue #62. For now it will just be ignored. The comment seems to
contain several times.
Fixes#62
