Skip to content

Diagnostic Architecture

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

Overview

The MyHOME diagnostic protocol provides a common architecture for discovering, identifying, interrogating, configuring, and programming physical Devices.

The protocol can be viewed as a hierarchy:

Diagnostic WHO
      │
      ▼
    Device
      │
      ▼
    Module
      │
      ▼
    Object
      │
      ▼
 Configuration

Each layer answers a different question:

Layer Role
Diagnostic WHO Selects the diagnostic functional domain
Device Represents the physical BUS Device
Module Represents a logical unit exposed by the Device
Object Defines the function implemented by a Module
Configuration Defines the properties of that Object

The diagnostic protocol provides operations for navigating and manipulating this hierarchy.

Diagnostic Domains

Diagnostic operations are separated into diagnostic WHO domains.

Observed domains include:

Functional domain Diagnostic WHO
Automation WHO1001
Temperature Control WHO1004
Energy Management WHO1018
Access Control WHO1023

A diagnostic WHO appears to identify a broader diagnostic/configuration domain, rather than simply mirroring the normal functional WHO.

For example, WHO1001 covers the MyHOME Automation environment, including functions associated with both lighting and automation.

The diagnostic domain also determines the addressing and configuration model applicable to its Devices.

See Diagnostic WHO Domains.

Device Identity

A physical Device can be identified in two important ways.

Hardware ID

Each Device exposes a hardware identifier through DIM13.

For example:

Device ID: 08CF44BF

On the wire, the hardware ID is transmitted as a decimal integer.

The hardware ID provides a stable way to select a specific physical Device independently of its configured BUS address.

It is used by operations such as:

WHAT10#ID → select Device for interview
WHAT9#ID  → select Device for programming

BUS Address

Devices and their Modules can also participate in the BUS addressing model of their diagnostic domain.

For WHO1001, this is primarily the A/PL addressing model.

A physical Device's diagnostic WHERE, however, should not automatically be treated as the intrinsic address of every Module within that Device.

A Device may expose several Modules with different addresses.

See Diagnostic Address Discovery

Device Selection

Once a Device has been discovered, MyHOME Suite can select it by hardware ID for a particular operation.

Two important selection modes have been observed:

Command Purpose
WHAT10#ID Select Device for interview/read operations
WHAT9#ID Select Device for programming

Despite selecting different operating modes, both initially cause the Device to produce essentially the same automatic Device description.

             Device selection
                   │
        ┌──────────┴──────────┐
        │                     │
     WHAT10                 WHAT9
   Interview              Programming
        │                     │
        └──────────┬──────────┘
                   ▼
        Automatic Device description
                   │
                   ▼
                 WHAT4

The subsequent operation determines whether MyHOME Suite continues into configuration reading or programming.

Automatic Device Description

After selection, the Device automatically reports its structure without MyHOME Suite requesting each dimension individually.

Depending on the Device, this can include:

DIM1   Device/catalogue identity
DIM2   Firmware
DIM3   Device metadata
DIM4   Device metadata
DIM5   Optional Device metadata
DIM6   Device metadata
DIM7   Diagnostic state
DIM13  Hardware ID
DIM30  Modules and Objects
DIM32  Intrinsic Module addresses

Not every Device reports every dimension.

This automatic description provides the structural context required for subsequent configuration operations.

It should be distinguished from the explicit configuration-reading phase, where Object properties are retrieved separately.

See Diagnostic Device Interview.

Device, Module and Object Model

The physical Device is not necessarily the smallest configurable unit.

A Device exposes one or more logical Modules, identified on the protocol by an internal slot index.

Each Module is associated with an Object defining its function.

The relationship is:

Physical Device
      │
      ├── Module 1
      │      └── Object
      │
      ├── Module 2
      │      └── Object
      │
      └── Module N
             └── Object

DIM30 exposes this relationship:

Device
  │
  ▼
Internal slot
  │
  ▼
Object ID
  │
  ▼
Enabled / disabled state

The Object ID maps to EN_KEY_OBJECT in the MH Catalogue.

Internal slot numbering is a protocol/database concept and does not necessarily correspond directly to the Module numbering displayed by MyHOME Suite.

See Device Modules and DIM30 and Objects.

Module Addressing

Some Objects possess their own intrinsic BUS address.

For WHO1001, this address can be reported through DIM32.

Conceptually:

Device
   │
   ▼
Module
   │
   ├── Object
   │
   └── Intrinsic address
           │
           ▼
         DIM32

This is important for multi-function Devices.

A physical Device can expose several Modules, each potentially having a different intrinsic A/PL address.

DIM32 should therefore be interpreted in the context of the Module rather than as a single Device-wide address.

