Skip to content

Diagnostic Protocol Reverse Engineering

Jump to bottom
anotherjulien edited this page Sep 14, 2026 · 1 revision

Overview

The MyHOME diagnostic protocol contains structures and operations that are not fully described by the publicly available OpenWebNet documentation.

Understanding these mechanisms therefore requires reverse engineering from observed behavior.

The analysis combines:

  • OpenWebNet packet captures;
  • controlled MyHOME Suite operations;
  • known Device configurations;
  • comparison between multiple Devices and firmware versions;
  • the MHCatalogue database;
  • controlled configuration changes followed by new captures.

The objective is to reconstruct the relationship between:

MyHOME Suite
     │
     ▼
Diagnostic OpenWebNet
     │
     ▼
Physical Device
     │
     ▼
Modules
     │
     ▼
Objects
     │
     ▼
Configuration

Sources of Evidence

Protocol Captures

Packet captures provide the primary evidence for protocol structure.

Useful captures include operations such as:

  • discovery of all Devices;
  • discovery of configured or unconfigured Devices;
  • Device interview by hardware ID;
  • Device interview by address;
  • configuration reading;
  • configuration programming;
  • scans of different diagnostic WHO domains.

A single capture can reveal frame structure and sequencing, but comparison across captures is usually necessary before assigning semantics to individual fields.

MyHOME Suite

MyHOME Suite provides the user-visible interpretation of Device configuration.

The GUI is useful for correlating protocol values with concepts such as:

  • Device identity;
  • Modules;
  • Function type;
  • A/PL addressing;
  • operating modes;
  • configuration properties;
  • allowed values;
  • enabled or disabled Modules.

A particularly useful technique is to change one GUI property at a time and compare the resulting protocol traffic.

MH Catalogue

The MH Catalogue provides the structural model required to interpret many protocol values.

Important tables include:

Concept Main tables
Device EN_ITEM, EN_DEVICE
System EN_SYSTEM, AS_ITEM_SYSTEM
Firmware EN_FIRMWARE, EN_BUILDS
Module EN_SLOTS
Object EN_KEY_OBJECT
Virgin Object EN_VIRGIN_OBJECT
Object selection AS_OBJECT_VIRGIN_OBJECT, AS_OBJECT_FIRMWARE
Configuration EN_CONF, EN_CONF_RANGE
Filtering EN_FILTER, EN_FILTER_RANGE

The database should not be treated as a direct specification of the wire protocol. Instead, protocol values are correlated with catalogue entities through repeated observations.

Reverse-Engineering Method

Identify Frame Structure

The first step is to determine the stable structure of a diagnostic frame.

For example, repeated observations establish the DIM30 structure as:

*#1001*WHERE*30*INTERNAL_SLOT*OBJECT_ID*DISABLED##

At this stage, field positions can be identified before their semantics are fully understood.

Compare Multiple Devices

Values should then be compared across Devices with different known configurations.

For example, DIM32 reports:

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

Comparison with known actuator and sensor configurations showed that CONFIGURED_WHERE corresponds to the Module/Object's intrinsic A/PL address where such an address exists.

This conclusion is stronger than interpreting a single frame in isolation.

Correlate with the GUI

Known MyHOME Suite configuration provides another independent reference.

For example:

Device 004FBEC8
GUI: A=1, PL=1

DIM32:
CONFIGURED_WHERE = 11

and:

Device 00C16454
GUI: A=2, PL=3

DIM32:
CONFIGURED_WHERE = 23

Repeated agreement between GUI state and protocol values provides evidence for the field interpretation.

Correlate with the Catalogue

Protocol values can then be matched against the MH Catalogue.

For example:

DIM30 OBJECT_ID
       │
       ▼
EN_KEY_OBJECT
       │
       ▼
Object definition

Similarly:

DIM35 CONF_IDX
       │
       ▼
EN_CONF.idx
       │
       ▼
Configuration property

The combination of capture evidence and database structure is substantially more useful than either source alone.

Controlled Configuration Changes

One of the strongest reverse-engineering techniques is to modify a known configuration and observe exactly which protocol fields change.

The preferred experiment is:

Capture initial state
        │
        ▼
Change one property
        │
        ▼
Capture again
        │
        ▼
Compare frames
        │
        ▼
Identify changed value
        │
        ▼
Repeat with another value

Changing only one variable reduces ambiguity.

Example: Object Change

Device 08CF44BF was changed from Object 164, Scenarios daylight sensor, to Object 128, Scenarios daylight and presence sensor.

The corresponding DIM30 Object ID changed while Device-level dimensions such as DIM3 and DIM6 remained unchanged.

This separates Device-level metadata from Module/Object-level state.

Example: Configuration Properties

For Object 128, known GUI values could be correlated with DIM35:

idx 10 → Hours
idx 11 → Minutes
idx 12 → Seconds
idx 20 → PIR sensitivity
idx 22 → Detection scheme

Changing these properties provides a direct method for testing their protocol encoding.

Cross-Capture Validation

A proposed interpretation should be tested against as many captures as possible.

This is particularly important when a field initially admits several plausible explanations.

Example: DIM30 Enabled State

The final DIM30 field was tested by correlating each internal slot with subsequent DIM32 and DIM35 activity.

Across multiple captures, the pattern was consistent:

DISABLED Observed behavior
0 Module participates in configuration reporting
1 Module does not participate in corresponding configuration reporting

This also matches MyHOME Suite's enabled/disabled Module state.

The field is therefore documented as DISABLED:

0 → enabled
1 → disabled

DISABLED is a reverse-engineered field name; it is not known to be the official OpenWebNet terminology.

