zwave-js: a Z-Wave driver written in TypeScript

The problem is that Z-Wave is hard to start with

The stated motivation is blunt about the state of the ecosystem. Z-Wave is described as an amazing piece of technology, but it is difficult to get started with and develop for, and the answer the project gives is that it should not be, followed by the line that they have you covered. The technical reasons are visible in the positioning. Z-Wave has historically been a closed protocol with a fragmented history of controller chips, and the people who wanted to write software against it were often reduced to a native library for one platform with a C API. This project replaces that with a driver written entirely in JavaScript and TypeScript, and the readme makes the point in the blunter terms of no static library mess. That is a real change in what a developer can do, because a driver in a language with an async model and a package ecosystem can be used from Node, from a Raspberry Pi, from a container, and from a home server, and the compatibility claim is stated as covering all known 500, 700 and 800 series Z-Wave controller hardware adapters. The consequence is that the driver runs on almost anything with a little bit of computing power and a serial port, which is a much lower bar than a native toolchain.

A high-level API, and the reason it matters at the edges

The API shape is described in the readme's feature list as an easy high-level API, and this is where a driver earns its keep. Raw Z-Wave is a stack of command classes, node ids, values with types and a security bootstrap, and a driver that exposes that directly hands the caller the complexity of the protocol. A high-level API on top of the driver turns a value update into something with a name, a type and a value, and turns a device that has not been interviewed yet into something the application can still work with. The readme describes the driver as modern and standards compliant, and the two claims together are the point: modern means the protocol is implemented as the specification says rather than as one vendor's firmware happens to do it, and standards compliant means a device from a third party is likely to behave as documented. For an application developer, that is the difference between a driver that works on the devices the author owns and one that works on the devices the users own, and the device configuration database is the other half of that story.

The device configuration database is the part contributors fill in

A separate site hosts the device configuration database, and the readme makes contributing to it the first thing it asks for. The stated reason is practical: contributing configuration files for new devices keeps the maintainers' hands free for the actual development. The second ask is sending devices to test, with the explanation that working with an actual device is much more efficient than trying to debug with log files, which is a specific and telling statement about how hard the reverse engineering is without hardware in hand. That is the shape of this project. The hard part of a Z-Wave driver is not the protocol, it is the several hundred devices on the market, each with its own command class set, its own values and its own quirks, and the configuration database is how that knowledge is captured in a form the driver can consume. A driver without a device database is a protocol implementation. A driver with one is a product, and the difference is entirely in the accumulated configuration files. The sponsorship structure is described as the third way to help, through GitHub sponsors, with a link to a page explaining how to support the development, and the top sponsor listed is Nabu Casa.

A monorepo with workspace packages and a lot of release machinery

The repository is a Yarn workspace monorepo and the layout shows what a project with this many consumers has to carry. The root package is private, versioned at 15.31.1, and declares the packages directory as its workspace, with individual packages such as @zwave-js/core, @zwave-js/cc for the command classes, @zwave-js/config for the device database, and a browser bindings package, each referenced as a workspace. Beyond the code there is the apparatus of publishing a typed API to npm, with an api-extractor configuration and a Microsoft API Extractor in the development dependencies, which is how the public type surface is kept consistent. The build tooling is Turbo driven, there is a separate tsconfig for the browser build, the docs and the tests, a vitest configuration, an eslint configuration, a commitlint configuration for conventional commits, a release config, and a packmod.sh script for producing the packages. The tooling also includes Oxlint and Oxfmt configuration files, and the native preview of the TypeScript compiler, and there is an MCP configuration file, an AI policy document and agent instruction directories, which is a sign of a project that has adopted AI tooling deliberately rather than by accident.

Releases every few days, and a branch that is the master branch

The release cadence is fast and regular, and the version numbers tell you the scale of the surface. The three most recent releases are v15.31.1 from 2026-10-07, v15.31.0 from 2026-09-28 and v15.30.0 from 2026-09-28, with the last push on 2026-10-17. A project shipping a minor release every few days at version 15 is one where the public API is broad and the device database changes constantly, because a new device configuration is itself worth a release. That has implications for consumers. Depending on a specific version means tracking the device database as well as the code, so a user with a device that gained support in a later release is on a different behaviour than you tested. The default branch is master, which is conventional for the project, and the release is published to npm under the zwave-js package name, with the node and npm version badges in the readme. The project started in 2018 and the readme says it has breathed new life into the Z-Wave ecosystem and is now powering thousands of smart homes, which is the one claim in the readme about scale and the one you should treat as a claim rather than a measurement, since no figure is given for the number of installations.

Where to start, and what the readme leaves to the documentation

The readme is short and points rather than explains, which is the right choice for a project with a documentation site of this size. The quick links row points to the licence, the changelog, the documentation site and the device configuration database, and there is a Gitpod button, which is a one click way to get a working environment in a browser without installing a serial driver locally. The documentation site carries the getting started guide, and the readme's instruction is simply to check it out to get started. The head of the page states the four properties in one line each, control your Z-Wave network from Node.js, an easy high-level API, just JavaScript or rather TypeScript with no static library mess, and a link to a description of it as fast. There is also a per-platform installation section referenced in the quick links list, and the sponsoring page under the documentation explains how to support the development. The practical entry path for a new user is therefore the documentation site for the API, the device database to check whether your hardware is supported, and the Gitpod workspace if you want to try the driver without a radio attached.

Editorial conclusion

zwave-js is a good fit for a smart home developer or an integrator who wants to talk to Z-Wave hardware from Node.js without a native library, and who values a device configuration database that other people maintain so their own effort goes into the code rather than into reverse engineering firmware. It is the wrong choice if you need a native library for a constrained device with no Node runtime, and it is the wrong choice if you want a finished product rather than a driver you integrate into your own application, because the project is a library and an SDK, not an end user interface. It is also the wrong choice if you cannot contribute device configuration files, since a driver that does not recognise your hardware is not much use. Before adopting it, check the device configuration database for your specific devices, and if your device is missing, contributing a configuration file is the fastest way to unblock yourself. The project is MIT licensed, the last push was on 2026-10-17, and the current release is v15.31.1 from 2026-10-07.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. zwave-js/zwave-js on GitHub