Skip to content

Configuration Filters

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

Overview

The MH Catalogue can define a broader configuration schema for an Object than the configuration actually supported by a particular Device and firmware.

Configuration filters specialize this generic schema by removing configuration properties or individual values that are not applicable in a specific firmware context.

The effective configuration model is therefore:

Generic Object configuration
          │
          ▼
       EN_CONF
          │
          ▼
     EN_CONF_RANGE
          │
          ▼
Firmware-specific filters
          │
          ▼
Effective configuration
          │
          ▼
MyHOME Suite

This filtering is important when decoding DIM35 and when determining which values can safely be written through #DIM35.

Configuration Context

A configuration property cannot be interpreted from the Object definition alone.

The effective schema depends on several levels of context:

Context Role
Device Identifies the physical hardware
Firmware Determines implemented capabilities
Module Determines where the Object is instantiated
Object Defines the generic configuration schema
Configuration property Defines the meaning and possible values of a DIM35 index
Filter Restricts the schema for the applicable firmware context

Conceptually:

Device
  │
  ▼
Firmware
  │
  ▼
Module
  │
  ▼
Object
  │
  ▼
Generic configuration
  │
  ▼
Filters
  │
  ▼
Effective configuration

Catalogue Tables

The main configuration tables are:

EN_KEY_OBJECT
      │
      ▼
   EN_CONF
      │
      ▼
EN_CONF_RANGE

These define the generic configuration properties and their possible values.

Filtering introduces:

EN_FILTER
    │
    ▼
EN_FILTER_RANGE

Together, these tables specialize the generic configuration schema for the relevant firmware context.

See MHCatalogue Configuration Schema.

Filter Types

Two principal filtering behaviors have been identified.

Complete Property Filtering

A filter with:

whole_range = 1

removes the complete configuration property from the effective schema.

Conceptually:

EN_CONF property
      │
      ▼
EN_FILTER
whole_range = 1
      │
      ▼
Property unavailable

The property can still exist in the generic Object definition even though MyHOME Suite does not expose it for the applicable firmware.

Individual Value Filtering

A filter with:

whole_range = 0

can use EN_FILTER_RANGE to remove particular values from the property's generic range.

Conceptually:

Generic values
0  1  2  3
      │
      ▼
EN_FILTER_RANGE
      │
      ▼
Filtered values
      │
      ▼
Effective values
0  1  2

The property itself remains available, but one or more values are excluded.

Effective Configuration

The generic configuration schema should therefore not be presented directly as the set of values supported by a Device.

The effective model is:

EN_CONF
   +
EN_CONF_RANGE
   +
Firmware context
   +
EN_FILTER
   +
EN_FILTER_RANGE
   =
Effective configuration schema

This distinction is particularly important when reconstructing the configuration interface exposed by MyHOME Suite.

Example: Shutter Actuator

Object 218, Shutter actuator, provides several examples of firmware-specific filtering.

Its generic configuration includes properties such as:

EN_CONF.idx Property
0 Modality
1 Shutter type
6 Local button modality
8 Preset number
16–25 Preset positions P1–P10
240–249 Groups G1–G10

For the investigated shutter actuator firmware, filters modify this generic schema before it is exposed in MyHOME Suite.

Shutter Type

The generic range for the shutter-type property contains more possibilities than those available for the investigated firmware.

Filtering removes unsupported values so that MyHOME Suite exposes the applicable choices, such as:

Standard
Pulse

The Object definition therefore describes the broader capability model, while the firmware filter determines the actual choices available on the Device.

Preset Number

The generic preset-number configuration includes value 10.

For the investigated firmware, value 10 is filtered from the selectable range.

MyHOME Suite consequently exposes:

1 ... 9

rather than the complete generic range.

Preset Position P10

Object 218 defines configuration indexes for preset positions P1 through P10.

However, the P10 property is filtered as a complete property for the investigated firmware.

The resulting UI behavior is:

P1 ... P9 → configurable
P10       → fixed at 100%

This is an example where the generic Object schema contains a configuration property that is not user-configurable on the actual firmware.

Example: Presence Sensor

Object 128, Scenarios daylight and presence sensor, also demonstrates firmware specialization.

The generic Object schema contains properties for:

  • PIR sensitivity;
  • ultrasonic sensitivity;
  • detection scheme;
  • time delay.

The investigated 08CF44BF Device exposes PIR-based detection but does not expose the complete generic sensor capability set.

Detection Scheme

The generic detection-scheme enumeration contains several modes:

Raw value Generic meaning
1 PIR only
2 US only
3 PIR and US
4 PIR or US

