home-assistant / home-assistant/core

myUplink: number.set_value silently ignored for NIBE room setpoint (returns success, value never applied)

Open
#181,722 1 comment 0 reactions 0 assignees View on GitHub
needs-more-information
Dominant language
Python
Stars
90.5k
Forks
38.6k
Avg merge
1d 2h
Merged PRs (30d)
597

Description

### The problem

On a NIBE S1255 (myUplink integration), calling `number.set_value` on the
**room setpoint** entity (`Val. cons. sde amb.: Radiateurs`, "room setpoint /
ambient setpoint" for the heating climate system) returns **HTTP 200 / no error**,
but **the value is never applied**. The entity keeps its previous state
indefinitely, and nothing is logged — not even at DEBUG.

The same parameter **can be changed from the myUplink mobile app**, and the new
value is then correctly reflected in Home Assistant. So the parameter is writable
on the device; only the write path through the integration silently fails.

Write access is not globally broken: on the same device, in the same session,
`select.select_option` on **Hot water demand** (`Medium` -> `Small`) was applied
in about 60 seconds. The OAuth token holds the `WRITESYSTEM` scope.

**The core issue is the silent failure.** The service call reports success, so
automations and scripts have no way to know the command had no effect. A user
building a heating routine gets a system that appears to work and does nothing.

### What was tried

| Action | Result |
|---|---|
| `number.set_value` room setpoint 19 -> 24 | HTTP 200, value stayed 19.0 (checked for 100 s) |
| Same, 19 -> 23 | HTTP 200, value stayed 19.0 |
| Same, 23 -> 22, *after* changing it in the app | HTTP 200, value stayed 23.0 |
| `select.select_option` Hot water demand Medium -> Small | applied in ~66 s |
| `number.set_value` degree minutes -> -60 | applied in ~66 s |
| Change the same room setpoint **from the myUplink app** | applied immediately, reflected in HA |

### Expected behaviour

Either the write succeeds, or the service call raises an error. A silent no-op is
the worst outcome: it cannot be detected by an automation.

If the myUplink API returns a per-parameter status for write requests, the
integration should surface a failed write as an exception rather than returning
success. If the API returns success while ignoring the write, that is worth
documenting as a known limitation for the affected parameters.

### Environment

- Home Assistant Core 2026.9.0 (HAOS 18.2, aarch64 VM)
- Integration: myUplink, OAuth via Home Assistant Cloud credentials
- Device: NIBE S1255-16 R EM 3x400V
- Token scopes: `WRITESYSTEM READSYSTEM offline_access`
- No myUplink premium subscription available on this account (no such option offered)

### Notes

Read side works perfectly: 34 entities, values fresh and consistent with the app.
Only this write path is affected. Happy to provide DEBUG logs or run further tests
on request.

Contributor guide

Open the contributing guide

Research direction

Start by locating the myUplink integration's number.set_value write path and reproduce the NIBE room setpoint case while inspecting the API response and available logs. Compare it with the working hot-water and degree-minutes writes. Done means a failed or ineffective write is surfaced as an error, or the affected parameter behavior is documented as a confirmed limitation.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
api, backend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.