Which shows you which packets are being sent/received and how large they are. The green entries are outgoing msgs and the red are incoming. The size is in bytes. You have 100,000 max bytes packet size. So usually you will be fine. But possibly if you are sending images around, that might have an impact.
Update: you might need to check the other socket.io entries as well as the one marked with 101. They are http rather than ws but just check that there isn't something massive in one of those as well.
It times out and the site reloads with zero bytes again, but only sometimes.
Most of the time the site works Ok with zero bytes and 'Pending' shown.
This is a fresh install of Nodejs and Node-RED, I loaded my flows one by one and made sure each was working and looked ok on the dash before I added the next flow.
No, you need to look on the details page. The summary always shows 0 which isn't correct. If you look at the picture I posted you will see that it is showing each packet with a length.
I can also see that you have several polling entries with 50kB in them which tells me that you are indeed passing large data packets. That is already 1/2 the max 100k you get in the default settings.
Yes I was referring to a mobile device but one that just started to exhibit this issue after over 4 years of operation without a single "lost Connection"
I close the phone's dashboard app after every use and when I go to connect to Node-Red on a Pi, about 30% of the time, I will get the "lost connection" message but it ultimately resolves.
I am not about to chase the source down and this is just an observation of an inconsequential blip in operation.
Thanks for the tip to look at the Messages tab.
Here is about 5 seconds.
Sure scrolls past fast. The gif recorder cant keep up and it is about 1/3 speed.
Not being able to sort by 'length' is a bit of hit and miss drag to find the biggest payload or what it might be.
After spending some time looking and scrolling, I cant see any over 100kb.
Starting to come to the conclusion that its the volume (ie size or number of pages) of the site rather than any one large payload.
After hours of Google foo and Stackoverflow confusion I'm coming to the conclusion that as a simple Node-RED user there is nothing I can do about any of this.
My two last thoughts then....
Is there a way to set an inactivity timer? If the user does not change pages or do a search (enter text) etc for say 1 hour then they get a popup or the site freezes or something to let them know 'game over'.
Is there there a 'network glitch' setting that I can bump out to make it just a little more robust? ie, don't disconnect on a hair trigger.
I hardly think you can claim that given the size and complexity of what you've created can you?
There is, but I don't think it would be easy or even necessarily possible with Dashboard. Really, you are talking about session management that disconnects the comms to node-red.
Again, there would be if you had control over the details of the connection. I'm not sure how things work with Dashboard but in uibuilder, a disconnection triggers a timer that attempts to reconnect. That timer has a multiplier on it so that the time between attempts increases to prevent constant bombardment of your browser with network calls.
There is something else you could do. However, I think it would involve a fair bit of re-engineering. That would be to rely less on the websocket connection and instead use Fetch calls to an API.
@TotallyInformation Thanks for the assistance along this thread.
Can uibuilder and the stock Node-RED dash exist side by side on the same server somehow?
I'd like to rebuild the entire site while the current site remains up and running. Then flip what ever switch is required to only serve up uibuilder pages and delete the dashboard nodes.
Re-reading your 'getting started walk-through' again for the Nth time and cant see it mentioned.
Yes, absolutely. I use them side-by-side all the time. I tend to do quick and dirty trials in Dashboard but will do specific UIs with uibuilder.
It is even possible to embed one into the other using iFrame's if you want to.
Well, it probably won't be quite like that. More likely that you will build the uibuilder version in parallel and eventually just stop developing the Dashboard and then delete bits.
Well no, that's true. Mainly because they do work quite happily side-by-side. Of course, you can only create a single Dashboard which is a single page - cleverly pretending to be multiple pages by using the tabs. With uibuilder you can have multiple uibuilder nodes and multiple actual pages with a single node - and, of course, can also do the same as Dashboard and have a SPA with virtual routing. And more depending on your desire and tools.
What they don't do is interact. You can share data and server processing via flows of course but Dashboard and uibuilder are quite separate front-ends. Though uibuilder does use the same ExpressJS web server instance as Dashboard by default, I'm careful to try and ensure that both the URL's and certainly the websocket connections are completely separate. Indeed each uibuilder node has a completely separate websocket connection.
uibuilder can also (for the last few releases) use a completely different ExpressJS web server instance as well. This is great if you want to be able to separately secure it because it uses a different port and allows different ExpressJS configuration to be used.
The choices are yours. But to get started, just ignore all that and keep it simple. Install the Node, add an instance to your flow, give it a unique URL and deploy. Then edit the resulting front-end code as desired (using one of the non-default templates if you want a quick leg-up for something like VueJS). You can be up and running with your prototype first page in seconds. Then you can take your time in working out if you want a front-end framework and translating (or redesigning) what you did in Dashboard. Typically, I personally tend to redesign because I'm not restricted to the mostly auto-layout card interface that Dashboard uses (which, of course, is what makes it such a pleasure to get started with).
I think this is the perfect quote to close this thread on.
After more than several hours of not getting anything functional working. Its clear there is a pretty good sized gap between the dashboards.
Thanks everyone for helping me understand some of the workings going on in the basement that I had no clue about.
You really didn't think you would get away with that did you
Reach out to me, uibuilder really isn't as hard as many people think. You literally can get something working in a few seconds and with very little code.
I'm also working on a new generation of uibuilder client library that is going to make things even simpler. It has a bunch of web components (custom html tags basically) that are uibuilder aware (and also work without it too) and a feature that allows you to create a UI via a JSON configuration. Still early days for that, though some basics are already working and a repo is available to try out.
That is true. And uibuilder, for now, won't be like Dashboard with its myriad nodes. However, its direction of travel will soon(ish) allow for that approach to be easily built. The server building blocks are already in place, the client ones under development.
For me though, the focus has never been on not needing any front-end code at all (after all, I was coding in SGML, the forerunner to HTML, on mainframes back in the '80's) but on flexibility. So even as I try to work my way up the stack, I continue to try and avoid lock-in to a specific technology. That is particularly critical for web UI's because the tech is changing so very fast.
Indeed, I've even started to think about how difficult it would be to have a version of uibuilder that didn't rely on Node-RED at all!
Anyway, to wrap up - do reach out to me if you want to walk through building a uibuilder-based UI - I'm keen to understand the things that people find difficult so that I can find ways to make things easier.