Rainwater Pipework Labelling

One risk with having two separate water pipework systems in a building, where one set of pipes carries Drinking Water supplied from the mains and the other set carries Rain Water, is that it’s important to ensure the right pipe is connected to the right appliances – especially when new connections are being added some time after the original pipework was installed. Accidentally connecting to the wrong pipe won’t be obvious since both pipes carry cold water, but Rain Water is not safe to drink (and must not be allowed into the water supply network).

In the Outbuildings (as opposed to the House) it helps that the pipework is exposed so it’s not too difficult to trace the pipes, but the regulations rightly specify that the rainwater pipework needs to be clearly labelled at suitable intervals.

It seemed sensible to label both sets of pipes, for extra clarity, and to follow the BS1710:2014 guidance for the label colour scheme. This uses Green as the background colour (to indicate a Water pipe) then various other coloured band(s) to indicate the type of water and the source. RM Labels offer a nice range of pipe labels and valve tags and I settled on:

  • For the Drinking Water pipes, their Drinking Water Pipe Marker PMW32a which has a Blue band, indicating “Potable water derived from the public water supply”
  • For the Rain Water pipes, their Rain Water Pipe Marker PMW59a which has a Grey band (to indicate a source other than the public water supply) and a Black stripe (to indicate the water is non-potable).

While it is of course necessary to follow the label colour standards and professional plumbers should be familiar with the colour codes, I’m not sure who else would know what the Grey, Black and Blue bands mean – but the text makes the pipe contents clear too.

“Rain Water” and “Drinking Water” pipe labels attached to insulated 22mm copper water pipes

One minor problem is that these labels don’t stick very well to polythene pipe insulation – especially in cold and damp conditions – so I opted to over-wrap the labels with the sort of clear sticky film intended for wrapping paperback textbooks (visible as a shiny band in the photo). That film is cut long enough to wrap over onto itself, which should help it stay in place.

(An alternative would have been to use slightly different labels that are supplied on a roll and which wrap all around the pipe by themselves, e.g. Drinking Water Pipe Banding for Potable Water from Public Water Supply – Self-adhesive – PB001PWPWS and its equivalent for Rain Water.)

myUplink Token Renewal Issues

At noon on Thursday 18th December the data for the NIBE Ground Source Heat Pump stopped updating onto heatpumpmonitor.org. Some of this data is sourced from the Heat Pump Controller, which only uploads it to NIBE’s myuplink.com so the required parameters need to be downloaded from there. The remainder of the data is sourced ‘locally’ – from heat meters and electricity meters – then all the data required by heatpumpmonitor.org is uploaded together.

HeatpumpMonitor.org graph not updating after noon on 2025-12-18

There are a few possible reasons for the lack of updates so once I’d noticed the issue I did a few checks:

  • Was my heatpumpmonitor ‘uploader’ script still working?
    • Yes and no: it was being invoked every minute as expected but it was failing to find any recent myUplink data to upload – which suggested a problem with the download from myUplink.
  • Was the myUplink ‘downloader’ script still working?
    • It was running but it was failing, with an error message (from the Python code that handles the OAuth2 Authentication):
oauthlib.oauth2.rfc6749.errors.TokenExpiredError: (token_expired)

The myUplink website and app were working fine, indicating that the heat pump was ‘online’ and showing recent data and graphs – so the data was getting to myUplink OK but the script that calls the myUplink API to download the data wasn’t successfully Authenticating, because it was presenting an ‘expired’ token.

Expiry of the tokens used for OAuth2 Authentication is perfectly normal; they have a relatively short lifetime of 3600 (seconds, i.e. 1 hour) and need to be renewed once they expire. Renewal is normally automatic, using the auto_refresh_url and the refresh_token to do that.

I had a vague recollection of this happening before, which led me to go through the process of creating and authenticating new application ‘secrets’ but I thought that didn’t help with having the tokens auto-renew. After a few days everything started working again so I assumed there had been a fix applied at the myUplink server end. However, it’s now been three days since the download API calls worked which feels like enough time for the myUplink administrators to have spotted an issue – although half of that time has been on the weekend.

Maybe trying to Authenticate a new Application will highlight a wider issue – or alternatively, if that works, it will show that re-Authenticatng the existing application will also work?

Using a new Application (i.e. with a different Client ID and Client Secret) worked OK – but that’s not actually testing token renewal so I need to wait for the token to expire and test it again.


Two hours later and the new Application happily renewed its (by then) expired token. Swapping the existing script over to the new Application credentials has made those spring into life and now data is flowing again.

So it looks like the Application credentials need refreshing periodically. Perhaps the refresh_token has its own expiry period? Looking back at some old files, there is a suspicious-looking date stamp of 18 Dec 2023 on one of the saved token files, which hints at a 2-year expiry period for the refresh_token.

If that’s the case, it should stop working again on 21 Dec 2027.