KNX Bus Connectivity for the Outbuildings

The House has a KNX bus installation, connected to a KNX IP Interface which allows home automation ‘hub’ software like openHAB or Home Assistant to control KNX devices such as lights and roller blinds. This IP Interface connection is also required for programming KNX devices using the KNX ETS software.

The Outbuildings will also have several KNX devices. The original plan was to implement these on a completely separate KNX bus installation, because:

  • There is no anticipated requirement for KNX devices in the House to interact directly with KNX devices in the Outbuildings – e.g. for a KNX wall switch in the House to control lights in the Outbuildings
  • The ‘Lite’ license for the KNX ETS software only allows a maximum of 20 KNX devices in each KNX ‘Project’ (but unlimited Projects) and the House already has 19 devices configured
    • By making the two KNX installations separate, they would each have their own KNX ‘Project’ and each of those would have fewer than 20 devices
    • The next step up from the ‘Lite’ license is the ‘Home’ license, which only allows a single Project – but that can have up to 64 devices

For convenience, a single home automation ‘hub’ will be used to manage all of the KNX devices – but that means it would need to talk to two separate KNX IP Interfaces, which is not (currently) a supported configuration for the Home Assistant KNX Integration.

There are several possible options to address this:

  1. Use a not-fully-supported workaround to allow Home Assistant to connect to two KNX IP Interface devices by running a second instance of the xknx software
  2. Use two separate instances of Home Assistant, each with their own KNX integration, connected to each other using https://github.com/custom-components/remote_homeassistant
  3. Revert to using openHAB (rather than Home Assistant), since openHAB does support connections to multiple KNX IP Interface devices
    1. Potentially using openHAB in conjunction with Home Assistant, using the openHAB <-> Home Assistant Bridge integration
  4. Connect the House and the Outbuildings as different ‘lines’ (or ‘line segments’) on the same KNX ‘bus’ – although then all the KNX devices need to be in a single ‘Project’, which requires a more expensive ETS license
    1. Potentially using a KNX ‘Line Coupler’ device and a KNX cable connecting the buildings
    2. Alternatively using KNX ‘IP Router‘ devices (rather than KNX ‘IP Interface‘ devices; one per building) – which then connect the two KNX ‘lines’ via the IP network connection between the buildings
      1. In principle, this could be achieved using the https://github.com/knxd/knxd software (running on something like a Raspberry Pi) to implement the Routing, using an IP Interface device in each building talking to knxd

Other considerations:

  • The existing ETS ‘Lite’ license is for ETS v5 but ETS v6 has been available for a while (and is already up to v6.3). An upgrade to ETS v6 will be required at some point anyway.
    • An upgrade from ETS v5 ‘Lite’ to ETS v6 ‘Lite’ costs €150
    • An upgrade from ETS v5 ‘Lite’ to ETS v6 ‘Home’ also costs €150
  • There would be a benefit in being able to add further KNX devices to the House, above the limit of 20 imposed by the ‘Lite’ license – further KNX wall switches, for example
  • The KNX ‘IP Router’ devices are relatively expensive (around £195) – and Routing KNX over IP would need two of those – whereas the KNX ‘IP Interface’ devices are cheaper (around £120)
  • A KNX ‘Line Coupler’ is around £140.
    • These can be configured as a Repeater (like an Ethernet Bridge) to simply replicate all the KNX messages while electrically isolating the two cables
    • Or they can be configured as a Coupler (more like a Network Router), with rules determining which subset of messages get passed across
  • A KNX installation consisting of even 64 devices is still considered ‘small’ and is well within the limits for even a single KNX line segment
    • The KNX cable runs are probably just short enough to allow this to all be cabled on one KNX line segment, but since there are separate buildings with separate mains electricity supplies (from the same grid connection and meter) it is best to keep them (electrically) separate

In the interests of keeping things simple, it seems best to consolidate everything into a single KNX Project, which means upgrading to the 64-device ‘Home’ license for ETS v6.

