Blackout: taking the kiosk out of service

Blackout means "this kiosk is shut". While active, Unreal ends any conversation in progress and refuses to start another — from the tablet, a second tablet, the spacebar, or anything else. This state survives level changes. Turning it off does not start a conversation; it simply allows one again.

The second of the two switches below — the kiosk taking itself out of service when its self-diagnostics fail — is fully documented in Taking itself out of service. That page covers the tuning settings and what clients see while latched.

Two switches, not one

Understand this first, because everything else follows: there are two independent switches, and the kiosk is shut while either is on.

Manual Automatic

	Manual	Automatic
Who turns it on	a person, or your code	the kiosk itself
Why	you decided to shut the kiosk	it worked out that it cannot do its job
How it goes on	admin menu toggle · `Set Blackout` Blueprint node · any WebSocket client sending `blackout`	it fails to reach the backend for half a minute · a check you registered is failing
How it goes off	only manually — the same toggle, node or command. It will never clear itself	only by itself — the moment the problem goes away. You cannot clear it from the tablet
Survives a restart	yes. Somebody shut the kiosk on purpose; a crash at 3 a.m. does not undo that decision	no, and it does not need to — the kiosk re-checks within seconds of starting and re-shuts if the problem is still there
The state key to read	`blackoutManual`	(no separate key — see below)

Who turns it on

a person, or your code

the kiosk itself

Why

you decided to shut the kiosk

it worked out that it cannot do its job

How it goes on

admin menu toggle · Set Blackout Blueprint node · any WebSocket client sending blackout

it fails to reach the backend for half a minute · a check you registered is failing

How it goes off

only manually — the same toggle, node or command. It will never clear itself

only by itself — the moment the problem goes away. You cannot clear it from the tablet

Survives a restart

yes. Somebody shut the kiosk on purpose; a crash at 3 a.m. does not undo that decision

no, and it does not need to — the kiosk re-checks within seconds of starting and re-shuts if the problem is still there

The state key to read

blackoutManual

(no separate key — see below)

The tablet fog reads blackout, which simply means "either switch is on". Your toggle button, however, must read blackoutManual. Otherwise, it lights up whenever the kiosk shuts itself, inviting an operator to press a button that will not help.

They cannot cancel each other, in either direction. This is deliberate, and answers a common question:

Your staff shut the kiosk, then the internet fails. Staff press the toggle to reopen. The toggle works — their switch goes off — but the kiosk stays shut because the automatic switch now holds it. Nothing is stuck or needs forcing; it opens when the internet returns.
Reverse the order, same answer. The internet fails, then staff shut the kiosk manually. When the internet returns, the automatic switch releases, but the kiosk stays shut until somebody clears the manual switch.
The order genuinely does not matter. Each switch only responds to its owner, and the kiosk is open only when both are off.

One asymmetry is worth knowing: there is no tablet route out of an automatic blackout. A box reporting it cannot work should not be coaxed into serving visitors from a touchscreen. If a probe misjudges a locked-down network, the solutions are fixing the probe target, the ini, or relaunching with -NoPromethistHealth — all requiring physical access to the machine.

When each one gets used

Situation Which switch How

Situation	Which switch	How
A loud event in the room — the microphone will not work, so nobody should try	manual	staff press the toggle on the tablet, and press it again afterwards
Cleaning, maintenance, a VIP walkthrough, the exhibition is closed	manual	same
The internet or our backend is down	automatic	nothing to do — it shuts and reopens on its own
Your computer vision / presence sensor / queue system has died	automatic, via `Report Health` — see below	your project reports the fault; the kiosk shuts, and reopens when you report it fixed
Your own operations team wants to shut it remotely	manual, via a WebSocket client sending `blackout`	your service holds it shut, then releases

A loud event in the room — the microphone will not work, so nobody should try

manual

staff press the toggle on the tablet, and press it again afterwards

Cleaning, maintenance, a VIP walkthrough, the exhibition is closed

manual

same

The internet or our backend is down

automatic

nothing to do — it shuts and reopens on its own

Your computer vision / presence sensor / queue system has died

automatic, via Report Health — see below

your project reports the fault; the kiosk shuts, and reopens when you report it fixed

Your own operations team wants to shut it remotely

manual, via a WebSocket client sending blackout

your service holds it shut, then releases

`Set Blackout` or `Report Health`? — the two Blueprint nodes

Both shut the kiosk, so it is easy to pick the wrong one. The difference is simple:

Set Blackout Report Health

	`Set Blackout`	`Report Health`
What it is	"shut the kiosk, because I say so"	"this piece of equipment is broken"
Which switch	the manual one — exactly the same switch as the tablet toggle	the automatic one
Use it when	you want to shut the kiosk from Unreal instead of from the tablet — a scheduled closing time, a button somewhere else, your own operations system	something you own has actually stopped working — a camera, a sensor, a queue system
Who can undo it	anybody, from the tablet	only your own code, by reporting the same check healthy again

What it is

"shut the kiosk, because I say so"

"this piece of equipment is broken"

Which switch

the manual one — exactly the same switch as the tablet toggle

the automatic one

Use it when

you want to shut the kiosk from Unreal instead of from the tablet — a scheduled closing time, a button somewhere else, your own operations system

something you own has actually stopped working — a camera, a sensor, a queue system

Who can undo it

anybody, from the tablet

only your own code, by reporting the same check healthy again

Set Blackout is just the tablet toggle, reachable from a graph. It carries no meaning beyond "closed"; it is a decision, not a diagnosis.

