#pyhvac

THIS IS WORK IN PROGRESS

LG is not tested. "auto" mode for Sharp J-Tech is flaky

Although most of the devices associated with IRremoteESP8266 seems to produce reasonable
output, this has, obviously, not been checked.


pyhvac is a Python 3 library/utility to generate IR code for A/C device.


This library uses code/work from:
 - Scott Kyle https://gist.github.com/appden/42d5272bf128125b019c45bc2ed3311f
 - mat_fr     https://www.instructables.com/id/Reverse-engineering-of-an-Air-Conditioning-control/
 - user two, mathieu, vincent https://www.analysir.com/blog/2014/12/27/reverse-engineering-panasonic-ac-infrared-protocol/
 - all the people who contributed to https://github.com/crankyoldgit/IRremoteESP8266

# Installation

We are on PyPi so

     pip3 install pyhvac
     or
     python3 -m pip install pyhvac

     After installation, the utility

     gaccode, gcpanasonic, gcdaikin, gclg, gcsharp

     can be used to generate codes. Use the -h option for help.

     Note that the utilities cannot fully excercise all the capabilities of their respective plugin.
     For instance, the code for a Sharp A/C can depend on the state of the device. gcsharp does not keep track of the
     state of the device.

# Library

pyhvac uses plugin to add support.

Each plugin file must have a

       PluginObject

class that must have a "get_device" method to return HVAC objects, a 'brand' attribute
and a 'models' attribute containing a dictionary matching models to objects. Note that brand and models MUST BE lowercased.

Each HVAC object describes a specific way of generating codes for IR transmission.

The codes should be returned as a list of bytes in either lsb or msb format. The
HVAC object must have its "is_msb" attribute set to False or True accordingly.

All HVAC objects are required to have at the minimum 2 capabilities:

    mode   with at least "off" and another value ("auto", "cool", ....)
    temperature  with the accepted range

Other capabilities are expected.

To simplify things, it is requested that some sort of normalization
of function names occur. In most cases an AC unit will have the following

    mode: the operating mode. Values are expected to be amongst
          "off"   turned off (This is mandatory)
          "auto"  automatic mode sometines known as "feel", "ai", ...
          "cool"  Cooling
          "heat"  Heating
          "dry"   dehumidifying
          "fan"   fan mode only

    temperature:  The full range of temperatures. If there
                  are 2 distinct ranges for cooling or heating,
                  the union should be used here.

                  The attribute 'temperature_step' can be used to
                  specify fractioanl temperature e.g. 0.5, 0.1


    fan: The air flow power. Values are expecterd to be amongst
           "auto"   Automatic mode
           lowest   The lowest air flow setting
           low
           medium
           high
           highest

           When there are only 3 modes, highest, medium and lowest should be used if possible

    swing: The use of the vertical orientation of the air flow..
            It can be a switch on/off (values 'off' and 'on') or more complex

            auto  automatic (in many cases similar to the on/off switch function)
            ceiling up up up
            90°    Horizontal orientation
            60°
            45°
            30°
            0°     Vertical orientation

Many other functions are possible, but still some canonization is recommended.

For instance, many manufactures trademarked their air purifying technology: nanoe, nanoex (Panasonic),
plasmacluster (Sharp), plasma (LG).... In this case it is recommended to use the name "purifier" for that functionm


The HVAC object offers to convenience methods:
       to_lirs, to transform the frames into lirc codes
       to_broadlink, to trnaform the frames into Broadlink compatible codes

TO BE CONTINUED
