TMS / API -> how to get overview for peripherals, touchpanel

[matus.bankovic]

Hi all,

Is there a way to generate a report  with info if the codecs are using a touchpanel or not? (TMS or API)

If yes, can there be a detail if the touchpanel is connected directly to the codec or via LAN?

Thank you,

Matus

[Steve Kapinos]

This information is not stored in TMS, so it's not possible to query TMS for it.

You could get most of the information if you queried the status.xml of the endpoints yourself and collated the info.

Tho I don't know if the codec will tell you if the touchpanel is remote or not.. you can get the panel details from the experimental root, but I don't see it telling you explictly if it's direct connected or not.

[Martin Koch]

I do not fully agree with Steve.

If you look at endpoints in the systems navigator of TMS, you will find

the extended settings and in this the configuration and status.

If a touch screen is present you would find it under status:

 Experimental Peripherals ConnectedDevice Type: TouchPanel 
  Experimental Peripherals ConnectedDevice Name: Cisco TelePresence Touch 
  Experimental Peripherals ConnectedDevice ID: x
  Experimental Peripherals ConnectedDevice Status: Connected 
  Experimental Peripherals ConnectedDevice UpgradeStatus: None 
  Experimental Peripherals ConnectedDevice UpgradeProgress: 0 
  Experimental Peripherals ConnectedDevice SoftwareInfo: TT6.3.0 3d8e7d1 
  Experimental Peripherals ConnectedDevice HardwareInfo: 101x 

I am not really sure if there is a way to tell how it is connected. At least with looking at:

 Facilit NetworkPort Mode ROLE=Admin: DirectPairing 

If its not directpairing and a touchpanel is present it has to be on the lan1 site, but I am

not sure if there is a way to say it its actually connected to lan2.

So in short, some info is present in TMS, but I am not aware how to get it out in an overview

or scripted way, you could search in the sql  db for it.

Besides that, I wondered about this as well, would be great in the systems overview,

maybe you should file a feature request for it!

Please remember to rate helpful responses and identify helpful or correct answers.

[Steve Kapinos]

Martin Koch wrote:
I do not fully agree with Steve.

Because I know that the information you posted is not actually retained in TMS, but is actually queried from the endpoint on demand and just displayed in the webpage.  The page you are highlighting is just a parsed view of the status.xml document which is queried on demand when that page is loaded.  It's contents are not stored in the database as a whole.  Only objects and properties TMS is concerned with are parsed out and retained in TMS.  The peripheral information is not.  That is why you can't query TMS for it... it's not retained nor broken out as information TMS tracks. 

Going to TMS to get the status.xml is a bit roundabout.. since the TMS page is not intended for machine consumption, while the status.xml of the endpoints is.

Martin Koch wrote:
If its not directpairing and a touchpanel is present it has to be on the lan1 site, but I am 
not sure if there is a way to say it its actually connected to lan2.

Which is also what I said   You can tell the mode of the port, but not explictly that the panel is there or not.

[Martin Koch]

Steve, sorry, but that is not how I see it, as this endpoint is in "behind firewall" mode

and the info also survives a reboot of the TMS and shows up on endpoints which are not active for some time.

So for me it clearly looks that tms must get this info reported and also stores it.

How would you other explain what I see (and I guess you could easily reproduce) (used TMS 13.2.2 for that).

Please remember to rate helpful responses and identify helpful or correct answers.

[Steve Kapinos]

Martin Koch wrote:
Steve, sorry, but that is not how I see it, as this endpoint is in "behind firewall" mode 
and the info also survives a reboot of the TMS and shows up on endpoints which are not active for some time.
So for me it clearly looks that tms must get this info reported and also stores it.

That is because Behind firewall is a special case and the xml documents for those endpoints are stored as TMS can not query for them on demand.  Those documents are cached in TMS when TMS is able to communicate with the device. (in objSystemTxasSystemData if you are curious)  That behavior is a special case due to the network connections with 'Behind Firewall' and not representative of TMS's general behavior.

All other times TMS is going to query the device for the document and just parse it for display.  For this Extended Settings Page, TMS is not parsing out the members and interpreting them... literally just displaying them.  The fact they are shown here does not mean that data is retained in TMS.

Goto a normal TC endpoint in TMS that is offline and goto the Extended Settings page... you will find TMS will drop you to the Connection Status page when it can not communicate to the endpoint... because it's trying to connect to the endpoint to get this data.  (or change your endpoint to 'reachable on lan' where it TMS can't talk to it, and try loading the extended settings page).

The TMS system abstraction layers do not know anything about these touchpanel properties, hence why TMS doesn't retain anything about them.  They are not part of the properties TMS retains when interogating a device and storing things in it's database.

The status.xml document is not stored for endpoints - there is caching to avoid grabbing it multiple times quickly (but this is in the order of seconds) but the xml docs as a rule of thumb are not stored in TMS for each device.  TMS queries them, interprets them into the common system data constructs TMS retains and understands, and that data is stored in TMS. 

[matus.bankovic]

Hi all,

Based on the following document https://supportforums.cisco.com/docs/DOC-29766

I am creating a  overview with the following commands via ssh as root.

To check on the codec uses a touchpanel and its connected:

Directly paired:

ifconfig | grep eth0.4090

netstat tcp | grep endeavour

Paired over a LAN:

netstat -pn tcp | grep admin

But this is more a workaround then a clean solution.

[Steve Kapinos]

Matus Bankovic wrote:
But this is more a workaround then a clean solution.

Agreed - I would not recommend it mainly because it relies on root being enabled, which should not be left enabled in open production environments.

If knowing the panel status and details is important to you all - I urge you to funnel that feedback through your sales teams to get the endpoint teams to add it