I’ve been using a WaveNode WN-2 power meter at our remote station for years now. It’s a fantastic piece of gear – four independent RF channels, high SWR alarms, forward and reverse wattage monitoring and a Windows app that displays everything in real time. Check it out at:

But here’s the problem: the data lives in the WaveNode application and nowhere else. I wanted that data in my Node-RED dashboard. I wanted it in Grafana for historical trending. I wanted to trigger automations based on SWR readings or power levels. The WaveNode software wasn’t designed to share its data with other applications.

So I built a bridge.

The result is WaveNode-to-MQTT, a small Windows utility that grabs all the WaveNode data and republishes it to MQTT topics. Once it’s in MQTT, you can do anything with it – display it in dashboards, log it to databases, trigger alerts, whatever you need.

Here is the project link: https://github.com/n3bkv/WaveNode-to-MQTT

Why MQTT?

If you’re not familiar with MQTT, it’s a lightweight messaging protocol designed for IoT and automation. It uses a publish/subscribe model – applications publish messages to topics, and other applications subscribe to the topics they care about.

MQTT has become the de facto standard for home automation and monitoring systems. Node-RED speaks MQTT natively. InfluxDB can subscribe directly to MQTT topics. Grafana can pull from MQTT. If you want to integrate something into a larger automation system, MQTT is the way to do it.

The WaveNode software, being a specialized RF measurement tool, doesn’t have any automation hooks built in. But it does use Windows message passing internally – it posts messages to its own window handle whenever readings change. I just needed to intercept those messages and forward them to MQTT.

What Data Gets Published

The bridge captures everything the WaveNode measures:

RF Power (per channel 1-4): – Peak forward watts – Average forward watts – SWR (Standing Wave Ratio)

Computed Metrics: – Reflected power (peak and average) – calculated from forward power and SWR – Return loss in dB – how good your antenna match is

DC Power: – Supply voltage and current

Rotator Data: – Current heading(s) – Destination heading – In-motion status

Auxiliary Inputs: – Two additional analog inputs for whatever you want to monitor

All of this gets published to individual MQTT topics like wavenode/peak_watts/1, wavenode/swr1, wavenode/dc/volts, etc.

Reflected Power and Return Loss

One thing I added that the WaveNode software doesn’t show directly is reflected power in watts and return loss in dB.

The WaveNode gives you forward power and SWR. From those two values, you can calculate reflected power using some RF math:

Reflection coefficient: |Γ| = (SWR – 1) / (SWR + 1)

Reflected power: Pref = Pfwd × |Γ|²

Return loss: RL(dB) = -20 × log10(|Γ|)

The bridge does this calculation automatically and publishes the results. Now I can see exactly how many watts are reflecting back from my antenna mismatches, not just the ratio. And return loss in dB is a more intuitive metric for antenna matching – higher numbers are better, and 20 dB return loss or better is generally considered excellent.

How It Actually Works

The WaveNode Windows application uses the Win32 messaging system to communicate internally. Every time a reading changes, it posts a window message with specific parameters encoding the measurement type and value.

The bridge application:

Finds the WaveNode application’s window handle (either from the registry or by process name)

Registers itself to receive those window messages

Decodes the message parameters to extract measurement type and value

Publishes the data to the appropriate MQTT topic

It’s essentially eavesdropping on WaveNode’s internal messaging and republishing it in a format other software can use.

Setting It Up

The setup is straightforward. The bridge runs on the same Windows computer as the WaveNode software (since it needs to intercept local window messages).

First, make sure you have an MQTT broker running somewhere. I use Mosquitto on a Raspberry Pi, but any MQTT broker works. It doesn’t have to be on the same computer – mine is across the network.

Download the WaveNode-to-MQTT executable from the GitHub releases (or build it yourself if you want – it’s a simple .NET application). Here’s the direct link to the download for the compiled Windows installer.

Run it the first time and you’ll get a setup dialog asking for:

Your MQTT broker’s IP address and port (default is 1883)

Username and password if your broker requires authentication

Base topic name (default is “wavenode”)

Some technical settings with tooltips that explain what they do

You can keep most of the defaults. If your broker doesn’t require authentication, leave those fields blank. Then make sure to change the IP to point to your computer running Mosquitto.

Click Save, and the bridge minimizes to run in the background. That’s it. It immediately starts publishing WaveNode data to MQTT.

