Added telegram 0x002A, 0x00D1, 0x01D1, 0x02E0, 0x00D2, 0x00D6, 0x04F2

static/data/telegram_metadata.json

@@ -632,6 +632,75 @@
     "distribution" : "BROADCAST-ON-CHANGE, UNICAST-ON-REQUEST, UNICAST-WRITE-REQUEST",
     "notes" : "",
     "type" : "info"
-
+  },
+  "0x002A" : {
+    "name" : "EMS HTIII Service Tool Monitor Service Functions",
+    "usedIn" : "tbd",
+    "description" : "This block contains monitor values of Heatronic III service function to be used by a service tool like Netcom",
+    "class" : "Monitor",
+    "emsCategory" : "EMS1.0 and EMS2.0: detail in bus variable description",
+    "distribution" : "BROADCAST-ON-CHANGE, BROADCAST-ON-POWER-UP, UNICAST-ON-REQUEST",
+    "notes" : "",
+    "type" : "info"
+  },
+  "0x00D1" : {
+    "name" : "NSC CU Interface Outdoor Temperature",
+    "usedIn" : "tbd",
+    "description" : "The outdoor sensor (measured) value is broadcasted with this datatype to the system.  If no valid outdoor temperature value is measured, it is not allowed to send this datatype! Exception: If outdoor temperature sensor was once present and is now missing (e.g. due to broken wire or sensor), signal may be sent with value for [NA_OPEN] or [NA_SHORT] once. The receiver (=user) of the signal may then raise an error. If the CU has multiple outdoor temperature values to choose from and the one with the highest priority goes missing, the value with the next highest priority shall be chosen and be distributed.  **Notes**: - The CU will broadcast the outdoor temperature with the highest priority in telegram 0x00D1 offset 0-1 and also indicate the source of that value in telegram 0x00D1 offset 2. This value shall always be used for control functions. - There is only one RF OT sensor and one internet OT and one external (at module) wired OT sensor allowed. - Bus members who have outdoor temperature information have to send it via broadcast using the \"External Outdoor Temperature Measurement\" datatype (telegram 0x01D1):      - telegram 0x01D1 offset 0-1: External Wired Sensor      - telegram 0x01D1 offset 2-3: RF Sensor      - telegram 0x01D1 offset 4-5: Internet  **Important**: All currently produced CUs (as of 01/2019) do not implement telegram 0x01D1 and the priority algorithm that comes with it. They also do not support telegram 0x01D1 offset 2.  **Note: Distribution** - Broadcasted every 1 minute, *if sensor is available*. - Broadcasted on power-up, *if sensor is available*. - If telegram 0x01D1 offset 2 is supported, it should be broadcasted together with telegram 0x01D1 offset 0-1.  *Note on EMS1 (backward compatibility)*: The outdoor temperature is measured and broadcasted to the system by the appliance (telegram 0x0019 offset 0-offset 1). However, outdoor temperature measurement is not a function of the appliance, and the interface must allow that the deployment could be changed in the future (e.g. using an RF based outdoor sensor). Therefore, new interfaces for outdoor temperature measurement were defined in EMS2.",
+    "class" : "Monitor",
+    "emsCategory" : "EMS2.0",
+    "distribution" : "BROADCAST-PERIODICALLY; distribution duration = 60s; timeout = 240s, UNICAST-ON-REQUEST, BROADCAST-ON-POWER-UP",
+    "notes" : "",
+    "type" : "info"
+  },
+  "0x01D1" : {
+    "name" : "External Outdoor Temperature Measurement",
+    "usedIn" : "tbd",
+    "description" : "The externally measured outdoor sensor value is broadcasted with this datatype.  If no valid outdoor temperature value is measured, it is not allowed to send this datatype! Exception: If outdoor temperature sensor was once present and is now missing (e.g. due to broken wire or sensor), signal may be sent with value for [NA_OPEN] or [NA_SHORT] once. The receiver (=user) of the signal may then raise an error. If the CU has multiple outdoor temperature values to choose from and the one with the highest priority goes missing, the value with the next highest priority shall be chosen and be distributed. See more details about this in telegram 0x00D1.  **Important**: All currently produced CUs (as of 01/2019) do not implement telegram 0x01D1 and the priority algorithm that comes with it.  **Note: Distribution** - Each module shall broadcast only the bus variable corresponding to the connected sensor. E.g. a RF coordinator may broadcast telegram 0x01D1 offset 2-3 only, in case it detected an RF OT sensor. - Broadcasted every 1 minute, *if sensor is available*. - Broadcasted on power-up, *if sensor is available*.",
+    "class" : "Monitor",
+    "emsCategory" : "EMS2.0",
+    "distribution" : "BROADCAST-PERIODICALLY; distribution duration = 60s; timeout = 240s, UNICAST-ON-REQUEST, BROADCAST-ON-POWER-UP",
+    "notes" : "",
+    "type" : "info"
+  },
+  "0x02E0" : {
+    "name" : "Heat request HC1 via appliance (system output)",
+    "usedIn" : "tbd",
+    "description" : "Heat request HC1 via appliance (system output). If HC1 is controlled by the appliance this data type is used to request for heating on the system output of the appliance. This request affects the global season optimizer.  **Important**: - The complete payload must be transmitted together. - See also rules for priority handling and transmission/reception of telegram 0x00D2 and telegram 0x00D6. - If the HC1 is controlled via a module, a controller must use telegram 0x00D2 instead of telegram 0x02E0.  **Notes**: - This data type is sent from the controller to the appliance. - Layout as telegram 0x00D2 but **no** ``MAX function`` needed, because there is only *one* requester (typically the system controller)!",
+    "class" : "Control",
+    "emsCategory" : "EMS2.0",
+    "distribution" : "UNICAST-PERIODICALLY; distribution duration = 60s; timeout = 240s, UNICAST-WRITE-REQUEST, UNICAST-ON-REQUEST",
+    "notes" : "",
+    "type" : "info"
+  },
+  "0x00D2" : {
+    "name" : "Sink Source Interface Heat System Output",
+    "usedIn" : "tbd",
+    "description" : "Heat request (system output). This is the EMS data type used to request for heating on the system output. This request affects the global season optimizer.  **Important**: - The complete payload must be transmitted together. - See also rules for priority handling and transmission/reception of telegram 0x00D2 and telegram 0x00D6. - If the HC1 is controlled via the appliance, a controller must use telegram 0x00D2 instead of telegram 0x02E0.  **Notes: Distribution** - This data type is sent with unicast to the owner typically every minute.  - The heat request becomes invalid if the request is not repeated within 4 min.",
+    "class" : "Control",
+    "emsCategory" : "EMS2.0",
+    "distribution" : "UNICAST-PERIODICALLY; distribution duration = 60s; timeout = 240s, UNICAST-WRITE-REQUEST",
+    "notes" : "",
+    "type" : "info"
+  },
+  "0x00D6" : {
+    "name" : "Sink Source Interface Cool System Output",
+    "usedIn" : "tbd",
+    "description" : "Cool request (system output). This is the EMS data type used to request for cooling on the system output.  This request affects the global season optimizer.   **Important**: - The complete payload must be transmitted together. - See also rules for priority handling and transmission/reception of telegram 0x00D2 and telegram 0x00D6. - If the HC1 is controlled via the appliance, a controller must use telegram 0x04F2 instead of telegram 0x00D6.  **Notes: Distribution** - This data type is sent with unicast to the owner typically every minute.  - The cool request becomes invalid if the request is not repeated within 4 min.",
+    "class" : "Control",
+    "emsCategory" : "EMS2.0",
+    "distribution" : "UNICAST-PERIODICALLY; distribution duration = 60s; timeout = 240s, UNICAST-WRITE-REQUEST, UNICAST-ON-REQUEST",
+    "notes" : "",
+    "type" : "info"
+  },
+  "0x04F2" : {
+    "name" : "Cool request HC1 via appliance (system output)",
+    "usedIn" : "tbd",
+    "description" : "Cool request HC1 via appliance (system output). If HC1 is controlled via the appliance this data type is used to request for cooling on the system output of the appliance. This request affects the global season optimizer.  **Important**: - The complete payload must be transmitted together. - See also rules for priority handling and transmission/reception of telegram 0x00D2 and telegram 0x00D6.- If the HC1 is controlled via a module, a controller must use telegram 0x00D6 instead of telegram 0x04F2.  **Notes**: - This data type is sent from the controller to the appliance. - Layout as telegram 0x00D6 but **no** ``MAX function``/``MIN function`` needed, because there is only *one* requester (typically the system controller)!",
+    "class" : "Control",
+    "emsCategory" : "EMS2.0",
+    "distribution" : "UNICAST-PERIODICALLY; distribution duration = 60s; timeout = 240s, UNICAST-WRITE-REQUEST, UNICAST-ON-REQUEST",
+    "notes" : "",
+    "type" : "info"
   }
 }