Not every Object has such an intrinsic address.

See Module Addressing and DIM32.

Configuration Model

Once the Object associated with a Module is known, its configuration can be interpreted using the MH Catalogue.

The basic model is:

Module
  │
  ▼
Object
  │
  ▼
EN_KEY_OBJECT
  │
  ▼
EN_CONF
  │
  ▼
EN_CONF_RANGE
  │
  ▼
Configuration properties

DIM35 serializes these Object configuration properties on the diagnostic protocol.

The configuration index is Object-local:

Object ID + CONF_IDX → Configuration property

Consequently, a DIM35 index cannot be interpreted correctly without first resolving the Module's Object through DIM30.

Firmware-specific catalogue filtering can further restrict which properties and values are actually available.

See Module Configuration and DIM35 and MHCatalogue Configuration Schema.

Intrinsic and Destination Addressing

A distinction must be made between the address of a Module itself and an address used by its configured function.

For example:

Actuator Module
     │
     └── DIM32 → own A/PL address

while a command Object may instead contain:

Command Module
     │
     └── DIM35 → destination A/PL

These represent different concepts.

An A/PL-like value appearing in configuration data should therefore not automatically be interpreted as the Module's intrinsic BUS address.

Reading Architecture

Device interrogation consists of two related but distinct stages.

Device Description

Selection with WHAT10 causes the Device to automatically describe itself:

WHAT10#ID
    │
    ▼
Automatic Device description
    │
    ├── Identity
    ├── Firmware
    ├── Hardware ID
    ├── Modules / Objects
    └── Module addresses
    │
    ▼
WHAT4

Configuration Reading

MyHOME Suite can subsequently request the Object configuration:

WHAT10
   │
   ▼
Automatic description
   │
   ▼
WHAT4
   │
   ▼
DIM38
   │
   ▼
DIM35 / Object-specific configuration
   │
   ▼
WHAT6

This distinction is important: the automatic Device description establishes the Device structure, while the later phase retrieves the configurable properties of its Objects.

See Diagnostic Configuration Reading.

Programming Architecture

Programming uses the same Device → Module → Object → Configuration hierarchy in the opposite direction.

The Device is selected using WHAT9:

WHAT9
   │
   ▼
Automatic Device description
   │
   ▼
WHAT4
   │
   ▼
WHAT14
   │
   ▼
#DIM30
   │
   ▼
Assign Object
   │
   ▼
#DIM35
   │
   ▼
Write configuration
   │
   ▼
WHAT4 / WHAT52
   │
   ▼
WHAT2

The initial Device description is therefore common to both interview and programming selection.

The paths diverge after that description:

                  Device
                    │
           Hardware ID selection
                    │
          ┌─────────┴─────────┐
          │                   │
       WHAT10               WHAT9
          │                   │
          └─────────┬─────────┘
                    ▼
          Automatic description
                    │
                  WHAT4
                    │
          ┌─────────┴─────────┐
          │                   │
        DIM38               WHAT14
          │                   │
          ▼                   ▼
         Read                Write
    configuration        configuration

See Diagnostic Device Programming.

Read and Write Model

Several diagnostic dimensions have corresponding write forms.

The observed symmetry is:

Model element Read Write
Module/Object association DIM30 #DIM30
Object configuration DIM35 #DIM35

This produces a bidirectional model:

             MH Catalogue
                  │
                  ▼
Device → Module → Object → Configuration
   ▲                           │
   │                           │
   ├──── DIM30 / DIM35 ───────┤
   │                           │
   └──── #DIM30 / #DIM35 ◄────┘

The diagnostic protocol therefore acts not only as a diagnostic interface but also as a serialization mechanism for the Device configuration model.

Relationship with the MH Catalogue

The protocol and catalogue describe complementary parts of the same configuration architecture.

The protocol supplies the live state:

Hardware ID
Firmware
Modules
Selected Objects
Addresses
Configuration values

The catalogue supplies the model required to interpret that state:

Supported Devices
Firmware definitions
Available Modules
Allowed Objects
Configuration properties
Ranges
Enumerations
Filters

Together they provide the decoding path:

Diagnostic WHO
      │
      ▼
Physical Device
      │
      ▼
Device + Firmware
      │
      ▼
Internal Module
      │
    DIM30
      │
      ▼
Object
   ┌──┴──────────────┐
   │                 │
 DIM32             DIM35
   │                 │
   ▼                 ▼
Intrinsic        Configuration
address          properties
                     │
                     ▼
              MH Catalogue schema

This architecture forms the basis for interpreting both configuration reads and programming operations.

See Also

Clone this wiki locally