Introduction

There’s an internal temperature sensor connected to the NIBE heat pump, to enable it to compensate for internal temperature gains: a hard-wired thermistor sensor located on the first-floor landing – i.e. pretty much in the middle of the house, away from direct sunlight and external doors. This does a good job of reporting the ‘average’ temperature of the house – although only when the heat pump is powered-up (and I turn it off at the mains over the summer since the controller draws 45W, which soon adds up – and impacts the annual efficiency calculation).

While the MVHR does tend to gradually even-out the temperatures (and humidity levels) in the different rooms, these can easily vary by several degrees – mostly due to passive solar gain in the south- and west-facing rooms. It’s therefore useful to have sensors in different rooms to monitor how the temperature varies throughout the house and potentially trigger the automatic closing of blinds or opening of windows.

Current Solution: Oregon Scientific Sensors

Since the house was built (and still, as of mid-2024) I’ve been using a variety of Temperature and Temperature & Humidity sensors from Oregon Scientific – such as the THGN132N. These are battery-powered (1 x AA) wireless (433MHz) sensors primarily intended for use with Oregon Scientific’s range of Weather Stations.

I originally used a few of these in my previous house. I arrived at the Oregon Scientific sensors via a roundabout route, having bought an OWL electricity monitor which happened to use the Oregon Scientific radio protocol and it was an easy option to integrate more sensors using that same protocol. I then moved the Oregon Scientific sensors to the new house – and bought a few more.

Given that they run off a single AA battery those last for a good long time – I’m diligent about adding a label with the installation date of batteries in devices like this and typically they run for 4 – 5 years on a good-quality non-rechargeable alkaline battery. One failed in June 2024 after having been installed since February 2020; the old battery was down to about 0.25 V and just starting to leak.

These sensors are integrated into the home monitoring and automation set-up via surprisingly many different hardware and software components:

• The 433MHz signals are received by an RFXCOM RFXtrx433E USB transceiver
  • This transceiver is required anyway, to control the vertical window blind in the Office, which uses the Somfy RTS protocol at 433.42MHz (there are few other Home Automation integration options for the Somfy protocol)
• The RFXCOM transceiver is connected via USB to the HP MicroServer which hosts the home automation software
  • USB port /dev/ttyUSB0 is passed-through to the Docker container running openHAB
  • This does constrain the placement of the RFXCOM transceiver to be within USB-cable-reach of the HP MicroServer – but it doesn’t seem to have trouble connecting to sensors anywhere else in the house
• Since it’s the openHAB software which talks to the RFXCOM transceiver, the easy option is to use the openHAB RFXCOM binding to process the readings from the Oregon Scientific sensors
  • Each new physical sensor appears as a ‘Thing’ in the openHAB Inbox and each Thing has multiple ‘Channels’ for the different parameters that get reported: Temperature, Humidity (where supported by the sensor hardware), Signal Strength, Battery Level and Low-Battery Warning.
  • Each of the ‘Channels’ is mapped to an openHAB ‘Item’ which is what can be graphed or added to the openHAB User Interface
• While openHAB has access to the temperature data, I also want it to be stored in the InfluxDB time-series database and to be graphable in Grafana. (Ideally I’d also want each reading to be published as an MQTT Message, but that doesn’t currently happen.) This is where things get (more) complicated:
  • openHAB is already configured for ‘Persistence’ of Item values in InfluxDB – primarily with a view to being able to replay things like lighting usage when the house is unoccupied, but a side effect is that the temperature sensor readings also get ‘persisted’ to InfluxDB
  • The sensors appear in the InfluxDB database called “openHAB”, against ‘measurements’ called things like B1_OS_TH_Temperature (Bedroom 1, Oregon Scientific, Temperature Humidity sensor) – which is the Name assigned to the Item in openHAB

Minor frustrations with this approach include:

• The multiple Oregon Scientific sensors are distinguished from each other by having their own numeric ‘Device Id’ – e.g. the ‘Thing’ called B1_OS_TH currently has Device Id 64257
  • The annoyance is that this number changes whenever the device is powered-up, such as when the battery is replaced. For continuity of records and for the display of readings it’s necessary to re-establish the mappings between the (new) openHAB Things / Channels and the (existing) openHAB Items
  • A sensor with an unknown Device Id will appear in the openHAB Inbox, from which it is easy to create the Thing and its Channels – and then associate these with the Items which had been mapped against the previous Device Id
