How Data Updates

How Data Updates

Polling

The integration polls the heat pump at the poll interval (30 s by default, see Installation and Setup) and reads every register of the enabled devices in one pass.

• One connection, shared. It asks Home Assistant's modbus integration for the connection, so every entry and every other integration using the same address shares one link. A hub from the YAML modbus: configuration is not part of that: it opens a client of its own.
• One read per address band. The controller serves its registers in contiguous bands, and a read that crosses a band's end is answered with a broken exception frame. The integration reads each band in one request and never across an end.
• A band the controller refuses - a module the heat pump does not have - marks its entities unavailable for that poll; the poll itself counts as good. It is logged at info level when the band goes and when it comes back.
• The system band 30001-30006 is served by every Weishaupt controller. A device that refuses it is not treated as a heat pump with missing modules: that poll fails.
• A failed poll keeps the last values. The entities go unavailable on the fourth failed poll in a row and come back with the next good one. An error in the integration itself counts as a failed poll too; its traceback is logged the first time after each load.
• Never at once with the web interface. Each band read and each write holds a lock the web interface entry of the same heat pump also takes, so the two never ask the controller at the same moment. Another integration on the same connection, or a second Home Assistant, is not coordinated with it.

Changes made at the controller's panel, on the WEM portal website or over Modbus reached the registers within one to two minutes on the tested WBB.

Writes and the EEPROM

• A write goes out at once, unless the value is already set: when the last poll shows the same value, the register is read once more first, so a change made at the panel since then is not missed.
• Numbers go out rounded to their step, the grid the controller's menu offers, so a value set in Fahrenheit lands on that grid too.
• An acknowledged write is no proof. On a WBB without the cooling release (Freigabe Kühlbetrieb, installer level), the controller acknowledged Automatic and kept the previous mode; the select shows that mode again after the next poll. Weishaupt's data-point list marks Automatic and Cooling "bei Kühlfreigabe".
• The EEPROM is rated by Weishaupt for 100 000 writes over its lifetime. Two diagnostic sensors on the WH System device count the writes that went out, in total and today - a write whose answer was lost or no longer waited for counts too, since the controller may have stored it, and so does one whose connection failed, which looks the same. The counts are kept with the entry, not in the sensors: they carry over restarts and reloads, also with the sensors disabled, and go when the entry is removed. The options set a warning threshold and a daily limit.
• Trigger automations that set values on a change (a PV surplus, a tariff switch), not on a schedule: every write that changes a value costs an EEPROM write.

The integration registers no actions of its own. Values are written with Home Assistant's standard actions: number.set_value, select.select_option, switch.turn_on and switch.turn_off.

Special values

• Setpoints that can be switched off. The constant flow temperatures, the summer/winter switchover and the SG-Ready boost can be switched off at the controller; the register then reports an "off" word (0x8000) instead of a temperature. Each comes as a number and a switch (… active): the number reads unknown while the setpoint is off, the switch turns it off and back on. Turning on restores the value it held before, also after a reload or a restart; the lowest allowed one only when the switch never saw a value.
• Reported setpoints. The room, flow and hot-water setpoints the controller only reports read 0 °C while it demands nothing; their demand attribute is none then and active while a setpoint is in force. The controller reports "no demand" as the value 1. To Home Assistant the 0 is a temperature like any other: it goes into the long-term statistics and lowers an hour's minimum and mean.
• Counters. Operating hours and switching cycles of the second heat source are totals: the statistics count hours and cycles per period. A counter that reads 0x8000 or 0xFFFF reads unknown, since in a total such a word would stay in the sum for good; a percentage from 101 up reads unknown too. A percentage of 0xFFFF means no sensor and reads unavailable.
• Electrical power (33126) is in no Weishaupt data-point list. Checked against an external meter on one WBB 12 it is the heat pump's own electrical draw in watts; the circulation pump and the controller are not in it (about 80 W there). Firmware that does not serve the register gets no entity - decided at the first poll after the integration starts, so reload the integration after a firmware update.

The power map

The heat output (Wärmeleistung) is calculated, not measured: from the power request (33103), the air intake temperature (30002, the air the heat pump draws its heat from) and the flow temperature, through a grid per model read from the graphs in Weishaupt's documentation. It is an estimate, not a measurement.

The integration ships these grids:

• weishaupt._wab8_kennfeld.json
• weishaupt_ls13_kennfeld.json
• weishaupt_wab11_kennfeld.json
• weishaupt_wbb12_kennfeld.json
• weishaupt_wbb20_kennfeld.json
• weishaupt_wbb_kennfeld.json
• weishaupt_web13_kennfeld.json
• weishaupt_wsb12_kennfeld.json
• weishaupt_wsb15_armd_kennfeld.json
• weishaupt_wsb6_kennfeld.json
• weishaupt_wsb8_armea_kennfeld.json
• weishaupt_wsb8_kennfeld.json
• weishaupt_wwp_ls_10_kennfeld.json
• weishaupt_wwp_ls_8_kennfeld.json

The two wwp_ls grids follow the "compressor frequency maximal" curves of the outdoor-unit manuals (83306301, 83306401). Their 55 °C curve ends at -15 °C, the operating limit; below it the value is carried on flat rather than dropping to 0 W.

A map of your own

Pick the file matching your model under Reconfigure. If yours is missing, copy the closest one, adjust known_x, known_y and known_t from your documentation and compile it once with .github/scripts/compile_kennfeld.py from the repository (needs numpy; with scipy the curve between your points is smooth, without it a straight line; pygal draws the preview picture). Keep the copy beside the shipped ones, in custom_components/weishaupt_modbus/kennfeld/ of the configuration directory, under a name ending in kennfeld.json: only those are offered, and the picture is found as the .svg of the same name. The integration only reads compiled grids. Contributions of new grids are welcome.

A map compiled before 2.0.2 carries its file name in the picture's title; compile it again if that name should not be public.

The preview picture

The picture of the selected map is published as www/local/weishaupt_modbus_powermap.svg in the configuration directory (with _<postfix> for a further pump), which Home Assistant serves as /local/local/weishaupt_modbus_powermap.svg. If the integration had to create www/ itself, restart Home Assistant once so it serves the folder. Everything under www/ can be fetched without logging in. A picture that carries script or links to the web is refused.

type: picture
image: /local/local/weishaupt_modbus_powermap.svg

Known limits of the values

• Yearly energies. The yearly registers (36104 and the other … Jahr rows) answer but stay at 0 on every controller seen so far, also after years of operation; the yearly total exists only on the display, in the WEM portal and in the web interface. The yearly performance factor over Modbus therefore has no value.
• Performance factors over Modbus are heat energy divided by electrical energy, and both registers count whole kWh. A factor is therefore shown only from 5 kWh of electricity on - unknown before that, as on most hot-water-only summer days and in the first days of a month - and even then it can be off by up to a fifth; with 20 kWh by about a twentieth. The web interface's statistics give the energies to three decimals.
• "Yesterday" energies keep no long-term statistics: a yesterday's value is no growing total; the matching "today" sensors keep them.