-
Notifications
You must be signed in to change notification settings - Fork 31
MHCatalogue Configuration Schema
The MHCatalogue Configuration Schema defines how MyHOME Suite represents the configurable properties of an Object.
It provides the information required to interpret raw diagnostic values such as those carried by DIM35, and also appears to provide the schema used when constructing configuration writes.
At a high level:
Device
│
▼
Firmware
│
▼
Module
│
▼
Object
│
▼
Configuration properties
│
▼
Allowed values / ranges
│
▼
Firmware-specific filtering
│
▼
Effective MyHOME Suite configuration
The most important tables involved are:
EN_KEY_OBJECT
EN_CONF
EN_CONF_RANGE
EN_FILTER
EN_FILTER_RANGE
AS_OBJECT_FIRMWARE
Additional tables can participate in more specialized configuration logic.
The configuration schema is centered on the Object.
An Object defines a configurable function such as:
- Light actuator
- Dimmer actuator
- Shutter actuator
- Light control
- Scheduled scenario PLUS
- Scenarios daylight and presence sensor
- IR scenario control
Each Object can expose one or more configuration properties.
Conceptually:
Object
│
├── Configuration property
│ └── Allowed values
│
├── Configuration property
│ └── Allowed values
│
└── Configuration property
└── Allowed values
The central relationship is:
EN_KEY_OBJECT
│
▼
EN_CONF
│
▼
EN_CONF_RANGE
Firmware-specific tables then restrict that generic model.
EN_KEY_OBJECT represents Objects.
Each Object corresponds to a function that can be associated with a Module.
Examples include:
| Object ID | Description |
|---|---|
6 |
Light actuator |
8 |
Dimmer actuator |
128 |
Scenarios daylight and presence sensor |
164 |
Scenarios daylight sensor |
218 |
Shutter actuator |
400 |
Light control |
406 |
Scheduled scenario PLUS |
431 |
IR scenario control |
In diagnostic communication, the Object ID is typically obtained from DIM30.
This creates the first important link:
DIM30
│
└── OBJECT_ID
│
▼
EN_KEY_OBJECT
Once the Object is known, its configuration schema can be resolved.
EN_CONF defines configuration properties associated with an Object.
The most important fields for diagnostic decoding are conceptually:
id_key_object
idx
configuration metadata
The key relationship is:
EN_CONF.id_key_object
│
▼
EN_KEY_OBJECT
while EN_CONF.idx corresponds to the configuration index used by DIM35.
A DIM35 frame has the observed form:
*#1001*WHERE*35#CONF_IDX#INTERNAL_SLOT*VALUE##
The configuration index is resolved as:
DIM35 CONF_IDX
│
▼
EN_CONF.idx
but only after the Object associated with the Module has been identified.
The complete lookup is therefore:
INTERNAL_SLOT
│
▼
DIM30
│
▼
OBJECT_ID
│
▼
EN_KEY_OBJECT
│
▼
EN_CONF
WHERE id_key_object = OBJECT_ID
AND idx = CONF_IDX
This is one of the most important relationships in the configuration model.
An EN_CONF.idx value does not have a universal meaning.
For example idx = 3 can represent different properties for different Objects.
The meaningful key is therefore effectively OBJECT_ID + idx, not idx alone.
This mirrors the diagnostic representation:
Object
+
CONF_IDX
+
VALUE
EN_CONF_RANGE defines the values accepted by a configuration property.
Depending on the property, these can represent:
- enumerations;
- numeric ranges;
- Boolean choices;
- discrete configuration modes;
- address components;
- timing values;
- percentages;
- identifiers.
Conceptually:
EN_CONF
│
▼
EN_CONF_RANGE
│
├── value 0
├── value 1
├── value 2
└── ...
For example, an Object may define PIR sensitivity with values:
-
0→ Low -
1→ Medium -
2→ High -
3→ Maximum
A diagnostic value DIM35 VALUE = 1 can therefore be translated into PIR sensitivity = Medium.
Other properties are continuous or integer-based.
Examples include:
- Hours
- Minutes
- Seconds
- Scenario number
- Preset position
- Remote control ID components
For these, EN_CONF_RANGE can define limits rather than human-readable enumerations.
The configuration schema stored in EN_CONF and EN_CONF_RANGE is often broader than the configuration actually exposed by a particular Device.
The catalogue must therefore distinguish between Generic Object capability and Capability implemented by this firmware.
The effective configuration is derived from both.
Generic Object schema
│
▼
Device firmware
│
▼
Firmware support
│
▼
Filtering
│
▼
Effective schema
AS_OBJECT_FIRMWARE associates Objects with firmware implementations.
This is important because an Object may exist generically in the catalogue while not being supported by every firmware version. This relationship is used when determining which Objects are actually available for a Device. It is particularly important in conjunction with Module definitions.
For example:
Device
│
▼
Firmware
│
▼
Module
│
▼
Objects valid for that Module
See Virgin Objects and Device Modules and DIM30.
Firmware-specific filtering is represented primarily through:
EN_FILTER
EN_FILTER_RANGE
These tables refine the generic configuration schema.
EN_FILTER can suppress an entire configuration property.
The observed behavior strongly supports the interpretation:
whole_range = 1
│
▼
Hide / suppress entire property
Conceptually:
Generic Object
│
├── property A
├── property B
└── property C
│
▼
EN_FILTER
│
▼
property C hidden
The resulting UI exposes only property A and property B
When a property remains available but certain values must be removed, EN_FILTER_RANGE is used.
The observed model is:
whole_range = 0
│
▼
Property remains visible
│
▼
EN_FILTER_RANGE
│
▼
Specific values removed
This behavior matches multiple MyHOME Suite UI observations.
Object 218 provides several useful examples.
The generic configuration contains multiple possible values. Firmware filters remove unsupported options so that MyHOME Suite exposes only the allowed values. Observed UI choices include:
Standard
Pulse
while a generic value is filtered out. This demonstrates value-level filtering.
The generic schema includes:
Preset 1
...
Preset 10
but MyHOME Suite allows selection only from 1 .. 9
The value corresponding to 10 is filtered.
The configuration schema contains properties for:
P1
P2
...
P10
but P10 is not user-editable in MyHOME Suite and is fixed at 100%.
The filtering data suppresses the configuration property associated with P10.
This is a strong example of an entire configuration property being present generically but hidden for the effective firmware/UI.
Object 128, Scenarios daylight and presence sensor, demonstrates both property-level and value-level filtering.
Its configuration includes:
-
idx 10→ Hours -
idx 11→ Minutes -
idx 12→ Seconds -
idx 20→ PIR sensitivity -
idx 21→ US sensitivity -
idx 22→ Detection scheme
The generic enumeration is:
-
0→ Low -
1→ Medium -
2→ High -
3→ Maximum
These values are exposed normally.
The property represented by idx 21 exists in the generic Object schema.
For the firmware investigated, it is filtered out. MyHOME Suite therefore does not expose it.
The generic Object schema includes values such as:
-
1→ PIR only -
2→ US only -
3→ PIR and US -
4→ PIR or US
The investigated Device exposes only PIR only because the unsupported detection modes are filtered.
This provides a clear example of:
EN_CONF
│
▼
generic property
│
▼
EN_CONF_RANGE
│
▼
generic values
│
▼
EN_FILTER / EN_FILTER_RANGE
│
▼
effective firmware-specific UI
Object 431 provides another useful example.
Its configuration includes properties such as:
- Scenario number
- Regulation type
- Remote control ID
- Push button number
One configuration property contains regulation-type choices. The generic schema includes more choices than the firmware used by the investigated Device allows. Firmware filtering removes the unsupported option. This again demonstrates that:
The Object schema defines the complete conceptual configuration space, while filters define the subset exposed by a particular firmware.
Not every user-facing configuration value maps directly to one DIM35 property.
Some values are split across multiple configuration entries.
Object 406, Scheduled scenario PLUS, stores a CEN number using two configuration properties.
The observed relationship is:
-
idx 0→ low component -
idx 1→ high component
The effective value is:
CEN = LOW + (HIGH << 8)
The catalogue schema therefore describes the serialized representation, which may require additional reconstruction before producing the user-facing value.
Object 431 provides another example.
Its Remote control ID is split across idx 20 (8 bits), idx 21 (8 bits) and idx 22 (4 bits) for a total of 20 bits matching the UI range 0 .. 1048575.
The exact byte/nibble ordering has not yet been fully established. This demonstrates that the database schema can describe low-level serialized properties rather than only high-level UI values.
The configuration schema cannot be decoded from EN_CONF alone.
The complete context includes:
Device
│
▼
Firmware
│
▼
Module
│
▼
Object
│
▼
Configuration property
Each level contributes information.
| Context level | Role in configuration decoding |
|---|---|
| Device | Determines the physical hardware. |
| Firmware | Determines which Modules, Objects, properties, and values are actually implemented. |
| Module | Determines where the Object is instantiated within the Device. |
| Object | Determines the applicable configuration schema. |
| Configuration Property | Determines the meaning of a DIM35 index and its value. |
The effective decoding key is therefore much richer than simply idx → property.
A more accurate model is Device + Firmware + Module + Object + idx → effective configuration property
DIM30 identifies the Object associated with a Module.
*#1001*WHERE*30*INTERNAL_SLOT*OBJECT_ID*FLAG##
This creates the mapping of an OBJECT_ID to an INTERNAL_SLOT, which is required before a later DIM35 frame can be decoded.
DIM35 can be considered a serialized representation of EN_CONF.
EN_CONF
│
├── idx
├── type
├── range
└── metadata
│
▼
DIM35
│
├── CONF_IDX
└── VALUE
The database provides the schema, while the Device provides the current values.
Catalogue
"What does idx 20 mean?"
│
▼
Diagnostic Device
"What is idx 20 currently set to?"
The configuration schema also participates in selecting which Object can be assigned to a Module.
The main related tables are:
EN_VIRGIN_OBJECT
AS_OBJECT_VIRGIN_OBJECT
AS_FIRMWARE_VIRGIN_OBJECT
EN_SLOT_KO_VIRGIN
AS_OBJECT_FIRMWARE
EN_SLOTS
The conceptual process is:
Module
│
▼
Virgin Object
│
▼
Possible Objects
│
▼
Firmware-supported Objects
│
▼
Effective selectable Objects
Once an Object has been selected, its EN_CONF schema becomes the basis for configuring that Module.
See Virgin Objects.
The catalogue should not be interpreted as a literal copy of the MyHOME Suite user interface.
It is more accurate to view it as a lower-level configuration model from which the UI is generated.
The database can contain:
- hidden properties;
- unsupported generic values;
- fixed values;
- serialized sub-fields;
- firmware-specific alternatives;
- internal implementation details.
The UI is therefore the result of multiple processing layers:
Generic Object model
│
▼
Firmware compatibility
│
▼
Filtering
│
▼
Value composition
│
▼
UI presentation
This explains why simply listing every EN_CONF row for an Object does not reproduce the MyHOME Suite configuration screen exactly.