Writing indoor temperature setpoints via /points endpoint silently fails — should use /zones/{zoneId} endpoint

[tangyyylambert]

The problem

When trying to change room temperature setpoints (parameters with sh-indoorSpHeat smart home category, e.g. parameter IDs 47751, 47752) via the integration, the API responds with "modified" but the value is never actually applied on the heat pump.

This affects NIBE SMO S40 (and likely other devices with zone-based climate systems).

Root cause

The integration uses the PATCH /v2/devices/{deviceId}/points endpoint for all writable parameters. However, for zone-based temperature setpoints, this endpoint silently accepts the request but does not apply the change.

The myUplink API has a dedicated endpoint for this: PATCH /v2/devices/{deviceId}/zones/{zoneId} which works correctly.

How I confirmed this

1. PATCH via /points — fails silently

curl -X PATCH "https://api.myuplink.com/v2/devices/{deviceId}/points" \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"47752":"22"}'

Response: {"47752": "modified"} — but a subsequent GET still returns the old value, and the heat pump is unchanged.

2. PATCH via /zones/{zoneId} — works

curl -X PATCH "https://api.myuplink.com/v2/devices/{deviceId}/zones/3" \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"setpointHeat": 22.0}'

This actually changes the setpoint on the heat pump and is confirmed via GET on /smart-home-zones.

3. Zone data from the API

GET /v2/devices/{deviceId}/smart-home-zones returns:

[
    {
        "zoneId": "2",
        "name": "RDC",
        "mode": "heat",
        "temperature": 20.7,
        "setpointHeat": 20.0,
        "setpointRangeMin": 15,
        "setpointRangeMax": 25,
        "isCelsius": true
    },
    {
        "zoneId": "3",
        "name": "Etage",
        "mode": "heat",
        "temperature": 20.5,
        "setpointHeat": 20.0,
        "setpointRangeMin": 15,
        "setpointRangeMax": 25,
        "isCelsius": true
    }
]

The zone name matches the parameter category field (e.g. "RDC", "Etage").

What I noticed in the code

The integration already has:

• A Zone class fully implemented in api.py
• A get_zones() method that calls /smart-home-zones
• A zones list on the Device class

However:

• The call to get_zones() is commented out in Device.async_fetch_data():

  # self.zones = await self.system.api.get_zones(self.id)

• There is no patch_zone() method — only patch_parameter() which uses /points

Proposed solution

1. Add a patch_zone method to the MyUplink class:

async def patch_zone(self, device_id, zone_id: str, setpoint_heat: float) -> bool:
    """Update the setpoint of a zone for a device."""
    _LOGGER.debug(
        "Patch zone %s for device %s with setpointHeat %s",
        zone_id, device_id, setpoint_heat,
    )
    async with self.lock, self.throttle:
        resp = await self.auth.request(
            "patch",
            f"devices/{device_id}/zones/{zone_id}",
            data=json.dumps({"setpointHeat": setpoint_heat}),
            headers={"Content-Type": "application/json"},
        )
    resp.raise_for_status()
    return resp.status == 200

2. Update Parameter.update_parameter() to route zone parameters:

async def update_parameter(self, value) -> None:
    """Patch parameter if writable."""
    if not self.is_writable:
        return
    if "sh-indoorSpHeat" in self.smart_home_categories and self.category:
        zones = await self.device.system.api.get_zones(self.device.id)
        for zone in zones:
            if zone.name == self.category:
                await self.device.system.api.patch_zone(
                    self.device.id, str(zone.id), float(value)
                )
                return
    await self.device.system.api.patch_parameter(
        self.device.id, str(self.id), str(value)
    )

