Dashboard and sessionid / socketid - perhaps I misunderstood something

Hello, I know it pays to RTFM. But just to be sure:

Is it correct that the dashboard sends the socketid of a switch (for example) but if a message including a valid socketid is sent to this button all other connected buttons on different sessions will change it`s state too?

So the sessionid / socketid is only relevant for tabs, notifications and audio ...

Messages coming from the dashboard do have a msg.socketid , and updates like change of tab, notifications, and audio alerts will be directed only to that session. Delete the msg.sessionid to send to all sessions.

socketid or sessionid - what is correct or is there a difference?

Because I`m not a native English speaker I read the "like" as "for example" and assumed that this is valid for all dashboard nodes.

Is there a way to get around this problem?. I know that the dashboard is single user but if the flow takes care what data it sends to which session it could separate different devices by IP.

I spend quite a lot of time to build a syslog server. It would be great if the user can set filters and other things on different devices differently.

Perhaps this could be a nice feature for the future: If the msg object to a dashboard node contains a sessionid the payload is only send to this session. Ok - this will break a lot of flows as they don't care about the sessionid but perhaps we can call the property msg.targetsessionid. But what to display on the status line? Perhaps [...]|[...]

Posting from my phone, this was actually a discussion on slack last week.


Dave’s response in the thread in the last message was that it was solved in the master branch.

1 Like

There is perhaps a little bug in the doc mixing socket and session which is in fact a name I mix all the time myself.
But my problem is that the functionality to send to specific sessions or sockets is somehow limited to some nodes like notifications. If so perhaps - like in my case, I actually read the docs - it would be better to be a little bit more specific here.

Well... yes - any clarifications for the docs would be gratefully received :slight_smile:
The general intention is that any input that materially changes the state of the backend should be reflected across all screens (so if power is shown to be off it really is off etc) - so states of switches, positions of sliders, etc. Things that are front end only like the tab that is visible - or notifications - can be sent to all sessions - or just one (as you don't suddenly want 50 screens to have to cancel an alert).

Totally understandable and certainly what everyone expect from a widget representing something like a light switch.
In my particular case I tried to use dashboard widgets not to present the state of the backend- I tried to use them to configure the frontend (here setting individual filters for individual screens). Similar to selecting individual tabs but on widget level.
I’m fine with that. Next time I should do some test before assuming a function which is not possible. Now I only have to find a workaround :wink: Doing it on the frontend where it perhaps belongs. This was the initial concept but to keep data traffic low I thought it would be a good idea to filter the data on the backend before sending it to the clients where most of it would be hidden and soon deleted because a filter is set by the client.