hass-core/homeassistant/components/zwave_js
AlCalzone c7cfd56b72
Support Z-Wave JS dimming lights using color intensity (#122639)
* Z-Wave JS: support non-dimmable color lights

* remove black_is_off light, support on/off/color

* fix: tests for on/off light

* fix: typo

* remove commented out old test code

* add test for off and on

* support colored lights without separate brightness control

* add test for color-only light

* refactor: extract color only light

* fix: preserve color when changing brightness

* extend tests

* refactor again

* refactor scale check

* refactor: remove impossible check

* review feedback

* review feedback

---------

Co-authored-by: Martin Hjelmare <marhje52@gmail.com>
2024-08-29 00:01:53 +02:00
..
docs Add zwave_js dev docs readme (#47621) 2021-03-15 15:08:45 +01:00
scripts Enable Ruff RET504 (#114528) 2024-04-06 11:07:37 +02:00
triggers Bump Ruff to 0.5.3 (#122167) 2024-07-19 12:06:53 +02:00
__init__.py Register Z-Wave services on integration setup (#119924) 2024-06-18 22:27:52 +02:00
addon.py Add empty line after module docstring [w-z] (#112706) 2024-03-08 10:35:45 -05:00
api.py Replace custom validator from zwave_js with from_dict funcs (#120279) 2024-06-24 08:43:13 +02:00
binary_sensor.py Start using runtime_data for zwave_js (#117261) 2024-05-11 14:08:30 -04:00
button.py Start using runtime_data for zwave_js (#117261) 2024-05-11 14:08:30 -04:00
climate.py Start using runtime_data for zwave_js (#117261) 2024-05-11 14:08:30 -04:00
config_flow.py Cleanup unused import in zwave_js config flow (#124716) 2024-08-27 18:41:27 +02:00
config_validation.py Add empty line after module docstring [w-z] (#112706) 2024-03-08 10:35:45 -05:00
const.py Add new security keys to zwave_js config flow (#115835) 2024-06-08 11:31:05 -04:00
cover.py Start using runtime_data for zwave_js (#117261) 2024-05-11 14:08:30 -04:00
device_action.py Improve lists in integrations [X-Z] (#113253) 2024-03-13 20:32:12 +01:00
device_automation_helpers.py Start using runtime_data for zwave_js (#117261) 2024-05-11 14:08:30 -04:00
device_condition.py Add empty line after module docstring [w-z] (#112706) 2024-03-08 10:35:45 -05:00
device_trigger.py Add empty line after module docstring [w-z] (#112706) 2024-03-08 10:35:45 -05:00
diagnostics.py Start using runtime_data for zwave_js (#117261) 2024-05-11 14:08:30 -04:00
discovery.py Support Z-Wave JS dimming lights using color intensity (#122639) 2024-08-29 00:01:53 +02:00
discovery_data_template.py Improve zwave_js TypeVar usage (#117810) 2024-05-21 07:42:07 +02:00
entity.py Add ruff rule PIE808 (#113621) 2024-03-17 09:56:26 +01:00
event.py Start using runtime_data for zwave_js (#117261) 2024-05-11 14:08:30 -04:00
fan.py Add TURN_OFF/TURN_ON feature flags for fan (#121447) 2024-07-19 11:35:24 +02:00
helpers.py Refactor targets for zwave_js services (#115734) 2024-08-22 21:07:21 +02:00
humidifier.py Start using runtime_data for zwave_js (#117261) 2024-05-11 14:08:30 -04:00
icons.json Update icons.json to new service schema part 4 (#124771) 2024-08-28 13:48:13 +02:00
light.py Support Z-Wave JS dimming lights using color intensity (#122639) 2024-08-29 00:01:53 +02:00
lock.py Fix ruff manual-dict-comprehension PERF403 (#120723) 2024-06-28 14:17:47 +02:00
logbook.py Add empty line after module docstring [w-z] (#112706) 2024-03-08 10:35:45 -05:00
manifest.json Bump zwave-js-server-python to 0.57.0 (#120047) 2024-06-21 09:29:10 +02:00
migrate.py Add empty line after module docstring [w-z] (#112706) 2024-03-08 10:35:45 -05:00
number.py Start using runtime_data for zwave_js (#117261) 2024-05-11 14:08:30 -04:00
README.md Add script to convert zwave_js device diagnostics to fixture (#102799) 2023-10-25 16:07:22 -04:00
repairs.py Add empty line after module docstring [w-z] (#112706) 2024-03-08 10:35:45 -05:00
select.py Start using runtime_data for zwave_js (#117261) 2024-05-11 14:08:30 -04:00
sensor.py Add discovery rule for a Z-Wave Basic CC sensor (#105134) 2024-06-22 11:22:32 +02:00
services.py Refactor targets for zwave_js services (#115734) 2024-08-22 21:07:21 +02:00
services.yaml Fix zwave_js services.yaml schema (#124455) 2024-08-23 08:38:08 +02:00
siren.py Start using runtime_data for zwave_js (#117261) 2024-05-11 14:08:30 -04:00
strings.json Refactor targets for zwave_js services (#115734) 2024-08-22 21:07:21 +02:00
switch.py Start using runtime_data for zwave_js (#117261) 2024-05-11 14:08:30 -04:00
trigger.py Add empty line after module docstring [w-z] (#112706) 2024-03-08 10:35:45 -05:00
update.py Start using runtime_data for zwave_js (#117261) 2024-05-11 14:08:30 -04:00

Z-Wave Integration

This document covers details that new contributors may find helpful when getting started.

Improving device support

This section can help new contributors learn how to improve Z-Wave device support within Home Assistant.

The Z-Wave integration uses a discovery mechanism to create the necessary entities for each of your Z-Wave nodes. To perform this discovery, the integration iterates through each node's Values and compares them to a list of discovery rules. If there is a match between a particular discovery rule and the given Value, the integration creates an entity for that value using information sent from the discovery logic to indicate entity platform and instance type.

In cases where an entity's functionality requires interaction with multiple Values, the discovery rule for that particular entity type is based on the primary Value, or the Value that must be there to indicate that this entity needs to be created, and then the rest of the Values required are discovered by the class instance for that entity. A good example of this is the discovery logic for the climate entity. Currently, the discovery logic is tied to the discovery of a Value with a property of mode and a command class of Thermostat Mode, but the actual entity uses many more Values than that to be fully functional as evident in the code.

There are several ways that device support can be improved within Home Assistant, but regardless of the reason, it is important to add device specific tests in these use cases. To do so, add the device's data to the fixtures folder and then define the new fixtures in conftest.py. Use existing tests as the model but the tests can go in the test_discovery.py module. To learn how to generate fixtures, see the following section.

Generating device fixtures

To generate a device fixture, download a diagnostics dump of the device from your Home Assistant instance. The dumped data will need to be modified to match the expected format. You can always do this transformation by hand, but the integration provides a helper script that will generate the appropriate fixture data from a device diagnostics dump for you. To use it, run the script with the path to the diagnostics dump you downloaded:

python homeassistant/components/zwave_js/scripts/convert_device_diagnostics_to_fixture.py <path/to/diagnostics/dump>

The script will print the fixture data to standard output, and you can use Unix piping to create a file from the fixture data:

python homeassistant/components/zwave_js/scripts/convert_device_diagnostics_to_fixture.py <path/to/diagnostics/dump> > <path_to_fixture_output>

You can alternatively pass the --file flag to the script and it will create the file for you in the fixtures folder: python homeassistant/components/zwave_js/scripts/convert_device_diagnostics_to_fixture.py <path/to/diagnostics/dump> --file

Switching HA support for a device from one entity type to another.

Sometimes manufacturers don't follow the spec properly and implement functionality using the wrong command class, resulting in HA discovering the feature as the wrong entity type. There is a section in the discovery rules for device specific discovery. This can be used to override the type of entity that HA discovers for that particular device's primary Value.

Adding feature support to complex entity types

Sometimes the generic Z-Wave entity logic does not provide all of the features a device is capable of. A great example of this is a climate entity where the current temperature is determined by one of multiple sensors that is configurable by a configuration parameter. In these cases, there is a section in the discovery rules for device specific discovery. By leveraging discovery_data_template.py, it is possible to create the same entity type but with different logic. Generally, we don't like to create entity classes that are device specific, so this mechanism allows us to generalize the implementation.

Architecture

This section describes the architecture of Z-Wave JS in Home Assistant and how the integration is connected all the way to the Z-Wave USB stick controller.

Connection diagram

alt text

Z-Wave USB stick

Communicates with devices via the Z-Wave radio and stores device pairing.

Z-Wave JS

Represents the USB stick serial protocol as devices.

Z-Wave JS Server

Forward the state of Z-Wave JS over a WebSocket connection.

Z-Wave JS Server Python

Consumes the WebSocket connection and makes the Z-Wave JS state available in Python.

Z-Wave integration

Represents Z-Wave devices in Home Assistant and allows control.

Home Assistant

Best home automation platform in the world.

Running Z-Wave JS Server

alt text

Z-Wave JS Server can be run as a standalone Node app.

It can also run as part of Z-Wave JS UI, which is also a standalone Node app.

Both apps are available as Home Assistant add-ons. There are also Docker containers etc.