-
Notifications
You must be signed in to change notification settings - Fork 31
Diagnostic DIM Reference
Diagnostic DIM messages carry structured information about a Device, its Modules, its Objects, and their configuration.
Within the diagnostic protocol, WHAT commands primarily control operations and state transitions, while DIM messages exchange structured data.
Conceptually:
Diagnostic Protocol
│
├── WHAT
│ └── operation / state control
│
└── DIM
└── structured diagnostic data
The best-understood dimensions currently come from the Automation Diagnostic domain, WHO1001.
Observed dimensions include:
DIM |
Current interpretation | Scope |
|---|---|---|
DIM1 |
Device/catalogue identity signature | Device |
DIM2 |
Firmware version | Device |
DIM3 |
Unknown Device metadata | Device |
DIM4 |
Unknown Device metadata | Device |
DIM5 |
Unknown Device metadata | Device |
DIM6 |
Unknown Device metadata | Device |
DIM7 |
Diagnostic/fault state | Device |
DIM13 |
Hardware ID | Device |
DIM30 |
Module / Object association | Module |
DIM32 |
Intrinsic Module/Object address | Module |
DIM35 |
Module/Object configuration | Configuration |
DIM38 |
Configuration-read request | Protocol control |
DIM310 |
Object-specific information | Configuration / Object-specific |
This list represents dimensions observed during the current reverse-engineering work and should not be considered an exhaustive list of all possible Diagnostic DIM values.
The dimensions observed during a Device interview can be divided into several functional groups.
These dimensions describe the physical Device itself:
Device
│
├── DIM1 identity
├── DIM2 firmware
├── DIM3 unknown metadata
├── DIM4 unknown metadata
├── DIM5 unknown metadata
├── DIM6 unknown metadata
├── DIM7 diagnostic state
└── DIM13 hardware ID
Not every Device returns every optional metadata dimension.
These dimensions describe the logical Modules exposed by the Device:
Device
│
└── Module
│
├── DIM30
│ └── Object association
│
└── DIM32
└── intrinsic address
A Device can return multiple DIM30 and DIM32 frames because it can expose multiple Modules.
Configuration reading introduces another group:
Configuration
│
├── DIM38
│ └── configuration-read request
│
├── DIM35
│ └── generic Object configuration
│
└── DIM310
└── Object-specific information
DIM35 is currently the best-understood general configuration mechanism.
Other Object-specific dimensions may exist.
*#1001*WHERE*1*VALUE1*VALUE2*VALUE3*VALUE4##
Current database correlations are:
| Field | Interpretation | Confidence |
|---|---|---|
VALUE1 |
AS_ITEM_SYSTEM.modobj |
Confirmed |
VALUE2 |
Unknown | Unknown |
VALUE3 |
EN_BRAND.brand_modobj |
Strong |
VALUE4 |
EN_LINE.line_modobj |
Strong |
DIM1 should be understood as a Device/catalogue identity signature.
It does not necessarily uniquely identify a commercial SKU.
The meaning of VALUE2 remains deliberately unresolved.
Several possible correlations have been investigated, but none has been established sufficiently to assign a semantic meaning.
*#1001*WHERE*2*V*R*B##
The three fields correlate with:
V → EN_FIRMWARE.firmware_V
R → EN_FIRMWARE.firmware_R
B → EN_BUILDS.firmware_b
Firmware information is particularly important because the Objects, configuration properties, and allowed values supported by a Device can depend on firmware.
An observed example is:
*#1001*0015*3*33*32*9##
The exact meaning of DIM3 is unknown.
DIM3 was rare in the larger Device scan.
An observed example is:
*#1001*0015*4*0*0*0*0*0*0##
DIM4 is consistently present in the WHO1001 Device interviews investigated so far, but its individual fields have not yet been decoded.
It should currently be treated as Device-level metadata.
DIM5 occurs only on some Devices in the captures investigated so far.
Unlike DIM4, it is not part of every observed WHO1001 Device interview.
Its exact structure and semantics remain unresolved.
An observed example is:
*#1001*0015*6*4*5*35##
Like DIM3, DIM6's exact meaning is unknown.
DIM7 carries a diagnostic/fault-state bitmask.
Conceptually:
DIM7
│
▼
24-bit diagnostic state
│
├── bit 0
├── bit 1
├── ...
└── bit 23
The meanings and polarity of individual bits have not yet been established for WHO1001.
Bit definitions documented for another Diagnostic WHO domain should not automatically be transferred to WHO1001.
*#1001*WHERE*13*DECIMAL_ID##
DIM13 reports the unique hardware ID of the physical Device.
The value is transported as a decimal integer.
For documentation, it is normalized to an eight-character uppercase hexadecimal value:
147801279 decimal
↓
08CF44BF hexadecimal
DIM13 is also used for hardware-ID Device discovery.
For example *#1001*0*13## requests Device enumeration under WHO1001.
See Diagnostic Device Discovery.
DIM30 is one of the most important diagnostic dimensions because it describes the logical structure exposed by a physical Device.
*#1001*WHERE*30*INTERNAL_SLOT*OBJECT_ID*DISABLED##
| Field | Meaning |
|---|---|
WHERE |
Device/address context |
INTERNAL_SLOT |
Internal Module slot index |
OBJECT_ID |
Object associated with the Module |
DISABLED |
Module enabled/disabled state |
DISABLED has the observed values:
| Value | Meaning |
|---|---|
0 |
Module enabled |
1 |
Module disabled |
DISABLED is a reverse-engineered field name rather than a known official OpenWebNet name.
The primary relationship is:
Physical Device
│
▼
Internal slot
│
▼
Module
│
▼
Object ID
│
▼
Object function
Examples include:
| Object ID | Object |
|---|---|
6 |
Light actuator |
8 |
Dimmer actuator |
128 |
Scenarios daylight and presence sensor |
164 |
Scenarios daylight sensor |
218 |
Shutter actuator |
400 |
Light control |
401 |
Automation control |
406 |
Scheduled scenario PLUS |
431 |
IR scenario control |
The Object IDs correlate with EN_KEY_OBJECT in the MyHOME Suite catalogue.
The INTERNAL_SLOT value is an internal protocol index.
It should not be assumed to equal the Module number displayed by MyHOME Suite.
Captured Devices demonstrate that the two numbering schemes can differ, especially when configuration of Module 1 disables Module 2, in this case the following Modules number is shifted.
Across the investigated captures, DISABLED=0 correlates with enabled Modules that participate in subsequent configuration reporting, while DISABLED=1 correlates with Modules disabled in MyHOME Suite.
The final field can therefore be interpreted as a Module enabled/disabled state rather than as part of Object identification.
An Object can be assigned to an internal Module slot using the observed write form:
*#1001*WHERE*#30*INTERNAL_SLOT*OBJECT_ID##
For example:
*#1001*0*#30*3*406##
assigns Object 406, Scheduled scenario PLUS, to internal slot 3.
The DISABLED field is present in the read form but is not included in the observed #DIM30 write form.
See Device Modules and DIM30, Objects, and Virgin Objects.
*#1001*RESPONSE_WHERE*32#INTERNAL_SLOT*1*CONFIGURED_WHERE##
DIM32 reports the intrinsic configured address of a Module/Object when that Object possesses its own address.
The fields currently appear to be:
INTERNAL_SLOT
│
├── identifies Module
│
▼
1
│
└── meaning unknown
│
▼
CONFIGURED_WHERE
│
└── Module/Object intrinsic address
The middle value 1 has consistently been observed but its meaning remains unknown.
Observed correlations include:
Object 218 → configured address 11
Object 218 → configured address 21
Object 8 → configured address 23
Object 6 → configured addresses 10 and 16
Object 164 → configured address 0015
Object 128 → configured address 0015
This demonstrates that DIM32 is not actuator-specific.
It can also apply to sensor Objects possessing an intrinsic address.
DIM32 should not be confused with a target address stored in a command Object's configuration.
Conceptually:
DIM32
│
└── "Where is this Module/Object?"
versus:
DIM35
│
└── potentially "What address does this command target?"
See Module Addressing and DIM32.
After the initial Device/Module description, MyHOME Suite sends:
*#1001*0*38#0##
DIM38 is strongly associated with the transition into the configuration-reading phase.
The observed sequence is:
Device description
│
▼
DIM30 / DIM32
│
▼
WHAT4
│
▼
DIM38 request
│
▼
Configuration responses
Unlike dimensions such as DIM1, DIM13, or DIM30, DIM38 is primarily observed as a request issued by MyHOME Suite, rather than as descriptive data returned by the Device.
Its exact formal semantics remain unknown.
DIM35 is the principal general configuration mechanism currently understood under WHO1001.
*#1001*WHERE*35#CONF_IDX#INTERNAL_SLOT*VALUE##
The fields are:
| Field | Interpretation |
|---|---|
CONF_IDX |
Configuration-property index |
INTERNAL_SLOT |
Module internal slot |
VALUE |
Current property value |
The CONF_IDX value correlates with EN_CONF.idx but only within the context of the Object associated with the Module.
The correct decoding chain is therefore:
DIM35
│
├── INTERNAL_SLOT
│ ↓
│ DIM30
│ ↓
│ OBJECT_ID
│
├── CONF_IDX
│ ↓
│ EN_CONF
│
└── VALUE
↓
EN_CONF_RANGE
↓
interpreted value
A CONF_IDX must never be interpreted globally without first resolving the Object.
Suppose DIM30 establishes:
internal slot 1 → Object 128
and DIM35 reports:
CONF_IDX = 20
INTERNAL_SLOT = 1
VALUE = 1
For Object 128, configuration index 20 corresponds to PIR sensitivity.
Its enumeration maps:
0 → Low
1 → Medium
2 → High
3 → Maximum
The resulting configuration is therefore:
PIR sensitivity = Medium
Programming uses a closely related form:
*#1001*WHERE*#35#CONF_IDX#INTERNAL_SLOT*VALUE##
The addition of the write marker produces a useful read/write symmetry:
Read:
DIM35 → Device reports property
Write:
#DIM35 → MyHOME Suite assigns property
See Module Configuration and DIM35.
DIM310 has been observed in a small number of Device interviews.
It appears during the broader configuration phase rather than as part of the common Device identity sequence.
Its exact semantics have not yet been established.
The presence of DIM310 also demonstrates that DIM35 is not necessarily the only mechanism by which Object-specific information can be exchanged.
The more general model is therefore:
Object configuration
│
├── DIM35
│ └── generic configuration properties
│
├── DIM310
│ └── observed Object-specific information
│
└── other DIMs
└── potentially Object/Device-specific
Some diagnostic dimensions have corresponding write forms.
The clearest examples currently are DIM30 and DIM35.
Read/report:
*#1001*0*30*3*406*0##
Write:
*#1001*0*#30*3*406##
This demonstrates that #DIM30 assigns an Object to an internal Module slot.
Read/report:
*#1001*WHERE*35#CONF_IDX#INTERNAL_SLOT*VALUE##
Write:
*#1001*WHERE*#35#CONF_IDX#INTERNAL_SLOT*VALUE##
This demonstrates that #DIM35 writes an Object configuration property.
The symmetry can be represented as:
READ
Device
│
├── DIM30 → Module / Object
└── DIM35 → Configuration
│
▼
MyHOME Suite
WRITE
MyHOME Suite
│
▼
├── #DIM30 → assign Object
└── #DIM35 → assign configuration
│
▼
Device
See Diagnostic Device Programming.
Not every Device returns every dimension.
The observed WHO1001 Device population demonstrates several patterns.
The most consistently observed Device-level dimensions are:
DIM1
DIM2
DIM4
DIM7
DIM13
These form the most stable core of the observed Device-description sequence.
The following occur only on some Devices:
DIM3
DIM5
DIM6
Their presence appears to depend on Device family, firmware, or another Device-specific characteristic.
DIM30 depends on the number and type of Modules exposed by the Device.
DIM32 occurs only where the corresponding Module/Object possesses an intrinsic address.
The number of DIM35 responses depends heavily on:
- Module count;
- Object type;
- Object configuration schema;
- firmware;
- filters;
- Device state.
An Object exposing four configuration properties can generate a very different response set from an Object exposing dozens.
A WHO1001 scan covering approximately 70 Device interviews provides a useful view of dimension frequency.
The captures contained approximately:
DIM |
Observed frequency / distribution |
|---|---|
DIM1 |
Present for all 70 Device interviews |
DIM2 |
Present for all 70 |
DIM3 |
1 Device |
DIM4 |
Present for all 70 |
DIM5 |
8 Devices |
DIM6 |
1 Device |
DIM7 |
Present for all 70 |
DIM13 |
Present throughout; capture includes duplicate responses |
DIM30 |
Many responses; depends on Module count |
DIM32 |
59 observed responses |
DIM35 |
Thousands of responses; depends on Object configuration |
DIM310 |
2 observed responses |
These counts should be interpreted carefully because network duplication can cause multiple copies of some frames.
The important result is the distribution, rather than the absolute packet count.
A typical interview can be represented as:
SELECT DEVICE
│
▼
DEVICE DESCRIPTION
│
├── DIM1
├── DIM2
├── DIM3 [optional]
├── DIM4
├── DIM5 [optional]
├── DIM6 [optional]
├── DIM7
└── DIM13
│
▼
MODULE DESCRIPTION
│
├── DIM30
├── DIM30
├── ...
│
└── DIM32 [where applicable]
│
▼
WHAT4
│
▼
CONFIGURATION REQUEST
│
└── DIM38
│
▼
CONFIGURATION RESPONSE
│
├── DIM35
├── DIM35
├── ...
│
└── Object-specific DIMs
└── DIM310 [observed]
│
▼
WHAT6
This is an observed workflow, not a requirement that every Device return every listed dimension.
Several diagnostic dimensions can be decoded by correlating them with the MyHOME Suite catalogue.
DIM1
│
├── VALUE1 → AS_ITEM_SYSTEM.modobj
├── VALUE2 → unknown
├── VALUE3 → EN_BRAND.brand_modobj
└── VALUE4 → EN_LINE.line_modobj
DIM2
│
└── V / R / B
│
▼
EN_FIRMWARE / EN_BUILDS
DIM30
│
├── INTERNAL_SLOT
└── OBJECT_ID
│
▼
EN_KEY_OBJECT
DIM35
│
├── INTERNAL_SLOT
│ ↓
│ DIM30
│ ↓
│ Object
│
├── CONF_IDX
│ ↓
│ EN_CONF
│
└── VALUE
↓
EN_CONF_RANGE
Firmware and filter tables further determine which configuration properties and values are valid for a particular Device.
This gives the overall decoding model:
Diagnostic frames
│
▼
Device identity
│
▼
Firmware
│
▼
Modules
│
▼
Objects
│
▼
Configuration schema
│
▼
Raw configuration values
│
▼
Effective MyHOME Suite configuration
- OpenWebNet Diagnostic Protocol
- Diagnostic Device Discovery
- Diagnostic Device Interview
- Diagnostic Configuration Reading
- Diagnostic Device Programming
- Diagnostic WHAT Reference
- Device Modules and DIM30
- Module Addressing and DIM32
- Module Configuration and DIM35
- Configuration Filters
- MHCatalogue Database
- MHCatalogue Configuration Schema
- Diagnostic Protocol Reverse Engineering