For the investigated Device/firmware, filtering restricts the effective configuration to:

PIR only

MyHOME Suite consequently displays PIR only as a non-modifiable detection scheme.

Ultrasonic Configuration

The generic Object definition also contains ultrasonic-related configuration.

These properties are not applicable to the investigated PIR-only hardware configuration and are filtered from the effective configuration exposed by MyHOME Suite.

This demonstrates why the Object schema alone cannot be used to infer the physical capabilities of a Device.

Example: IR Scenario Control

Object 431, IR scenario control, contains a regulation-type configuration.

Its generic schema contains a broader enumeration than the one exposed by the investigated firmware.

A firmware-specific filter removes the unsupported value, leaving the choices presented by MyHOME Suite:

Regulate all
Lights only
Shutters only

Again, the effective enumeration is obtained by applying filters to the generic Object range.

Relationship with DIM35

DIM35 carries the actual configuration values of an Object:

*#1001*WHERE*35#CONF_IDX#INTERNAL_SLOT*VALUE##

The decoding path is:

INTERNAL_SLOT
      │
      ▼
    DIM30
      │
      ▼
   OBJECT_ID
      │
      ▼
EN_KEY_OBJECT
      │
      ▼
EN_CONF.idx = CONF_IDX
      │
      ▼
EN_CONF_RANGE
      │
      ▼
Apply configuration filters
      │
      ▼
Interpret VALUE

Filters therefore form part of the context required to reconstruct the configuration model associated with DIM35.

They do not change the meaning of CONF_IDX; instead, they determine whether the property or particular values are applicable in the current firmware context.

See Module Configuration and DIM35.

Relationship with Programming

Filters are also important when generating configuration writes.

A generic EN_CONF_RANGE entry does not by itself prove that a value should be written to every Device implementing that Object.

Before generating:

*#1001*WHERE*#35#CONF_IDX#INTERNAL_SLOT*VALUE##

the effective firmware-specific schema should be determined.

The programming model is therefore:

Device + Firmware
       │
       ▼
Module + Object
       │
       ▼
Generic EN_CONF schema
       │
       ▼
Apply filters
       │
       ▼
Effective properties and values
       │
       ▼
#DIM35

A property removed by a complete-property filter should not automatically be treated as writable merely because it exists in EN_CONF.

Likewise, a value excluded by EN_FILTER_RANGE should not be treated as supported merely because it exists in EN_CONF_RANGE.

See Diagnostic Device Programming.

Generic Capability vs Device Capability

Configuration filters reveal an important characteristic of the MH Catalogue data model.

EN_KEY_OBJECT, EN_CONF, and EN_CONF_RANGE primarily describe a generic Object capability model.

The actual Device configuration is a specialization of that model:

                Object
                  │
        Generic capability model
                  │
                  ▼
              Firmware
                  │
                  ▼
               Filters
                  │
                  ▼
        Effective Device capability
                  │
                  ▼
            MyHOME Suite UI

Consequently:

The presence of a property or value in the generic Object schema does not by itself prove that the property or value is supported by a particular Device firmware.

This distinction should be preserved when using the MH Catalogue for protocol decoding.

Decoding Procedure

When reconstructing the effective configuration of a Module:

  1. Identify the Device and firmware.
  2. Resolve the internal Module slot.
  3. Resolve its Object through DIM30.
  4. Load the Object's generic EN_CONF properties.
  5. Load their generic EN_CONF_RANGE definitions.
  6. Determine the filters applicable to the firmware context.
  7. Remove complete properties where whole_range = 1.
  8. Remove filtered values through EN_FILTER_RANGE where applicable.
  9. Interpret the resulting DIM35 values against the effective schema.

The result should correspond much more closely to the configuration exposed by MyHOME Suite than the unfiltered Object schema alone.

Summary

Configuration filters specialize the generic MH Catalogue Object schema for a particular firmware context.

Two important behaviors have been identified:

whole_range = 1
      │
      ▼
Remove complete property

and:

whole_range = 0
      │
      ▼
EN_FILTER_RANGE
      │
      ▼
Remove individual values

The complete configuration-decoding model is therefore:

Device
  │
Firmware
  │
Module
  │
Object
  │
EN_CONF
  │
EN_CONF_RANGE
  │
Configuration filters
  │
  ▼
Effective configuration
  │
  ├── DIM35 reading
  │
  └── #DIM35 programming

Filters are the mechanism that explains why the generic configuration stored in the MH Catalogue can differ from the properties and values actually exposed by MyHOME Suite for a specific Device and firmware.

See Also

Clone this wiki locally