Absolutely no debug panel output

using v0.20.8
pi model 3 B+ running raspbian 9.11
over the internet (https + password protected, etc.)
I recently recovered a dead micro SD card on my raspberry pi and everything appeared to work after starting up.

Even my flows were doing their job and continue to do so, but nowhere in the web UI do I see any debug info. I've tried messing with filters (checking all, viewing all nodes), clearing the debug window, opening it in a new browser window, but nothing shows any debug info. "node status" also shows nothing on the node itself.

I created the simplest of flows in a new tab: timestamp --> debug (enabled), deploy, and nothing shows up.

I get the toast notification at the top saying "Successfully injected: timestamp"
When I enable metrics and click the timestamp, I see this:

16 Sep 13:30:42 - [metric] {"level":99,"nodeid":"23cef67e.f0e8ea","event":"node.inject.receive","msgid":"8796955b.ee32f8","timestamp":1568655042490}
16 Sep 13:30:42 - [metric] {"level":99,"nodeid":"23cef67e.f0e8ea","event":"node.inject.send","msgid":"8796955b.ee32f8","timestamp":1568655042491}
16 Sep 13:30:42 - [metric] {"level":99,"nodeid":"6821cca0.3bb9c4","event":"node.debug.receive","msgid":"8796955b.ee32f8","timestamp":1568655042492}

I'm hoping it's something easy or a conflict with a pallete problem.


The editor uses a websocket connection to get this 'real time' messages from the runtime.

If you aren't getting status or debug, then something is getting in the way of the websocket. Check the browser console for any errors relating to the /comms path.

You do mean the backend...right? do you have4 the sidebar open and the debug tab selected?

and you do have the debug nodes activated...right


1 Like

@zenofmud here is the debug sidebar immediately after hammering on the timestamp button a few times. you can see the toast that pops up.

A few things to try:

  • have you tested from a device on the same network - e.g. get rid of the complexity of the Internet connection.
  • change the debug output to include console as well as panel. See if anything is produced in the console.
  • change the debug node to show the whole msg
  • open you're browsers console and see if any errors are being produced there.

Ahhh it's the websocket thing. running it on the pi works as expected. I also eventually get a console error in the browser when running it remotely.

WebSocket connection to 'wss://foo.bar/comms' failed: WebSocket opening handshake timed out
r @ red.min.js:16

so how do I get around this? It's been a while since I set it up, but I don't recall ever running into any websocket requirements. It wasn't mentioned in the settings or "securing node red" articles I read.

There's nothing to configure in Node-RED to get this to work - it'll be something in the network between the Pi running Node-RED and your browser.

You say you're exposing it over the internet - does that mean you doing some sort of port-forwarding in your home router? You may need to do some extra configuration to allow websocket connections.

Indeed. I will check out my forwarding options and see if the solution presents itself.

I did read a bit suggesting exposing websockets is not great from a security standpoint... are there alternatives beyond vnc--which isn't the worst, but not my first choice.

I use a vpn server. You could also use services like ngrok. You better stop your port forwarding quickly, otherwise you will for sure get serious problems with viruses etc

If you are port forwarding, make sure that you only allow secure protocols (https, wss, etc).

Another option is to use a VPN. Many home routers will terminate a VPN for you that you can start from your PC. Otherwise a spare Pi will do the job. A bit of a pain to get set up but once done, it will just keep working.

Just remember that a VPN extends your home network over the Internet to your PC. Make absolutely sure that you use very strong random passcodes (or certificates) and make totally certain that your PC is well protected.

Services like NGROK provide a decent in-between option as long as you are happy trusting the service. Probably not a problem as long as you stick with well recognised and trusted brands.

Indeed it doesn't need to be spare either. I have one loaded up with all sorts of stuff and the vpn performs adequately. Again, ensure there are no security loopholes.

Yes, please repeat the mantra "There is no such thing as a magic bullet for security".

Indeed, if anyone even vaguely associated with IT ever tries to sell you magic beans (a bit early for pantomime references I realise), walk away!


Thanks for all the suggestions. I do, in fact, have a spare pi running a VPN server and it is, in fact, a pain to set up. I'm also going to leave my forwarded ports open, contrary to the advice to stop forwarding them all because of viruses.

In any case, secure websockets (wss:) uses the same port as https: so unless there's a setting I'm missing in my settings.js that forces nodered to use that port, I'm stumped on my original issue.

It isn't an issue with Node-RED. The error you gave is showing that you cannot reach the websockets using the WSS protocol (TLS encrypted WS). This is an environmental/networking issue. While the port is the same as https, the protocol isn't. All manner of things could be getting in the way.

A little more detail here regarding the websockets:

It appears one fix is to set up proxypass, but I'm not sure how that's possible with the pi installation since it isn't using an obvious Apache type config. there is a proxy line commented out in the service file but I don't know what uncommenting that would accomplish.

Setting up a proxy is done in a web server. If there is a web server acting as a reverse proxy for your external connection (which is recommended), it needs to be correctly configured to handle websockets & TLS.

Nodered handles it all, doesn't it?

Only if no proxy is in use.

Indicates that you are trying to connect over https/wss and your browser cannot connect to the wss connection.

From the info in the error, it looks like a connection from outside your network and that there is a proxy between you and your server (because no port number is showing indicating something has proxied the connection to port 1880). However, it looks like the proxy isn't configured correctly to be able to pass wss connections on the given URI through to Node-RED's actual URI.

1 Like

here is my setup:
pi running nose red with https
Verizon router forwarding 443 to that pi
dynu is handling dynamic names

now that I type that out, I forget what handles the ports for various other services. I need to do some remembering and digging.

Ah, that's how mine always ends up after too much alcohol :wink: