pywizlight puts WiZ smart bulbs on a Python API

A narrow target: WiZ bulbs on the local network

pywizlight describes itself as a Python connector for WiZ devices, and the description in the packaging metadata is blunter still, calling it a connector for WiZ light bulbs and naming the SLV Play product as an example. The repository topics narrow the scope further, listing udp and bulb-state alongside python3 and hacktoberfest. That combination points at the mechanism: the library talks to devices over UDP on the local network rather than through a hosted service, and what it exposes is the state of a bulb, not a general device management surface. The WiZ Light API documentation is linked from the README as the reference for the underlying protocol, which is the sensible place to look when you need to know what a field means rather than what a method is called. The project carries no homepage of its own, so the documentation link and the packaged API are the two reference points a user has.

Three install routes, and the Python floor is the gate

The normal install is a single command:

pip install pywizlight

Two distribution channels are documented alongside it. On Fedora, or on a CentOS or RHEL 8 machine with EPEL enabled, the package is in the Fedora Package Collection:

sudo dnf -y install python3-pywizlight

On NixOS, the README says the latest release is usually in the unstable channel while stable releases might ship older versions, and gives the command:

nix-env -iA nixos.python37Packages.pywizlight

The one constraint that governs all three routes is the Python version, since the README states a requirement of >=3.11 and the packaging metadata sets python_requires to the same value. The NixOS example is worth a second look, because it names a python37 package attribute while the library itself now requires 3.11 or newer, so a reader following that line literally on a current system is following a stale path. That is a documentation detail, not a defect in the library, but it is exactly the kind of thing that wastes an afternoon.

What the packaging says about the shape of the library

setup.py describes the distribution in a way that removes most guesswork. The package name is pywizlight, the author fields are Stephan Traub with the sbidy email address, and the version is not written down in setup.py at all: a helper function reads pywizlight/_version.py, matches the __version__ string out of it with a regular expression, and asserts that the match succeeded before handing it to setuptools. The console script is registered as wizlight and points at pywizlight.cli:main, which tells you the command line entry point is a click application, since click is the only install requirement and the only entry in requirements.txt. Packages are discovered with find_packages, excluding test.py and tests. The pyproject.toml itself is minimal, holding just the pytest configuration, and the licence is declared as MIT both in the setup metadata and in the repository's LICENSE file.

Async tests and static typing are configured, not assumed

The repository includes a mypy.ini at the top level, a .coveragerc and a pytest configuration in pyproject.toml, and that pytest configuration is a single line with real consequences:

asyncio_mode = "auto"

In pytest-asyncio terms, auto mode means async test functions are collected and run without each one needing its own marker, which is what you want in a library where the public surface is asynchronous. It is a small file that signals the library is written around asyncio rather than wrapped in it later. The presence of mypy.ini and a coverage configuration shows the same intent from the other direction, that types and test coverage are part of the project's normal working method rather than an afterthought. The workflow badges at the top of the README point the same way, with separate pipelines for uploading the Python package, updating the docs and running lint.

The release line and how far along it is

The tags tell a plain story. Version 0.6.6 was published on 2026-08-05, version 0.6.5 on 2026-07-08 and version 0.6.4 on 2026-07-06, and the last push to the repository was on 2026-08-05 as well. Two of the three recent versions are marked as pre-releases in their titles, which is the signal that this is a library still finding its shape rather than one with a frozen public interface. The project is not archived, and the commit cadence through the summer of 2026 was regular, but the 0.x version number is the more important fact for anyone planning to depend on it, because 0.x carries no compatibility promise by convention. The documentation directory and the Update Docs workflow badge suggest the API reference is generated rather than hand-written, so it should track the code, but the README itself remains the only written tutorial, and it stops at installation.

Where pywizlight is the wrong tool

Three cases. The first is a mixed-vendor smart home, because the connector targets one device family and the topics say so plainly, so every other bulb in the house is a separate integration with its own quirks. The second is a project that needs a stable command line contract, since the wizlight console script exists and is wired to a click main function, but the README documents no options, no output format and no exit codes, so scripting against the command rather than the library means reverse engineering it. The third is a strict dependency policy, because the library brings click with it for a single device family, and the alternative of speaking UDP to the bulb directly with a few lines of standard library code avoids a third party runtime dependency entirely, at the cost of owning the protocol details yourself.

Editorial conclusion

pywizlight is a good fit for a home automation script, a Home Assistant style integration, or a small tool that needs to read and set the state of WiZ bulbs over the local network without a vendor cloud account. It is a poor fit for a fleet of mixed smart home hardware, for a team that needs a documented and stable command line interface, and for a locked-down environment that cannot add a third party runtime dependency for a single device family. Check three things before you depend on it: that Python 3.11 or newer is what you actually have, since python_requires is set to >=3.11 and older interpreters are not supported; that the bulbs in question speak the local protocol the topics imply, since the repository is tagged for udp and bulb state rather than for a general device protocol; and that the version you pin is one you have read, because the 0.6.x line has shipped pre-releases alongside the tagged releases and the last push was on 2026-08-05.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. sbidy/pywizlight on GitHub