-
Notifications
You must be signed in to change notification settings - Fork 2
Current limits and planned work
The library deliberately models verified controller behavior rather than exposing every readable word as an untyped value. This page records larger areas that remain incomplete, intentionally deferred, or owned by another project.
The list is a technical roadmap, not a promise that every item will be included in the next release.
Complete weekly schedules require their own coherent model for:
- schedule blocks,
- day selection,
- time periods,
- validation,
- ordered writes,
- controller-specific limits,
- special periods such as holidays and vacations.
They should not be added as a collection of unrelated raw registers. A future implementation should provide typed schedule values and safe update sequences.
Some heat-meter values span several registers or require unit-dependent interpretation. These include accumulated energy, volume, flow rate, power, identification data, and temperatures.
The source tree contains a dedicated heat-meter subsystem area, but complete public modeling should expose coherent typed values rather than unrelated raw words. Multi-register consistency, units, overflow behavior, and model-specific availability must be verified before broad write or presentation support is added.
The controller exposes error and status masks. Full decoding should use
well-documented IntFlag types after all bit meanings have been verified across
the supported models and firmware families.
Until then, an undecoded mask is safer than assigning an incorrect meaning to a bit.
The library already uses:
- controller-model definitions,
- conservative address ranges,
- hydronic system code numbers,
- stable Rk roles,
- model/system support checks,
- function and parameter state,
- sensor-variant resolution.
Further work may apply the same principles to more datapoints so that values are not merely readable by address, but are also known to be meaningful for the active system and function configuration.
Availability rules must remain deterministic and documented. A value should not be hidden or reclassified merely because its current measurement looks unexpected.
Known official system code numbers are mapped to hydronic definitions. A controller may still report an unknown, OEM-specific, or newer system code.
The current conservative fallback keeps model-level access available but cannot provide a verified topology, optional solar or buffer-tank flags, or exact Rk roles for an unknown system.
Possible future work includes:
- adding newly documented official systems,
- recording OEM systems only when their topology and model mapping are verified,
- exposing clearer diagnostics for unknown or model-incompatible system codes.
A small number of controller functions require more than a normal register or coil write. Examples may involve:
- command values,
- ordered writes across several fields,
- temporary control-level changes,
- acknowledgements,
- resets or restarts,
- firmware-dependent sequences.
These remain deferred until their complete sequence, validation, rollback, and failure behavior are known.
Readable does not imply safely writable.
The library has model-specific logical sensor definitions and configurable sensor variants. Some larger controllers also allow broad alternative use of physical inputs as temperature, binary, voltage, current, pulse, or remote signals.
Future refinements may document more exact terminal-level capabilities and current-input variants where the official manuals provide enough information to resolve them without guessing.
Terminal assignments belong in model and configuration data, not in application-specific entity code.
Controllers from Sauter, Yados, Pewo, or other OEM vendors may be compatible when they use the same model identity and Modbus layout. They are not currently maintained as independent model profiles.
An OEM profile should only be added when the following are verified:
- reported model identity,
- address ranges and block boundaries,
- scaling and units,
- system code numbers,
- sensor and function differences,
- safe write behavior.
Brand similarity or enclosure appearance is not sufficient evidence.
Derived values are appropriate when they express controller-specific behavior that is broadly useful. They should remain limited and well tested.
Future derived values must follow these rules:
- prefer a direct controller value when one exists,
- document all input values and unavailable states,
- avoid presentation-only formatting,
- do not duplicate application policy,
- do not hide uncertainty behind a plausible estimate.
The wiki documents the main concepts and examples, but the project may later benefit from generated API documentation for public classes, enums, exceptions, metadata types, and component properties.
Generated reference documentation should supplement the conceptual wiki rather than replace it.
Home Assistant entity mapping belongs to
trovis-modbus-hass, not
to this library.
Previously identified integration mapping areas included:
- native date values,
- native time values,
- yearless
MonthDaypresentation, - enum sensors and selects,
- additional sensors, numbers, switches, and binary sensors,
- removal or redesign of abstractions that do not match TROVIS semantics.
Their current implementation status must be tracked in the integration repository. The library should provide correct neutral values and metadata, but must not implement Home Assistant entities or presentation rules.
When one of these areas is implemented:
- update the relevant detailed wiki page,
- remove or rewrite the corresponding limitation here,
- add migration notes when public behavior changes,
- describe the release-specific change in the GitHub release notes,
- leave the README unchanged unless the general scope or supported controller list has changed.
Disclaimer: Any information on this wiki is informal advice only. It is not supported nor endorsed by Samson, Sauter, YADOS, Pewo or any other equipment maker. There is no warranty expressed or implied: you take sole responsibility for everything you do with your heating controller.