I am currently looking into setting up a DALI system with my own programmable DALI master and (over time) a multitude of DALI (LED) lights.
The general idea is to use an already existing DALI python library to program the setup; basically I'd like to use something like MQTT to send / capture events and translate those into DALI commands.
The first issue I'm looking into is how to know which lighting fixture I'd be addressing. As I understood it, for the initial (short) address assignment / commissioning, first a series of random addresses are given and then the master just tracks back on those addresses and assigns the short addresses. All OK, but I was just wondering whether it's possible to choose the addresses in a deterministic way, i.e. based on the type of device / some unique identifier …
The main issue I would see is that in case the master would lose power, it basically would lose all the short addresses, right?
I'm just not sure whether the backward frames (/the response the slaves send back) do actually contain any other distinguishing information, to base this on …
Best Answer
There are many control systems on the market that solve this problem by retaining the list of assigned short addresses (and a mapping to the higher level system addresses, in your case MQTT) in non volatile memory of the master eg. EEPROM, Flash, battery backed RAM. You don't have to re-randomise/assign short addresses on every power on of the master, which is not the intended system design for DALI anyway, this is meant to be a one-off commissioning step. There is a defined list (Table 14 in IEC63286-102) of settings in the control gear (slaves/LED drivers) which must retain their values over power cycles and includes the short address.
One of the changes between Ed 2 and Ed 1 of IEC 62386 is that the YES response has been defined to be the short address, if assigned, or MASK (0xFF) if not. However, this is of limited use to you because although it means that you could replace the power up randomisation run with scan of 0-63 short addresses using any query that would return YES, you could do that anyway with Ed 1 control gear using QUERY MISSING SHORT ADDRESS (opcode 0x96).
For many years, deterministic commissioning was not possible in general, because there was no unique unchanging identifier which could be relied on being present in all control gear. DALI was originally specified in IEC 60929 Annex E.4 (sometimes this version of DALI is referred to as Ed 0) which had no concept of a hard coded unique identifier, probably to allow cheap mass production of identical units. Thus the randomisation process was required to distinguish between the units at commissioning time.
Whilst unique identifiers were a requirement of IEC62386-102 Ed 1 when memory banks were introduced, this was not enforced by the DALI logo registration process and some manufacturers managed to get away without them (also sometimes without valid GTINs either). Edition 2 and the DALI-2 logo certification process strictly requires the unique identifiers and valid GTINs in memory bank 0, so if you are using control gear listed products you can rely on that feature.
But because you can only read memory bank 0 by using short-addressed commands, you have to adopt a process where you assign short addresses temporarily while you read the memory bank, then reassign them. (I mean on a typical bus situation with multiple control gears. There is no restriction on which addressing modes work with most of the commands, including reading the memory bank, but group and broadcast addressing are not much use here because of collisions, except in special cases eg you could legitimately use broadcast if you only attach/power up one control gear at a time).
To ensure deterministic addressing works every time, you need to take into account the fact that the control gear serial number only has to be unique per GTIN (manufactured type) so you must also read the GTINs. If you just relied on the serial numbers you could occasionally get collisions, although it would be rare with maximum 64 units in a 32 bit address space. Whilst you can have collisions in the 24 bit random address space you can re-randomise to resolve it, but you could not do similar with the hard coded serial numbers.