How a weather station and two freezer probes grew into a local wireless sensor bridge for HomeSeer.

Building SensorBridge for HomeSeer

How a weather station and two freezer probes grew into a local wireless sensor bridge.

It started with an AcuRite Atlas weather station and two fridge/freezer probes.

They were already sending readings through the air. I wanted to bring those readings into HomeSeer, where they could do something useful: warn me about a warming freezer, help with irrigation, or keep a history without another cloud account.

An inexpensive RTL-SDR USB radio and the open-source rtl_433 decoder provided the receiving end. SensorBridge became the HomeSeer side - choosing which sensors to adopt, making sense of their readings, and turning them into devices, history, and alerts.

A few weeks later, it was listening to the water meter at the curb and learning what a normal freezer defrost cycle looks like.

These projects have a way of growing.

First, decide what belongs to you

One of the first things you discover with a radio receiver is that your house isn’t the only house transmitting.

Weather stations, temperature probes, and other sensors nearby can all turn up. Automatically creating a HomeSeer device for everything the radio hears would get crowded quickly.

Instead, SensorBridge puts discoveries in a Heard nearby inbox. You can see the reported model, radio band, receiving frequency, and signal strength, then adopt the sensors you want. Give each one a name, room, and floor, and it becomes a HomeSeer device.

Everything is opt-in. Certain security sensors, key fobs, garage remotes, and tire-pressure sensors are excluded from adoption.

The underlying decoder supports hundreds of device types, but hearing a transmission is only the beginning. SensorBridge still needs to understand what its fields mean and how they should behave in HomeSeer.

The fridge became the first radio lesson

The probe inside my fridge was transmitting, but a receiver across the house couldn’t reliably decode it.

The fridge cabinet was taking more than 15 dB out of the signal. Moving the receiver closer made the difference between occasional noise and useful readings.

That helped move support for multiple radios up the list.

SensorBridge can now work with up to four local USB radios, identified by serial number, or receive data from rtl_433 running on another computer. Each radio can stay on 433 MHz or 915 MHz, use a wide 915 MHz receiving mode, or alternate between bands.

Also coming soon are Raspberry Pi and ESP32-based receivers, with Wi-Fi or Power over Ethernet (PoE) options. That will make it easier to place a receiver near your sensors—in the garage, an outbuilding, or wherever reception is best—and send the readings back to SensorBridge over your local network. With PoE, a single cable supplies both power and the network connection.

You can put the receiver where reception is good, while HomeSeer stays where it belongs.

A temperature reading should lead to a useful answer

“23.7” is a reading. Too warm is something you can build an event around.

SensorBridge’s temperature alarms use named states:

• Normal
• Too warm
• Too cold
• No recent readings

You set the limits and how long a reading must remain outside them before the alarm changes. Briefly opening the fridge door shouldn’t produce the same response as a cooling failure.

Missing readings get their own state, too. A freezer that appears perfectly stable because its probe stopped reporting isn’t particularly reassuring.

That distinction also led to separate silence thresholds for device status and alarms. A water meter can miss a few broadcasts without needing immediate attention; a freezer probe may need a much quicker warning.

Learning the difference between defrost and trouble

The predictive warnings have been one of the more interesting parts to build.

A freezer doesn’t hold a perfectly flat temperature. It cycles, the door opens, and automatic defrost can produce a warming pattern that looks alarming if you only follow the slope.

SensorBridge learns each fridge or freezer’s normal behavior and looks for warming that departs from it. The aim is to give a Too warm soon warning while there’s still time to investigate.

In testing against more than five days of recorded fridge and freezer data, it produced no false warnings across 7,763 minutes. In simulated failures, warnings arrived 37 to 41 minutes before the temperature crossed its limit.

Those are results from the data I’ve tested so far, rather than a promise of a fixed warning time for every appliance. More real-world testing will help establish how well it handles other fridges, freezers, and habits.

But it’s already encouraging... and a good excuse to use some enjoyable math.

The water meter had its own surprise

The meter was broadcasting about once a minute, yet its consumption reading changed only once an hour.