Report Health is a diagnosis, which is why staff cannot clear it. If your camera dies and an operator presses the tablet toggle, you do not want the kiosk to reopen — the camera is still dead. Report Health makes that impossible. It also names the fault on the tablet, so whoever is standing there sees "vision" rather than a mysteriously shut kiosk.

The rule of thumb: if a human decided, use Set Blackout. If a machine detected, use Report Health.

`Report Health` — telling the kiosk about your own equipment

One Blueprint node on the PromethistLink component allows anything in your installation to participate in the kiosk’s out-of-service decision:

Report Health (Check = "vision", Healthy = false, Detail = "the camera process stopped answering")

Three things to know:

You name the check. Use any name, one per watched item. Two reporters sharing a name overwrite each other.
You must report the recovery. Nothing expires: a bad check stays bad until the same reporter declares it healthy again. Reporting from a timer makes the "is it still broken" question answer itself.
The failing names are shown. They reach the tablet, letting the operator see what is wrong instead of a shut kiosk. The sample tablet formats them into a sentence in tablet.ts.

Anything can call it — a Blueprint, or an external process reaching over the tablet’s control channel.

How the kiosk checks itself

The problem: because no connection remains open between visitors, an idle kiosk cannot distinguish a working backend from a dead one. It only notices issues when a visitor is standing there.

So it asks on a timer, on by default — requiring zero configuration. While idle, the kiosk fetches a URL every 10 seconds. Three failures spanning at least half a minute shut the kiosk; the very first success reopens it, without a visitor present. It also asks immediately after anything suspicious — a failed connect, a dropped session, or a network cable moving — rather than waiting for the next tick.

Four properties make it safe to leave on:

It never runs during a conversation, preventing interruptions. Answers arriving after a visitor presses Start are discarded.
Slow to shut, instant to reopen. One bad answer proves nothing; half a minute of them does. A fifteen-second router reboot between visitors will not close your installation.
It works from a cold boot, before anyone starts a session — which is the case that matters, because a kiosk restarted remotely into a broken network lacks visitors to test it.
Any answer at all counts as working — a 404, a 401, even a server error. See the honest caveat below.

Set ProbeUrl if your backend is not ours. Until the kiosk reaches a backend, the probe targets ours — meaning a box that never contacts our host would judge itself by our uptime. Place this under [PromethistLinkHealth] in Saved/PromethistLinkConfig.ini, alongside the interval and failure count. The README contains the full list; nothing here requires a rebuild.

Whose outage is it? When a failure is confirmed, the kiosk queries a neutral third-party address (Google’s generate_204 by default) purely to word the message: our backend is down versus this building has no internet. This directs you to the right person. It changes only the sentence, never the verdict. Set ProbeNeutralUrl= to empty to prevent third-party contact. On a locked-down kiosk LAN that blocks everything but our backend, a blocked Google would report every backend outage as "no internet".

The honest limit of this check. Any reply counts as healthy, proving only that the kiosk can reach the backend, not that the backend is behaving. A server that is up but broken reads fine here, and the kiosk will keep accepting visitors it cannot actually serve. This trade is deliberate: somebody else’s routine deploy returning a 502 for thirty seconds must not close your installation, and a simple fetch cannot tell that apart from a real fault. Closing this gap properly means checking something meaningful, which is on our list.

If a piece of your infrastructure needs stricter monitoring—an API whose failure would lose data, say—do not wait for us. Poll it from your own Blueprint on a timer and feed the answer to Report Health. That is exactly what the node is for, and it is only a few nodes of work. There is currently no way to hand us a second URL to check for you; tell us if you want one and we will look at it.

What you have to build: the out-of-service screen

Unreal decides when to stop serving visitors. It never decides what they see instead — that part is always yours.

On Blackout Changed (bBlackedOut)
   ->  show your out-of-service content

It fires before the conversation is torn down, so your visuals are already up before the avatar goes idle. The other order shows a frame or two of a live-looking avatar with nothing behind it.

Do not just show an error. An out-of-service kiosk is still a screen in a public space. A short loop about the building, exhibition, or company — a showreel, opening hours, anything — is better than an apology. It turns a broken backend into a lost feature instead of a dead installation.

If you are streaming (D and E), some of this is done for you. Those shapes lack an Unreal-rendered big screen to draw on — the big screen is a browser showing video — so the plugin talks directly to that browser. A viewer already watching learns the kiosk is out of service and returns to the player’s landing page. A viewer arriving while shut is turned away at the Connect button, avoiding a loading bar timeout. Both behaviours live in our build of the player, so keep that branch if you fork it.

What is automatic, and what is yours

What happens Automatic?

	What happens	Automatic?
The tablet cannot reach Unreal	the tablet fogs, its controls grey out, a spinner shows	yes, always
Unreal cannot reach the backend	the kiosk shuts, and reopens by itself	yes, always
Something else in your installation broke	nothing, until you `Report Health` it	no — only you can tell
The big screen’s out-of-service content	whatever `On Blackout Changed` draws	no — always yours

The tablet cannot reach Unreal

the tablet fogs, its controls grey out, a spinner shows

yes, always

Unreal cannot reach the backend

the kiosk shuts, and reopens by itself

yes, always

Something else in your installation broke

nothing, until you Report Health it

no — only you can tell

The big screen’s out-of-service content

whatever On Blackout Changed draws

no — always yours

-NoPromethistHealth on the command line entirely disables self-checking — including the automatic switch — for the day it gets something wrong on a box you cannot rebuild.