-
Notifications
You must be signed in to change notification settings - Fork 31
Objects
An Object represents a logical function that can be implemented by a Module of a MyHOME Device.
Examples include:
- Light actuator;
- Dimmer actuator;
- Shutter actuator;
- Light control;
- Scheduled scenario PLUS;
- daylight/presence sensors;
- IR scenario control.
Objects form the central link between the Device's Module structure and its configuration:
Device
│
▼
Module
│
▼
Object
│
▼
Configuration
In the MH Catalogue database, Objects are primarily represented by EN_KEY_OBJECT.
The database and earlier reverse-engineering work also use the terms Key Object and KO. In this documentation, these are referred to simply as Objects.
Each Object has a numeric Object ID.
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 ID is important because it is also exposed directly by the diagnostic protocol through DIM30.
DIM30 OBJECT_ID
│
▼
EN_KEY_OBJECT
│
▼
Object
This relationship allows a Module reported by a physical Device to be associated with its logical function in the catalogue.
A Module is a logical unit exposed by a Device firmware.
The Object determines what that Module currently does.
For example:
Device
│
├── Module 1
│ └── Light actuator
│
├── Module 2
│ └── Light actuator
│
└── Module 3
└── Light control
Different physical Devices can expose very different Module/Object structures.
An actuator-only Device may expose only actuator Objects, while a combined Device can expose both actuator and independently configurable command Objects.
The diagnostic protocol identifies Modules using an internal slot index.
For example:
*#1001*0*30*3*406*0##
indicates that internal slot 3 is associated with Object 406.
The internal slot index should not be assumed to equal the Module number displayed by MyHOME Suite.
An Object describes a logical function, not the physical Device itself.
For example:
Physical Device
"Shutter actuator bus"
│
▼
Object
"Shutter actuator"
These descriptions come from different catalogue layers:
| Concept | Catalogue source |
|---|---|
| Physical Device description | EN_DEVICE.name |
| Object/function description | EN_KEY_OBJECT.descr |
This distinction is particularly important when identifying Devices from diagnostic captures.
A Device can also expose several Objects simultaneously, so an Object description should not normally be used as the description of the entire physical Device.
Object availability depends on firmware.
The catalogue associates Objects with firmware through structures including:
AS_OBJECT_FIRMWARE
Conceptually:
Device
│
▼
Firmware
│
▼
Supported Objects
An Object existing in EN_KEY_OBJECT therefore does not imply that every Device or firmware can implement it.
The relevant Device, firmware, and Module context must also be considered.
A Virgin Object represents a configurable Object class from which one or more normal Objects may be selected.
The main compatibility relationship is:
Virgin Object
│
├── Object A
├── Object B
└── Object C
This mapping is represented by:
AS_OBJECT_VIRGIN_OBJECT
A practical Object-selection model is:
Module
│
▼
Virgin Object
│
▼
Compatible Objects
│
▼
Firmware-supported Objects
│
▼
Selectable Object
This is particularly useful for understanding the Function type choices displayed by MyHOME Suite.
See Virgin Objects.
Each Object can define its own configuration schema.
The primary relationship is:
EN_KEY_OBJECT
│
▼
EN_CONF
│
▼
EN_CONF_RANGE
EN_CONF defines the configurable properties of the Object, while EN_CONF_RANGE defines their possible values or ranges.
For example:
Object 128
Scenarios daylight and presence sensor
│
├── Time delay — Hours
├── Time delay — Minutes
├── Time delay — Seconds
├── PIR sensitivity
├── US sensitivity
└── Detection scheme
Another Object can use the same configuration indexes for completely different purposes.
Therefore:
A configuration index has meaning only within the context of its Object.
During configuration reading, the Object provides the context required to decode DIM35.
The decoding sequence is:
DIM35 INTERNAL_SLOT
│
▼
DIM30
│
▼
OBJECT_ID
│
▼
EN_KEY_OBJECT
│
▼
EN_CONF + CONF_IDX
│
▼
Configuration property
For example:
DIM30
slot 1 → Object 128
DIM35
slot 1
idx 20
value 1
Object 128 defines configuration index 20 as PIR sensitivity.
The corresponding value mapping gives:
1 → Medium
Therefore:
PIR sensitivity = Medium
Without first resolving Object 128, the meaning of idx 20 cannot be determined reliably.
See DIM35 - Module Configuration and MHCatalogue Configuration Schema.
Not every Module provides the same degree of Object selection.
Some Modules implement a specific function determined by their hardware/firmware.
For example, an actuator Module may always be a Light actuator.
Conceptually:
Module
│
└── fixed Object
The user can configure the Object's properties but cannot replace the Object with an unrelated function.
Other Modules can support several alternative Objects.
Conceptually:
Module
│
▼
Virgin Object
│
├── Object A
├── Object B
└── Object C
MyHOME Suite can then expose these alternatives through its Function type selection.
The actual choices depend on the Module and firmware.
DIM30 does more than report Object assignments.
A write form has also been observed:
*#1001*WHERE*#30*INTERNAL_SLOT*OBJECT_ID##
For example:
*#1001*0*#30*3*406##
assigns Object 406 to internal slot 3 during programming.
This creates a clear read/write symmetry:
READ
DIM30
│
▼
Which Object is assigned?
WRITE
#DIM30
│
▼
Assign this Object
Once the Object is assigned, its properties can be programmed through mechanisms such as #DIM35.
Determining which Objects are valid for a Module requires more than a lookup in EN_KEY_OBJECT.
The current model combines:
Module structure
+
Virgin Object compatibility
+
Firmware support
=
Valid Objects
Important catalogue structures include:
EN_KEY_OBJECT
EN_VIRGIN_OBJECT
AS_OBJECT_VIRGIN_OBJECT
AS_OBJECT_FIRMWARE
AS_FIRMWARE_VIRGIN_OBJECT
EN_SLOT_KO_VIRGIN
EN_SLOTS
This distinction is important:
Object exists in catalogue ≠ Object is valid for this Module
The current Object model can be summarized as:
Physical Device
│
▼
Firmware
│
▼
Module
│
├── fixed Object
│
└── Virgin Object
│
▼
compatible Objects
│
▼
selected Object
│
▼
Configuration schema
│
▼
Current configuration
The diagnostic protocol exposes this model primarily through:
DIM30 → Module / Object association
DIM32 → intrinsic Module/Object address
DIM35 → Object configuration
The MH Catalogue provides the semantic definitions required to interpret those values.