dali

DALI Light

This is a light platform that will setup your DALI lights and buses. The platform relies on python-dali and has only been tested with the hasseb DALI master (therefore no configuration available for other controllers). The platform will discover all your DALI lights and create entities for each ballast and bus.

A DALI Light is represented as a classic dimmable light entity. A DALI bus is also represented as a dimmable light entity whose address is the broadcast address. The state of a bus is computed based on the states of its lights: if all of its lights have the same state, the bus will show that state. If any lights differ, or any are unavailable, the bus will be off.

Commissioning / addressing

This integration now performs the commissioning / addressing sequence before entity discovery: lamps without a short address will be initialized and given one, and they will be individually controllable from Home Assistant.

It also performs short address collision detection within a bus; collisions are found by querying each short address for their serial number. If a collision is detected, offending gears will have their short addresses deleted, and the commissioning routine will be ran a second time, so that these lamps get a new address.

Short address collision won't happen in everyday use scenarios. A situation where it will happen is the following:

1. A gear breaks and is replaced by a spare. The commissioning routine will give the spare gear the same short address as the broken one had, since it is the first one available.
2. The broken gear is repaired. The spare is taken out and replaced by the repaired gear, or the repaired gear becomes the new spare.
3. Another gear breaks and is replaced by the spare. Now both of them have the same short address.

Note about short addresses

As of now, short addresses are used in entity IDs. If addressing changes happen, there might be entity ID reference issues in the UI, automations, history, and the like.

Example configuration

- platform: dali
  max_buses: 4
  drivers:
    - name: Living Room
      max_gears: 4
      readdress: false

• max_buses: maximum number of DALI buses (or DALI drivers) you expect to have. Default is 4 (as the Raspberry Pi 4 has 4 USB ports). This is used in unique ID calculations, so DALI entity names may be switched around if you change this after the first run. If that happens, just go into the "Entities" section in the UI and rename everything.

• drivers: list of DALI drivers (or DALI masters - I've seen both terms in use. I'm referring to the Hasseb device linked above) you'd like to use. The entries under this section will be read sequentially and applied to the USB devices in enumeration order, which, as long as you do not switch which USB port they are connected to, should be consistent even between host reboots. Again, if anything happens, just rename the entities.

  • name: friendly name for this bus. The bus entity will have this as its friendly name, and <friendly name with underscores>_bus as its entity ID. Lights hanging from this bus will have <friendly name with underscores>_<short address> as their entity IDs.

  • max_gears: maximum number of lights hanging from this bus.

    Be careful with this parameter, as the setup iterates through short addresses in the range [0, max_gears) to discover ballasts. If you have two buses with one ballast each, but one of them has short address 0 and the other has short address 1, and you've configured max_gears to be 1 in both cases, it will never find the ballast with short address 1 despite being technically correct.

    I recommend that, if you are making changes to the system such as adding / removing gears or changing short addresses, you keep this parameter at 64, so that all lamps will be discovered.

  • readdress: if true, on next integration reload, all short addresses will be wiped before commissioning, and new ones will be assigned. Default is false

Services

The integration offers services that allow the user to:

• Delete the short address of a gear, or all of the gears on a bus. Individual addressing will no longer work until next integration reload. Broadcast will work.

• Change the short address of a gear. Can be used on the bus, but will cause a collision (which will be resolved on next commissioning). The gear will still be individually controllable, but the friendly name and entity ID will feature the old address number until next integration reload.

• Physically identify the device. The specified light (or all of the lights of the specified bus) will turn off, on, and change brightness in a certain pattern.

All of them take a target, which can be any DALI light or bus.

Dependencies

pyhidapi, which is a dependency of this integration, relies on the hidapi library. On a venv installation, you may build it or install it through your preferred package manager.

On a HASS OS installation, I found that the quickest way to get it to work was to install the library through apk (apk add hidapi on the SSH container, not the host). This installs it in /usr/lib, which isn't persistent between container restarts, so it has to be moved to a directory that is (e.g. /config/deps/).

You will then have to fork pyhidapi and modify the __load_hidapi function to indicate the correct library path, and edit manifest.conf to replace awelkie's repo with your own. If you choose /config/deps/, you can use my fork.

dali2mqtt

Here you can find dgomes' dali2mqtt daemon, for use if you'd rather have Home Assistant installed in a platform that cannot be connected to a DALI master.

To-do

• Change unique ID and entity ID to something more adequate (serial number?)
• Change max_buses default to 64 as that's the real limit imposed by the standard, and not everyone will run this on a Raspberry Pi
• Add hid_path to driver config