Script Editor

Scripts are server-side pieces of automation that belong to a project. The Script Editor is where you write them, schedule them, and try them out while developing.

The engine’s rules, its limits and the ins.* API are on the Overview page.

Fields

Field	Required	Description
Name	Yes	Script name, up to 100 characters. Unique within the project
Description	No	Description, up to 255 characters
Code	Yes	JavaScript source, up to 65,535 characters
Schedule Type	Yes	When it runs — see the table below
Period	Conditional	For Periodic, in milliseconds. The smallest value is 100 ms
Time	Conditional	For Daily, the time of day
Delay	Conditional	For Once, how long to wait before running
Log	Yes	Whether runs are written to the project log

Schedule types

Type	When it runs	Field it needs
Periodic	Continuously, at Period	Period (≥ 100 ms)
Daily	Every day at the given time	Time
Once	Once, after Delay	Delay
None	Never on its own — only when run by hand	—

If you want a script triggered only from somewhere else (ins.executeScript, an animation click, an alarm hook), leave the type as None.

Pick the period you need, not the smallest one

Every script path in the product — device poll expressions, alarm conditions, operator runs, report previews — shares one thread pool. A period of 100 ms runs that script 600 times a minute, which occupies the pool for nothing if it is not genuinely required.

Saving and scheduling are two separate steps

Saving a script does not make it run. Saving stores the definition; scheduling puts it into the running order. By the same token you do not have to delete a script to stop it — cancelling its schedule is enough.

That separation is what lets you stop a script temporarily without disturbing its definition, which is the ordinary need during maintenance.

Running: two separate paths

Trying a script out while developing and running a saved script by hand are not the same thing, and they return different things.

	Running from inside the editor	Running a saved script by hand
Code it runs	Whatever is in the editor now — you need not save first	The saved code
Whose identity it runs as	Yours	The space’s automation identity
What it returns	The script’s return value	A receipt — whether the run happened, and how long it took

The saved run withholding the return value is deliberate: that run executes as the automation identity, which sees the same rows a scheduled run would see. Handing a value it produced back to the person who pressed the button could disclose rows that person cannot see.

In practice: develop and debug with the run inside the editor. When you need to see a value out of a saved run, write it to a variable and read the variable back:

ins.setVariableValue('DEBUG_OUTPUT', { value: computed });

Writing to the log

With Log on, the script’s runs and its ins.consoleLog output land in the project log. With it off, console output goes nowhere — turning it on during development is the usual cure for “the script runs but I see nothing”.

Do not leave console output on in production

ins.consoleLog is a development tool. Left on in a periodic script, it fills the project log within seconds.

Operations that may need approval

Scheduling, cancelling and running by hand can require a signature or an approval, depending on how the installation is configured. Where that applies, the operation is written to the audit trail recording who performed it and on what grounds.

Related

• Overview — engine rules and limits
• Server-side API — the ins.* reference
• Expressions — variable, alarm and animation expressions