v0.4.2

Release 0.4.2: support configuring various air-Q options.

Previously, aioairq allowed only to query the device.
In this release Alexander Münch, @theHacker, introduced both the generic
mechanism to POST various setting commands to the air-Q as well as a
number of specific class methods to control LED themes, time servers,
night mode, etc.

Features:
- Add support to configure night mode
- Add support to configure the time server
- Add support to disable/enable the "cloudRemote" setting
- Add support for changing the interface configuration (static setup vs. DHCP)
- Add support for LED themes
- Add blink(), restart() and shutdown()
- Add ruff, codespell, yamllint

Fixes:
- Handle appropriately a refused API access, to account for the
latest firmware restriction to air-Q Science

v0.3.2

Release 0.3.2: remove IP / mDNS validation

Original design relied on aioairq.AirQ.__init__ checking if the input was a valid IP address or an mDNS of a very specific structure, and raising an InvalidInput otherwise.
Now, aioairq==0.3.2 removes said check completely following a user's request to allow arbitrary host name and DNS entries. In the config flow, "cannot_connect" covers the cases of misspelled or erroneous inputs now, which previously were covered by a dedicated "invalid_input".

v0.3.1

Release 0.3.1: clip_negative_values and get_latest_data

get_latest_data implements a convenient public call to fetch from
either "data" or "average" route, as well as allowing to conveniently
toggle negative value clipping (default) and dropping of uncertainties
(default)

v0.3.0

Closer to Home Assistant and more disciplined about exceptions

• dedicated submodule for exceptions (still exposed at module level through
  aioairq.__all__)

• core.DeviceInfo:

  • breaking: room_type -> suggested_area to further consistency with Home Assistant
  • all fields, except for id are optional (much like with
    homeassistant.helpers.entity.DeviceInfo)

• core.AirQ.get:

  • limited to an explicit set of queries / webserver routes
    (namely AirQ._supported_routes = ["log", "config", "data", "average", "ping"]).
    Other routes return objects with different structure, which aren't consistent
    with the current decoding steps
  • Error handling for JSONDecodeError and KeyError, which ought not to happen
    with the aforementioned routes (added as a precaution against unexpected firmware
    behaviour)

• encrypt.AESCipher:

  • failed authentication is now inferred as close to the point of failure as possible.
    The success or failure of the authentication is based on the ability to decode
    the response from the device, thus the error InvalidAuth is raised
    in AESCipher.decode

v0.2.0

• Breaking changes:
  • AirQ constructor requires an aiohttp.ClientSession
    This session is to be used for all requests during the lifetime of the
    object.
  • .test_authentication() -> bool => .validate() -> None
    Instead of returning False the new method raises InvalidAuth
  • .drop_errors_from_data => .drop_uncertainties_from_data
    To avoid ambiguity
• Features:
  • AirQ provides fetch_device_info which returns a subclass of
    NamedTuple with some handy information (mainly for the purpose of
    subsequently passing it on to Home Assistant)

v0.1.1

First released version 0.1.1 as published as PyPi package