Get custom parameter values from a session

Is there a way via message to query a session and get the custom parameter values from a view that is active in that session. All sessions are all showing same view and only 1 session per IP address.

In short what I am looking to do is from Session A. Look at session B by IP address and get the current values of custom parameters x,y,z and then be able to use those in session A

method I am thinking of would be for each session to create a UDT with its IP address without '.' as name of the UDT instance and then write the custom parameters to that UDT. Then given an IP address of that session another session would be able to see what the custom parameter values are by looking at that tag.

if there is another simple way to do this without the creating tags please share.

  1. Have the views of interest always copy their parameters object to session custom properties.

  2. Have origin session send a broadcast to all sessions to report back, by including the desired IP address and the origin session's ID in the message payload.

  3. Have receiving session handler check payload IP against session property, and if matching, send a targeted message back (using the payload session ID).

{ I'm having a hard time imagining what problem you are trying to solve. Perhaps you should share that. This smells like an XY problem. }

I have a project with a view with a set of different parameters to setup different sets of template and template repeaters for a single view. The IP address is in header. These views are on several different TVs. We have one view that can be used to select an IP address and then select the different parameters for those repeaters / templates. User presses a button and forces that session to open view with those parameters. What this does is it allows someone with a tablet to walk up to a tv select the IP address and change what that TV is showing.

What I am looking to do is be able to grab the current status of those parameters from that session. So when you select the IP address of the target session it sets the settings to what it is currently set to. you can then edit and update.

I'd use messages.

Tip: write complete sentences with grammatical subject and don't skip verbs. It makes it much easier to read and translate for non-English speakers. e.g. "Have a project ..." is a command. I presume you meant "I have a project ...", etc. The second sentence has no verb.

This sounds like something a QR on each TV would be useful for. Tablet scans the QR which auto selects that TV, rather than trying to find its ip from a list

2 Likes

Oooooo! That's a really good idea. Have the QR include the session ID and page ID and then any messaging can be closely targeted.

(Would also make using pageVarMap() instead of messaging quite effective.)

3 Likes

That would be nice -- Or RFID chip, but not valid options in my environment. Before we took these steps the clients plans were to have a locker full of wireless key/mouse for each TV, grab them from locker and go out to where TV is to adjust what info it is displaying. TV displays are all dashboard style

I think Nick meant that your dashboards should always show their unique QR code, perhaps in a dock. Then your settings control project can use a mobile barcode action on your tablets/phones to synchronize to a particular TV.

1 Like

Wouldn't be able to scan due to positioning in some cases, and other cases the local person would call/radio to an office and ask it changed.

Future state is that all tvs get fixed ip address and then we have a table of IP address and name so you would just select TV by name

OK. With a fixed collection of displays, the UDTs per TV might be the best solution after all.

As I was thinking through this was thinking could do a default config in the udt so you could have temp setup then switch in back to a 'default' for that TV

The UDT approach has a some advantages:

  • Perspective views just need a tagpath parameter, that is always the same for a particular TV.
  • Restarting a TV will bring it back to the same settings it was using when it died.
  • No messaging required at all. Just indirect bind members of the indicated UDT to the appropriate custom props. Settings project just writes directly into the UDT.