[BUG] TRV Boost cancellation fails on missing previous.mode; beta returns False without cancelling

Summary

Cancelling an active Hive radiator valve (TRV) Boost through Home Assistant's hive.boost_heating_off action fails with KeyError: 'mode'.

The parent thermostat Boost cancels successfully, but TRV Boosts remain active.

This matches the previously reported Home Assistant issue: home-assistant/core#157114

Environment

• Home Assistant Core: 2026.10.3, official Docker installation
• Hive integration: Built-in Home Assistant integration
• Installed Python library: pyhive-integration 1.0.10
• Separately tested beta: 2.0.0b5, using isolated, mocked tests only

Steps to reproduce

1. Start a native Boost on a Hive TRV using hive.boost_heating_on.
2. Confirm that the TRV is Boosting.
3. Call hive.boost_heating_off for that radiator.
4. Observe the error and that the TRV continues Boosting.

The failure affected multiple TRVs during zone-wide cancellation. The thermostat cancellation succeeded.

Actual error

In apyhiveapi/heating.py, setBoostOff attempts:

prev_mode = data["props"]["previous"]["mode"]

When previous.mode is absent, a KeyError occurs before the cancellation/restoration write.

Additional findings

Our isolated investigations identified several related concerns:

1. Stale product reference: Stable version 1.0.10 retrieves a product object before refreshing the product cache, then continues using that old object. A simulated refresh with complete restoration information therefore does not resolve the failure.

2. Beta 2.0.0b5: The beta avoids the exception when previous.mode is missing, but returns False without cancelling the Boost.

3. Home Assistant acknowledgement: The built-in HA Hive handler does not inspect that Boolean result. A failed or skipped cancellation could consequently appear successful.

4. Missing target: Both versions may substitute 7°C when the previous restoration target is absent, potentially restoring an unintended temperature.

5. Synthetic tests: Both versions can correctly restore Schedule, Manual and Off settings when complete valid previous-state information is supplied. We have not yet captured the cached-versus-refreshed restoration data for an affected real TRV.

No modifications were made to the live Home Assistant installation.

Expected behaviour

Cancelling a TRV Boost should either:

• Successfully end the Boost and safely restore the correct previous mode and target; or
• Return a clear failure if reliable restoration information is unavailable.

A no-op must not be reported as a successful cancellation.

Questions for maintainers

• Can Hive legitimately omit props.previous.mode for an active TRV Boost?
• Could the library refresh product data before selecting the restoration state?
• Could restoration inputs be validated and failures propagated correctly to Home Assistant?
• Is there a supported way to shorten an existing TRV Boost by submitting a new, shorter Boost while preserving the original pre-Boost state?

The last question may offer an alternative to early cancellation.

Related upstream change: #145

Any guidance would be appreciated. We are happy to assist with further testing without changing the live integration.