Correlation Scope

Protocol values must be correlated at the correct scope.

Possible scopes include:

Diagnostic domain
     │
     ▼
Device
     │
     ▼
Firmware
     │
     ▼
Internal Module slot
     │
     ▼
Object
     │
     ▼
Configuration property

Using the wrong scope can produce false correlations.

For example, an internal slot is often a better correlation key than WHERE during a Device operation because the diagnostic WHERE used during different phases can change.

Likewise, a DIM35 configuration index is meaningful only after resolving the Object associated with that internal slot.

Distinguishing Observation from Interpretation

Reverse engineering should distinguish what appears directly on the wire from the meaning assigned to it.

For example:

Observed:
*#1001*0015*32#1*1*0015##

Interpretation:
internal slot 1 has intrinsic address A=0, PL=15

The frame itself is an observation.

The interpretation results from correlation with multiple Devices, GUI configuration, and catalogue structure.

This distinction is particularly important for fields whose semantics remain unresolved.

Unknown Fields

Unknown values should remain unknown until sufficient evidence exists.

A good example is DIM1 VALUE2:

*#1001*WHERE*1*VALUE1*VALUE2*VALUE3*VALUE4##

Current mappings are:

Field Interpretation
VALUE1 AS_ITEM_SYSTEM.modobj
VALUE2 Unknown
VALUE3 EN_BRAND.brand_modobj
VALUE4 EN_LINE.line_modobj

Several classifications could potentially correlate with VALUE2, but correlation alone is insufficient to establish its meaning.

It should therefore remain documented simply as unknown until new evidence establishes its semantics.

The same principle applies to commands or dimensions whose behavioral position is known but whose exact internal operation is not.

Behavioral Semantics

Some protocol elements can be characterized by their observed behavior even when their exact internal meaning remains unknown.

For example:

Element Observed role
WHAT4 Phase/Object completion or application boundary
WHAT14 Preparation/opening of programming phase
WHAT52 Post-Object programming operation
DIM3 Device-level metadata
DIM6 Device-level metadata
DIM310 Object-specific/configuration information in limited observations

These descriptions intentionally avoid assigning more precise semantics than the captures currently support.

Read/Write Symmetry

Another useful technique is identifying symmetry between read and write frames.

For example:

READ
DIM30
DIM35

WRITE
#DIM30
#DIM35

Observed structures include:

READ
*#1001*WHERE*30*INTERNAL_SLOT*OBJECT_ID*DISABLED##
*#1001*WHERE*35#CONF_IDX#INTERNAL_SLOT*VALUE##

WRITE
*#1001*WHERE*#30*INTERNAL_SLOT*OBJECT_ID##
*#1001*WHERE*#35#CONF_IDX#INTERNAL_SLOT*VALUE##

This symmetry helps identify the role of fields and demonstrates that parts of the diagnostic protocol form a bidirectional configuration serialization mechanism.

Sequence Analysis

Individual frames should also be interpreted within their surrounding protocol sequence.

For Device selection, for example, both WHAT10 and WHAT9 cause an automatic Device-description response:

WHAT10 → select for interview
WHAT9  → select for programming
              │
              ▼
     Automatic Device description
              │
              ▼
            WHAT4

The subsequent operation distinguishes the two modes:

WHAT10
   │
   ▼
Automatic description
   │
   ▼
WHAT4
   │
   ▼
DIM38
   │
   ▼
Configuration reading

versus:

WHAT9
   │
   ▼
Automatic description
   │
   ▼
WHAT4
   │
   ▼
WHAT14
   │
   ▼
Configuration programming

This illustrates why command semantics should be inferred from complete transactions rather than isolated frames.

Firmware and Device Variation

Not every Device implements every dimension or configuration property.

Differences can result from:

  • Device hardware;
  • Object type;
  • firmware version;
  • available Modules;
  • enabled Modules;
  • firmware-specific catalogue filtering.

For example, the absence of DIM32 does not imply that a Module is disabled. Some Objects, such as command functions whose addresses represent destinations rather than their own intrinsic BUS address, may not expose DIM32.

Similarly, the generic configuration schema in EN_CONF can contain properties or values that are unavailable on a particular firmware.

Reverse engineering must therefore preserve Device, firmware, Module, and Object context.

Documentation Principles

The resulting protocol documentation follows several rules:

  1. Document directly observed frame structures separately from their interpretation.
  2. Validate field meanings across multiple Devices or controlled configuration changes where possible.
  3. Use the MH Catalogue as a decoding model, not as proof of wire-protocol semantics by itself.
  4. Keep unresolved fields explicitly unknown.
  5. Avoid transferring semantics between diagnostic WHO domains without capture evidence.
  6. Preserve the distinction between Device, Module, Object, and Configuration.
  7. Record behavioral roles when exact internal semantics cannot yet be established.
  8. Revisit earlier interpretations when new captures produce contradictory evidence.

The goal is not merely to assign names to unknown fields, but to construct a model that continues to explain new Devices and captures without contradiction.

Reverse-Engineering Workflow

A practical investigation workflow is:

Capture operation
      │
      ▼
Extract diagnostic frames
      │
      ▼
Group by Device and transaction
      │
      ▼
Identify stable frame structure
      │
      ▼
Compare Devices / configurations
      │
      ▼
Correlate with MyHOME Suite
      │
      ▼
Correlate with MH Catalogue
      │
      ▼
Form interpretation
      │
      ▼
Test against other captures
      │
      ▼
Controlled configuration change
      │
      ▼
Confirm, refine, or reject

This iterative process is the basis of the protocol model documented throughout this wiki.

See Also

Clone this wiki locally