Nibe Uplink REST API Binding [3.3.0;4.2.0)

There seems to be a few different issues here. The first error:

I find quite strange, because that channel group type is statically defined in xml-files, so I have no idea why openhab cannot find it. Perhaps a restart of the bundle could be enough to fix it.

The second error:

Should only be possible to get when doing the oauth authorization flow, so it’s strange that it appears several minutes later. It does however indicate that the authorization failed for some reason, which would explain why no things can be discovered.
You could check the file /var/lib/openhab/jsondb/StorageHandler.For.OAuthClientService.json to see if a valid token has been aquired. It should look something like this (Do NOT post the full contents of the file, it can be used to access your system!):

 "nibeuplinkrest:apibridge:apibridge.AccessTokenResponse": {
    "class": "java.lang.String",
    "value": "{\n  \"accessToken\": \"<really long base64 encoded string>\",\n  \"tokenType\": \"bearer\",\n  \"expiresIn\": 1800,\n  \"refreshToken\": \"<long base64 encoded string>\",\n  \"scope\": \"READSYSTEM WRITESYSTEM\",\n  \"createdOn\": \"2022-07-21T12:24:24.949985\"\n}"
  },
  "nibeuplinkrest:apibridge:apibridge.LastUsed": {
    "class": "java.lang.String",
    "value": "\"2022-07-21T12:24:24.951892\""
  },
  "nibeuplinkrest:apibridge:apibridge.ServiceConfiguration": {
    "class": "java.lang.String",
    "value": "{\n  \"handle\": \"nibeuplinkrest:apibridge:apibridge\",\n  \"tokenUrl\": \"https://api.nibeuplink.com/oauth/token\",\n  \"authorizationUrl\": \"https://api.nibeuplink.com/oauth/authorize\",\n  \"clientId\": \"<your client ID>\",\n  \"clientSecret\": \"<your client secret>\",\n  \"scope\": \"READSYSTEM WRITESYSTEM\",\n  \"supportsBasicAuth\": false,\n  \"tokenExpiresInSeconds\": 10\n}"
  },

I would suggest to first restart the bundle bundle:restart org.openhab.binding.nibeuplinkrest to make sure everything gets loaded correctly, but I will experiment a bit when I get home from work. The binding has been stable for over a year for me (except for occasional outages on nibe’s side), but it was also years ago i did the authorization and discovery, so perhaps some bugs have snuck in there in the meantime.

Edit: Just tried with a fresh OH (3.3 stable) and everything worked as expected, so there shouldn’t be any changes in core that have caused the binding to stop working.

Does anyone know if there’s Modbus TCP also in Nibe F750?

Hi @tunnus,

I have a NIBE F735G (special version for Viebrockhaus customers).
I didn’t manage to get Modbus TCP running on this heat pump. I think it is simply not implemented.

I am now using the nibeheatpump binding with the arduino RS485 bridge in between.
This works very well since some months now.
Note: I use the F730 model in the nibe uplink REST API binding and F750 model in the nibeheatpump binding.

Cheers
Jonathan

I use MyHeatPump (google.com) and running modbus.
No limitation of 20 registers.

Hej Anders and others,

Silly question, but the few parameters/settings that are writable via this binding - is that assuming a payed subscription at Nibe? Or is Nibe allowing these settings to be modified without that in the API-version this is using?

I seem to have this set up correctly and authenticated. It does read the temperature correctly and I’ve managed to connect the Thermostat Thing to Items to control the target temperature. (hard to tell for sure if I’m doing it right though as I’m learning openHab while trying to get this working :slight_smile: ).

I can see GET-requests going away and pulling accurate data from my outdoor and indoor sensor. When changing the Item I’ve connected the target temperature in the Thermostat to I see a POST going away:

Sending POST request to https://api.nibeuplink.com/api/v1/systems/<my-sys-nr>/smarthome/thermostats with data {"externalId":1,"name":"System 1 Thermostat","climateSystems":[1],"actualTemp":232,"targetTemp":250}

But then its complete silence. Reading back #47398 via the GET is also at the old value (which is also what I see “physically” on the real display-unit):

2022-11-19 23:59:28.008 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Updating 4 parameters for system <my-sys-nr>
2022-11-19 23:59:28.012 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel system1#40033 to 23.2 °C
2022-11-19 23:59:28.020 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel system1#43161 to OFF
2022-11-19 23:59:28.025 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel status#40004 to -0.8 °C
2022-11-19 23:59:28.035 [TRACE] [dler.NibeUplinkRestBaseSystemHandler] - Setting channel control#47398 to 20 °C

What am I missing? Or is this expected behavior since I haven’t payed up? :slight_smile:

Thanks!

Best Regards,
Fredrik

Yes, I think a subscription is required to make these settings work. You don’t have to pay for the full package however, only the one for updating settings. The other one, for the history of the values, is not required.

