[BUG] Heat on demand fails

[nsleigh]

Describe the bug
When you try to change the thermostat "Heat on Demand" setting you get and error. Looking in the log I see this:

Logger: apyhiveapi.api.hive_async_api
Source: components/hive/switch.py:70
First occurred: 07:59:12 (2 occurrences)
Last logged: 09:29:22

Something has gone wrong calling https://beekeeper.hivehome.com/1.0/nodes/heating/7657f6ad-f0b9-4da2-b402-d8c3cfa2a00d - HTTP status is - 400 — response: {"error" : "MALFORMED_REQUEST" }

To Reproduce
Click the "Heat on Demand" switch in the thermostat.

Desktop (please complete the following information):

• OS: Any
• Browser Chrome
• Version 2026.4.1

Thermostat SLT6

Additional Info

Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/commands.py:281
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 09:29:22 (1 occurrence)
Last logged: 09:29:22

[140418478916448] Unexpected exception
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 281, in handle_call_service
    response = await hass.services.async_call(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<7 lines>...
    )
    ^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2900, in async_call
    response_data = await coro
                    ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2943, in _execute_service
    return await target(service_call)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 949, in entity_service_call
    response_data = await _async_handle_entity_calls(
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<5 lines>...
    )
    ^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 828, in _async_handle_entity_calls
    single_result = await entity.async_request_call(_with_context(entity, coro))
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 1708, in async_request_call
    return await coro
           ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 823, in _with_context
    return await coro
           ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 907, in _handle_single_entity_call
    result = await task
             ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/hive/__init__.py", line 103, in wrapper
    await func(self, *args, **kwargs)
  File "/usr/src/homeassistant/homeassistant/components/hive/switch.py", line 70, in async_turn_on
    await self.hive.switch.turnOn(self.device)
  File "/usr/local/lib/python3.14/site-packages/apyhiveapi/plug.py", line 223, in turnOn
    return await self.session.heating.setHeatOnDemand(device, "ENABLED")
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/apyhiveapi/heating.py", line 501, in setHeatOnDemand
    resp = await self.session.api.setState(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        data["type"], device["hiveID"], autoBoost=state
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/local/lib/python3.14/site-packages/apyhiveapi/api/hive_async_api.py", line 318, in setState
    resp = await self.request("post", url, data=jsc)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.14/site-packages/apyhiveapi/api/hive_async_api.py", line 118, in request
    raise HiveApiError
apyhiveapi.helper.hive_exceptions.HiveApiError

[nsleigh]

I reproduced this against a real account (with a lot of help from Claude!) and did some systematic payload-shape testing on POST /nodes/heating/{id}, verifying each attempt by re-fetching the device afterwards (a 2xx response alone isn't reliable — see below).

Confirmed: the bug is present both in the currently-published pyhive-integration 1.0.9 (what this component pins) and on the library's dev branch — the autoBoost write logic hasn't changed in the library's history, so this looks like a change on Hive's backend, not a regression in this integration.

Systematic test results (verified via re-fetch, not just HTTP status):

Bodies containing a top-level autoBoost key — all rejected, regardless of value shape:

• {"autoBoost": "ENABLED"} → 400 MALFORMED_REQUEST (current behaviour)
• {"autoBoost": true} → 400 MALFORMED_REQUEST
• {"autoBoost": "enabled"} → 400 MALFORMED_REQUEST
• {"autoBoost": {"active": true}} → 400 MALFORMED_REQUEST
• {"autoBoost": {"active": true, "duration": 30, "trvs": []}} → 400 MALFORMED_REQUEST

Bodies avoiding a literal top-level autoBoost key — all return HTTP 200, but silently do not change the device (confirmed via re-fetch):

• {"auto_boost": "ENABLED"} → 200, no-op
• {"auto_boost": {"active": true}} → 200, no-op
• {"props": {"autoBoost": {"active": true}}} → 200, no-op
• {"products": [{"id": "...", "props": {"autoBoost": {...}}}]} → 200, no-op

Takeaway: any request whose top-level JSON contains the literal key autoBoost gets hard-rejected as malformed, independent of the value's type/shape. Requests without that exact key get a 200 but are silently ignored (the endpoint seems to tolerate unrecognized fields rather than erroring on them). That pattern suggests Hive may have removed/relocated autoBoost writes from this endpoint rather than just renaming or reshaping the field — simple field-name/shape guessing on POST /nodes/heating/{id} is unlikely to find the fix from here.

Next useful step is probably a traffic capture of the official Hive app (mitmproxy/Charles/Proxyman) while toggling Heat on Demand, to see whether it still hits this same endpoint at all but as this is only set after holiday mode starts I am not sure this is possible.

My guess is that this is read-only.

Background
I was looking for a way to enable holiday mode without using the Hive app, I found that when it was enabled heat on demand was off so that the values didn't override the thermostat. So I thought this was the way to go. I am not looking to see if there is an API to set holiday mode.

[nsleigh]

Follow-up with a confirmed root cause and a fix (again with a lot of help from Claude).

Root cause confirmed via HAR capture: autoBoost is not a client-writable field at all. I captured real traffic from the Hive website while using its holiday-mode UI, and it never touches nodes/heating/{id}/autoBoost directly. Instead, autoBoost appears to be a side effect the backend applies automatically when Holiday Mode is active. That explains the earlier test results in my previous comment: any request body containing a literal top-level autoBoost key gets hard-rejected as MALFORMED_REQUEST, regardless of shape — because Hive's backend no longer accepts direct writes to it at all.

What Hive's own website actually uses (GET/POST/DELETE on /holiday-mode, confirmed from the capture):

GET /1.0/holiday-mode
-> {"active": false, "enabled": false, "start": 1783006500000, "end": 1783296000000, "temperature": 12, "status": "OK"}

POST /1.0/holiday-mode
body: {"start": 1783767707701, "end": 1784372507701, "temperature": 12}   # start/end are epoch milliseconds
-> 200, echoes the body back

DELETE /1.0/holiday-mode
body: {}
-> {"set": true}

I've implemented get_holiday_mode() / set_holiday_mode(start, end, temperature) / cancel_holiday_mode() in the Pyhive library (dev branch) matching this exact shape, with unit tests. That gives Home Assistant a real, working path to schedule/cancel Holiday Mode — which is what actually controls this behaviour, rather than trying to flip autoBoost directly (which Hive's backend no longer allows, assuming it ever did).

Given this, my recommendation for the Heat On Demand switch specifically: it should probably be removed/marked read-only in this integration, since Hive appears to have removed direct client control of it. Happy to open a PR for the library side; the Home Assistant component side (surfacing holiday mode as a service/entity) would be a separate follow-up.