The settings get saved to a JSON file in your AppData folder, so you don’t have to configure it again. If you do need to change something, just go into your Task Manager, kill the program and then delete the configuration settings in your AppData folder (C:\YourUser\AppData\Roaming\WaveNode.Mqtt\config.json).  This will allow you to see the configuration dialog box to re-enter your setup parameters.

If you do not see the AppData folder in your user directory, turn on View Hidden Files.

The Throttling Feature

One thing I learned quickly: WaveNode updates fast. Like, really fast. With four RF channels updating multiple times per second, you can easily flood your MQTT broker with messages.

The bridge includes throttling to prevent this. You can configure:

Minimum publish interval: Don’t publish the same topic more often than X milliseconds (default 200ms)

Minimum delta: Only publish if the value changed by at least X amount (default 0.1)

These settings are adjustable in the config file or via environment variables. For most dashboards and logging, 200ms is plenty fast. If you need real-time updates for something specific, you can reduce it.

What I’m Using It For

Node-RED Dashboard: I have gauges showing real-time SWR and power on each antenna. The reflected power calculation is particularly useful – I can see instantly if something’s wrong with an antenna just by watching the reflected watts climb. See the file node-red-flow.json in the Github project repository for a sample dashboard.

Grafana Trending: I’m working on feeding data into InfluxDB, then into Grafana. So I can have charts showing power output over time, SWR trends, etc. It will be fascinating to see how our station performs over time and in different weather conditions.

Automation Triggers: One area I’m considering is having Node-RED watch the SWR topics. If SWR goes above 2.5:1 on any antenna, it could send me a Discord notification to check out what is going on.

Technical Details

DirectMode: The bridge can ask WaveNode to send messages directly to its window instead of broadcasting. This is more efficient and reduces message clutter. It’s enabled by default.

UpdateMode: You can configure WaveNode to send all samples, only changed values, or only on request. I use “only changed values” (mode 1) to reduce unnecessary traffic.

Retained Messages: By default, MQTT messages are published with the “retain” flag. This means when a new client subscribes, it immediately gets the last value for each topic. Perfect for dashboards – they show current readings right away without waiting for the next update.

Building It Yourself

The code is simple enough that you can build it yourself if you want. It’s a .NET 8 WinForms application – just a few hundred lines of code.

Clone the repo, make sure you have .NET 8 installed, and run:

dotnet build

Or if you want a standalone executable:

dotnet publish -c Release -r win-x64 -p:PublishSingleFile=true -p:SelfContained=true

The generated .exe includes the entire .NET runtime, so you can copy it to any Windows machine without installing dependencies.

Troubleshooting Tips

If you get no MQTT output: Double-check your broker address and port. Try connecting to the broker with another MQTT client (like MQTT Explorer) to verify it’s accessible. Check the console output from the bridge for connection errors.

If the WaveNode HWND isn’t found: Make sure the WaveNode application is running and has been opened at least once. The bridge looks for it by registry key or process name. Sometimes on first run, WaveNode hasn’t created its registry entries yet.

If you’re getting too many messages: Increase the PublishMinIntervalMs value in the config. I started at 200ms, but for simple dashboards, even 500ms or 1000ms is fine.

If dashboard values look stale: This is usually because you’ve disabled the Retain flag. Keep it enabled so subscribers immediately get the latest value when they connect.

Why This Approach Works

I could have tried to reverse-engineer WaveNode’s data protocol or hack into its database files. But intercepting Windows messages is simpler, more reliable and less likely to break when WaveNode updates its software. There was some great info on the Wavenode site on how the Windows messaging worked that helped a lot in developing this solution.

If you are curious, you can check it out here:

The bridge is essentially invisible to WaveNode – it just listens passively and doesn’t interfere with normal operation. WaveNode doesn’t know or care that something else is reading its messages.

And by using MQTT as the output, I’m not locking myself into any particular dashboard or automation platform. Anything that speaks MQTT can consume this data.

The Results

Since deploying this bridge, my station monitoring has become much more comprehensive. Having WaveNode data integrated into my Node-RED dashboard means I can see everything going on at the station on one screen. No more program switching.

Where to Get It

The complete project is on GitHub:

You can download the prebuilt executable from the releases, or clone and build it yourself. Everything’s open source under MIT license.

And if you make improvements or add features, pull requests are always welcome!

73 and may your SWR always be low!