Added functionality in the pure hot plus cool link

[soraxas]

Including turning heat mode on/off, setting the target temperature, and set the stream of wind focus or wide spread.

Also fixed several issues in sensor returning string "OFF" but the original code casting it to int, which causes exception thrown. Added checking for it.

This was tested in a pure hot plus cool link ONLY. Not sure if the added functionality and messages will affect the communication with pure cool link or not. It might be better to separate the two devices in the future.

[CharlesBlonde]

Thanks a lot! I haven't any heating device and it was one of my goal to add this feature so I appreciate a lot your PR. I haven't test yet with my devices but I guess it will break for non heating device (unit tests are broken). So we'll have to be able to do it working in the same time for heating and non heating device. Thanks to your PR, I think I know now what are the dedicated heating parameters (hmod, hsta, etc ...). I'll work on it this WE but I'll need your help to validate.

Besides, It is not yet documented but I'm using tox to validate unit tests and code analysis.

[soraxas]

No worries man, yea for sure probably we will need to validate the device by its device code before sending the parameters, so that both devices could work at the same time (and sending correct parameters for the specific device).

For your information, the string repr for my device are as follow: DysonDevice(__SERIAL-CODE__,True,Pure Hot+Cool,21.03.08,True,False,455, NetworkDevice(__SERIAL-CODE__,__IP-ADDRESS__))

where I believe 455 is the product code for pure hot+cool, and 475 is the one used for pure cool (from what I have gathered around from elsewhere).

And yes for sure let me know when you need to validate anything. Cheers.

[coveralls]

Coverage increased (+0.6%) to 97.079% when pulling dd1aa90e72f29962dc16b9b8c488f3b3f6f12fc2 on soraxas:master into a2b4ae6dfc796fa757e7f7b65dbf36a9817d9c65 on CharlesBlonde:master.

[CharlesBlonde]

Hi @soraxas ,

I did some changes in order to:

• Fix broken behavior with non heating devices
• Fix Travis build (lint can be quite painful ...). Be careful, I rename CELSIUS method to celsius because method in uppercase doesn't follow Python best practices and Lint doesn't like it :)
• Add unit tests
• Add an helper method to convert Fahrenheit to Kelvin (like you did for Celsius)
• Refactor string representations methods (__repr__(self)). It has nothing to do with this PR but it was useful for debugging

Can you validate it is still working with an heating device ?

Besides, for my unit tests I created a fake json state message. As I don't know what are possibles values, can you replace them with valid values (starting from https://github.com/soraxas/libpurecoollink/blob/master/tests/data/state_hot.json#L19). If you are changing values, it will break this test https://github.com/soraxas/libpurecoollink/blob/master/tests/test_libpurecoollink.py#L702 so you can update the assertions too or I will fix them after.

I'm waiting for your feedback before merging this PR.

[soraxas]

Hey @CharlesBlonde thanks for your last commit they works wonderfully :) And sorry for late reply, only got time yesterday for testing.

I have confirmed that it still work physically with a heating device. I have added a few const values and changed the unit test to valid values. I have also done some extensive testing on the behaviour of the new states and will document them below.

For the pure hot plus cool link, there are three states that the device would response to by the "STATE-SET" message. There are also two additional states that indicates the device status.

Set-able state:

• hmod: controls heat mode on/off of the device. It has two possible value of HEAT,OFF. The former will turn on the heating mode and the latter will turn it off.
• ffoc: controls the focus mode on/off of the device. It has two possible value of ON,OFF. It controls the stream of air flow being focused or diffused. They are the two buttons at the bottom of this image.
• hmax: controls the temperature of the heating mode. It has a range of possible number from 2736 to 3102 inclusive (They are obtained experimentally, I don't know why the randomness of the last digit). They are temperature in kelvin and the last digit is the first decimal place (i.e. temperature in kelvin times 10). Therefore, 2740 represents 274K -> 1 Celsius. The possible temperature set-able from app or remote are 2740 to 3100 inclusive (1 Celsius to 37 Celsius) with an increment by 10. However, it is possible to set the temperature with a decimal place by altering the mqtt request, where the display on the device will display the temperater by rounding it. For example, sending 2934 will render the number 20 on the physical device (since 2934 -> 20.4 C) and sending 2935 will render the number 21 on the physical device (since 2935 -> 20.5 C). This indicates it will round down or up depending on the decimal place. Note that if a using a remote to send command will always reset the hmax's last digit to zero (e.g. pressing the increase temperature button when hmax=2935 will result in hmax=2950). Last but not least, sending hmax=0 will result in temperature being set at hmax=2736 (probably the lowest possible value for the heating parameter) and sending hmax=5000 will result in temperature being set at hmax=3102 (probably the highest possible value for the heating parameter)

Recieve-able state

• hmod: see above
• ffoc: see above
• hmax: see above
• hsta: The difference between this and hmod is that this indicates if the device is actually heating. When turned on heating mode, both hmod=HEAT and hsta=HEAT. If the room temperature reaches the target temperature, hmod will remains being hmod=HEAT but hsta will becomes hsta=OFF and the device will stop heating up (until the room temperature drops again and it will start back up).
• tilt: This indicates if the device is tilted. I wasn't sure what this means before, but after trial and error this appears to represents if the device is currently laying horizontally or not (probably for checking if the device had been knocked down accidentally). If it is standing straight in normal position, tilt=OK. But when I lay the device horizontally (so the fan is facing ceiling/floor), the state will becomes tilt=TILT and the physical device will shut itself down immediately. I guess the tilt sensor was added to heating device because of the potential danger of a knocked down and tilted device over-heating the ground/carpet? Eitherway, this sensor will triggers when the physical device is tilt and when it does it always shuts down regardless of heat mode being on or off. Probably act as a safe measure.

Feel free to use the wordings if you want to documentation it in the wiki. Let me know if you need further testing or clarification. P.S. I only just noticed a few days ago that you've implemented this lib for usage in homeassistant, love it :)

[CharlesBlonde]

Thank you so much for this PR !

I was thinking about buying an Cool+Hot device, do all the development work and then send back device to have a refund. I don't need to do this anymore thanks to your wonderful work !

And your documentation is perfect. The bad news, for me, is that I'll have now to document all the other fields as you did in order to have a technical comprehensive documentation ! No more excuse :)

And yes, the main goal for this library was to be able to create an Home Assistant component. There is still a lot of features to add (heating for example) but the first version is working quite fine, at least for me.

I'll resolve conflicts (it was expected) and merge this PR this week-end.

[soraxas]

Thank you for your kind words! Haha I am amused by your dedications and enthusiasm for preparing to go through all that to support a device :)

Much appreciated your work! Cheers

[coveralls]

Coverage increased (+0.6%) to 97.149% when pulling 014ed99e8fabfbee1a42556231f54bbadce4a159 on soraxas:master into 90662c70f5ffb9811265c336a8d4010844c1b240 on CharlesBlonde:master.