Hum. Still not working after having subscribed. I can confirm that via nibeuplink.com it does work to set the target temperature, it gets reflected on the “physical display”. But doing it via OH still yields the POST - event, but nothing more. No more logging. No actual change (it’s still reading back the old value and no change on the display).
What’s more that POST event comes back in the log again with me interacting with OH. (looks to be every 15min, which is not related to my update frequency that is now every 60s).

How can I debug this further?

It usually takes a while for the change to actually be applied, the binding sends the command to nibe uplink, but the heat pump only checks in every 5-10 minutes, and that’s when it gets the update. It’s the same as when changing the setting in the Nibe uplink ui, the update can be in a pending state for a while before it reaches the heat pump.

What setting are you trying to change? For some settings, Nibe requires it to update at least every 30 minutes, or the setting is reverted (probably a failsafe to not leave the heat pump in a bad state if connection is lost).

I’m trying to change the target temperature of the thermostat (Room sensor setpoint S1, control#47398 to be specific). And if I interpret the logs correctly (the ones I posted above) the binding is picking this up correctly. I’m on a F750 for what that is worth.

Yes, the thermostats are one of the things that requires updating at least every 30 minutes, so the binding sends the values every 15 minutes in addition to when a command is sent.

Have you activated the smart home features in the heat pump? (Setting 4.1.7)
Then after a few minutes you should be able to see the values on the “smart home” page in the serviceinfo menu (3.1)

Edit: misunderstood the parameter, haven’t actually tried that one, but can investigate. But at least I would think you have to activate room sensor control for that system (menu 1.9.4)

Ahh, that explains the periodic post. Good.

I don’t think I have a 4.1.7? But if I look at https://www.nibe.eu/assets/documents/19556/331472-3.pdf page 60, setting 4.1.3 and forward I can see that I have one connected user. And as I said, changing via nibeuplink.com does work so there is connection between the “cloud” and the heat pump.

Edit: misunderstood the parameter, haven’t actually tried that one, but can investigate. But at least I would think you have to activate room sensor control for that system (menu 1.9.4)

Then I’ve misunderstood how to hook things up in openHAB or something, I thought I was doing this by the book :slight_smile: (1.9.4 have been activated).

And by doing by the book I mean that I’ve attached an Item to the Target temperature of the thermostat, like this:

Just to verify, can you change the setting through the Nibe uplink ui? How does the temperature settings page look? What happens when you change it there?

Yes, it works via nibeuplink.com. When I change there (via “Manage” in the screenshot below) it works for quite a bit in the background, then it is taking effect. The physical display of the heat pump get updated. So that works as expected.

The UI looks like this for me:

You will see -7 now. That’s because I’ve now switched to use the outdoor sensor. Before this was 20, 21 or whatever I set as target for the inside temperature using the indoor sensor.

I’m no longer in the house with access to the Raspberry, so harder now to debug.

EDIT: Think I found the root of the problem now. As you said, setting 4.1.7 is involved. Which I don’t think I have in my settings, but its references here:

That thermostat is also reflecting what I’ve set through openHAB. It’s just not connected to the actual system which should not be a issue with the binding/openHAB. Old software in the heat pump? Blind operator? :slight_smile:

How does it look if you (in the nibe uplink ui) navigate to Manage → heat pump → plus functions? Do you have the smart home category there, like this?

I don’t see plus functions there. I did at the physical display on the actual heat pump, but then it was only smart price adaption (no trace of smart home).

This is how the UI look like for me when going Manage → Heat pump (the picture):

I would guess that the SW in the heat pump is anno 2014 and never updated so that could be the cause I guess?

That could probably be it. But if you remove the Thermostat Thing (and wait until it disappears from Nibe uplink, could take up to an hour). You should be able to use one of the other channels, control#47398 or control#47011 to control the temperature. If you have a thermostat configured it takes precedence, that’s probably why it didn’t work before.

Thanks for all the support! I’ll give it a try to update the heat pump at the next visit. So that what I see in nibe uplink is the cloud version of the thermostat created by the binding in openHab? (but that for some reason, probably outdated sw, never gets connected to my actual heat pump)
Also good to know that there could be other options if that’s not going to work. What determines whether 47398 or 47011 is used? I see 47394 as a switch, but that’s not exposed by this binding or am I missing it? Basically - what is the equivalent of menu item 1.9.4?

It depends on whether the room sensor is active. In that case 47398 us used to set the target temperature. Otherwise, 47011 us used to set the heat curve offset.

Nibe doesn’t expose all settings through their official API unfortunately. If you have a need to automate those you can use the official openhab binding, which interacts with Nibe uplink through the web page, but I think that requires some manual configuration of channels for the less common parameters and settings.

If anyone ever experience what I describe in the thread above: It was outdated firmware on the heat-pump that was the cause. “Smart home” appeared as an option when i upgraded the SW; and its now syncing with the virtual thermostat, that in turn is controlled via openHAB (i.e. all is working!). Just need to decide now if I want to work with the thermostat all the time, or figure out how to switch between thermostat (which I’ve used so far when in the house) and heat curve offset (which Iv’e used so far when not being in the house). But as you say pacive I may be able to do that with the other binding.