SVSI Roving Monitors - Switchport Status?

zack.boyd

Hey all -

Looking to deploy SVSI with monitor carts that need to be 'roving'. IE the cart can get plugged into any room, but the system should know what room that device is plugged in.

Best way to accomplish this? Query the switch for switchport status? That feels like a pain. Anyone have better solutions?

Thanks!

HARMAN_icraigie

You can send LLDP status through N-Act programming. There will be a video (or two) on this exact issue released in the very near future but for the moment here is a link to how to implement basic N-Act programming https://youtu.be/8OLA2dNOR60

vining

Uses Global Cache to control 3rd party devices?

HARMAN_icraigie

It's a pre AMX video... but there are some interesting GC compatibility tools built into some of the SVSI hardware, if the need ever arises.

pdabrowski

If you're running Native netlinx, you can always send a 'getStatus' API command in the ONLINE event handler and then parse as needed from there.

zack.boyd

@pdabrowski said:
If you're running Native netlinx, you can always send a 'getStatus' API command in the ONLINE event handler and then parse as needed from there.

Would getStatus return switchport information?

HARMAN_Chris

Zack, no this will not return the LLDP information. A high level outline of what is needed:

1) Each SVSI encoder/decoder will need an nAct event loaded to the device for the chassisID property (trigger on change). In this event, you can create your own syntax to parse on the Netlinx side.
2) The nAct event should be aimed at a n800x controller (known ip address) located within the video VLAN.
Sample nAct event syntax

udpClient 255.255.255.255 50005 \22{name:{{name}},ip:{{ipAddr}},type:{{unitType}},stream:{{stream}},chassis:{{chassisID}}}\03\22

3)The n800x controller will then broadcast your generated string to the control network via the second NIC
4)The netlinx masters will all receive the broadcast message and parse to determine if this is an encoder/decoder they care about. The string contains all of the details they need for control and communications should it be relevant to the NX master.
5)All control is aimed from Netlinx to the n800x controller over port 50020

This architecture allows the endpoints to have a known gateway for comms yet still participate in a dynamic environment where they will be receiving commands from multiple masters.

HARMAN_icraigie

Multicast delivery of the N-act message is an option in an environment without an N-Command. You can set up the N-Act programming to deliver asynchronous updates across multicast as well - avoiding that PITA polling and parsing regime.