Aioairq

Latest version: v0.4.4

Safety actively analyzes 720919 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 1 of 2

0.4.4

Use debugging logging extensively.
Additionally, when the logging level is set to `DEBUG`, compute
differences between the numerical sensor readings and log those too.
This makes `DEBUG` somewhat computationally more expensive.
Also add tests for the functionality that prepares more details for
the extensive debug logging.

0.4.3

By default `aioairq.core.AirQ.get_latest_data` now returns values
from SPS30 PM sensor under the same keys as the values from the sensor
that has been predominantly used so far.
Previous behaviour is still available by setting `return_original_keys=True`.

Add test and documentation.

0.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

0.3.2

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](https://github.com/CorantGmbH/aioairq/issues/2#issuecomment-1855924466) 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"`.

0.3.1

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)

0.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`

Page 1 of 2

© 2025 Safety CLI Cybersecurity Inc. All Rights Reserved.