That leaves the question of whether to connect the buildings with a KNX cable (and a KNX Line Coupler) or whether to use an IP network connection between the buildings (which is required anyway, and will be a fibre optic cable) and two KNX IP Router devices. While KNX cable is pretty tough, and well-shielded, for an underground connection between different buildings it seems best to use something different (and less sensitive to interference) – which favours an IP connection and two KNX IP Routers.

One complication is that KNX IP Routers use a Multicast network address. This is straightforward to manage on a single LAN segment but more problematic when the traffic needs to pass through multiple IP Routers, such as are planned for the IP network connection between the two buildings.

NIBE F1145 GSHP Migration from NIBE Uplink to myUplink Platform

Historically, NIBE’s F-series of heat pumps (like my F1145 GSHP) used the “NIBE Uplink” Cloud-hosted monitoring platform and the newer S-series heat pumps used the newer “myUplink” instead. The S-series models have more capable control system hardware and touch-screen displays and benefit from some of the more advanced features of the myUplink platform. The network protocols used to link the heat pump to the Cloud platform are also different – rather more ‘dynamic’ so setting changes made via the myUplink app take effect more quickly. Another important change is that firmware updates are downloaded automatically and only need confirmation from the control panel, rather than having to be installed via a slightly temperamental procedure using a USB drive.

About a year ago, NIBE decided to retire NIBE Uplink and move the F-series units across to the myUplink platform and they’ve been gradually making firmware updates available which, when installed, point an F-series heat pump at myUplink instead of NIBE Uplink. They started with the more common models such as the standalone SMO 20 controller (used with various F-series ASHP models) and have been working their way through their model range. The SMO 20 update was made available in late 2023 whereas the firmware update for my F1145 only became available in mid 2024.

I had been running Version 9478(R1) of the F1145 firmware, dated 2021-07-09 (the latest available until mid 2024) and I upgraded to Version 9699(R5), dated 2024-07-03. The update was applied without any issues and after logging into the myUplink platform using my NIBE Uplink login credentials, my heat pump appeared in the myUplink dashboard. My installer’s account, which was granted the ‘Manager’ role for my system. migrated too – maintaining their access.

Observations on NIBE Uplink Network Communications

Roughly every 30 seconds, the unit issued a DNS ‘A’ record query for control.nibeuplink.com which resolves to a CNAME record pointing at an azure.com address. It then proceeded to connect to that address using the HTTPS protocol and exchange about 11 packets of data before closing the HTTPS connection. Periodically there were NTPv4 queries to ntp.nibeuplink.com which maps to CNAME time.google.com (although I have been substituting the address of a local NTP server instead).

Observations on myUplink Network Communications

Looking at the network communications following the migration, there are many more server addresses in play; ones I spotted include:

  • iotstatic.myuplink.com
  • api.myuplink.com
  • internalapi.myuplink.com
  • auth-emmy.myuplink.com
  • ipv4.myuplink.com
  • ntp.myuplink.com

It looks like the main data flow is now on TCP port 8883, which implies MQTT-over-TLS, on a persistent TCP connection. By default there seem to be updates every minute and, interestingly, whenever the myUplink smartphone App is accessed there’s a lot more activity that gets triggered.

ntp.myuplink.com is mapped to a CNAME of se.pool.ntp.org – i.e. one of the servers in the public NTP pool for Sweden.

Implications for Heat Pump Monitoring

I had been calling the NIBE Uplink API every 2 minutes from an automated script, to retrieve operational parameter values such as temperatures and circulation pump speeds, and storing those in a local database for display using the Grafana graphing dashboard. Some of these parameters were also being uploaded (via a separate automated script) to emoncms.org for display on the heatpumpmonitor.org dashboard.

While there is also a good API for myUplink, it’s structured differently – actually a bit ‘better’ in that fewer API calls are required to retrieve more parameter data. I now need to update the scripts so as to reinstate the data download to my local database. Since the API is looking more efficient I’m minded to increase the frequency to every minute.