Scripts

Server-side scripts are Python files the server watches and runs. They react to events, define dynamic aliases, and automate the parts of an operation nobody should be doing by hand at three in the morning.

The Scripts page in the navigation rail is the execution monitor for them. It is read only: scripts are added by placing files where the server can see them, not through the GUI.

For writing them, see Tuoni Script Engine.

What the monitor shows

Two panes. On the left, every execution the server has observed, with its status and how much output it produced. On the right, the output of whichever one is selected, including errors.

Executions are kept after they finish, so this is also the record: what ran last night, whether it finished, and what it printed while doing so.

Engine state

The chip in the toolbar says whether the engine is enabled. Since 0.15 it is on by default.

While it is disabled, the server stops watching for files and stops running them, and the monitor says so - but the history stays readable, which is the state you want when you have turned scripting off to investigate something it did.

An account with the right permission can open the server settings straight from that warning.

Access

The monitor needs View Resources. Without it the page says so rather than showing an empty list, because "no scripts" and "you may not see the scripts" are different facts and the difference matters when you are working out why an automation appears not to exist.

When the page says the monitor is unavailable

The execution endpoints are newer than the page. A server that does not expose them gets a message to that effect and a retry, rather than an empty table. If you see it, the client is newer than the server it is connected to.