Motorised Vertical Blind

The window in the office on the second floor is large (5.5 m^2) and directly west-facing. It’s a nice feature and provides a great view but it does let the evening sun in which tends to overheat the office on the hotter days of the year. The answer is some shading. External shading is more effective than internal at keeping heat out and it might be sensible to add some fixed external shading in due course but for now I’m going to fit an internal blind and see how much of a difference that makes.

One complication is that the top of the window follows the line of the north roof, which slopes at 12 degrees and means normal roller blinds (as fitted to the other windows) won’t work. A “bottom up” roller blind might have done the job but I settled on a vertical blind with slats of differing lengths that stack on the tall side of the window. Something that proved more complicated than I was expecting was arranging for motorised control – I want to be able to close the blind automatically based on the time of day, the temperature and the amount of sunshine.

All of the windows have a connection point at one of the top corners for an electric blind, with a 3-core & earth cable which runs back to a control unit. For most blinds this is fine – the 3 cores are used for Neutral, Live #1 (Up) and Live #2 (Down). However, my chosen brand of vertical blind motor wanted a permanent live as well as two switching cables, requiring a 4-core & earth cable. I briefly considered running a different / extra cable but then decided to pursue other options.

In general I’m not a fan of radio control since in the past I’ve had issues with devices only working intermittently but it seemed like the least-bad way to go in this case. The Benthin IQ2 motor recommended by my blind supplier works with the Somfy RTS radio control standard and for manual control this works very well with a hand-held transmitter. For remote or automated control things are a bit more complex but the¬†RFXtrx433E USB HA controller from RFXCOM¬†supports the Somfy RTS protocol and is also supported by OpenHAB, my chosen home automation software. Using one of those also allows me to retire my old RFXCOM receiver which is listening for temperature and humidity messages from a range of Oregon Scientific indoor environment sensors.

Vertical blind installed in office window

Vertical blind in office window – fully open

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.