The logic: when a parameter has the sh-indoorSpHeat smart home category, we look up the matching zone by name (which corresponds to the parameter's category field), and use the zones endpoint instead of the points endpoint.

Environment

• Device: NIBE SMO S40
• myUplink subscription: Premium (manage)
• Integration version: 1.7.3
• Home Assistant: 2025.x

Additional context

Other writable parameters (e.g. 27233 Quick water heating) work fine via /points. The issue is specifically with zone-based temperature setpoints that require the /zones/{zoneId} endpoint.

The Swagger documentation at https://api.myuplink.com/swagger/index.html confirms both endpoints exist:

• PATCH /v2/devices/{deviceId}/points — for general parameter updates
• PATCH /v2/devices/{deviceId}/zones/{zoneId} — for zone-specific updates

Thank you for this great integration! Happy to submit a PR if you'd prefer.

[jaroschek]

Hello @boonddaguy,

Thank you for your suggestions. To be honest, I didn't implement zones because I had no idea how to make the zones available in Home Assistant as devices with entities.

But based on your description (and my ever gaining knowledge of Home Assistant itself) I now have the idea to implement each zone as an own device that is related to the main device as it needs the same device id to. And each zone property should be implemented as an entity of this zone device.

Therefore I suggest to implement zone related methods (and not reuse existing parameter related methods).

Additionally there will be a service implementation for zone properties too.

I will just need some time to work on this new feature set. It is currently already working in my head and the structure of it takes form.

But a PR is always welcome too. So feel free to create your own implementation. (I just hope it will be in line with my already developing idea of the feature 😉)

[jaroschek]

@boonddaguy Thinking further ...

(based on the existing details and properties of each zone)

Should a zone perhaps be better implemented as a climate entity of the main device? Most of its properties are climate related:

But as there could also exist properties for CO2 or humidity a zone could still exist as a Home Assistant device with an own climate entity and additional entities based on the other properties. And then there is this ominous command only mode. If this is true, there will be no climate entity, as the values are not in degrees.

I will just have to read and learn the details and caveats of climate entity implementation.

So may be a start would be the initial implementation of the needed zone related methods and services to control the setpoint properties of each zone in the first place.

[jaroschek]

Hello @boonddaguy,

as a first step I have now implemented a simple Service myuplink.set_device_zone_property_value to modify a property of a Smart Home Zone:

The new service is currently available in the pre-release 1.8.0-rc2 .

Please give it a try and let me know what you think.

The next steps will be the implementation of zone properties as entities defining each zone as a separate device related to the main device. As defined in the myUplink API only setpointHeat, setPointCool and mode will be editable entities. Ideally mode will be a select entity which options come from supportedModes. But if the property commandOnly is set to true these properties will be just sensors without the ability to modify them.

Unfortunately my only Smart Home Zone is in commandOnly as I don't have the needed devices nor would use them. So I will have to implement it without the ability to test it locally.

[jaroschek]

Hello @boonddaguy,

I have now reached a step during the implementation of Home Assistant entities for myUplink Smart Home Zones, where I would like to have some test feedback. As I mentioned before, my single Smart Home Zone is in commandOnly, so I can't get any sensor readings nor can I update any property.

Here is an example of the response of GET /v2/devices/{deviceId}/smart-home-zones returns: data I get for my device:

[
  {
    "zoneId": "2",
    "name": "Klimatisierungssyste",
    "commandOnly": true,
    "supportedModes": "",
    "mode": "heatcool",
    "temperature": null,
    "setpoint": null,
    "setpointHeat": null,
    "setpointCool": null,
    "setpointRangeMin": null,
    "setpointRangeMax": null,
    "isCelsius": true,
    "indoorCo2": 0,
    "indoorHumidity": 0
  }
]

The newly created release 1.8.0-rc3 features optional sensor entities and an optional climate entity for each Smart Home Zone. The availability of these entities is defined by the availability and values of the properties of each Smart Home Zone.

If commandOnly is set to true, only a single sensor entity for the property mode is created. Otherwise there will be sensors for CO2, humidity and temperature, if the related properties contain any valid value. The climate entity will also be only available, if commandOnly is set to false.

And the climate entity itself relies heavily on the values of the Smart Home Zone properties. As nearly every property is allowed to return null, I was forced to make the climate entity very conditional. And unfortunately the definitions for the properties mode and supported_modes don't say anything about the accepted/possible values. So I had to guess them.

So please give the new pre-release a try. I would appreciate any feedback.

[tangyyylambert]

Hi @jaroschek ,

Sorry for the delayed response — I don't get much time to tinker with HA unfortunately, so it took me a while to test this.

First, here's what my GET /v2/devices/{deviceId}/smart-home-zones returns:

[
    {
        "zoneId": "2",
        "name": "RDC",
        "commandOnly": false,
        "supportedModes": "",
        "mode": "heat",
        "temperature": 19.9,
        "setpoint": 20.0,
        "setpointHeat": 20.0,
        "setpointCool": null,
        "setpointRangeMin": 15,
        "setpointRangeMax": 25,
        "isCelsius": true,
        "indoorCo2": 0,
        "indoorHumidity": 0.0
    },
    {
        "zoneId": "3",
        "name": "Etage",
        "commandOnly": false,
        "supportedModes": "",
        "mode": "heat",
        "temperature": 20.2,
        "setpoint": 20.0,
        "setpointHeat": 20.0,
        "setpointCool": null,
        "setpointRangeMin": 15,
        "setpointRangeMax": 25,
        "isCelsius": true,
        "indoorCo2": 0,
        "indoorHumidity": 0.0
    }
]

As you can see, my zones are not commandOnly and have actual temperature/setpoint values — so this should be a good test case for you.

However, the climate platform crashes on setup with 1.8.0-rc3. The issue is that supportedModes is an empty string "" in my data, and api.py line 372 tries to call float() on it, which raises a ValueError:

Error while setting up myuplink platform for climate: could not convert string to float: ''
File "/config/custom_components/myuplink/climate.py", line 71, in _update_from_zone
    if zone.supported_modes is not None:
File "/config/custom_components/myuplink/api.py", line 372, in supported_modes
    float(self.raw_data["supportedModes"])
ValueError: could not convert string to float: ''

This also breaks the entire myUplink integration (all entities become unavailable), so I had to roll back to the stable release.

I think a simple guard like checking for empty string before the float conversion should fix it.

Happy to test again once you push a fix. Thanks for working on this!

[jaroschek]

Hello @boonddaguy,

thank you for the fast test and feedback. This was really a silly bug from myself. I have fixed the type error. As the value is already a string or just null, type casting is not necessary for supportedModes.

I have created a new pre-release: 1.8.0-rc4

[tangyyylambert]

Hi,

I will try test it this evening.
Have a good day :D

[jaroschek]

@boonddaguy, I have to admit that RC4 contained several more bugs, that I could fix now.

The latest pre-release 1.8.0-rc5 delivers now working climate entities (based on dummy-data).

But as my Smart Home Zone is in commandOnly, I can not test or verify the patch requests.

[jaroschek]

@boonddaguy, there is yet another pre-release version: 1.8.0-rc6

This time I added a new config option to enable or disable the newly added support for Smart Home Zone. As for users like me the Smart Home Zone is not of any use, disabling this feature will avoid an unnecessary API call that would add another 4 seconds and increase the necessary time window for each update loop. The new config option is enabled by default.

[tangyyylambert]

Hi,

Great news — I installed 1.8.0-rc6 and the climate entities are working! 🎉

Both my zones (RDC and Etage) now show up as climate entities with correct temperature readings and setpoint controls.

I haven't tried modifying the setpoint directly from the climate entity yet. What I did test is the service myuplink.set_device_zone_property_value (e.g. zone 2, setpointHeat 22.0) and that works correctly — the change is applied to the heat pump.

One minor thing: after performing the action, it takes a few minutes for the sensors to reflect the new value in HA. I assume this is just due to the API polling interval, not an issue with the integration itself. Can you confirm?

Also, I'm getting this deprecation warning in the logs:

2026-03-14 08:06:03.041 WARNING (MainThread) [homeassistant.helpers.service] The deprecated argument hass was passed to async_extract_config_entry_ids from myuplink. It will be removed in HA Core 2026.10. Use async_extract_config_entry_ids without hass argument instead, please create a bug report at https://github.com/jaroschek/home-assistant-myuplink/issues

Thanks again for the great work on this release!

[jaroschek]

Hello @boonddaguy, great to read from your successful test! I really appreciate!

And I have to confirm, that the delay is caused by the polling interval. The service does not change any state of an existing entity or sensor directly. It just works on the api. Thus the sensor need to fetch the updated state by itself.

It would be interesting, if the change made through the thermostat would directly change the state in Home Assistant or if the polling interval would be visible too.

Could you please test the function of modifying a setpoint through the thermostat entity too? If that also works, I could merge the new feature to main and create a new latest release.

Thank you for your support!

[tangyyylambert]

Hi,

I tested modifying the setpoint directly through the climate/thermostat entity. It works — the change is applied to the heat pump successfully.

However, the state in HA doesn't update immediately. It takes some time before the new value appears, and this also affects the thermostat widget itself: when I change the setpoint from 20 to 21, the widget immediately reverts back to showing 20, and only displays 21 after a delay.

I believe this is due to the polling interval, but I can't confirm for sure — there's nothing in the logs that would tell me whether it's a direct update or a polled refresh. All I can say is that it's not instantaneous.

This could be confusing for users, as there's no visual confirmation that the change was actually applied until the value eventually updates. Ideally, the entity state could be optimistically updated right after a successful write.

Both methods (service and thermostat entity) work correctly for writing though — the heat pump does receive the change.

[tangyyylambert]

Hi,

Do you have any news to update the repository ?
You have probably many things to you, i am just coming to have some news, do not take any pressure ;)

[jaroschek]

Hello,

I know... it's been a while.

Regarding your feedback I have now made some small changes that should avoid the intermediate revert of a recently changed value. I also addressed the deprecation warning you noticed.

I have created a new pre-release with these changes: 1.8.0-rc8

Would you be so kind and make a (hopefully last) test of these latest changes?

Thank you very much!