Nibe Uplink REST API Binding [3.3.0;4.2.0)

Add-on Marketplace Bundles
, ,
1

logo

This binding connects to the Nibe Uplink public REST API to get current information about, and change some settings on your connected Nibe Heatpump. The binding is compatible with OpenHAB 3.1 and later.

This uses a different method of obtaining data than the official Nibe uplink binding, instead of interfacing with the Nibe uplink website, this version uses Nibe’s official 3rd party REST API. This makes it work different in a couple of ways:

  • It uses OAuth for authentication, which makes it a bit more difficult to set up, but you don’t need to provide your credentials to anyone other than Nibe.
  • It supports autodiscovery of any connected systems once the Bridge is set up
  • You can connect a thermostat to your heatpump via OpenHAB, which can increase/decrease the water flow temperature based on the measured temperature and optionally a setpoint
  • It doesn’t allow to change arbitrary settings on your heatpump, only a limited set is available (due to constraints in the api)

See the documentation for more details

Documentation

Source code

Changelog

Version 1.0

Initial Add-on Marketplace release

Version 1.1

Fixes a bug where there was a channel-type name collision when having Smart Price Adaptation activated, causing some channels to misbehave.

NOTE: The fix might make some channels invisible in the UI because their channel-type is no longer valid. The channels themselves continues to work and updates the Items as usual. To fix this, simply delete the Thing, run discovery and re-add the Thing. All Items will be connected automatically.

v1.1.1

Fix a bug where Thermostat Things did not get properly disposed when disabling or removing.

v1.1.2

Fixed some user-reported bugs

  • kWh-channels should now be scaled correctly
  • Sending QuantityTypes as commands should now work
  • Adapt to API sending ‘l/m’ as unit for litres per minute

v1.2.0

Fix bug where scaling factor would sometimes be set to 0

Also built version to be cross-compatible with OH 3.4 and 4.0

v1.2.1

Added some logging to help with debugging

v1.3.0

