Controller profiles and hydronic model

This page describes how trovis-modbus identifies a controller, limits the available datapoints, interprets the selected hydronic system, assigns roles to Rk1 through Rk4, and resolves configurable sensor inputs.

Supported controllers

The library maintains an explicit model definition for each supported TROVIS controller.

Controller	Raw reported model value	Built-in Rk1-Rk3 slots
TROVIS 5573	5573	2
TROVIS 5573-1	55731	2
TROVIS 5575	5575	2
TROVIS 5576	5576	2
TROVIS 5578	5578	3
TROVIS 5578-E	55781	3
TROVIS 5579	5579	3

The reported model value is read from the controller during the setup probe and mapped to one unambiguous model definition.

Conservative address-range families

The readable Modbus ranges are grouped into two conservative controller families.

Controller family	Rk1-Rk3 slots	Reference register and coil profile
TROVIS 5573, 5573-1, 5575, 5576	2	TROVIS 5573 Rev. 2.54
TROVIS 5578, 5578-E, 5579	3	TROVIS 5578 Rev. 2.62 final

These range profiles define address availability and known block boundaries. They do not replace the separate per-model definitions, hydronic system model, or sensor-variant rules.

Known register gaps, reserved areas, and manufacturer block boundaries are preserved. The grouped reader does not bridge these boundaries merely because two addresses appear numerically close.

Model definitions

Each model definition contains:

• the exact controller model,
• the number of built-in Rk1-Rk3 slots,
• the logical sensor keys supported by the model,
• groups of configurable or mutually exclusive sensor roles.

A model definition describes logical capabilities. Physical terminals are kept out of this layer because their meaning may depend on the system code number, function blocks, and parameters.

The detected model controls which register and coil ranges, logical sensor views, and control-circuit slots are available.

Safe setup probe

A typical application first probes the controller:

probe = await Trovis557x.async_probe(unit)

The probe intentionally reads only safe identity and sensor data. It returns the reported model and detected physical sensor readings required to construct the full device:

device = Trovis557x(
    unit,
    model=probe.model,
    detected_sensors=probe.detected_sensors,
)

This prevents applications from exposing control circuits or logical sensor views that do not exist on the detected model.

System code number and hydronic configuration

The controller's system code number selects the hydronic installation. The library maps known system code numbers to immutable configuration definitions.

A configuration definition contains:

• the system code number,
• the documented model support,
• the hydronic topology,
• the functional sensors used by the installation,
• optional model/system-specific capabilities.

The top-level object exposes:

Property	Meaning
device.configuration_definition	Known definition for the reported system code number, or None
device.configuration_topology	Hydronic topology from that definition, or None
device.configuration_supported_by_model	True, False, or None when the system is unknown

An unknown system code does not prevent basic controller access. The library falls back conservatively where possible and avoids inventing a topology.

Stable technical Rk slots

Rk1 through Rk4 are stable technical controller slots. Their hydronic meaning is assigned by the selected installation rather than by their number alone.

Slot	Possible roles
Rk1	heating circuit, precontrol circuit, buffer-tank circuit, unused
Rk2	heating circuit, precontrol circuit, unused
Rk3	heating circuit, precontrol circuit, unused; only built into three-slot models
Rk4	domestic-hot-water circuit or unused

The current role is returned by:

role = device.control_circuit_role(1)

Applications should use the role instead of assuming that every Rk1-Rk3 slot is a room-heating circuit.

Useful topology properties include:

Property	Meaning
device.control_circuit_indices	Technical Rk slots enabled by model and topology
device.room_heating_circuit_indices	Rk1-Rk3 slots whose role is room heating
device.has_rk4	Whether the installation contains Rk4 domestic hot water
device.has_buffer_tank_circuit	Whether Rk1 has the buffer-tank role
device.has_buffer_tank_charging_parameters	Whether PA1 P16-P19 are documented for this model/system pair
device.has_solar	Whether the topology contains a solar circuit

Device model

A Trovis557x instance exposes logical controller areas instead of a flat list of raw Modbus addresses.

Trovis557x
├── info
├── controller
├── clock
├── functions
├── parameters
├── sensors
├── rk1
├── rk2
├── rk3                 # model dependent
├── rk4
├── buffer_tank         # availability depends on topology
├── solar               # availability depends on topology
└── system_activity     # derived property

Main components

Component	Purpose
info	Model, firmware, hardware version, serial information, and system code number
controller	Controller-wide state, limits, switches, and settings
clock	Native controller date and time
functions	Function-block state used by applications and configuration resolvers
parameters	Parameter state used by applications and configuration resolvers
sensors	Physical temperatures, analog inputs, pulse input, and remote values
rk1, rk2, rk3	Technical Rk1-Rk3 control-circuit data
rk4	Domestic-hot-water circuit data
buffer_tank	Buffer-tank-specific extension for installations where Rk1 has that role
solar	Solar-circuit-specific data for installations containing solar

The subsystem objects are stable API attributes. Applications decide whether an optional subsystem is exposed by checking the corresponding availability property.

device.control_circuits contains only the built-in Rk1-Rk3 slots supported by the detected controller model.

Physical sensor detection

The setup probe reads the model-supported sensor registers and records sensor views whose raw value is present rather than a TROVIS invalid-value sentinel.

Detection answers the question:

Is a readable value present at this model-supported input?

It does not by itself answer:

Which logical role is currently selected for a configurable physical input?

That second question is handled by the sensor-variant resolver.

Configurable sensor variants

Some physical inputs can represent different logical sensors or a non-sensor function. Examples include:

• SF2 or RF2,
• VF2, VF3, or VF4,
• FG, analog, or pulse interpretations,
• the 5578-E AE1-AE3 alternatives.

The resolver uses the model definition together with controller functions, parameters, and relevant coils. It does not guess from the numerical value.

Each variant receives a status such as:

• selected,
• inactive,
• unresolved.

The top-level device exposes several useful result sets:

Property	Meaning
device.sensor_variant_resolution	Full variant results and evidence
device.canonical_sensor_keys	Fixed sensors and conclusively resolved variants
device.available_sensor_keys	Detected sensors safe to expose normally
device.unresolved_detected_sensor_keys	Detected role-specific views kept for diagnostics
device.inactive_detected_sensor_keys	Detected views whose input is configured for another use
device.unsupported_detected_sensors	Probe results rejected by the detected model definition

A one-key variant may remain available when the input is detected and no alternative sensor role exists, while multi-role unresolved inputs remain configuration diagnostics rather than normal application values.

Fallback behavior

When the model is known but the hydronic system code is unknown:

• the model-specific address ranges remain active,
• the supported number of Rk1-Rk3 slots remains known,
• logical sensor filtering remains active,
• Rk1-Rk3 default conservatively to heating roles,
• Rk4 remains the safe domestic-hot-water fallback,
• optional solar and buffer-tank topology flags remain unavailable.

This fallback keeps basic access possible without presenting an unknown installation as fully understood.