Keeping the dashboard alive


There should be no need to implement a ping type capability as the underlying library already has one built in.


Yes, you are correct but I wanted "my own ping" so I can monitor it myself (my code example is a very simplified example from a much more advanced page)

Do you happen to know how I can get my hands on the websocket connection readyState when using the ui_template node? Like I do in the normal template node

Also, how to force a re-connection from code inside the ui_template node?

Then by just monitoring the readyState, it would be easy to force a re-connection when/if needed

Kind regards, Walter


I agree. Same here

Connection Lost (Node-RED Snap)

Here is how my Dashboard drops connection with 2 graph widgets. Without them it's quite stable so I blame this widget for being quite expensive. With one graph it was more or less usable, with 2 I had to move them to a separate tab as it's pain to use.

While this tablet is quite old, I notice similar issue with newer phone (Samsung S5) - it loads quicker but also disconnects.


For android tablets always plugged in there's a secret feature to keep the screen always on (but dimmed) :


But as you can see on my video above, having screen always on does not help at all.


On your tablet, the connection seems to retry every 5 seconds. That, I believe is very different to the issues faced by most of the others in this thread.

For everyone in this thread. What is really needed is a separate example not using Dashboard to see where the problem actually lies - whether it is in Dashboard, the device/browser or elsewhere. You also need to do the same testing from a PC set to stay awake.

There are so many variables involved with this that it is currently pretty impossible to know what is causing this issue in any particular instance & I suspect there are several causes.

I think that, something not yet mentioned, you may be able to tweak the settings on so that it doesn't time out so fast as well. I noticed as I built uibuilder that is very sensitive to network & timing issues & if it has any problems at all it falls back to polling methods rather than websockets. You can see this happening if you can get access to the developer tools.


You might find weinre helpful if you are trying to debug web apps on mobile devices. It provides the ability to remotely debug a web page.

Alternatively, newer versions of Andriod have remote debugging available.

On iOS, I think that "native" remote debugging is only possible from a Mac, see Safari Web Inspector Guide