Send reply ONLY to incoming socket ID in dashboard 2

Because reasons, I am in the process of migrating a public facing website from dashboard 1 to dashboard 2.

I'm very close to finishing the dashboard 2 change over. Just one last issue....

With dashboard 1, I used Cloudflare cache to stop every connected client from updating with other client changes.
It seems that dash 2 works different and so the CF cache is no longer effective.

With dashboard 2, all connected clients get updated when anyone makes a change.

Searching around it seems I need to get the socket ID (msg._client.socketId) and send the change to ONLY that socket id.

Here is something to show the idea....

When anyone types any text, everyone sees it in their browser if they are on the same page as the template node (some HTML and CSS that makes up a table).
I need to only update the table for the socket ID that typed something in.

I know Node-RED and all dashboards are not multi-tenet, but it seems from this thread that I should be able to offer some isolation via the socket ID?

That post thread suggests that it might be possible, but nothing to suggest how one might go about it with a dashboard 2 template node....

Thanks for helping.

I've never needed to pay attention to things like the socketID before....

But looking at it now, I see the same ID makes its way from the text entry node (or form etc) all the way through my flow to the template node...

So why does every connected socket see the msg.payload?
Dashboard 2.0 must ignore it and broadcast it to all connected clients?

Reading the 'WebSocket' forum post for the nth time, I see that it is talking about the websocket in/out nodes.

When I add them to the dashboard (2.0) path, I cant connect or get any debug output....

Is it not possible to have just one of the dash 2.0 pages to be a websocket and thus fit in with the other pages?
Do I need to re-make all my dash 2.0 pages to be websockets in nodes some how?

By default, only the ui-notification and ui-control will pay attention to any received _client.socketId (to be consistent with D1.0)

You can turn it on for any other node types in the "Client Data" tab. Note it will do this for all ui-template nodes that you send socketId to. That data will also not persist a refresh, its active whilst that socket client is active, on refresh, they're given a new socket connection.

If you have some ui-template nodes where you do want the data to be shared, you can use a change node in advance of it, and "delete" the msg._client object before sending the msg

Thanks for the reply Joe.
I'm having trouble understanding that doc page and so am struggling to test it out....

But what I am wondering right away is why the 'form' node is not included the 'Client Data' tab?
I can try and convert my form to a series of text boxes to get me over the hump, but they are not as easy to control their layout on a page as the form node.

I will mark Joes post as the solution, but for those that find this thread in future search...

The 'ui-form' node works, I don't know why its not in the list, but it does not seem to matter, it work as expected generating a _client.socketId and the template node respects that and only that client sees the changed data.

The problem is the ui-dropdown node.... While it does generate a socketId and while it is in the 'Client Data' tab list there is a problem with it working with other UI nodes....
Even if you tick the option to 'If msg arrives on input, pass through to output' it does not pick up any selections in that node as it passes through. So you cant use the ui-dropdown in conjunction with any other nodes in your UI in a passthrough manor.
Months back when I built the page with both the form and dropdown UI elements, I simply grabbed the dropdown outputs as they were made and did a flow.set in a function node. A simple two node flow.
That worked great, regardless of if the user selected the dropdown or the form first, each time the ui-form was submitted a function node did a flow.get and handed both the dropdown msg and form msg together.

Now that I need the socketId as well as any dropdown selections it gets more complicated.

Since I started working with dash 2, I have had to have a programmer on the payroll, so he has written some code to keep a list of ui-dropdown list selections and associate them with the socketId.
Then when the ui-form is submitted, its socketId will be checked in the FIFO list, if found, their ui-dropdown socketId selection will be matched against the form socketId, if not found, add it to the top of the FIFO list.
I figure a list of about 100 'deep' should be enough, old ones will drop off the bottom. Not perfect, but should be workable. Users will just learn to refresh their browser page if they don't get the results they expect, that refresh will generate a new socketId and they will go in the top of the list.

I am back on track and each clients selections are returned to only just that client.

Thanks everyone.

1 Like

What would you like to test out? If you want to send data to just a single user/client, tick the box for the widget type you want to have unique data for, and it'll just work.

The form node has no input option (yet), so data can't be sent to a form on a specific client. All nodes (including forms) will generate the _client data. The list defines which nodes accept that data as input, and will then just constrain the communication to a given client/user.

Open to alternative options here, but I don't see another way we could build it or have it work?

Can you expand on this please? Are you expecting msg.payload to change on pass through?

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