Z-Wave JS

The radio, the server and Home Assistant

Home Assistant runs on my Raspberry Pi and connects to an existing Z-Wave JS server over WebSocket. The controller provides the Z-Wave radio connection; the server runs the driver that communicates with the devices. The Home Assistant integration exposes supported entities and events.

Z-Wave device ↔ radio controller ↔ Z-Wave JS server ↔ Home Assistant integration

A button event or sensor report travels toward Home Assistant. A request to change a Z-Wave light travels back through the server and controller. Home Assistant evaluates the automation logic and chooses which integration handles each resulting action.

This connection uses the Z-Wave JS server directly. It does not require an MQTT broker. Z-Wave JS UI offers an optional MQTT gateway, but that is a separate connection method from the native integration used here. My MQTT setup article describes the services that use the broker in this build.

What I connect through Z-Wave JS

My dashboards reference Z-Wave lights, binary sensors and supporting sensor information. Automations also use event entities from the physical scene controller. These are the main roles those connections serve.

Scroll the table horizontally to compare all four columns.

Ring sensors and Ring cameras have different paths

The Ring-branded contact sensors here are devices on my Z-Wave network. Their reports reach Home Assistant through Z-Wave JS. My Ring cameras use separate integrations and bridges with Ring cloud dependencies. The shared brand does not mean the sensors and cameras have the same connection or failure modes.

Device support sets the available controls

The WallMote supplies scene events; the dimmer supplies lighting control. Battery and diagnostic information are supporting entities where the device and integration expose them. I use those roles separately rather than assuming every Z-Wave device provides the same controls or measurements.

Physical controls across integrations

Scene buttons into lighting, switches and media

My WallMote automations listen for button-press events and call actions to toggle Hue lights, grouped lighting, switches or media players. The remote supplies the input; Home Assistant decides what that input does.

WallMote press → Z-Wave JS event → Home Assistant automation → target integration

This makes a physical controller useful beyond its own radio network. A Hue light remains connected through Hue, and a media player keeps its own integration. These configured actions run through Home Assistant; they are not direct Z-Wave device associations.

Sensor reports into lighting routines

Z-Wave binary sensors provide triggers for Hue lighting actions. My configuration also combines sensor inputs with conditions and notification actions, including a path involving Alexa Media Player. Other sensor-driven lighting logic checks alarm state before proceeding.

The sensor supplies an input, not the entire decision. Conditions and the selected action determine what happens next. A sensor report can arrive successfully even when an automation condition prevents the lighting action.

Z-Wave lights as outputs and inputs

My Z-Wave lighting participates in routines alongside grouped lights, Ring lights and other switches. Some automations also respond to a Z-Wave light's reported state, while others use grouped-light state or alarm conditions to decide how to control it.

This lets the same light work through direct dashboard controls and wider routines. Home Assistant joins the different integrations; Z-Wave JS handles the Z-Wave portion of the requested change.

Button events and persistent sensor states

A scene-control press is an occurrence. A contact sensor or light reports a state that Home Assistant can display and use in conditions. These need different automation triggers even though both arrive through the same integration.

My scene-control automations use received events from Z-Wave event entities and match the button-press event type. They do not depend on a button remaining in an on state. Repeated presses are separate inputs, even when the same button is used each time.

For sensor and light automations, the relevant input is a state change or a current-state condition. That distinction is useful when debugging: check whether the expected event occurred for a remote, or whether the expected state was reported for a sensor.

A scene event also differs from a Home Assistant scene that applies a collection of settings. Here, the controller event is the trigger; my configured action determines the outcome. The official event documentation covers the underlying Z-Wave notification and scene-event mechanisms.

Local communication, dependencies and recovery

Local radio does not remove every dependency

The Z-Wave connection is local, but these cross-integration routines still need Home Assistant, the Z-Wave JS server and the target integration. If Home Assistant is unavailable, the automation cannot translate a remote press into a Hue or media action. A target with a cloud dependency keeps that dependency.

A server or controller connection problem affects the Z-Wave path. A failed target service is a different problem. Separating those cases helps explain why a button event might be visible while the requested action does not happen.

Battery devices and reported values

Battery-powered devices can need waking before an interview or configuration change completes. Use the device's documented wake-up procedure when needed. A sleeping device and a failed device are not automatically the same condition.

Battery values and node status help with diagnosis, but a saved value is not proof of a fresh report. Confirm a new event or state update when checking the input, and verify the target response separately when checking an action.

Preserve the network before changing it

Controller/network backups, server data and security keys are separate recovery concerns from Home Assistant automation definitions. Before replacing a controller or moving a server, follow the documented backup and migration process for that installation. This is recovery guidance, not a claim that I have tested every restore path.

Only one server process should control a given adapter. Starting another server against it is not a troubleshooting shortcut. The Home Assistant Z-Wave guide explains server setup, device interviews and migration.

Checking the full path from input to result

For a missed press, a missing sensor update or a light that did not respond, I can follow the configured path in stages:

1. Check the server connection. Confirm Home Assistant is connected to the intended Z-Wave JS server and that the server can access the controller.
2. Check the device report. Look for a fresh button event or sensor state. If it is missing, investigate the device, its power and its radio connection before the target action.
3. Check the automation trace. Confirm the event type or state matched the trigger, and inspect conditions and the selected action.
4. Check the target integration. A Hue, Ring or media action uses its own connection after the Z-Wave input has arrived.
5. Check the resulting state. Verify the light or other target actually responded. An observed input establishes only the first part of the path.

That is the role Z-Wave JS serves in my build: it connects physical inputs and lighting to Home Assistant, while Home Assistant gives them useful relationships with the rest of the system.