Feat: Add CDT Support as CA (Configuration Appliance) Client Actor

[daviddsapir]

Overview

This commit introduces CDT support as a CEM client actor.

It provides full support for the CDT use case, specifically Scenario 1. This includes the ability to retrieve setpoints, their constraints, and map them to their corresponding operation modes via HvacSetpointRelations.

For the use case to fully function, support for the CDSF (Configuration of DHW System Function) use case is necessary.
Specifically, we need to request HvacOperationModeDescriptionListDataType, which is used in conjunction with HvacSystemFunctionSetpointRelationListDataType to establish the mapping between operation modes and their setpoints, and to enable the ability to write setpoints.

❗Writing setpoints was tested and confirmed to work with Vaillant's HeatPump by requesting the HvacOperationModeDescriptionListDataType message and performing the mapping without the CDSF use case.

Mapping Setpoints to Operation Modes

This commit introduces a mapping between Operation Modes and setpoints, enabling retrieval of the setpoint based on a specified Operation Mode. According to the SPEC, the following rules apply for each mode:

• Auto: If supported in this scenario, this mode must relate to one to four temperature setpoints.
• Off: If supported in this scenario, this mode must relate to either no setpoints or exactly one temperature setpoint.
• On: This mode must relate to exactly one temperature setpoint.
• Eco: This mode must relate to exactly one temperature setpoint.

Relations between system functions, operation modes and setpoints.

• HVAC operation modes are used to describe which behaviour the HVAC system functions have.
  Each HVAC operation mode may be used by several HVAC system functions.
• Each supported operation mode can relate to one ore more temperature setpoints.

Diagram example:

Therefore, in order to get the operation modes and their setpoints we need to:

1. Obtain the SystemFunctionId for the “DHW” system function.
2. Retrieve the operation modes associated with this system function ID.
3. Map the setpoints to each operation mode to get a map in which we can get the setpoint by mode.

Required Messages for Mapping:

• HvacSystemFunctionDescriptionListData: Retrieves the SystemFunctionId for the “DHW” system function.
• HvacSystemFunctionSetpointRelationData: Provides the relationships between operation modes and setpoints for the “DHW” system function.
• HvacOperationModeDescriptionListData: Supplies the operation mode descriptions for the operation modes in the relations.

⚠️ Only the HvacSystemFunctionSetpointRelationData is request in the CDT usecase. The other 2 required messages are requested in the CDSF usecase scenario 1. This is why this usecase depends on other use cases: CDSF (Configuration of DHW System Function) and MDT (Monitoring of DHW Temperature).

Resources used (specifications):

• EEBus UC Technical Specification Configuration of DHW Temperature
• EEBus SPINE Technical Specification Resource Specification

[daviddsapir]

According to the spec., the following rules apply:

• isSetpointChangeable - If set to "true" the server SHALL accept changes of the setpoint by appropriate clients (e.g. the bound client). If set to "false" the server SHALL decline change requests. If absent, the server SHOULD accept changes.
• isSetpointActive - If set to "false", the setpoint is inactive. If set to "true" or omitted, the setpoint is active.

Ref: [Resource Specification] 4.3.23.4 setpointListData.

[DerAndereAndi]

Is this a question or a note to yourself? :)

[daviddsapir]

This is a note for you TBH 🙂

To clarify why I used the || operator:

In some parts of EEBus, for boolean fields, an absent (nil) value is considered false, so you typically check it like this: isActive := (setpoint.IsSetpointActive != nil && *setpoint.IsSetpointActive)

However, in this case, the specification requires the opposite: if the value is absent, it should default to true.

[DerAndereAndi]

Hehe 😃

Yeah, consistency usually wins, and hurts when it is not present. Would you mind adding this note as a comment into the code? It is nearly impossible to keep this in mind and always check the specs or find this note.

[daviddsapir]

Done.

Added this note as a comment into the code:

// As per [Resource Specification] 4.3.23.4 setpointListData:
// - isSetpointActive: If false, the setpoint is inactive; if true or omitted, it is active.
// - isSetpointChangeable: If true, the server accepts changes; if false, it declines changes. If absent, changes are accepted.
isActive := (setpoint.IsSetpointActive == nil || *setpoint.IsSetpointActive)
isChangeable := (setpoint.IsSetpointChangeable == nil || *setpoint.IsSetpointChangeable)

[DerAndereAndi]

Thanks a lot for this addition! Looks good on first glance. Before I go into details (which will take some time), would it be possible to add more tests on the added functionality. Both in the new client and the use case implementation? I wouldn't want the coverage to drop ;)

In addition, is it possible to get some SPINE trace logs to see the actual code in action? This would help me a lot checking the implementation.

[daviddsapir]

no problem, I'll do both :)