static/data/telegrams.csv

@@ -1792,3 +1792,54 @@ Telegram_ID,Offset,Variable_Name,Min,Max,Resolution,Unit,Comment
 0x0492,2,Additional Electrical Limit Compressor,0,15,1,enum,"Maximum electrical heater power allowed when compressor is running, KW_0 = 0, KW_2 = 1, KW_3 = 2, KW_4 = 3, KW_6 = 4, KW_9 = 5, KW_12 = 6, KW_15 = 7, KW_1_5 = 8, KW_4_5 = 9, KW_1 = 10, KW_13_5 = 11, KW_2_5 = 12, KW_3_5 = 13, KW_5 = 14, KW_5_5 = 15"
 0x0492,3,Additional Electrical Limit No Compressor,0,15,1,enum,"Maximum electrical heater power allowed when compressor is not running, KW_0 = 0, KW_2 = 1, KW_3 = 2, KW_4 = 3, KW_6 = 4, KW_9 = 5, KW_12 = 6, KW_15 = 7, KW_1_5 = 8, KW_4_5 = 9, KW_1 = 10, KW_13_5 = 11, KW_2_5 = 12, KW_3_5 = 13, KW_5 = 14, KW_5_5 = 15"
 0x0492,4,Additional Electrical Limit DHW,0,15,1,enum,"Maximum electrical heater power allowed when DHW is produced, KW_0 = 0, KW_2 = 1, KW_3 = 2, KW_4 = 3, KW_6 = 4, KW_9 = 5, KW_12 = 6, KW_15 = 7, KW_1_5 = 8, KW_4_5 = 9, KW_1 = 10, KW_13_5 = 11, KW_2_5 = 12, KW_3_5 = 13, KW_5 = 14, KW_5_5 = 15"
