Migration

Migration

Upgrading from 1.x

Up to 1.x the integration opened its connection to the controller itself, with its own reconnect logic and block planner. Since 2.0 it asks Home Assistant's modbus integration for a unit on the connection to the controller's address. Home Assistant keeps one connection per endpoint and serialises everything that goes over it, so two entries of this integration, or another integration asking for the same endpoint, queue up behind one link. A hub from the YAML modbus: configuration is not part of that: it opens a client of its own. The wire is handled by the modbus-connection library, which Home Assistant installs with its modbus integration.

Upgrading: update Home Assistant to 2026.9.0 or later first, then install 2.0 or later and restart. Existing entries migrate on first start; an entry keeps the host and port you configured. If the controller does not answer during setup, Home Assistant retries.

What stays

• The entities, their unique IDs and history - except the web-interface entities of 1.x, which the migration removes together with the stored web-interface login (their empty devices go too since 2.1.2, also from an entry migrated before), and except where the recorder notices below say otherwise. Coming from the upstream 2.0 pre-release, the migration also removes its web-interface login and the heat pump's MAC address from the entry (since 2.1.2).
• The entity IDs you chose. One exception: an ID of the three relabelled second-heat-source counters that ends in the old label, such as ..._switching_cycles_e_heating_2, takes the new label - also when you chose it, unless another entity already holds that ID; then it keeps the old one and the log says so.
• The shipped power map you selected. A power map of your own has to be compiled once (see How Data Updates); until then the heating power reads unknown.

What is gone

The web-interface scraping of 1.x with its settings, this integration's own pymodbus requirement, the pygal requirement (the preview picture is drawn by the compile script, not at runtime), its reconnect and back-off logic, and the five-register block limit: the controller serves each address band in one read.

What is new

A switch beside every setpoint the controller can switch off, the Options dialog (poll interval, EEPROM write warning and limit) and the write counters. Apart from the three relabelled second-heat-source counters, nothing existing is renamed. Prefix and device postfix can no longer be changed after setup.

Changed state strings

An automation that matched on an old one needs the new name; Home Assistant raises no notice for them.

Register	Value	Was (1.x)	Is
Operating status (30006)	0 (undefined)	system_operationmode_pvmode	system_operationmode_undefined
Operating status (30006)	10 (utility lock)	system_operationmode_sgtariff	system_operationmode_evu
Operating status (30006)	37, 39 (heating, hot water in SG-Ready mode)	..._heating_sgr, ..._hotwater_sgr	..._heating_sgr3, ..._hotwater_sgr3
Heat pump operation (33101)	0 (undefined)	heatpump_operationmode_pvmode	heatpump_operationmode_undefined
Heat pump operation (33101)	36	heatpump_operationmode_bereitschaft	heatpump_operationmode_regenerativ
Heat pump operation (33101)	37, 39	..._heating_sgr, ..._hotwater_sgr	..._heating_sgr3, ..._hotwater_sgr3

The 1.x names are those of the fork point. The codes follow Weishaupt's 2025 data-point list, where 0 is "undefined", 10 the utility lock and 36 "regenerative".

Recorder notices after the upgrade

The recorder raises a notice once per sensor whose statistics changed; open Developer tools → Statistics to settle each:

• A changed unit on the three relabelled second-heat-source counters (hours and cycles had swapped names) and on a few unit-less rows (an empty unit became none): choose to update the unit of the recorded statistics - the history is the register's and stays.
• A changed unit on H1.2 to H1.5: they read °C now, as the data-point list says. 1.x recorded their raw register words - tenths of a degree, and 32768 without a sensor - so delete their old statistics instead; with the unit updated they would read ten times too high.
• A removed state class on the seven "... yesterday" energy sensors: a yesterday's value is no growing total, so they keep no long-term statistics any more. Delete their old statistics; the matching "... today" sensors keep them.

Upgrading within 2.x

From 2.0.0 or 2.0.1 to 2.0.2 or later

• SG-Ready 1 and 2 (35101, 35102) showed their input as a number, 0 or 1; they now read off and on, states w2_status_aus and w2_status_ein. Their long-term statistics end there; the recorder notes this once per sensor.
• Settings the controller only reports, and registers without a known meaning, moved to the Diagnostic category; they no longer appear on automatically generated dashboards.
• A power map of your own compiled before 2.0.2 carries its file name in the picture's title; compile it again if that name should not be public.

From 2.0.2 to 2.1

• Reported setpoints (room, flow and hot-water setpoint) read 0 °C while the controller demands nothing; 2.0.2 showed unknown. An automation that waited for unknown should look at the demand attribute instead (see How Data Updates).
• Heating circuits are compared with the controller's setup at every load, with a repair notice where they differ (see Installation and Setup).
• Devices of heating circuits switched off in the entry are removed when the entry loads. Switched on again, the circuit comes back with its names, entity IDs and history.
• The integration is named "Weishaupt Modbus" everywhere, and some display names changed (English "Error" and "Hydraulic separator temperature", several Dutch names). Entity IDs stay as they are.
• Operating hours and switching cycles of the second heat source are totals since 2.1.0b3; up to 2.1.0b2 they were averaged. That older statistic stays in the database, but graphs no longer show it. In the first minutes after the update Home Assistant may list a mean type changed notice for them; it goes by itself with the next statistics run - do not delete the statistics for it.
• A counter reading 0x8000 or 0xFFFF, a percentage from 101 up, and a performance factor below 5 kWh of electricity read unknown (see How Data Updates).
• The write counters are kept with the entry, no longer in their sensors. 2.1.0 took over the counts the sensors held, but the way it read them fails on Home Assistant 2026.11; updating straight to 2.1.1 or later, they start over at 0.

From a 2.1 beta with the web interface (2.1.0b1 to 2.1.0b3)

• From 2.1.0b1 or 2.1.0b2 straight to 2.1.1 or later, the write counters start over at 0, as they do coming from 2.0.2.
• The heating power limit of the web interface was a sensor until 2.1.0b2 and is a number now. The entry removes the sensor from the registry when it loads; automations that read sensor.…heating_power_limit move to the number. Its history stays in the recorder: Developer tools → Statistics lists its long-term statistics as having no state and offers to delete them.
• The web interface pauses instead of stopping after three failures in a row and resumes by itself; its repair notice is a warning now (see Web Interface).