Temperature and Humidity Monitoring in the Outbuildings

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.

M-Bus Electricity Sub-Meters for the Outbuildings

I’ve been finding the electricity sub-meters in the House very useful, showing the electrical consumption of the ‘significant’ electrical loads as a proportion of the total recorded by the main electricity meter, so I’ll be adding some in the Outbuildings too.

For the House, I initially used cheap meters with only an S0 ‘pulse’ output and recorded the readings manually every month. Later, I found some affordable (second-hand) M-Bus adaptors for the ‘pulse’ meters (various models from the Relay Padpuls range) and added those, enabling the meters to be included in the once-per-minute reading cycle for the Water meters and the Heat meters.

The ‘significant’ loads that in my view warrant a dedicated sub-meter are:

  • Heat Pumps
    • In conjunction with a Heat Meter for heat pumps with a Water output, enabling the real-world efficiency to be calculated
    • With an Air-to-Air heat pump, as will be installed in the Outbuildings, it’s not practical to measure the heat output – but it’s still worth recording the electricity input
    • If there are secondary circulation pumps or control units which have a separate electrical supply from the main Heat Pump unit, these should ideally have their own sub-meter
  • Mechanical Ventilation (with or without Heat Recovery) Systems
    • While their consumption is not especially high, the fact that these typically run 24×7 means their total usage can add up – and since they’re still quite unusual in UK homes it’s good to track their actual energy consumption
    • Some MVHR units vary their fan power to provide a consistent airflow, in which case a gradual increase in energy consumption can be an indication that the filters need replacing – although normally the filters should be replaced before this increase becomes noticeable
  • Electric Vehicle Charge Points
    • Sometimes these incorporate their own electricity metering, which can be accessed via a Smartphone App or other interface, but it’s convenient to have them metered in the same way as the other electrical loads
    • Each charge point should have its own meter, should there be more than one
  • Other ‘large’ or ‘interesting’ loads
    • Immersion heaters
    • Rainwater harvesting pumps

There’s a wide choice of electricity meters with an S0 ‘pulse’ output (EN 62053-31) and a rather smaller choice of meters with a Modbus output. For meters with a native M-Bus (Meter-Bus) output the choice is smaller still – but for a building that needs to have some M-Bus metering anyway it’s much more straightforward to add further M-Bus meters than to cater for alternative metering protocols as well.

I’ve settled on using MID-certified M-Bus meters from UK company Rayleigh Instruments, having added one of their meters to the House a few months ago and after receiving positive feedback from another self-builder who uses one for their air-to-water Heat Pump:

  • The 2-module-wide RI-D35-100-MB which is a directly-connected meter for loads up to 100A
    • This reports Manufacturer = “RAY” which is one of two manufacturer codes allocated to “Rayleigh Instruments, United Kingdom”
    • This returns a lot of data via M-Bus which spills over into a second M-Bus telegram, requiring the M-Bus software to be able to handle a multi-telegram response
  • The 1-module-wide RI-D175-MB which is a directly-connected meter for loads up to 45A
    • Despite being branded as a Rayleigh Instruments unit, this reports Manufacturer = “PAD” which is a manufacturer code allocated “PadMess, Germany”
    • Note that this meter appears not to respond to a Secondary M-Bus address, so Primary addressing must be used
    • There’s a variant of this available with a Current Transformer (CT) input instead of being directly-connected, which caters for currents up to 100A
    • There’s more information about this specific meter in a Technical Article page here.

These are available for about £25 each; surprisingly the larger meter is less than 10% more expensive than the smaller one, so actually I only use the smaller one for loads up to about 16A (where the smaller terminals are helpful for connecting smaller-section cables) and use the larger one for loads like the EV charge points, where the load won’t even exceed 32A.

The Rayleigh meters are shipped with their Primary M-Bus address set to ‘0’ (RI-D35-100-MB) or ‘1’ (RI-D175-MB) so if the intention is to extract readings using the Primary rather than the Secondary M-Bus addresses, these need to be changed from the default. This can be accomplished using one of the utilities shipped as part of the libmbus codebase:

$ mbus-serial-set-address -b 2400 /dev/ttyUSB0 old_primary_address new_primary_address