+0x002A,0,voltage measured,0,24,1,V,"voltage measured at 1-2-4 connection (HTIII->6.b)"
+0x002A,1,temperature,0,250,1,°C,"temperature of combustion chamber"
+0x002A,2,used fan map,0,6,1,---,""
+0x002A,3,actual flow rate turbine,0,99,1,1/min,""
+0x002A,4.0,active programmer channels DHW,0,1,1,---,"active programmer channels DHW (HMI code->6.E), FALSE = 0, TRUE = 1"
+0x002A,4.1,active programmer channels CH,0,1,1,---,"active programmer channels CH (HTIII->6.E), FALSE = 0, TRUE = 1"
+0x002A,4.2,External frost thermostat 230Vac,0,1,1,---,"FALSE = 0, TRUE = 1"
+0x002A,4.3,On Off DHW demand 230Vac,0,1,1,---,"FALSE = 0, TRUE = 1"
+0x002A,4.4,On_Off room thermostat Rth 230Vac Y S compliant,0,1,1,---,"FALSE = 0, TRUE = 1"
+0x002A,5,internal GFA status code,0,255,1,---,""
+0x002A,6,internal GFA fault code,0,255,1,---,"no_fault = 0"
+0x002A,7-8,Fanspeed setpoint,0,900,10,rpm,""
+0x002A,9-10,Fanspeed,0,900,10,rpm,""
+0x002A,11-12,3rd Hot water temperature,-32768,32767,0.1,°C,"NA_OPEN = -32768, NA_SHORT = 32767"
+0x002A,13,Actual position of 2nd three way valve,0,100,1,%,"solar_totally_excluded = 0, solar_totally_included = 100"
+0x002A,14-15,Mixer temperature,-32768,32767,0.1,°C,"NA_OPEN = -32768, NA_SHORT = 32767"
+0x002A,16-17,MFH multi family house temperature,-32768,32767,0.1,°C,""
+0x002A,18-19,Solar storage temperature,-32768,32767,0.1,°C,"NA_OPEN = -32768, NA_SHORT = 32767"
+0x002A,20.0,CUS system error :low loss header tem sensor defective,0,1,1,---,"Low loss header sensor at CUS defect (open, short circuit, out of position, etc.), FALSE = 0, TRUE = 1"
+0x002A,20.1,CUS system error: AirPurgeModeActive,0,1,1,---,"No heat requests served, pump and 3wv are used to purge air, FALSE = 0, TRUE = 1"
+0x002A,20.2,CUS system error: SiphonFillModeActive,0,1,1,---,"FALSE = 0, TRUE = 1"
+0x002A,20.3,CUS system error,0,1,1,---,""
+0x002A,20.4,CUS system error,0,1,1,---,""
+0x002A,20.5,CUS system error,0,1,1,---,""
+0x002A,20.6,CUS system error,0,1,1,---,""
+0x002A,20.7,CUS system error,0,1,1,---,""
+0x00D1,0-1,Outdoor temperature measured value,-32768,32767,0.1,°C,"Range: -40 to 50°C  **Note**: In case telegram 0x00D1 offset 2 is supported, the priority of the outdoor temperature reported with this bus variable shall be:     1) Wired sensor at ACU     2) Externally wired sensor (e.g. at module)     3) RF (over coordinator)     4) Internet (over gateway), NA_OPEN = -32768, NA_SHORT = 32767"
+0x00D1,2,Outdoor temperature source,0,3,1,enum,"Defines the source of the outdoor temperature broadcasted with telegram 0x00D1 offset 0-1., WIRED_AT_CU = 0, WIRED_AT_MODULE = 1, RF = 2, INTERNET = 3"
+0x01D1,0-1,Outdoor temperature measured value (from module),-32768,32767,0.1,°C,"Range: -40 to 50°C  Externally wired sensor (e.g. at module), NA_OPEN = -32768, NA_SHORT = 32767"
+0x01D1,2-3,Outdoor temperature measured value (from RF),-32768,32767,0.1,°C,"Range: -40 to 50°C  Wireless sensor via RF coordinator, NA_OPEN = -32768, NA_SHORT = 32767"
+0x01D1,4-5,Outdoor temperature measured value (from Internet),-32768,32767,0.1,°C,"Range: -40 to 50°C via Internet from e.g. weather service, NA_OPEN = -32768, NA_SHORT = 32767"
+0x02E0,0,Requested Season,0,1,1,enum,"This is the requested season of the local season optimizer for HC1 via appliance. - IDLE = 0: Indicates that there is no heat request from the heating circuit and the local season optimizer doesn't specifically request for heating mode.  - HEAT = 1: Indicates that the local season optimizer wishes to stay in heating mode. *Default value*: see chapter *Timeouts* and table *Handling of timeouts on telegram 0x00D2 and telegram 0x00D6* **Note**: The CU uses -1 to indicate an INVALID value for season. Therefore, this value cannot be used in the EMS interface!, IDLE = 0, HEATING = 1"
+0x02E0,1,Requested supply temperature,0,90,1,°C,"This is the supply temperature the source has to deliver to the sink., OFF_HEAT = 0"
+0x02E0,2,Requested power,0,100,1,%,"This is the power the source uses to deliver the heat. 100 % relates to the maximum allowed power for CH set in telegram 0x00E6 offset 4. When this control value is below the minimum allowed power of the appliance (telegram 0x00E6 offset 5), the appliance is expected to deliver the requested power in cycle operation (like PWM)., OFF = 0"
+0x02E0,3,Fast Mode,0,1,1,enum,"The sink can influence the strategy of how the heat is delivered by the source. - NO = 0 (Efficient) - YES = 1, FALSE = 0, No_Efficient = 0, TRUE = 1, Yes = 1"
+0x02E0,4,Priority,1,2,1,enum,"This indicates that the season should change as fast as possible., NORMAL = 1, HIGH = 2"
+0x00D2,0,Requested Season,0,1,1,enum,"``MAX function``; This is the requested season of the local season optimizer for each individual heating circuit. - IDLE = 0: Indicates that there is no heat request from the heating circuit and the local season optimizer doesn't specifically request for heating mode.  - HEAT = 1: Indicates that the local season optimizer wishes to stay in heating mode. **Note**: The CU uses -1 to indicate an INVALID value for season. Therefore, this value cannot be used in the EMS interface!, IDLE = 0, HEATING = 1"
+0x00D2,1,Requested supply temperature,0,90,1,°C,"``MAX function``; This is the supply temperature the source has to deliver to the sinks., OFF_HEAT = 0"
+0x00D2,2,Requested power,0,100,1,%,"``MAX function``; This is the power the source uses to deliver the heat. 100 % relates to the maximum allowed power for CH set in telegram 0x00E6 offset 4. When this control value is below the minimum allowed power of the appliance (telegram 0x00E6 offset 5), the appliance is expected to deliver the requested power in cycle operation (like PWM)., OFF = 0"
+0x00D2,3,Fast Mode,0,1,1,enum,"``MAX function``; The sink can influence the strategy of how the heat is delivered by the source. - NO = 0 (Efficient) - YES = 1, FALSE = 0, No_Efficient = 0, TRUE = 1, Yes = 1"
+0x00D2,4,Priority,1,2,1,enum,"``MAX function``; This indicates that the season should change as fast as possible., NORMAL = 1, HIGH = 2"
+0x00D6,0,Requested Season,0,1,1,enum,"``MAX function``; This is the requested season of the local season optimizer for each individual heating circuit. - IDLE = 0: Indicates that there is no request from the heating circuit and the local season optimizer does not specifically request for cooling mode.  - COOLING = 1: Indicates that the local season optimizer wishes to stay in cooling mode *Default value*: see chapter *Timeouts* and table *Handling of timeouts on telegram 0x00D2 and telegram 0x00D6*. **Note**: The CU uses -1 to indicate an INVALID value for season. Therefore, this value cannot be used in the EMS interface!, IDLE = 0, COOLING = 1"
+0x00D6,1,Requested supply temperature,10,90,1,°C,"``MIN function``; This is the supply temperature the source has to deliver to the sinks., OFF_COOL = 90"
+0x00D6,2,Requested power,0,100,1,%,"``MAX function``; This is the power the source uses to deliver the request., OFF = 0"
+0x00D6,3,Fast Mode,0,1,1,enum,"``MAX function``; The sink can influence the strategy of how the request is delivered by the source. - NO = 0 (Efficient) - YES = 1, FALSE = 0, No_Efficient = 0, TRUE = 1, Yes = 1"
+0x00D6,4,Priority,1,2,1,enum,"``MAX function``; This indicates that the season should change as fast as possible., NORMAL = 1, HIGH = 2"
+0x04F2,0,Requested Season,0,1,1,enum,"This is the requested season of the local season optimizer for HC1 via appliance. - IDLE = 0: Indicates that there is no request from the heating circuit and the local season optimizer does not specifically request for cooling mode. - COOLING = 1: Indicates that the local season optimizer wishes to stay in cooling mode *Default value*: see chapter *Timeouts* and table *Handling of timeouts on telegram 0x00D2 and telegram 0x00D6. **Note**: The CU uses -1 to indicate an INVALID value for season. Therefore, this value cannot be used in the EMS interface!, IDLE = 0, COOLING = 1"
+0x04F2,1,Requested supply temperature,0,90,1,°C,"This is the supply temperature the source has to deliver to the sinks., OFF_COOL = 90"
+0x04F2,2,Requested power,0,100,1,%,"This is the power the source uses to deliver the request., OFF = 0"
+0x04F2,3,Fast Mode,0,1,1,enum,"The sink can influence the strategy of how the request is delivered by the source. - NO = 0 (Efficient) - YES = 1, FALSE = 0, No_Efficient = 0, TRUE = 1, Yes = 1"
+0x04F2,4,Priority,1,2,1,enum,"This indicates that the season should change as fast as possible., NORMAL = 1, HIGH = 2"