• The reporting of battery status is a bit hit-and-miss
  • The reported ‘Battery Level’ percentage is only ever 100% or 10%, and it drops to 10% ages (years?) before the battery actually gives out
  • The only practical way to assess battery health is to check for an absence of updates (seen as a ‘flatline’ on a temperature graph) which is a sign the battery is completely dead
• The HP MicroServer (or rather its Operating System installation) is prone to losing track of the USB connection to the RFXCOM transceiver
  • The symptom is that /dev/ttyUSB0 goes away and /dev/ttyUSB1 appears in its place – but openHAB is still looking at /dev/ttyUSB0 so all the sensor readings stop changing in openHAB

Before buying the RFXCOM RFXtrx433E transceiver (to support the Somfy blind protocol) I used a variation of this approach:

• I’d used an older RFXCOM transceiver (still 433MHz but not compatible with the Somfy protocol) which was connected via Ethernet rather than USB
• I’d used some Perl scripts to talk to this older RFXCOM transceiver, reacting to the incoming radio data and publishing MQTT messages with the various temperature / humidity readings
  • These MQTT messages then followed the ‘standard’ route into InfluxDB (via ‘Telegraf’) for access from Grafana

This older approach didn’t suffer from the USB interface stability issues but exacerbated the ‘Device Id’ issues since it needed a mapping between the (effectively) temporary Device Id and the persistent name of each sensor. I used to put up with the Id changing (and edit the graphing logic) but could have used an ‘MQTT Re-Publisher’ to apply a mapping; something like https://github.com/kylegordon/mqtt-republisher

Alternative Sensors

The Oregon Scientific sensors seem to no longer be manufactured and if I wasn’t already invested in them I would have used something different. Since I have them, I intend to continue using them until they stop working reliably – they don’t need any sort of Cloud service and should continue to operate well for many years.

Alternative candidates include the following:

1. Some of the rooms have a KNX wall-switch such as the MDT BE-TAS86 which is also available with a built-in temperature sensor, as the BE-TAS86T
   • The temperature sensor adds about 20 EUR to the price (152 versus 133 EUR) and it’s a purchase-time option, not something that can be retro-fitted
   • A hard-wired sensor on the KNX bus is definitely a robust way to go, compared to a battery / wireless device
   • Integration would be KNX -> openHAB -> MQTT (via the openHAB MQTT Binding) which is what I do for the KNX-connected temperature sensors for the underfloor heating
2. The Aranet4 CO2 sensor also measures Temperature, Humidity and Atmospheric Pressure
   • These are high-quality sensors with long battery life (nominally 4 years from 2 x AA) – but they’re expensive (139 GBP excluding VAT)
   • The most robust integration requires the ‘Pro’ sensor and a ‘Pro’ Base Station, which is even more expensive (379 GBP excluding VAT)
   • It’s possible to integrate using the built-in Bluetooth interface (as used by the smartphone app) – see e.g. the Home Assistant Integration for Aranet (which relies on the Bluetooth integration that recommends an ESP32-based Bluetooth Proxy (because of issues with Linux support for Bluetooth))
   • In summary, these would not be cost effective for Temperature / Humidity monitoring, but if the sensors can be justified for CO2 management then also reporting Temperature and Humidity is an easy add-on
3. One frustration with the Oregon Scientific sensors is that they’re a Proprietary solution and their radio protocol needed to be reverse-engineered. Open Source is much better in this respect and I’ve been impressed with the OpenEnergyMonitor ecosystem, which includes the emonTH sensor for Temperature / Humidity monitoring
   • These sensors need to be coupled with a Base Station such as the emonPi – despite also using 433MHz I don’t believe they’re supported by the RFXCOM transceiver
   • They’re relatively expensive (37 GBP excluding VAT)
4. There are now several flavours of mass-produced sensors, either with or without LCD displays
   • There seem to be literally hundreds of sensors listed on Amazon / eBay / AliExpress
   • These typically communicate using Zigbee, Bluetooth Low-Energy (BLE) or WiFi – though I can’t imagine the battery life is very good on WiFi (they generally run from a CR2032)
   • To address the ‘Open Source’ issue many of these are compatible with replacement firmware to get away from the intended usage with a smartphone app – see e.g. https://github.com/pvvx/ATC_MiThermometer
   • The main appeal of these is the price – often less than 5 GBP each

Multi-Room Temperature and Humidity Monitoring by Marsh Flatts Farm Self Build Diary is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.