Skip to content

MHCatalogue Database

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

Overview

The MH Catalogue Database is the SQLite catalogue used by MyHOME Suite to describe supported Devices, firmware, Modules, Objects, and their configuration capabilities.

It provides the static model that MyHOME Suite combines with information read from a physical installation.

MHCatalogue_ERD_current

The database does not represent the current state of an installation. Instead, it describes how supported hardware and its possible configurations should be interpreted.

Main Data Model

The catalogue can be viewed as several interconnected layers:

Device Catalogue
      │
      ▼
Firmware
      │
      ▼
Module Structure
      │
      ▼
Object Model
      │
      ▼
Configuration Schema
Layer Purpose Important tables
Device Describes physical products EN_ITEM, EN_DEVICE
System Associates products with functional systems EN_SYSTEM, AS_ITEM_SYSTEM
Firmware Describes supported firmware implementations EN_FIRMWARE, EN_BUILDS
Module Describes logical units exposed by firmware EN_SLOTS
Object Describes functions assignable to Modules EN_KEY_OBJECT
Virgin Object Describes configurable/unassigned Object classes EN_VIRGIN_OBJECT
Configuration Defines Object properties and values EN_CONF, EN_CONF_RANGE
Filtering Restricts generic configuration for specific implementations EN_FILTER, EN_FILTER_RANGE

Devices

The Device layer describes physical MyHOME products.

Physical Device Description

EN_DEVICE contains Device-specific catalogue information.

For Device identification, the preferred standard description is:

EN_DEVICE.name

This describes the physical Device, rather than one of its individual functions.

For example:

Device
"Shutter actuator bus"

is distinct from an Object description such as:

Object
"Shutter actuator"

The distinction is important when interpreting diagnostic scans.

Items and Commercial Products

The catalogue separates physical/product information across related item and Device structures.

Commercial information such as product codes/SKUs belongs to this catalogue layer.

A single functional Device definition can therefore be associated with commercial product information without requiring the diagnostic protocol itself to transmit a SKU.

Systems and Buses

The catalogue organizes Devices and Objects into functional systems.

Important tables include:

EN_SYSTEM
AS_ITEM_SYSTEM
AS_OBJECT_SYSTEM
AS_BUS_SYSTEM
EN_BUS
EN_BUS_TYPE
AS_BUS_ITEM

EN_SYSTEM

EN_SYSTEM contains functional domains such as:

Automation
Temperature Control
Alarm
Video Door Entry
Sound System
Energy Management
Access Control

AS_ITEM_SYSTEM associates catalogue items with these systems.

Diagnostic WHO Is Separate

The system model should not be confused with Diagnostic WHO numbering.

In particular EN_SYSTEM.sys_modobj is not the Diagnostic WHO.

No direct database mapping has yet been identified between EN_SYSTEM and values such as:

WHO1001
WHO1004
WHO1018
WHO1023

See Diagnostic WHO Domains and MHCatalogue Systems and Buses.

Firmware

Firmware is an important intermediate layer between a physical Device and the functions it exposes.

Relevant tables include:

EN_FIRMWARE
EN_BUILDS
AS_OBJECT_FIRMWARE
AS_FIRMWARE_VIRGIN_OBJECT

Diagnostic DIM2 provides firmware information that correlates with the catalogue's firmware representation.

Conceptually:

Device
  │
  ▼
Firmware
  │
  ├── Module structure
  ├── supported Objects
  └── configuration restrictions

The firmware context is therefore required to determine the effective capabilities of a Device.

Modules

A physical Device can expose one or more configurable logical units.

In MyHOME Suite these are presented as Modules.

The catalogue represents their firmware-level structure primarily through tables such as:

EN_SLOTS
EN_SLOT_KO_VIRGIN

A Module provides a location where an Object can be instantiated:

Device
  │
  ▼
Firmware
  │
  ▼
Module
  │
  ▼
Object

Diagnostic DIM30 exposes a closely related runtime representation.

Internal Slot Index

The database and diagnostic protocol can use an internal slot/index representation. This should not automatically be equated with the Module number displayed by MyHOME Suite. Therefore:

Internal slot index ≠ necessarily GUI Module number

See Device Modules and DIM30.

Objects

Objects represent the logical functions implemented by Modules.

The principal table is:

EN_KEY_OBJECT

Examples include:

Light actuator
Dimmer actuator
Shutter actuator
Light control
Scheduled scenario PLUS
Scenarios daylight sensor
IR scenario control

