NIBE Uplink Application Programming Interface (API)

The Ground Source Heat Pump (GSHP) is a NIBE F1145 unit which supports the NIBE Uplink facility – which basically means the unit connects to the Internet, uploads status information on a regular basis and permits some degree of remote control.

Data can be accessed at the website, via an iOS or Android app and also via an API. While the apps are handy it’s the API that holds the potential to integrate the data from the heatpump into a wider domestic monitoring scheme.

I get the impression the main purpose reason for having an API is to support the mobile apps and it’s evident the apps are using it under the covers but kudos to NIBE for making it available for other developers to use. It uses fairly standard Internet API technologies like REST, JSON and OAuth2 but it’s not particularly mature and not perfectly documented so the learning curve is relatively steep.

After a few hours of trial and error I’ve got it working from a Perl script and it’s currently logging temperature data via MQTT into InfluxDB from where I can easily graph it using Grafana – sample below showing the heat pump firing to top-up the temperature on the hot water tank (click the image to enlarge) – the graph is a bit “lumpy” since I’m currently only grabbing data every 5 minutes, though that’s configurable.

Grafana display of GSHP data from NIBE Uplink API

Grafana display of GSHP data from NIBE Uplink API

The biggest hurdle was getting the authentication scheme working – OAuth2 permits a program to make requests on behalf of a user without asking for their password all the time – but that was new to me, and it’s a little idiosyncratic. Perl module LWP::Authen::OAuth2 helped a lot and in particular that takes the pain out of handling token renewal when making API calls.

UPDATE: I’ve now written a separate Technical Article on this topic which includes some sample script code and a HOWTO guide. See here.

Week 33, Day 1

Week 33, Day 1:

  • Bank Holiday Monday so no proper work on site today, just me tidying up a few bits and pieces – like running the cables for the ceiling speakers in the open plan area
  • I also got my KNX and DALI test-bed up and running quite nicely – more info below the photo
Week 33, Day 1

Week 33, Day 1

I should probably write a Technical Article about the Home Automation solution sometime but for now these and the other similar notes will have to suffice. In summary, I’m using KNX as the high-level control protocol but this hands off to DALI for (most of) the lighting – on the basis that there’s much more choice of LED dimmers that support DALI than KNX, and they tend to be cheaper.

The original plan was to use DALI relays for the non-dimmable lights (e.g. some internal wall lights and the outdoor floodlights) but there actually seems to be less choice of DALI relays than KNX relays and a single 16-way KNX relay will switch all the lights and is much cheaper than multiple DALI relays. There are also some trade-offs with respect to the limits that apply to each protocol:

  • DALI has a fixed limit of 64 addresses per DALI bus, and I was going to exceed that with all of the non-dimmable lights grabbing their own DALI address
  • KNX has a limit of 20 devices (using the ETS Lite license) but a 16-way relay counts as a single “device” so is relative low-impact in terms of the KNX device limit

Since I’m no expert in either KNX or DALI I wanted to bench-test the main components before hiding away all the first-fix wiring. That testing has gone well and I’m now happy I understand enough about these systems to proceed.

I also had good results testing openHAB which is currently my preferred solution for extending the control options to include web browsers, tablets and smart phones. In particular, the openHAB KNX “binding” is working very well so I can use that to control all the KNX devices (including the lights, via the KNX-to-DALI interface) from a smart phone or tablet as well as from the fixed switches in the house. I find it particularly pleasing that when you use one of the fixed switches the smart phone app updates the status immediately, showing that e.g. a light has been turned on or off. (The fixed switches will be momentary-action so they return to the “off” position, likely to be these MK Logic ones marked “press”. They will be configured to work in a “toggle” mode – press once to turn on, press again to turn off.)