One of the most popular topics on this Blog is using the NIBE Uplink API to retrieve operational data reported by the Internet-connected NIBE heat pumps. That API is protected by OAuth2 authentication, which is a robust solution but which is rather more complicated than other APIs which simply expect an API Key or a non-expiring Token for authentication purposes.
There’s a Technical Articles page dating from 2016 which explains how to use the Perl scripting language on Linux to call the NIBE Uplink API, navigating the multiple steps of the OAuth2 handshake – see NIBE Heat Pump Monitoring via NIBE Uplink API (Perl Version). I originally chose Perl because that’s the language I was familiar with – and there was a Perl Module which handled many of the OAuth2 complexities.
Recently I’ve been learning Python for work and that’s proven to be a bit more friendly for this sort of thing. It’s also a language that more people are familiar with – and it’s rather more commonly used on different platforms, notably Microsoft Windows.
I’ve therefore adapted the original Technical Article to use Python rather than Perl and published that as NIBE Heat Pump Monitoring via NIBE Uplink API (Python Version). The Perl version is still relevant so will remain available too (especially since it has some valuable comments and responses) but my advice is for new users to follow the Python version instead.
I’ve also included some more general updates (such as the new NIBE S-Series heat pumps using an alternative API connected to myUplink.com) and some new screenshots. The script code is also now in a GitHub Repository rather than being embedded in the Blog page – and I intend to add some more comprehensive script examples once I migrate my other scripts from Perl to Python.
5 years after installation I’ve just encountered the first significant failure of the home automation system. The KNX module that monitors the momentary-action ‘light’ switches in the bedrooms stopped responding. Upon checking the unit all of its LEDs were flashing on about a 1-second cycle, so it wasn’t completely dead, but it clearly wasn’t happy. Turning it off and on again didn’t help.
The module is a 16-Channel Binary Input Module for Potential-Free Contacts, made by MDT in Germany. Searching for reports of similar problems turned up a couple of posts (in German) on https://knx-user-forum.de/ that hinted at a firmware bug. These devices come with a generous 3-year warranty, but I confirmed the purchase date and it was May 2016. A new replacement unit would be about 200 GBP.
I contacted MDT Support who confirmed there was nothing further I could do as an end-user and suggested I send the unit back to them for repair. They expected it would just need new firmware loading.
Sadly, thanks to Brexit, sending devices for repair in the EU is much more complex than when the UK was in the Single Market. The principal consideration is avoiding the imposition of either Import Duty or VAT – either when the package is going to Germany or coming back to the UK. (These would apply to the initial purchase, but because all applicable taxes had been paid in 2016 they do not need to be paid again, since nobody is making a new purchase.) I found little useful guidance on the Royal Mail or HMRC websites but stumbled across this very useful post from Mura Car Accessories, based in Romania and followed those instructions carefully – with good results. (A key step seems to be declaring a Temporary Export for Repair Purposes on the C22 form.)
The delivery of the repaired item was delayed because of an issue recording the UK (alphanumeric) postal code in one of the German systems (some mix-up between MDT and UPS, by the look of things), but it was delivered today and simply needed re-installing and re-programming. I am grateful to MDT for not charging for either the repair or the return shipment, so I got a good-as-new device for just the 7.50 GBP outward postal charge.
While the unit was away for repair, none of the wall switches were working, which was slightly annoying but actually highlighted a strength of KNX’s modular architecture. All of the rest of the home automation system continued to work perfectly and a simple workaround was to control the bedroom lights with the openHAB iPhone app instead – which still triggered the openHAB rule that sets ‘Night Mode’ when the bedside lights are turned off.