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.

M-Bus Water Meter Reading Discrepancies

There are three water meters in the house:

  • One on the incoming Cold water supply
  • One on the cold water supply to the bottom of the hot water cylinder, which measures the Hot water consumption (and needs to be subtracted from the incoming cold meter reading to leave the cold water usage)
  • One on the separate cold water supply to the potential-future-rainwater-harvesting pipework
    • This third one is actually fed from the incoming mains supply outside the house but might in future be connected to a rainwater harvesting system
    • Within the house, the pipework connected to this meter feeds the toilets, the washing machine and the outside taps (i.e. all the appliances which are permitted to be fed with harvested rainwater)

These meters are in addition to the water company’s ‘revenue’ meter and could be considered excessive, but:

  • The water company’s meter is about 600 metres away from the house so there’s a lot of underground pipework that could potentially leak (and which runs through fields which get ploughed) and it’s good to be able to cross-check the meter readings in case any leaks develop
  • It’s useful to be able to compare the Hot water usage with the Cold water usage – and to see how much of the water usage could potentially be displaced by rainwater harvesting
    • This is especially pertinent as I firm-up the specification for the Outbuildings, to be constructed as part of “Phase 2” of the building work, and compare the cost of a rainwater harvesting system with the potential savings

The three internal meters have M-Bus readers fitted and are automatically read every minute – along with all the other M-Bus readers in the house. (Reading so often is completely over-the-top for Water meters, but not for e.g. Electricity meters, and it’s easiest just to read all the meters on every read-cycle than to mess about reading different meters at different intervals.) Then, every month, I manually record the monthly meter readings (as reported by M-Bus) into a spreadsheet to look at a summary-level view and monitor trends in usage.

Over the past couple of months I’ve noticed the ‘rainwater’ meter showing much higher readings than before, which seemed odd. On the 1st of May, the usage was up a bit; on the 1st of June the usage was up a lot – roughly 10 x the usage in February, for example. Initially I suspected a leak but on checking further it was clear the meter reading wasn’t changing unless there was obvious water usage.

Then I realised what was happening: it’s not that the meter is now reporting ‘high‘ – it’s that the meter has previously been reporting ‘low‘. The dials on the meter are showing 114 m3 but the M-Bus adaptor is reporting 85 m3. Plotting a graph of the meter readings over time (that I don’t normally do) makes it clear that something went wrong around the end of April 2022 that got fixed around the middle of April 2024.

‘Rainwater’ Water Meter readings, early 2022 through to mid 2024

I know what I did to ‘fix’ it – I’d been checking the details of the meter to be able to match it in the new building and removed and re-fitted the M-Bus adaptor. I don’t know what I did to ‘break’ it – but given that some readings were still coming through I presume the adaptor was knocked slightly out of position. (If it had stopped reading completely I would have spotted it.)

The meters are Itron Aquadis models with Cyble M-Bus adaptors that slide into some slots on the front of the meters – but they don’t clip into place hence they’re reliant on friction (or gravity) holding them in position, and they can get knocked.

[2026-01-28 Update: Actually the Cyble adaptors are intended to be fixed in place with a screw which hadn’t been fitted – although one of the three adaptors had the right screw loosely inserted. These screws have an M4 thread 25mm long with a ‘Cheese’ Head and are made from Nylon. Also, there’s a ‘cap’ covering the brass thread insert they screw into which needs to be destructively removed to expose that thread. With that screw properly fitted the adaptors are kept in the correct alignment.]

Now the problem is that the internal registers on the M-Bus adaptor don’t match the dials on the meter and there are no buttons or display on the M-Bus adaptor to make any adjustments – so it’s a case of using the Cyble M-Bus software that I originally used to set the M-Bus IDs to re-set the reading from the dials.

This was easy enough – once I’d worked out the Cyble M-Bus software needs to run as Administrator. Changing the reading is as simple as clicking on the digits and entering the new reading.

Screenshot of Cyble MBus v1.4 software

I’d forgotten these adaptors have the option to report against a Leakage threshold value; what’s not clear is how the detection of a ‘leak’ gets reported – there no obvious ‘leakage’ field in the XML data record that comes back to the M-Bus reader.