Each Object has an Object ID.

Diagnostic DIM30 carries this identifier, creating a direct bridge between protocol and catalogue:

DIM30 OBJECT_ID
       │
       ▼
EN_KEY_OBJECT

The Object determines which configuration schema applies to the Module.

See MHCatalogue Object Model.

Virgin Objects

The catalogue also contains Virgin Objects, representing configurable Object classes before a particular normal Object/function is selected.

Important tables include:

EN_VIRGIN_OBJECT
AS_OBJECT_VIRGIN_OBJECT
AS_FIRMWARE_VIRGIN_OBJECT
EN_SLOT_KO_VIRGIN

A Virgin Object can be associated with several possible Objects:

Virgin Object
      │
      ├── Object A
      ├── Object B
      └── Object C

Firmware and Module restrictions further determine which choices are actually valid.

A practical selection model is:

Module
  │
  ▼
Virgin Object
  │
  ▼
Possible Objects
  │
  ▼
Firmware-supported Objects
  │
  ▼
Selectable Objects

See Virgin Objects.

Configuration Schema

Once an Object is assigned to a Module, its configurable properties are primarily described by:

EN_CONF
EN_CONF_RANGE

EN_CONF defines properties, while EN_CONF_RANGE describes their possible values or ranges.

The configuration index:

EN_CONF.idx

correlates with the configuration index carried by diagnostic DIM35.

The decoding chain is therefore:

DIM30
  │
  ▼
Object
  │
  ▼
DIM35 CONF_IDX
  │
  ▼
EN_CONF.idx
  │
  ▼
Configuration property
  │
  ▼
EN_CONF_RANGE
  │
  ▼
Interpreted value

See MHCatalogue Configuration Schema.

Configuration Filtering

The generic configuration schema can contain capabilities that are not available on every Device or firmware.

The effective schema is refined using tables such as:

EN_FILTER
EN_FILTER_RANGE

Observed behavior supports two important mechanisms:

Mechanism Effect
EN_FILTER with whole-range filtering Suppresses an entire configuration property
EN_FILTER_RANGE Suppresses individual values from a property's generic range

Conceptually:

Generic Object schema
       │
       ▼
Firmware context
       │
       ▼
Configuration filters
       │
       ▼
Effective schema
       │
       ▼
MyHOME Suite UI

This explains why simply listing all EN_CONF rows for an Object does not necessarily reproduce the configuration shown by MyHOME Suite.

See Configuration Filters.

Relationship with the Diagnostic Protocol

The catalogue and diagnostic protocol provide complementary information.

Catalogue

The catalogue answers questions such as:

  • What kind of Device is this?
  • Which Objects can this firmware expose?
  • What does configuration index 20 mean for this Object?
  • Which values are allowed?

Diagnostic Protocol

The diagnostic protocol answers questions such as:

  • Which physical Device is currently present?
  • Which firmware is it running?
  • Which Objects are currently assigned to its Modules?
  • What are their current configuration values?

Together

Diagnostic Protocol
      │
      ├── DIM1  → Device identification
      ├── DIM2  → Firmware
      ├── DIM30 → Module / Object
      └── DIM35 → Current configuration
                   │
                   ▼
             MH Catalogue
                   │
                   ▼
           Semantic decoding

Catalogue as Protocol Schema

One of the strongest findings from the reverse-engineering work is that the MH Catalogue acts as a schema for the diagnostic configuration protocol.

For reading:

Device
  │
  ▼
DIM30 / DIM35
  │
  ▼
MH Catalogue
  │
  ▼
MyHOME Suite configuration

For programming:

MyHOME Suite configuration
  │
  ▼
MH Catalogue
  │
  ▼
#DIM30 / #DIM35
  │
  ▼
Device

This relationship is especially strong for the mapping between:

DIM30 OBJECT_ID ↔ EN_KEY_OBJECT

DIM35 CONF_IDX ↔ EN_CONF.idx

The database therefore describes not only the UI but also much of the serialization model used to communicate configuration to and from Devices.

Main Relationships

The central catalogue relationships can be summarized as:

Device / Item
      │
      ├── System
      │
      └── Firmware
             │
             ▼
           Module
             │
             ├── Virgin Object
             │       │
             │       ▼
             │   possible Objects
             │
             └── Object
                    │
                    ▼
              Configuration
                    │
                    ▼
             Allowed values
                    │
                    ▼
                 Filters

These relationships provide the foundation for interpreting both Device interviews and Device programming.

See Also

Clone this wiki locally