Added some more status channels (coolingpassiveActive, brinePumpActive

Fix compatibility issues with openHAB 4.0

Drop support for openHAB 3.2.0

Resources

https://github.com/pacive/openhab-addons/releases/download/v1.3.0/org.openhab.binding.nibeuplinkrest-4.1.0-SNAPSHOT.jar

3 Likes
2

What about the official binding?

Is it the same binding?

1 Like
3

No it’s not the same. This version uses Nibe’s official rest API for 3rd party integrations, whereas the official binding uses the API that the nibe uplink web page gets data from. Unfortunately, me and the developer of the already included binding couldn’t agree on a way to merge them into one, and having two different bindings for the same service didn’t seem like a good idea. Me and a few other users prefer this integration, so when the marketplace was launched I uploaded it here. If this breaks the marketplace rules i can remove it.

4

That is clearly a pity to not have found a solution to have only one binding.

@ysc : is it compliant with the marketplace rules?

At least you should mention what is the difference with the official binding.

5

Agreed that would be the minimum. Also a link to the source code is required.

As for whether is it acceptable in the marketplace… it’s a tough one. Maybe the rest of @staff can comment. It seems different because it uses another protocol but the end goal seems to be the same.

That’s unfortunate, the way I see it, most of the time when you have multiple versions (outside the temporary beta versions await review), it seems to be because of interpersonal drama. The marketplace is not meant as a way to circumvent fruitful collaboration, causing users to have to decide which one is the “best” among multiple alternatives of the same thing - and they don’t need to know (or care, really) how it came to be.

If they are in the know, then of course they’re free to install what suits them best (there are alternatives to the community marketplace to install an add-on), but since the marketplace is featured by default in the UI and a lot of openHAB users don’t visit this forum, it would only cause confusion.

I don’t know if it’s feasible, but why couldn’t the two of you be co-owners of the Nibe binding? You would work in your own Java packages, not sharing any code, and the thing type labels would clearly state which ones are related to which protocol, and the doc would clearly explain that they are two protocols to address the heat pump, with the pros/cons of each. It doesn’t solve the “confusion” problem but at least there would be only a single binding.

1 Like
6

This I can most certainly do. Edit: Done!

I agree, you can see the discussion we had in this thread. After that I decided to just use my version for my self, but was later asked by a couple of other users who were interested in using this integration.

It might be doable to just have separate packages side by side in the same binding, but at least the xml files would have to be merged, no? It could probably be done if one takes care to not have any duplicate channel-uids etc.

As said above, if you feel this is not a good fit for the marketplace I can remove it.

7

I’m getting a Failed Install on this Binding, just upgraded to OH3.2

8

Does it show any additional errors in the logs?

9

No, just the ‘Failed Install’ in de Addons Marketplace. I did have the old version installed, but that didn’t work any more (3.2 upgrade). Forced deleted the Thing, but still unable to install the new version.

10

Have you made sure that the old version is deleted from the addons directory and isn’t listed when you run bundle:list in the console?

If it fails to install at all, this isn’t due to the binding, but something that prevents the marketplace from downloading or installing the bundle.

11

Thanks, that was the, some leftovers showed in the bundle list and after uninstalling them via the console, I could install the new version via Marketplace

Many Thanks!

1 Like
12

Have now migrated to OH3.2 on Docker and installed this binding. Thanks for you good work!

13

Hi,

thanks for the great binding. I am using it since months now.

Current setup:
System: openhabian on Raspberry Pi 3 B+
OH version: openHAB 3.3.0.M1
Binding version: Bundle-Version = 3.2.0.202109130834
Installed via Community Marketplace

Lately I wanted to add some more channel links and was wondering why my items (all items linked to channels of my NIBE F730 heatpump) stopped updating.
In the normal log:set “INFO” there is no hint of the binding/things behaving unnormal. Also the status of the things (heatpump and bridge) are displayed normal and “ONLINE” in the things overview.

I then checked the DEBUG and TRACE log level and found these messages:

2022-02-18 22:11:19.336 [TRACE] [internal.api.NibeUplinkRestConnector] - Queueing system and status request for <mySystemID>
2022-02-18 22:11:19.337 [DEBUG] [internal.api.NibeUplinkRestConnector] - Queue full, request discarded
2022-02-18 22:11:19.338 [TRACE] [internal.api.NibeUplinkRestConnector] - Queueing parameter request for <mySystemID> with 15 parameters
2022-02-18 22:11:19.339 [DEBUG] [internal.api.NibeUplinkRestConnector] - Queue full, request discarded
2022-02-18 22:11:19.340 [TRACE] [internal.api.NibeUplinkRestConnector] - Queueing parameter request for <mySystemID> with 10 parameters

After that I did some trial and error and removed some of the previously added linkings one after another. Doing a restart of the bundle in karaf console and at a certain amount of linked items the faults are gone and the remaining items are updating well.

What is this?
Is there a maximum number of parameters which can be fetched at the same time?
I didn’t find anything in the docs.

Thanks for the help :slight_smile:

Cheers
Jonathan

14

Yes, the API only allows to fetch 15 parameters (i.e. channels) in each request, ant it’s also rate limited to about 15 requests/minute. So what the binding does is to put all parameters in a queue and send the off 15 at a time a few seconds apart. If more parameters are queued for the next round the queue starts filling up until it reaches its maximum after which new requests are discarded.

If you want to use a lot of channels you can increase the refresh interval (on the bridge) so it has more time to send all requests before the next batch.

It might also be that the binding has gotten into a weird state and just queues the requests without sending them. Not sure what would cause this, but I’ve had it happen to me as well (though only once over the few years I’ve used the binding, so it’s hard to debug). In that case a restart of the binding should be enough.

15

Hi Anders,
I installed your addon on my openhab installation (OpenHAB 3.2.0 on a Raspberry Pi 4) and configuring and activating the addon was successfully. Added the Bridge a thing and it shows a green ONLINE. When I am scanning afterwards for things it shows the System thing and I add it too (entering the Serial number of the Nibe heatpump from https://myuplink.com). BUT: the System thing always shows the status INITIALIZING and never shows any channels.
In the openhab.log I see entries:

2022-03-20 02:06:40.340 [WARN ] [ore.internal.thing.ThingTypeResource] - Cannot find channel group type: nibeuplinkrest:control
2022-03-20 02:07:56.012 [WARN ] [re.thing.internal.ThingFactoryHelper] - Could not create channels for channel group 'control' for thing type 'nibeuplinkrest:system:ffc83e0a2c:43b4b2cf8f', because channel group type 'nibeuplinkrest:control' could not be found.

Do you have any hint what goes wrong?

16

Unfortunately, this binding is not compatible with the new myuplink.com service, only the older nibeuplink.com. In case that was just a typo, you shouldn’t need to enter any serial number, everything should be handled by auto discovery.

The error message still confuses me a bit though, are there any other errors in the log when running discovery?
In not, can you turn on debug logging and try running discovery again?

17

Hi Anders,
I tried to register at the old service http://nibeuplink.com, but the registration failed for my heatpump :frowning:, did try it several times. The registration at the new portal worked flawless.
So as I understood it, this will not work without successful registration at the old service. Are there any plans to support the new service also?

18

I have looked at the new API a little, but it’s hard to implement anything when I don’t have any way to test it, since my own heat pump only works with the old service. So unfortunately there are no plans at the moment unless I can get some help with the development.

19

Hi Anders,

thank you very much for your help. I recognized, that the NIBE 1255 heatpump has a Modbus TCP interface, which only has to be activated in the menu of the heatpump. So I managed to read the values straight from the modbus of the heatpump with the Modbus binding, without going through the Uplink-API.

20

Hi,

I wonder if this still working, is there anyone using it successfully?

I added the nibeuplink.com and the new app from the developer website (api.nibeuplink.com) , made the oauth authentication and the bridge lit up green “ONLINE” as it should.

But no system was discovered afterwards. Forcing a little bit the hand, I manually added a system, and used the ID from the nibeuplink.com URL as SystemID… and that seemed to work as the System appeared green lit ONLINE as well. And then again, nothing else is discovered afterwards.

Like @milinovsky im having the error:

2022-07-21 11:47:54.095 [WARN ] [ore.internal.thing.ThingTypeResource] - Cannot find channel group type: nibeuplinkrest:control
2022-07-21 11:48:11.077 [WARN ] [re.thing.internal.ThingFactoryHelper] - Could not create channels for channel group 'control' for thing type 'nibeuplinkrest:system:483fc54afc:053fc839e0', because channel group type 'nibeuplinkrest:control' could not be found.

And after a few minutes I also get these errors:

2022-07-21 11:58:01.275 [ERROR] [ence.jdbc.internal.JdbcConfiguration] - Mandatory url parameter is missing in configuration!
2022-07-21 12:00:03.313 [WARN ] [ore.internal.thing.ThingTypeResource] - Cannot find channel group type: nibeuplinkrest:control
2022-07-21 12:01:00.418 [ERROR] [oauth2client.internal.OAuthConnector] - grant type authorization_code to URL https://api.nibeuplink.com/oauth/token failed with error code invalid_request, description 
2022-07-21 12:01:00.423 [WARN ] [rnal.auth.NibeUplinkRestOAuthServlet] - Error authorizing thing: null

Which tells me that either the documented procedure here is wrong with missing information or this doesn’t work at all.

Is there any other options for explaining these errors?

OH 3.3.0 on Arch Linux VM