Skip to content

Module Addressing and DIM32

Jump to bottom
anotherjulien edited this page Sep 14, 2026 · 2 revisions

Overview

DIM32 reports the intrinsic BUS address of a Module/Object when that function possesses its own A/PL address.

It complements DIM30:

DIM30 → What function does the Module implement?
DIM32 → What is that Module's own BUS address?

DIM32 is therefore primarily relevant to Objects such as actuators and sensors that are themselves addressed on the Automation BUS.

Frame Structure

The observed form is:

*#1001*WHERE*32#INTERNAL_SLOT*1*CONFIGURED_WHERE##
Field Meaning
WHERE Device/address context
32 DIM32
INTERNAL_SLOT Internal Module slot index
1 Constant in the observed captures; exact meaning unknown
CONFIGURED_WHERE Intrinsic BUS address of the Module/Object

For example:

*#1001*0015*32#1*1*0015##

reports that internal slot 1 has intrinsic address 0015, corresponding to A=0, PL=15.

Relationship with DIM30

DIM32 must be interpreted in the context of the Module identified through DIM30.

For example, Device 004FBEC8 reports:

DIM30 → slot 1 → Object 218
DIM32 → slot 1 → 11

Object 218 is Shutter actuator, giving:

Module 1
  ├── Object: Shutter actuator
  └── Address: A=1, PL=1

The internal slot therefore provides the link between the two dimensions:

            INTERNAL_SLOT
                 │
       ┌─────────┴─────────┐
       ▼                   ▼
     DIM30               DIM32
       │                   │
       ▼                   ▼
     Object          Intrinsic address

Observed Examples

DIM32 has been observed with several different Object types:

Device Object Function CONFIGURED_WHERE
004FBEC8 218 Shutter actuator 11
00861DE9 218 Shutter actuator 21
00C16454 8 Dimmer actuator 23
00C58E91 6 Light actuator 10, 16
08CF44BF 164 / 128 Sensor 0015

This shows that DIM32 is not specific to actuators. It represents intrinsic Module/Object addressing more generally.

Intrinsic vs Destination Addressing

An important distinction exists between an Object's own address and an address it uses as part of its configuration.

Intrinsic Address

An intrinsic address identifies the Module/Object itself on the BUS.

For an actuator:

Light actuator
A=1
PL=0

DIM32 → 10

For the sensor 08CF44BF:

Sensor
A=0
PL=15

DIM32 → 0015

These addresses are reported through DIM32.

Destination Address

Command Objects behave differently.

For example, Object 400, Light control, can be configured to command another BUS address:

Light control
     │
     │ commands
     ▼
Target A/PL

That A/PL represents the destination of the command, not necessarily the intrinsic address of the command Module itself.

Such configuration is represented through Object properties, typically exposed through DIM35.

Therefore:

Address type Meaning Typical source
Intrinsic address Where the Module/Object itself resides DIM32
Destination address What the Object commands or references DIM35 configuration

This explains why command Objects such as Object 400 commonly do not produce DIM32, even though their configuration contains A/PL values.

Module-Level Addressing

DIM32 applies at the Module level, not necessarily to the physical Device as a whole.

A multi-channel Device can therefore contain several Modules with different intrinsic addresses.

For example, Device 00C58E91 contains two Light actuator Modules:

Physical Device
  │
  ├── Module 1
  │     ├── Object 6
  │     └── A=1, PL=0
  │
  ├── Module 2
  │     ├── Object 6
  │     └── A=1, PL=6
  │
  └── Module 3
        └── Object 400
              Light control

The first two Modules produce separate DIM32 responses, while the command Module does not.

This demonstrates that a physical Device does not necessarily have a single A/PL address shared by all of its logical functions.

Relationship with Device WHERE

The WHERE used to communicate with a Device during diagnostics and the CONFIGURED_WHERE reported by DIM32 are related but conceptually distinct.

For example:

*#1001*0015*32#1*1*0015##

contains 0015 twice:

  • the first 0015 is the diagnostic response WHERE;
  • the second 0015 is the configured intrinsic address of internal slot 1.

For this Device they happen to be equal.

This should not be generalized into a requirement that every Module's DIM32 address must equal the Device-level diagnostic WHERE, particularly for multi-Module Devices with independently addressed functions.

Relationship with Enabled Modules

DIM32 has been observed for enabled Modules reported by DIM30 with DISABLED=0.

Conceptually:

DIM30
  │
  ├── Object
  └── DISABLED=0
          │
          ▼
        DIM32
   when the Object
   has an intrinsic address

The absence of DIM32 does not imply that the Module is disabled. An enabled Object may simply not possess an intrinsic BUS address of the type represented by DIM32.

Object type must therefore be considered when interpreting its presence or absence.

Relationship with the Catalogue

DIM32 does not directly identify an Object. The Object is first resolved through DIM30.

The decoding model is:

DIM30
  │
  ▼
INTERNAL_SLOT + OBJECT_ID
  │
  ▼
Module / Object
  │
  ▼
DIM32
  │
  ▼
Intrinsic BUS address

The catalogue provides the semantic context required to determine what kind of function the addressed Module implements.

This is particularly important when distinguishing actuator/sensor addressing from command destination configuration.

Summary

DIM32 reports the intrinsic BUS address of an enabled Module/Object when that function possesses such an address.

Its observed structure is:

*#1001*WHERE*32#INTERNAL_SLOT*1*CONFIGURED_WHERE##

The key distinction is:

DIM30 → Module and Object
DIM32 → Module/Object's own address
DIM35 → Object configuration,
        including destination addresses where applicable

DIM32 should therefore be understood as part of the Module identity/addressing model, rather than as a generic representation of every A/PL value associated with an Object.

See Also

Clone this wiki locally