Home AMX User Forum AMX Control Products

How to password protect MVP 8400?

Please excuse if this is a noob question. But how can we password protect the touch panel to allow faculty and staff (authorized users) to activate the system using the touchpad, yet prevent students (unauthorized users!!) from turning things on? We've been searching documents and forums for hours for an answer to this simple question!?
MVP-8400 Modero Viewpoint TP , relatively new model, installed 08/2010.

TIA for any suggestions!!
Bill Nelson

Comments

  • ericmedleyericmedley Posts: 4,177
    Please excuse if this is a noob question. But how can we password protect the touch panel to allow faculty and staff (authorized users) to activate the system using the touchpad, yet prevent students (unauthorized users!!) from turning things on? We've been searching documents and forums for hours for an answer to this simple question!?
    MVP-8400 Modero Viewpoint TP , relatively new model, installed 08/2010.

    TIA for any suggestions!!
    Bill Nelson

    the easiest way I can think of is to put a password routine in code and have the panel frequently return to a login page. I used to work at a University and we tried to do the same thing. What we found was the instructors hated the fact that the panels went back to the login page 'too often' and they ended up giving out the passwords to students anyway. Pretty soon, you'd find students in rooms running the gear during off hours.

    At any rate, I'd do it in code and send the panel back to the login page after X minutes of panel inactivity.
  • Joe HebertJoe Hebert Posts: 2,159
    Please excuse if this is a noob question. But how can we password protect the touch panel to allow faculty and staff (authorized users) to activate the system using the touchpad, yet prevent students (unauthorized users!!) from turning things on?
    Near the bottom of the General tab for a button in TPD4 there is a Password Protection property which is available for you to use code free if you want to go that route.
  • the8thstthe8thst Posts: 470
    The easiest solution to create a page that only has a login button. Then under the button properties for the login button you select password protected and choose one of the 4 passwords and have a page flip programmed to send the panel to the main AV select page.

    Then set the login page as the "inactivity page" in the panel properties in TPD4.

    Once this is all done you will have a panel that returns to a "login page" after x minutes of inactivity and you don't need to write a single line of code.
  • ericmedleyericmedley Posts: 4,177
    .. and you don't need to write a single line of code...
    Unless you need to change the pass code from time to time - but it'll never happen...
    Unless you need to change the pass code on umpteen panels all over campus - but it'll never happen...
    Unless you need to edit umpteen TP4 files - but it'll never happen...
    Unless you need to have different access codes for different people - but it'll never happen...
    Unless you need multiple pass codes on the same panel - but it'll never happen...
    Unless you need to tie the pass code into something like Active Directory or LDAP - but it'll never happen...
    Unless you need to turn off the pass code function remotely for a short time without giving away the pass code - but it'll never happen...
    etc...
    :D

    I say these things because every single one of them has happened to me multiple times.
  • AuserAuser Posts: 506
    ericmedley wrote: »
    Unless you need to change the pass code from time to time - but it'll never happen...
    Unless you need to change the pass code on umpteen panels all over campus - but it'll never happen...
    Unless you need to edit umpteen TP4 files - but it'll never happen...
    Unless you need to have different access codes for different people - but it'll never happen...
    Unless you need multiple pass codes on the same panel - but it'll never happen...
    Unless you need to tie the pass code into something like Active Directory or LDAP - but it'll never happen...
    Unless you need to turn off the pass code function remotely for a short time without giving away the pass code - but it'll never happen...
    etc...
    :D

    I say these things because every single one of them has happened to me multiple times.

    Can't say I've tried using them, but do the following commands not provide the flexibility you're talking about?
    AMX PI wrote:

    MVP Panel Lock Passcode Commands:

    (Note: A device must first be defined in the NetLinx programming language with values
    for the Device: Port: System (in all programming examples - Panel is used in
    place of these values)).


    "'^LPC'"
    Clear all users from the User Access Passwords list on the Password Setup page.

    Syntax:
    SEND_COMMAND <DEV>,"'^LPC'"

    Example:
    SEND_COMMAND Panel,"'^LPC'"
    Clear all users from the User Access Password list on
    the Password Setup page.


    "'^LPR-<user>'"
    Remove a given user from the User Access Passwords list on the Password Setup page.

    Syntax:
    SEND_COMMAND <DEV>,"'^LPR-<user>'"

    Variable:
    user = 1 - 50 ASCII characters.

    Example:
    SEND_COMMAND Panel,"'^LPR-Robert'"
    Remove user named 'Robert' from the User Access Password
    list on the Password Setup page.

    "'^LPS-<user>,<passcode>'"
    Set the user name and password.
    This command allows you to:
    1. Add a new user name and password OR
    2. Set the password for a given user.
    The user name and password combo is added to the User Access and/or Password
    list in the Password Setup page. The user name must be alphanumeric.

    Syntax:
    SEND_COMMAND <DEV>,"'^LPS-<user>,<passcode>'"


    Variable:
    user = 1 - 50 ASCII characters.
    passcode = 1 - 50 ASCII characters.


    Example:
    SEND_COMMAND Panel,"'^LPS-Manager,undock'"
    Sets a new user name as "Manager" and the password to "undock".

    Example 2:
    SEND_COMMAND Panel,"'^LPS-Manager,test'"
    Changes the given user name password to "test".
  • ericmedleyericmedley Posts: 4,177
    Auser wrote: »
    Can't say I've tried using them, but do the following commands not provide the flexibility you're talking about?

    Yes, in a sense. But, if you have to reload the panel from the saved TP file or make a small change, you then have to still modify the file or send the commands from the program.

    So, why not just build a single routine that runs all the time and manages the password(s) from a central location? I could write a routine that could manage hundreds of panels from one text file saved on a master or server or even on the local master that I could easily update and change on the fly without having to load a TP file or reboot a master.

    This is an old argument hashed out on this forum many times. I just don't want to spend that much time in TP Design myself. I like the flexibility of running my panels from code. It's so much easier to manage large scale systems than the one-off panel files with built-in navigation.

    But, I realize that there is a camp of people who disagree. To each his own.
  • a_riot42a_riot42 Posts: 1,624
    ericmedley wrote: »
    But, I realize that there is a camp of people who disagree.

    I would agree. You never know what someone is going to ask for, and things that'll never happen tend to happen quite frequently. Some folks want to track which user has logged in and be able to prevent some users, at certain times, from doing certain things, etc. It's easier to do it yourself, although those commands look like they could come in handy. I had a request where the client wanted the users to be able to control lighting without a password, but starting a source did, and tweaking projector settings required a different password, etc, so its easier to implement it all in code. We are selling custom programming after all, so anytime there is an opportunity to customize something I will generally always take that route.
    Paul
  • DHawthorneDHawthorne Posts: 4,584
    I wrote a routine once for a client who wanted password protection for his panels, and wanted to be able to change it on the fly. I used the internal panel passwords, and my module would update the passwords on all the panels when changed with the "master" password. They can all be manipulated in code. You could do the entire thing with your own password schema too, just storing it internally in a persistent variable. Probably the worst thing (IMO) is to just use the internal passwords with no code support at all to change them, since once they get out, the client is stuck with everyone knowing it, until you have to run out and change them all manually ... just to have it happen again later.
  • the8thstthe8thst Posts: 470
    I will defend my post about using the internal passwords for this use because of the tone of the original post.

    I took it for granted that we all know and agree that it is better to implement this in code, but I got the impression from the original post that the author is not well versed in AMX programming. I got that impression from the references to spending hours searching docs and forums when it really isn't a tough problem and the TP4 commands are pretty easy to find in PI.

    I then suggested the quickest and easiest way I could think of to solve the author's request without writing the code to make it flexible and easily adjustable on the fly.

    My assumptions may be correct or incorrect, but that was my thought process.
  • ericmedleyericmedley Posts: 4,177
    the8thst wrote: »
    I will defend my post about using the internal passwords for this use because of the tone of the original post.

    I took it for granted that we all know and agree that it is better to implement this in code, but I got the impression from the original post that the author is not well versed in AMX programming. I got that impression from the references to spending hours searching docs and forums when it really isn't a tough problem and the TP4 commands are pretty easy to find in PI.

    I then suggested the quickest and easiest way I could think of to solve the author's request without writing the code to make it flexible and easily adjustable on the fly.

    My assumptions may be correct or incorrect, but that was my thought process.

    Fair 'nuff. I still think you're a cool dude. :)
Sign In or Register to comment.