# Looking for feedback — features you'd want in a Node-RED Protocol Inspector plugin

**URL:** <https://discourse.nodered.org/t/looking-for-feedback-features-youd-want-in-a-node-red-protocol-inspector-plugin/101443>\
**Category:** Developing Nodes\
**Created:** [10 July 2026 09:57 UTC](https://discourse.nodered.org/t/looking-for-feedback-features-youd-want-in-a-node-red-protocol-inspector-plugin/101443 "2026-07-10T09:57:30Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![lizzardguki](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/lizzardguki/32/103637_2.png) [@lizzardguki](https://discourse.nodered.org/u/lizzardguki)\
**Post date:** [10 July 2026 09:57 UTC](https://discourse.nodered.org/t/looking-for-feedback-features-youd-want-in-a-node-red-protocol-inspector-plugin/101443/1 "2026-07-10T09:57:30Z")

</div>

Hi all,

I am building a sidebar plugin for Node-RED called `node-red-contrib-protocol-inspector` — a DevTools Network-tab-style inspector that captures and displays HTTP, MQTT, and WebSocket traffic flowing through your flows, via monkey-patching (no changes needed to existing nodes).

Current features:

- Live traffic capture for HTTP, MQTT, and WebSocket messages
- Filterable, searchable request/response log
- Payload inspection (headers, body, timing)

Before I lock in the feature set for a wider release, I would love input from people who actually debug flows day-to-day:

1. **What protocols/node types cause you the most pain to debug today?** (Serial, TCP, custom nodes, etc.)
2. **What would you want to filter/search by** — node ID, topic, status code, payload content, something else?
3. **Would you want export capabilities** (HAR-style export, copy as cURL, save session to replay later)?
4. **Any interest in request/response diffing** or highlighting changed fields between messages?
5. **Should it integrate with `msg._msgid`** to trace a message across multiple nodes in a flow?
6. **Performance concerns** — how do you feel about overhead on high-throughput flows? Would a sampling/rate-limit mode be useful?

Any thoughts, pain points, or "I wish DevTools could just—" moments are welcome. I am trying to build something the community actually needs, not just what I assumed they needed.

Thanks!  
Nemanja

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [10 July 2026 11:10 UTC](https://discourse.nodered.org/t/looking-for-feedback-features-youd-want-in-a-node-red-protocol-inspector-plugin/101443/2 "2026-07-10T11:10:24Z")

</div>

I would want to know a couple of things before using such a feature set:

- What overheads does it introduce?
- Why is this better than using the dev tools network page?
- Why is this better than using debug msg output?
- Does it work automatically with non-core nodes? E.g. UIBUILDER, Dashboard 2, etc.

---

<div class="post-metadata">

**Author:** ![gregorius](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gregorius/32/73816_2.png) [@gregorius](https://discourse.nodered.org/u/gregorius)\
**Post date:** [10 July 2026 17:05 UTC](https://discourse.nodered.org/t/looking-for-feedback-features-youd-want-in-a-node-red-protocol-inspector-plugin/101443/3 "2026-07-10T17:05:12Z")

</div>

> [@lizzardguki](#):
>
> - Payload inspection (headers, body, timing)

I've done that using [message tracing](https://github.com/gorenje/node-red-contrib-introspection#message-tracing) with my introspection package. That basically covers all use cases I have for inspecting live traffic through my flows.

It also integrates the debug panel, so I can do all my filtering using that panel.

> [@lizzardguki](#):
>
> 1. Performance concerns

When I started talking about message tracing here in the [forum](https://discourse.nodered.org/t/message-tracing-for-beginners/92287), that was the first comment: _don't do this, it will kill the editor performance_. Well it didn't but just in case it does, I did recently add [rate limiting](https://discourse.nodered.org/t/message-tracing-in-nr5/101278/4) to it.

Even if there is a risk of performance degradation, a little clarity/insight can go a long way so the trade off is probably well worth it.

---

<div class="post-metadata">

**Author:** ![lizzardguki](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/lizzardguki/32/103637_2.png) [@lizzardguki](https://discourse.nodered.org/u/lizzardguki)\
**Post date:** [12 July 2026 15:24 UTC](https://discourse.nodered.org/t/looking-for-feedback-features-youd-want-in-a-node-red-protocol-inspector-plugin/101443/4 "2026-07-12T15:24:26Z")

</div>

Overhead: The inspector monkey-patches http.request/https.request, the MQTT client send/receive, and ws send/message at the module level, so it's just wrapping existing calls to log metadata (timestamp, direction, size, headers) into a ring buffer — no extra network hops or serialization of payloads unless you expand an entry. Should be low single-digit % CPU overhead even under load, but I haven't benchmarked it formally yet — I'll post numbers.

vs. Chrome DevTools Network tab: DevTools only sees traffic from the browser (admin UI), not what Node-RED itself is sending server-side — MQTT, outbound HTTP from function/request nodes, WebSocket traffic to external brokers/devices. This plugin captures the runtime side that DevTools can't see at all.

vs. debug node output: i catched myself over the years shipping flows which constantly needed updating, a good habit was not including debug flows, and every time updating was several minutes of adding nodes, debugging, deploying.

Non-core nodes (UIBUILDER, Dashboard 2, etc.): Since it patches at the Node.js module level (http/https/ws/mqtt client libraries), it should work with any node using those standard libraries under the hood, including UIBUILDER and Dashboard 2 — not something I've explicitly verified against every contrib node yet. If you're up for testing UIBUILDER specifically once I push a build, I'd appreciate it.

---

<div class="post-metadata">

**Author:** ![lizzardguki](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/lizzardguki/32/103637_2.png) [@lizzardguki](https://discourse.nodered.org/u/lizzardguki)\
**Post date:** [12 July 2026 15:37 UTC](https://discourse.nodered.org/t/looking-for-feedback-features-youd-want-in-a-node-red-protocol-inspector-plugin/101443/5 "2026-07-12T15:37:58Z")

</div>

Thanks Gregorius, that's a solid reference point. A few differences worth noting for people comparing them:

node-red-contrib-introspection traces messages within your flow (node-to-node), routed through the debug panel. protocol-inspector targets the layer below that — actual wire traffic (HTTP requests, MQTT pub/sub, WebSocket frames) via monkey-patching the underlying clients, surfaced in a dedicated DevTools-style sidebar rather than the debug panel. So it's less "what did my function node output" and more "what actually went out over the network, with what headers/timing."

Good to hear rate limiting solved your perf concerns — I'll likely need similar throttling once WS/MQTT volume gets high, so that's useful precedent. Appreciate the pointer to the message-tracing thread, going to read through it.

---

<div class="post-metadata">

**Author:** ![gregorius](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gregorius/32/73816_2.png) [@gregorius](https://discourse.nodered.org/u/gregorius)\
**Post date:** [12 July 2026 15:56 UTC](https://discourse.nodered.org/t/looking-for-feedback-features-youd-want-in-a-node-red-protocol-inspector-plugin/101443/6 "2026-07-12T15:56:57Z")

</div>

Perhaps another idea would be to have a clamp mode whereby highlighting nodes immediate generates debug details - also something that I implemented later for the message tracing. Most importantly is of course that all features work without having to deploy - else you might lose bugs by redeploy. Something that I would recommend for the usefulness of what you're doing!

This might be non-trivial - I don't know how you implement the monkey patching. The message tracer can do this because I hook into specific events that are generated for each message, so I can turn it on/off at runtime without deploying.

---

<div class="post-metadata">

**Author:** ![TotallyInformation](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/totallyinformation/32/31_2.png) [@TotallyInformation](https://discourse.nodered.org/u/TotallyInformation)\
**Post date:** [12 July 2026 16:20 UTC](https://discourse.nodered.org/t/looking-for-feedback-features-youd-want-in-a-node-red-protocol-inspector-plugin/101443/7 "2026-07-12T16:20:12Z")

</div>

> [@lizzardguki](#):
>
> If you're up for testing UIBUILDER specifically once I push a build, I'd appreciate it.

I'll give it a go.

One thing to note is that UIBUILDER and, I think, both of the Dashboards all use [Socket.IO](http://Socket.IO) rather than websockets directly. Though, of course, [Socket.IO](http://Socket.IO) is usually configured to prefer websockets. Don't think that will be a particular problem but worthy of note anyway.

> [@lizzardguki](#):
>
> vs. Chrome DevTools

Annoyingly, while Chromium dev tools for node.js does include a network tab. It is in preview and does not appear to show any Node-RED network activity, at least on my Windows dev setup and using Vivaldi browser.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/1X/d073cd938eafa2e558d7c2cd59003b3ef4963033.png) [@system](https://discourse.nodered.org/u/system)\
**Post date:** [10 September 2026 16:21 UTC](https://discourse.nodered.org/t/looking-for-feedback-features-youd-want-in-a-node-red-protocol-inspector-plugin/101443/8 "2026-09-10T16:21:04Z")

</div>

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.