-
Notifications
You must be signed in to change notification settings - Fork 31
Diagnostic Device interview
A Diagnostic Device Interview is the process by which MyHOME Suite interrogates a single physical Device after that Device has been discovered or is otherwise already known.
The purpose of the interview is to build a description of the Device before its Module configuration is read or modified.
At a high level:
Device selected
↓
Device identity
↓
Firmware and metadata
↓
Diagnostic state
↓
Hardware ID
↓
Module / Object enumeration
↓
Module addressing
↓
Description complete
↓
Configuration reading
The best-understood interview sequence is currently the Automation Diagnostic domain, WHO1001.
The same general mechanisms are expected to apply to other Diagnostic WHO domains, although their native addressing and some of their dimensions may differ.
See Diagnostic Device Discovery and Diagnostic WHO Domains.
An interview begins once MyHOME Suite has enough information to address one specific Device.
There are two principal ways to identify that Device:
_ Physical Device
│
┌──────────┴──────────┐
│ │
▼ ▼
Hardware ID Domain address
│ │
└──────────┬──────────┘
▼
Device Interview
The Device may have been found during a preceding discovery operation, or its hardware ID or address may already have been known.
Discovery is therefore not a mandatory part of every interview.
A Device can be selected directly using its unique hardware ID.
Under WHO1001, the observed request is:
*1001*10#<DEVICE_ID>*0##
The hardware ID is represented on the wire as a decimal integer.
For example, the Device conventionally identified as:
08CF44BF
has the decimal representation:
147801279
and can therefore be selected using:
*1001*10#147801279*0##
After this request, the Device begins its individual interview.
No preceding DIM13 enumeration is required when the hardware ID is already known.
A Device can also be interviewed directly through its native address within the Diagnostic WHO domain.
Under WHO1001, this uses the Automation A/PL address.
For example, a Device at:
A=0
PL=1
can be addressed using:
*#1001*01*0##
The Device then begins the same general interview process.
This means that hardware-ID selection and address selection are two different paths into essentially the same operation:
Hardware ID Address
│ │
▼ ▼
WHAT10 selection DIM0 request at WHERE
│ │
└───────────────┬──────────────────┘
▼
Device Interview
The exact address-selection syntax outside WHO1001 remains to be established.
When a Device is interviewed by address, its diagnostic responses naturally contain the corresponding WHERE.
For example:
*#1001*0015*13*147801279##
contains both:
- a diagnostic WHERE:
0015; - a hardware ID:
147801279.
The WHERE and hardware ID identify the Device in different ways and should not be treated as interchangeable identifiers.
The hardware ID identifies the physical Device.
The WHERE represents the Device in the addressing context of the Diagnostic WHO.
An interview can therefore establish a relationship such as:
Hardware ID
08CF44BF
│
│ interview
▼
Diagnostic WHERE
0015
│
▼
Automation address context
A=0 / PL=15
This association is particularly useful when a Device was originally found through address-based discovery.
The WHO1001 interview can be divided conceptually into several phases:
SELECT DEVICE
│
▼
DEVICE DESCRIPTION
│
├── identity
├── firmware
├── metadata
├── diagnostics
└── hardware ID
│
▼
MODULE DESCRIPTION
│
├── Module
├── Object
└── intrinsic address where applicable
│
▼
DESCRIPTION COMPLETION
│
▼
CONFIGURATION REQUEST
│
▼
MODULE CONFIGURATION
The boundary between these phases is useful conceptually, although some protocol commands involved in the transitions do not yet have fully established formal meanings.
DIM1 reports a catalogue/device identity signature.
The observed form is:
*#1001*WHERE*1*VALUE1*VALUE2*VALUE3*VALUE4##
Current interpretation:
| Field | Interpretation | Confidence |
|---|---|---|
VALUE1 |
AS_ITEM_SYSTEM.modobj |
Confirmed |
VALUE2 |
Unknown | Unknown |
VALUE3 |
EN_BRAND.brand_modobj |
Strong |
VALUE4 |
EN_LINE.line_modobj |
Strong |
For example:
*#1001*0015*1*81*6*2*0##
describes the catalogue identity of the interviewed Device.
VALUE2 must currently be treated as an opaque protocol value. Several possible interpretations have been investigated, but none has been established.
DIM1 should therefore be considered a Device identity signature, not necessarily a unique SKU identifier.
DIM2 reports the Device firmware version.
The observed structure is:
*#1001*WHERE*2*V*R*B##
The three values correlate with the catalogue firmware fields:
V → EN_FIRMWARE.firmware_V
R → EN_FIRMWARE.firmware_R
B → EN_BUILDS.firmware_b
For example:
*#1001*0015*2*2*16*0##
corresponds to firmware:
V = 2
R = 16
B = 0
Firmware information is important because the Modules, Objects, configuration properties, and allowed configuration values exposed by a Device can depend on its firmware.
Several additional dimensions occur during the description phase.
These include:
-
DIM3; -
DIM4; -
DIM5; -
DIM6.
Their exact semantics are not yet fully understood.
They should therefore be documented as device-level metadata rather than assigned speculative functional meanings.
DIM7 carries diagnostic information about the Device.
Observed values are 24 bits long.
For example:
*#1001*0015*7*111111111111111101101111##
The current evidence supports treating this as a 24-bit diagnostic/fault state.
The meanings and polarity of the individual bits have not yet been fully established.
During the interview, the Device reports its hardware ID through DIM13.
General form:
*#1001*WHERE*13*DECIMAL_ID##
Example:
*#1001*0015*13*147801279##
which corresponds to:
08CF44BF
when represented as an eight-character hexadecimal identifier.
DIM13 is particularly important during an address-based interview because it establishes the connection between:
domain address
↕
physical hardware ID
After describing the physical Device, the interview reports the Modules exposed by its firmware.
This is performed using DIM30.
General observed form:
*#1001*WHERE*30*INTERNAL_SLOT*OBJECT_ID*FLAG##
For example:
*#1001*0*30*3*406*0##
identifies an internal Module entry associated with Object ID 406.
The important conceptual relationship is:
Physical Device
│
▼
Internal Module index
│
▼
Object ID
│
▼
Object function
The INTERNAL_SLOT field is a protocol-level index used to reference the Module.
It must not automatically be interpreted as the Module number shown in the MyHOME Suite GUI.
Likewise, the final FLAG field remains incompletely understood.
The Object ID reported by DIM30 identifies the function associated with the Module.
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 |
These correspond to the Key Objects represented by EN_KEY_OBJECT in the catalogue database.
The documentation uses the term Object rather than KO wherever possible.
See Objects.
Some Modules are configurable and may initially represent a Virgin Object rather than one final functional Object.
The catalogue contains mappings between Virgin Objects and the Objects that can potentially replace them.
Conceptually:
Module
│
▼
Virgin Object
│
├── possible Object A
├── possible Object B
└── possible Object C
The actual Objects permitted for a particular Device also depend on its firmware and Module structure.
This allows MyHOME Suite to determine which Function choices can be presented when configuring a Module.
See Virgin Objects and MHCatalogue Logical Object Model.
Some Modules possess their own intrinsic system address.
Under WHO1001, this can be reported using DIM32.
Observed form:
*#1001*RESPONSE_WHERE*32#INTERNAL_SLOT*1*CONFIGURED_WHERE##
For example, a shutter actuator Module can report:
Module
│
▼
Object 218
Shutter actuator
│
▼
DIM32
│
▼
A=1 / PL=1
DIM32 is not limited to actuator Objects. It has also been observed for sensor Objects with their own intrinsic A/PL address.
It should therefore be understood as describing the Module/Object's own configured address, where such a concept exists.
This differs from a command Module whose configuration specifies the address of another Object that it controls.
See Module Addressing and DIM32.
After the description sequence, WHO1001 interviews commonly contain:
*1001*4*0##
Earlier captures suggested that WHAT4 marked completion of the Device-description phase.
Programming captures subsequently showed the same WHAT value during per-Object write operations.
Its formal meaning is therefore broader than simply "description complete".
In an interview, its position nevertheless provides a useful observable boundary between the initial Device/Module description and the following configuration phase.
The exact semantics of WHAT4 remain under investigation.
See Diagnostic WHAT Reference.
After the initial description has completed, MyHOME Suite requests the Device's configuration.
Under WHO1001, the observed request is:
*#1001*0*38#0##
This marks the transition from:
- What is this Device?
- What Modules does it expose?
- What Objects are associated with them?
to:
- How are those Modules and Objects configured?
The Device then returns Module/Object-specific configuration information.
For many Objects, this is carried through DIM35.
The detailed configuration phase is covered separately in:
Diagnostic Configuration Reading
and:
Module Configuration and DIM35
A typical WHO1001 read sequence eventually contains:
*1001*6*0##
Capture behavior strongly associates WHAT6 with completion of the configuration-reading phase.
The overall interview/read cycle can therefore be represented as:
SELECT DEVICE
│
▼
DEVICE DESCRIPTION
│
├── DIM1
├── DIM2
├── DIM3–DIM6 where applicable
├── DIM7
└── DIM13
│
▼
MODULE DESCRIPTION
│
├── DIM30
└── DIM32 where applicable
│
▼
WHAT4
│
▼
CONFIGURATION REQUEST
DIM38
│
▼
MODULE CONFIGURATION
DIM35 / object-specific dimensions
│
▼
WHAT6
This represents the current best model of the WHO1001 individual Device interview and configuration-read process.
Discovery and interview should be kept conceptually separate.
Discovery answers:
Which Devices are present?
An interview answers:
What is this particular Device, what Modules does it expose, and how is it configured?
The transition is:
_ DISCOVERY
│
┌──────────┴──────────┐
│ │
Hardware IDs Domain addresses
│ │
└──────────┬──────────┘
▼
SELECT DEVICE
│
▼
INTERVIEW
│
┌──────────┼──────────┐
▼ ▼ ▼
Device Modules Configuration
A known Device can enter the interview directly without discovery.
It is also useful to distinguish the initial Device interview from the subsequent detailed configuration read.
The Device interview establishes the structure:
Device
│
├── identity
├── firmware
├── diagnostics
├── hardware ID
│
└── Modules
│
└── Objects
Configuration reading then fills in the properties of those Objects:
Module
│
└── Object
│
├── Property = Value
├── Property = Value
└── Property = Value
This distinction mirrors the way the catalogue database is structured: first determine the Device, firmware, Module, and Object context, then use that context to interpret configuration properties.
The Device interview provides the information needed to navigate the MyHOME Suite catalogue.
At a simplified level:
DIM1
│
▼
Device / item family
│
DIM2
│
▼
Firmware
│
▼
Available Modules
│
DIM30
│
▼
Objects
│
▼
Object configuration schema
│
DIM35
│
▼
Configured values
The catalogue is therefore not merely a list of commercial Devices. It provides much of the schema required to interpret the structure and configuration reported during a diagnostic interview.
See MHCatalogue Database.