DALI control device addressing modes and event source schemes

Question

I have a multi-master DALI setup at home, where my part-301 push button couplers have been assigned with fixed functions provisioned through the OEM's SW. This means that I'm using plenty of application controllers which directly control my LED control gear, etc. I'm happy with that, but now I'm about to implement some "add-on" dynamic functionality using some DIY SW instead of a ready-made commercial centralized DALI controller.

What is the point of DALI control device groups and instance groups? How are they usually used in real-world deployments?

Control device groups

In IEC 62386-103:2014, Table 1, 24-bit command frame encoding, it's shown that one can talk to the control devices either via broadcast, or broadcast unassigned, or through a short address, which all make sense to me. Then there's also the option of using the Device group addressing. I wonder what's the point of this option. I understand the use case of groups for control gear, but since this is about part-103 control devices, I wonder why/when to use a group of them -- especially considering that there aren't that many DALI commands which actually apply to control devices. What am I missing?

When is it useful to send a DALI-2 command to a control device group?

Event source addressing

In Table 3, 24-bit event message frame encoding, the standard gives five options on how a control device sends event messages:

I wonder how these are used in the real world. I know that scheme #2 (Device/Instance) requires some out-of-band knowledge about how to interpret the event frames (see this code in python-dali for how they pre-generate a look-up table so that the bus traffic viewer can properly decode these frames, for example).

The control devices that I am familiar with are from Lunatone, namely:

• ceiling sensors which provide two instances:
  • instance number 0, instance type 3 (part-303), motion detection,
  • instance number 1, instance type 4 (part-304), light intensity measurement.
• push button couplers which provide four instances:
  • one instance per each push button channel,
  • all instances of type 1 (part-301), push button.

I think the use case for different event message addressing schemas might be roughly this (I'm using the same order as the standard):

• #1, Device (each packet contains short address + instance type): useful for ceiling sensors where the central controller maintains some out-of-band map of short address to physical location; this physical location implicitly determines the "control gear to control". The logic might be something like "movement -> turn on", "no movement -> turn off after a delay".
• #2, Device/instance (each packet contains short address and instance number): useful for push-button couplers. This needs an out-of-band mapping from this pair of numbers to the target "control gear to control". A short device address is not enough because it's common to have a single push-button coupler serving a few buttons which are physically close to each other, perhaps in the same junction box in a wall. E.g., a left one could drive the corridor where the right one drives the bathroom.
• #3, Device group (each packet contains device group and instance type): useful for ceiling sensors where the "device group" determines what room they are in. That information is -- in effect -- stored in the control device itself in the device group.
• #0 Instance (each packet contains instance type and instance number). I don't know how to use this one; these data do not even tell me to which physical control device this event belongs to. What would be a real-world device where this schema is useful?
• #4 Instance group (each packet contains instance group and instance type): useful for push buttons. The mapping of "which button drives what light" is stored in the control device, through the instance group. Technically speaking, I can ignore the instance type.

For #1 and #2, the mapping of short address to "functionality" is arbitrary and the control device itself doesn't require any special configuration. Everything is in the centralized application controller which contains the full configuration. Benefits: less work when provisioning the system. Everything is in the central location, at a place which needs extra config anyway.

For #3 and #4, the device group or instance group gets provisioned to the control device, and the centralized controller uses these numbers to determine what function to perform. I see benefits of this as well; think of a staircase light control. The central system only sees "instance group 26", and it knows (via some out-of-band config) that this number corresponds to a hallway. The controller cannot distinguish between buttons at various sides of the corridor; the event is always the exact same one, and any such event simply cycles through the on/off states of the light. There's surely some beauty in that, if only because it makes the central controller a bit simpler. But -- the config gets split into several places, making it harder to provision, I suppose.

Do I understand this right? Is this how the system is usually set up in the real world? Which of these is more common, using the short address as the key, or using the device group/instance group for that purpose?

I struggle with #0. Is there a real-world use case for this?

Is there a best-practices document for DALI system design?