home-assistant / home-assistant/core
myUplink: number.set_value silently ignored for NIBE room setpoint (returns success, value never applied)
- 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
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