Receiving more messages didn’t mean receiving more detailed usage information.

SensorBridge learns that update cycle and distributes each reported increase across the hour it represents. That produces a more useful history without pretending to know precisely when every gallon was used.

For the supported Neptune E-Coder broadcasts, it tracks gallons used over the last hour, today, the last 24 hours, and the last seven days, along with a Water in use state.

The reporting interval matters when building events: an hourly-updating meter can help reveal sustained or unexpected usage, but it won’t give you an immediate answer when someone opens a faucet.

Keeping the readings useful over time

Once the sensors were coming in reliably, the next question was what to do with all that data.

SensorBridge keeps minute history for 13 months by default, with daily summaries retained indefinitely. There are charts, records, comparisons, and CSV export, and you can rearrange dashboard cards and sensor lists by dragging them.

Weather features include dew point, feels-like temperature, wind gusts, rain and lightning totals, and pressure trends. For pressure, you can also see the three-hour and 24-hour change, plus today’s high and low.

There’s per-sensor calibration as well. An offset can correct a probe that consistently reads a little high or low. You can optionally apply the correction to stored history, while retaining the raw readings alongside it.

And then there’s a small nuisance familiar to anyone using inexpensive wireless probes: changing the battery can change the sensor’s ID.

SensorBridge can associate the new ID with the existing device, preserving its place in HomeSeer. It also supports replacing a sensor with a different model, so replacing hardware doesn’t have to mean rebuilding the events that use it.

Making new sensors easier to support

As the number of supported devices grew, knowledge about them had become scattered through the code.

What does this field mean? Is it a measurement or a running counter? Which units does it use? Which icon and named states belong with it?

That information now lives in device definitions. Each definition describes a device family and how its readings should become HomeSeer features.

Before switching over, I compared the new definition-based results with the existing implementation across 2,730 feature plans. They matched before the change went live, and existing HomeSeer devices and events continued working.

It’s less visible than a new dashboard card, but it lays the groundwork for adding device families without scattering another set of special cases throughout the plugin.

The bugs only a running house could find

The test suite has grown from 184 checks to more than 1,000, using real radio captures, appliance logs, and water-meter readings.

Running the plugin every day still found things the tests hadn’t.

An alarm’s pending hold time could survive several quick restarts and fire on the first reading afterward. A meter could remain marked Silent after a restart until its consumption value changed—even though broadcasts had resumed. Both are fixed and were checked against live behavior.

Another decoded field claimed a low battery for an AcuRite hub that had no battery. SensorBridge now leaves that field out.

The guiding rule is straightforward: if a value doesn’t represent something real and useful, it shouldn’t become a convincing-looking HomeSeer feature.

What you could automate

A few examples I’m building toward or using in testing:

• Protect the groceries: send a phone notification when a freezer changes to Too warm soon.
• Notice a failed probe: alert when an alarm reports No recent readings, rather than letting a dead battery quietly remove your monitoring.
• Watch unexpected water use: notify when reported usage continues through hours when you’d normally expect none, allowing for the meter’s update interval.
• Adjust irrigation: skip a watering cycle when the measured rain total exceeds your chosen threshold.
• Watch nearby lightning: announce when a supported weather station reports new strikes within a chosen distance.

The useful part is bringing those readings into the same system as the lights, announcements, schedules, and notifications you already use.

Where it stands

SensorBridge is currently version 0.0.5, in active development and running daily on my own HomeSeer system. I’m preparing it for the HomeSeer store, including help pages and Linux support.

Next on the list:

• More verified device-family definitions.
• Dashboard cards and settings generated from those definitions.
• Additional receiver options, including ESP32-based receivers over MQTT.
• A guide to running a remote radio on a Raspberry Pi.
• Soil-moisture sensors, which are already installed and undergoing testing.

For the supported radio sensors, reception and processing stay local. There’s no cloud account to create, and no manufacturer hub required.

I’d like to hear what’s already transmitting around your house or yard. If you use rtl_433 today, which sensors would you most want to bring into HomeSeer—and what would you have them do?