Moving from SiteManager 2.x
SiteManager 26.10 is a new product. It replaces the SiteManager 2.x desktop application and its command line. This page explains what changed and what you need to do. Your scripts written for 2.x keep working.
SiteManager 1 in the program
In a few places the program calls the older product "SiteManager 1": the last lines of sitemanager --help, and the Import page. This always means the 2.x desktop application and its command line, which this manual calls SiteManager 2.x.
What changed
| In 2.x | In SiteManager 26.10 |
|---|---|
A desktop application (sitemanager-gui) that you start on a laptop or PC when you need it. |
A service (sitemanagerd) that runs all the time on the wall's computer, and a web interface that you open in a browser from any computer. |
| A command line that talks straight to the displays. | The same command line, which still talks straight to the displays (direct mode). It can also use the service (service mode): with no login when the service runs in local mode on the same computer, and with an API token for a service in network mode. |
| One tool on one computer. | A record of every change, and alerts by email, webhook or syslog. If you open SiteManager to the network, also several users with roles. |
| Status while the application is open. | Live status, a status history of up to a year, and alerts when something goes wrong. |
Project files (.mtspf) that hold your displays. |
The service keeps the site, and identifies displays by serial number. You can import a 2.x project file. |
screen.xml and config.txt written by hand or with another tool. |
A wall layout editor that generates screen.xml, config.txt and the output sections of mt-canvus.ini, previews the change and applies it with a backup. |
| New in 26.10. | Profiles and drift checks, to keep displays in line with a standard set of settings. |
| New in 26.10. | Staged firmware rollouts, with a canary display and checks that the wall is idle. |
SiteManager 26.10 uses the display interface that current firmware provides, so you do not need to update display firmware to use it.
Install
Install SiteManager 26.10 on the computer that stays on the touch network. See Installing SiteManager. Then open the web interface at http://127.0.0.1:8790/ on that computer. By default SiteManager works on that computer only, with no login, like a 2.x application you start on one PC. You do not need to create users or accept a certificate.
To manage the site from other computers, open SiteManager to the network. It then uses HTTPS, logins and API tokens.
The ports to the displays are the same as in 2.x: UDP 37812 to find displays and TCP 8080 to talk to them. In local mode the service needs no inbound port. In network mode it adds one, TCP 8790. See Ports and firewall.
The programs are in new places, so check scripts that name the full path:
| Platform | In 2.x | In SiteManager 26.10 |
|---|---|---|
| Windows | C:\Program Files\SiteManager\sitemanager |
C:\Program Files\MultiTaction\SiteManager\sitemanager.exe |
| Linux | /opt/sitemanager/bin/sitemanager |
/usr/bin/sitemanager |
| macOS | /Applications/SiteManager.app/Contents/MacOS/sitemanager |
sitemanager in the folder you unpacked the archive into |
The graphical program (sitemanager-gui and the desktop icon) does not exist any more. Use the web interface.
Bring your displays across
You have two ways to add your displays to the new site:
- Discover them again. Open Discover and run a broadcast. See Find and add displays. This is the simplest way when the displays are on the same network as the service.
- Import your 2.x project file. See Importing a project file.
SiteManager 26.10 identifies a display by its serial number. If a display gets a new address, SiteManager follows it.
Your 2.x command-line scripts
Commands written for 2.x keep working. When the first thing after sitemanager is a 2.x option, such as --hosts, --scan or --info, the whole command line is read the 2.x way:
sitemanager --hosts 10.77.84.100,10.77.84.101 --info
sitemanager --hosts 10.77.84.100 --settings.osd.timeout=30
sitemanager --hosts 10.77.84.100 --settings.save
sitemanager --scan
A 2.x style command line:
- always talks straight to the displays, whatever API token is stored, and also on a computer where a SiteManager service runs in local mode;
- prints one JSON object on standard output, keyed by display address, with the keys sorted and indented by four spaces. The exceptions are
--scan, which prints adisplayslist, and--syslog, which prints the log text. Settings use dotted keys such assettings.osd.timeout. The result of a task has the key"result:"with its colon, as in 2.x; - uses the same exit codes as 2.x:
| Code | Meaning |
|---|---|
| 0 | All commands were done on all displays. |
| 1 | A general error. |
| 2 | A display refused a command. |
| 3 | A display could not be reached, or the outcome of a write is not known. |
| 4 | The command line could not be understood. |
Options of the new command line, such as --json, --timeout, --token and --direct, are not accepted in a 2.x style command line. If you wrote a script in the new grammar that names displays with --hosts (for example sitemanager settings set --hosts A,B ...), it needs --direct on a computer where a SiteManager service in local mode runs. A 2.x style command line does not. The new commands, such as sitemanager displays and sitemanager settings, use the new grammar described in The command line.
Which 2.x commands still work
All of them. Every option of the 2.x command line is still there:
| Option | What it does |
|---|---|
--hosts A,B |
The displays to act on. |
--scan [SUBNET] |
Finds displays with a broadcast. The subnet only filters the answers. With no value it accepts all of them. For a routed network use sitemanager discover sweep. |
--info, --status, --firmware-version, --temperatures |
Read information from displays. |
--syslog |
Reads the display's system log. It works with one display at a time. |
--identify[=SECONDS] |
Shows an identify message. The default is 5 seconds. |
--available-updates |
Lists firmware updates for the displays. |
--firmware-update VERSION |
Updates the displays to a version. |
--download-firmware VERSION, --import-firmware FILE, --remove-firmware VERSION |
Manage the local firmware cache. |
--allow-downgrade |
With --firmware-update or --available-updates: also consider versions that are not newer than the display's. |
--geometry-calibration |
Runs geometry calibration. |
--power.restart |
Restarts the displays. |
--power.standby, --power.standby.enabled[=BOOL] |
Reads or sets standby. |
--settings.save, --settings.discard, --settings.unsaved |
Saves, discards or checks pending changes. |
--settings.network.*, --settings.osd.*, --settings.picture.brightness, --settings.remote-control.*, --settings.ssh.enabled, --settings.syslog.*, --settings.tuio.* |
Read or set display settings. Without a value an option reads. |
--settings.network, --settings.osd, --settings.picture, --settings.remote-control, --settings.ssh, --settings.syslog, --settings.tuio |
Read a whole group. |
--video, --video.source[=SOURCE], --video.external-signal-state, --video.internal-signal-state |
Read the video source and signal states, or set the source (osd or external). |
--tracker.parameter=EXTENSION/PARAMETER[=VALUE] |
Reads or sets a tracker parameter. |
--tracker.schema |
Reads the tracker parameter schema. |
--help, -h, --version, -v |
Help and version. |
Run sitemanager --help for the full list with descriptions. The new command list is sitemanager help.
The environment variables of 2.x for firmware still apply: MULTI_UPDATE_URL, MULTI_UPDATE_OS, MULTI_UPDATE_BRANCH and MULTI_SITEMANAGER_FIRMWARE_IMAGES. MULTI_UPDATE_FORCE does not. Use --allow-downgrade.
Secured displays
SiteManager can secure a display with an access key that only it holds. Securing a display locks out older SiteManager versions, SiteManager 2.x and other tools until it is released. Upgrade every SiteManager on a site before securing displays. A 2.x application, or a 2.x-style command, that meets a secured display is refused by the display. The commands that talk to a display directly say This display is secured by a SiteManager service. Run the command through that service, or release the display there first. Release the display in SiteManager (see Release a display), or run the command through the service.
The 2.x-style --firmware-update also refuses, before anything is sent, an image that is unsigned or signed by another certificate authority when the display installs only firmware signed by MultiTaction, as sitemanager firmware rollout does. See Update display firmware.
What is different
SiteManager 26.10 fixes a few things, so a few results are not the same as in 2.x:
- The proxy password is printed as
"<hidden>". 2.x printed it. - A value that no setting accepts, such as a timeout out of range, is refused with exit code 4 before anything is sent. 2.x sent it and the display answered with an error.
- A setting that the display already holds is not sent again.
- Numbers are printed in their shortest form, for example
39.1and not39.099998474121094. MULTI_UPDATE_FORCEis ignored.--allow-downgradeinstalls an image that is not newer.- Running
sitemanagerwith no arguments prints the list of the new commands and exits with 4. In 2.x it printed the help. - A write that gets no answer is sent once and reported as
UNKNOWNon standard error, with exit code 3, never as a success. - Two names for the same display, for example a host name and its IP address, are refused with exit code 4, also for reads.
- Host keys in the JSON are lower case.
- A failed read prints nothing on standard output for that host, only a line on standard error.
- Control-C between hosts or tasks prints what was done and what was not attempted, and exits with 3.
--helpalso lists settings that 2.x had no option for. Settings that the display reports but that cannot be changed can be read and not set.- As in 2.x, these commands do not check whether the wall is in use. A note on standard error points you to
sitemanager reboot,calibrateandfirmware rollout, which do check. - When a SiteManager service runs on the same computer, writes print a warning that they bypass its audit log and job locks.
The same job in the new commands
If you are writing new scripts, use the new commands. In service mode they are checked, locked and audited.
| 2.x style | New command |
|---|---|
--hosts H --info, --status, --firmware-version |
sitemanager displays show SERIAL or sitemanager --json displays |
--temperatures |
sitemanager history SERIAL --metric temperature |
--syslog |
The system log is part of the diagnostics bundle. |
--scan |
sitemanager discover broadcast |
--identify |
sitemanager identify --displays S --seconds N |
--settings.GROUP.KEY=VALUE |
sitemanager settings set --displays S --settings.GROUP.KEY=VALUE |
--settings.GROUP |
sitemanager settings get GROUP --displays S |
--settings.save, --settings.discard, --settings.unsaved |
sitemanager settings save, discard and unsaved |
--tracker.parameter=E/P=V |
sitemanager tracker set --displays S E/P=V |
--tracker.schema |
sitemanager tracker schema SERIAL |
--power.restart |
sitemanager reboot --displays S |
--geometry-calibration |
sitemanager calibrate --displays S |
--available-updates |
sitemanager firmware catalogue and sitemanager firmware check |
--firmware-update V |
sitemanager firmware rollout --displays S --version V |
--download-firmware V |
sitemanager firmware download V |
--import-firmware FILE |
sitemanager firmware import FILE |
--remove-firmware V |
sitemanager firmware remove SHA256 (you name an image by its checksum) |
The new commands name displays by serial number (--displays), by wall (--wall) or all of them (--all). Add --direct --hosts A,B to talk to displays by address without a service. When a service in local mode runs on the computer, the new commands use it, and --hosts needs --direct. See The command line and the Command reference.
Importing a project file
SiteManager 2.x saves your displays in a project file with the extension .mtspf. You can import it into SiteManager 26.10.
- Open Import in the menu. In local mode you are the administrator. In network mode, sign in as an administrator, because a viewer cannot import a project.
- Choose the project file. A file can be up to 1 MiB.
- Choose the Wall the displays go on. The default is a new wall named after the project.
- Tick Read each display at its address if the file has no serial numbers. SiteManager then reads each display, which only sends read requests.
- Select Preview.
The preview shows how many displays would be added, updated or left unchanged, and how many have no serial number or could not be reached. Nothing is saved yet. For each display it lists the name, address, serial number, orientation and canvas position. The orientation becomes the display's rotation. On a wall that has no layout yet, the canvas positions build its grid.
Check the preview. When it is right, select Apply this import.
From the command line:
sitemanager site import-mtspf project.mtspf
sitemanager site import-mtspf project.mtspf --apply
Note
The importer follows the format 2.x writes. Always read the preview before you apply, and check the layout afterwards on the wall page.
Where to go next
- The web interface
- The command line
- Walls and Cornerstone files, to replace hand-written
screen.xmlandconfig.txt