Author Archives: dMb

Temperature and Humidity Monitoring in the Outbuildings – Stage 3

Posted on by
Reply

An earlier Post outlined the plan to use IKEA TIMMERFLOTTE Temperature & Humidity Sensors with a GL.iNet GL-S20 Thread Border Router in conjunction with Home Assistant, to monitor the environmental conditions in various parts of the Outbuildings – especially the unheated rooms which are open to the ambient conditions.

I got the TIMMERFLOTTE devices on-boarded to Home Assistant fairly easily and they even noticed they had a firmware update available and downloaded and installed that over-the-air – all without needing any other IKEA-specific ‘hub’ or similar devices. The on-boarding (“commissioning” in Matter terminology) requires a smartphone (iOS in my case) and makes use of some of the built-in Apple software to help the Home Assistant App handle the set-up. For that to work, the smartphone must (temporarily) connect to the same network subnet as both the Thread Border Router and Home Assistant.

While the devices worked fine when tested in the House, they were not working when moved to the Outbuildings – despite them being on the same network Subnet (which gets ‘stretched’ to the Outbuildings – albeit via a few Ethernet Bridges and extra network hops). This was puzzling because everything was expected to work the same in both locations. It turned out to be a firewall issue, related to the use of an extra IPv6 address range: in the House the network traffic only has to traverse the network Switch to get from the Thread Border Router to Home Assistant (so it doesn’t reach the firewall) but with the Thread Border Router moved to the Outbuildings the traffic is traversing the inter-building link so hits the firewall to get to Home Assistant – even though it’s on the same Subnet. Three firewall rules turned out to be required:

  • Allow IPv6 UDP traffic with Source Port 5353 (i.e. mDNS)
  • Allow IPv6 UDP traffic with Destination Port 5540 (i.e. Matter)
  • Allow IPv6 ICMP traffic – to permit Home Assistant to ‘ping’ the sensors for diagnostic purposes

It’s clear the Matter protocol expects a completely ‘flat’ network topology – which isn’t great from a security or problem-solving standpoint. A decent compromise is to have a dedicated and largely isolated ‘flat’ Subnet for Matter / Thread traffic – but to dual-home the Home Assistant server so it can also participate in Matter communications (while using its ‘other’ network interface for all other communications).

myUplink Token Renewal Issues

Posted on by
Reply

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.