4.5. Conditions

Conditions allow to enable/disable a complete configuration part for e.g. a particular variant of a device.

A good example for this is a product line of heat pumps, each of which answers to the same query with different meanings of the returned values (e.g. evaporator temperature versus air outlet temperature).

In order to make a configuration line conditional, it has to start with one or more conditions in square brackets, e.g. for a conditional message definition:

[condition A][condition B]TYPE,CIRCUIT,NAME,COMMENT,QQ,ZZ,PBSB,ID,fields...

When multiple conditions are used in sequence, then all of them have to be true (i.e. combined with logical AND).

Each condition always references a previously declared condition.

Condition declaration

In order to use a named condition, it has to be declared in the same CSV file before the configuration line using it. A condition declaration line is prefixed with a "*" (just like a defaults row) and looks like this:

*[CONDITIONNAME],MESSAGECIRCUIT,MESSAGENAME,COMMENT,FIELDNAME,ZZ,VALUES

The individual columns are these:

• CONDITIONNAME:
  The name of the condition.
• MESSAGECIRCUIT:
  The optional circuit name of the message carrying the values the condition is composed of (defaults to the own circuit name derived from the CSV file name).
• MESSAGENAME:
  The optional name of the message carrying the values the condition is composed of. If left empty, the condition references the scan of the own slave address or another.
• COMMENT:
  An optional comment for the condition.
• FIELDNAME:
  The optional name of the message field carrying the values the condition is composed of. If left empty, the first field of the message is used instead (numeric or string).
• ZZ:
  The optional slave address from which to read the message (defaults to the own address derived from the CSV file name).
• VALUES:
  The optional list of values the referenced message field has to match in order for the condition to be true. Multiple items are separated by a semicolon. Each item is either a single numeric value (e.g. "18"), a simple numeric value range separated by a dash (19-22), or a numeric value range using numeric compare (e.g. "<=5", ">10").
  If left empty, the referenced message is only checked for having been seen.

Examples

Here are some example condition declarations:

*[brinetowater],ehp,ApplianceCode,,,,4-10
This condition is true, when the first numeric field of the message named "ApplianceCode" in the circuit "ehp" has a raw value between 4 and 10 (both inclusive).

*[dhw],mc,CfgHeatSinkType,water,,,2
This condition is true, when the first numeric field of the message named "CfgHeatSinkType" in the circuit "mc" has a raw value of 2.

*[SW>201],scan,,,SW,,>201
This condition is true, when the scan of the own slave address reveals a software version of higher than 201.

*[SW],scan,,,SW,,
This condition is true, when the scan of the own slave address was successful. It can also be used for checking a particular software version number when referencing the condition.

Condition usage

Each condition always references a previously declared condition and may optionally use different values to check (instead of those used in the condition declaration).

Instead of declaring all conditions for e.g. all the software versions of a device, the declaration can also be reduced to the the field itself without a particular value and in the condition reference the value(s) to check can be declared on-the-fly.

Examples

Here is an example for using conditions:

[brinetowater][SW>201][HW>=100]r,ehp,prerun,,,08,B509,0D9E01,...

In this example, the message "prerun" for the circuit "ehp" is only valid, if the conditions named "brinetowater", "SW>201", and "HW>=100" are all met (i.e. these are combined using a logical AND). For this to work, it is enough if the conditions named "SW" and "HW" were declared previously (i.e. not particularly with the required version numbers).