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).

In the House, there are Oregon Scientific temperature and humidity sensors in about half the rooms, as described in the Multi-Room Temperature and Humidity Monitoring page. These are integrated with Home Assistant via an RFXCOM 433MHz gateway. At the time those were installed they were an easy and cheap add-on to an existing monitoring solution and continue to work well – but they don’t feel like the best choice for a new setup in the Outbuildings. Where sensors like the THGN132N are listed by online stores they’re showing “Out of Stock” but would be £20 each, inc VAT.

In the Outbuildings, the Workshop and Utility Room are insulated and heated – and will report temperature (and humidity?) data via their Daikin air-to-air heat pump controls – so arguably those don’t need any further sensors. It’s the unheated, uninsulated and well-ventilated spaces which are of more interest – especially in terms of any risk of below-freezing temperatures (frozen water pipes?) or condensation.

An important emerging standard for environmental sensors and other IoT devices is the Matter IoT protocol, typically run over the Thread radio network. The vendor-independent nature of both Matter and Thread is appealing and they both operate locally within a site – not relying on an Internet connection or Cloud-hosted services. The Home Assistant folks are committed to supporting these protocols and IKEA have recently announced they will be moving their IoT product line over to the Matter and Thread standards and there’s an initiative to integrate Thread with KNX. That feels like enough momentum to make these protocols ‘mainstream’ – but even if they prove unsuitable it will be good to learn about how both Matter and Thread operate. Matter is based on IPv6 and it will be interesting to see how that has been implemented.

The separation between the Matter service protocol and the Thread (or WiFi) network layer feels like a robust IT architecture decision – as does the ability to have multiple Matter Controllers active simultaneously.

For the temperature and humidity sensors, Ikea’s TIMMERFLOTTE should be a good option – though they’re not available for purchase quite yet. If those don’t work out, other Matter-over-Thread sensors are available. The other required pieces of the puzzle are:

• A Matter Controller – which is expected to be Home Assistant
  • Controllers are used to operate installed Matter devices
  • The Controller software runs as a separate process but on the same server as Home Assistant
• A Thread Border Router – which connects the Thread radio network to wired and / or wireless Ethernet
  • This will almost always be a dedicated hardware device, since it needs to be located where it can act as a Thread radio, within range of Thread client devices
  • It’s possible to run the OpenThread Border Router software on something like a Raspberry Pi with additional boards to handle the Thread radio communications, but that seems like a lot of work to end up with a very flexible but unoptimised solution
  • Many of the devices which act as Thread Border Routers are part of the Google, Amazon, or Samsung ecosystems, which makes me think they’ll be expecting to integrate with other devices from those ecosystems – and might tend to be more ‘closed’ and less standards-compliant as a result
  • The GL-iNet GL-S20 IoT Gateway | Thread Border Router looks like a nice option:
    • It can be powered via PoE
    • It is supplied with a wall mount bracket
    • It runs the OpenThread Border Router software
    • It’s affordable – about £35 from the official GL.iNet store on AliExpress

I’ve now ordered one of the GL-S20 TBRs, though it will take a week or so to arrive from China.