Basic support for Hysen Heating Controller (dev type 0x4ead)

[ptd006]

Contains a new device class hysen for various Broadlink-OEM WiFi thermostats made by Xiamen Hysen Control Technology Co., Ltd. These are sold under brands including Floureon.

It now provides essentially complete support, including:

• get_temp() : get current room temperature
• set_temp(temp in degrees C) : switch to manual control and set thermostat temperature
• switch_to_auto() : switch to automatic (predefined) schedule/temperatures
• get_full_status() : get all known fields, incl. timer schedule
• set_advanced( ... ) : advanced settings
• set_time(hour,minute,second,day)
• set_schedule( ... ) : set times/temps for auto mode
• set_power : power on/off (doesn't disable WiFi) and control lock.
• set_mode : set sensor, loop mode and control mode.

Photo of device: http://peter.windridge.org.uk/playing-with-cheap-iot-devices/20171120_163450.jpg

Note that package PyCRC is used for calculating the CRC16 required in payload.

Fixes #130

[ralphm2004]

Tested with
https://www.amazon.de/FLOUREON-Heizk%C3%B6rperthermostat-Heizungsthermostat-Heizungsregelung-Programmierbar/dp/B0771MPJXK
and worked.

[serjs]

Hi!

Thank you for your work! I can confirm that changes reusable for FLOUREON thermostat, i have same as @ralphm2004 mention in his comment. Looks like this solved almost all Chinese thermostat based on Broadlink OEM-T1

I also notice that you use PyCRC (link) which is new module dependency for this project. I think that we need to add this dep as setup requirements on the road to mainstream if we really need to use CRC16

@mjg59 Can you look into this?

[ptd006]

Hi @serjs,
Thanks for testing, glad it's working!

Modbus CRC16 is required. It could be implemented as a standalone function to avoid the extra dependency. However, personally I favour keeping it as a dependency. I have added it to my setup.py in ptd006@586f17f .

The downside is people not using this thermostat may baulk at installing extra packages.

[ptd006]

N.b. I think part of the control byte in switch_to_auto (the 0x11 in input_payload) actually controls the "loop mode" (which defines whether Saturday should follow the weekend or weekday schedule). More specifically I think this byte should actually be:
`( (loop_mode + 1) << 4) + auto_mode
where

  # auto_mode = 1 for auto (scheduled/timed) mode, 0 for manual mode
  # loop_mode refers to index in [ "12345,67", "123456,7", "1234567" ] using the Android app's notation
  # E.g. loop_mode = 0 ("12345,67") means Saturday and Sunday follow the "weekend" schedule
  # loop_mode = 2 ("1234567") means every day (including Saturday and Sunday) follows the "weekday" schedule

I have not tested this properly but hope to do so next week when I will also commit code to set the timer schedule.

I hadn't noticed before because I was only using "Saturday and Sunday weekend" mode (I guess that applies for most people..)