How to set up a machine light

When to use this

Sometimes the fastest way to know a machine needs attention isn’t a dashboard, it’s a light you can see from across the floor. A machine light turns the same running/stopped state and open andon calls the app already shows you into a physical signal at the machine itself, red means someone’s needed, green means it’s running clean.

What you need

A gateway already online (see set up a gateway: from hardware to green).
The machine already connected, with a running state signal (any machine set up the regular way, or a current-sensed machine, has one).
One of these light types:
- A bare relay beacon, wired to the gateway’s built-in relay output, a single-color lamp. Simple, no extra hardware to buy beyond the lamp itself. See wire the gateway’s panel I/O for the physical wiring, it’s a one-time bench/panel task.
- A USB tower light (a few brands are supported), plugged straight into the gateway with one cable, more colors and a buzzer, no wiring at all. Ask your Spall contact which tower to order.

Steps

Gateways → your gateway → Lights tab.
Click Add light source.
Give it a name (e.g. “Bench Grinder tower light”) and pick its model from the list (which USB tower you bought, or bare relay beacon). For a USB tower, leave the port blank the first time, plug it in, and the app offers to fill it in for you (see Plugging in a new tower below).
Click Create.
For each colored segment the light shows (red / amber / green / buzzer for a tower, one segment for a relay), click Bind…, pick the machine whose state should drive it, and choose Follow machine state. That’s the one-click default and covers almost every case: running/stopped, plus any open andon call.
For anything more specific (“auger jammed,” “temperature over limit”), switch to Follow a signal instead and pick an existing derived measurement, one you’ve already set up on that machine to compute the condition you care about. If you haven’t set one up yet, click Create a derived signal right there in the bind form, it opens the measurement editor scoped to the same machine, and brings you back here once you save. That editor is also where you check the condition against real history before you commit the light to it, and once it’s named, it’s reusable anywhere else in the app too, beyond this light.
The gateway only actually hears about the light once its configuration is pushed, see Sending it to the gateway below, it’s the very next thing to do.

Sending it to the gateway

Creating or changing a light here only saves it in the app, it doesn’t reach the gateway on its own. Whenever the Lights tab has changes the gateway hasn’t received yet, a banner appears right at the top: “Changes here are not on the gateway yet.” Click Push config and it’s sent over immediately, the same push the Config tab’s own Push button triggers, so pushing from either tab does the same thing. Only an admin can click it, everyone else sees the same banner with a note to ask one. Until it’s pushed, a light you just added or rebound won’t respond to Test or Override yet either, see below, those tell you the same thing in the moment you try them.

Testing a color before you wire anything up

Once a light has been pushed to the gateway at least once, each segment has its own Test button right on the Lights tab. Click it and that color pulses for a few seconds, then releases on its own, so you can confirm the lamp order and that the color you expect is the color you get, while you’re still standing at the machine with the cable in your hand. Test all walks every segment in order (red, amber, green, buzzer) so you can confirm the whole tower in one click. You don’t need to bind a single segment first, Test works before any binding exists, it just needs the light itself to have reached the gateway.

If the light hasn’t been pushed yet, Test says so plainly (“this light hasn’t been applied to the gateway yet, push the gateway config first”) instead of pretending the pulse went out, push it (see Sending it to the gateway above) and try again. If the gateway isn’t currently online, or a USB tower’s port hasn’t been detected yet, the Test button says so too and stays disabled instead of pretending it worked. The buzzer’s test always stops itself after a few seconds no matter what auto-silence timeout you’ve set, so it never gets stuck buzzing while you’re troubleshooting.

Testing never creates a binding by itself, and it’s separate from the Override control below. Override is a lasting, timed color change for a segment that’s already bound, and it’s held to the same rule, it also refuses with the same plain message on a light that hasn’t reached the gateway yet. Test is a quick, self-releasing pulse that works whether or not anything’s bound yet.

Plugging in a new tower

The first time you plug a supported USB tower into a gateway, its Lights tab shows a banner: “New device on USB port X, set up as a light?”. Click Set up and the port is filled in for you, nothing is ever configured on its own without you clicking through this.

Once you’ve set a light up, the app remembers that light by its physical USB port, and stops offering that port as a new device, even if the gateway mentions it again before it’s had a chance to notice the light is already spoken for. If you unplug the light and plug it into a different port (or move it to a different gateway), it counts as a new light and needs setting up again on the new port, moving the plug moves the identity, and the OLD port becomes offerable again since nothing claims it anymore.

What the light shows

Red: the machine is stopped past its detection window, or there’s an andon call open that no one’s picked up yet. On a USB tower, a brand-new call also flashes and sounds the buzzer for a couple of minutes to grab attention, then settles to steady red so it doesn’t keep nagging once someone’s had a chance to notice. If the buzzer condition keeps going past a minute, the noise quiets on its own, the light itself stays exactly as red as before, only the sound backs off.
Amber: someone’s acknowledged the open call and is on it, or the light can’t tell right now (its connection to the cloud has been down long enough that it can’t vouch for “nothing’s open”). A bare relay beacon can’t show amber, it goes dark for both this and green, only a USB tower shows the difference.
Amber, slow flash (no data): a separate case from the one above, this one is about the machine’s own data instead of the cloud link. The app always shows a “no data” status right on the Lights tab whenever the reading behind a segment’s binding goes stale (by default, about two minutes without a fresh value), it never shows a fake zero and calls it clear. Whether the tower itself also flashes for this is a separate, per-source setting on the Lights tab, off unless you turn it on. Turn it on there if you want the physical light to flash a slow amber for this case too, and set how long a reading can go stale before it does. This flash is slower than a real flashing-amber binding, so it’s never mistaken for one. A bare relay beacon can’t show it either, same as the amber above.
Green: running, nothing open.
More than one segment can be lit at once if that’s what’s going on, the app never hides a real condition behind another one to keep things looking tidy.

The light figures out running/stopped and any down-machine red entirely on the gateway itself, it doesn’t need a live connection to the cloud for that part. Only the andon-call state (open, acknowledged, resolved) depends on hearing from the app, and if that connection has been down too long, the light plays it safe and shows amber instead of pretending everything’s fine.

Turning a light a color yourself

Next to each segment, an Override control lets anyone with edit access (not a view-only account) force that segment to a color for a set time, useful for a planned situation the automatic rule doesn’t cover yet (for a quick “does the wiring actually work” check, use Test above instead, it releases itself and never leaves a lasting override banner behind). An override always shows a banner (“Overridden to <color> by <name> until <time>”) right on the segment so it’s never mistaken for the real, automatic state, and it always has an end time, or you can clear it early yourself. Once it expires (or you clear it), the light goes back to following its normal binding.

Checking it’s reporting

Back on the Lights tab, each segment shows a quiet status chip, its last-reported value and how long ago that was (“as of 12s ago”). A freshly-bound segment reads “Not yet reported” until the gateway’s next check-in, that’s expected, not a fault. If the gateway evaluated a color but couldn’t confirm the tower actually showed it (unplugged, a bad cable), the chip says so plainly instead of pretending the light is fine. This chip is the app’s own view of the physical light, it can never show something the light itself doesn’t already agree with.

Troubleshooting

Test or Override says “this light hasn’t been applied to the gateway yet”, that’s the reason it won’t fire a pulse or a color change: the gateway doesn’t have this light in its configuration yet. Push it (the banner at the top of the Lights tab, or the Config tab’s own Push button) and try again.
Chip stuck on “Not yet reported”, confirm the gateway is online (its Status tab) and that configuration has been pushed since you added the light (the banner at the top of the Lights tab, or Config tab, Push).
Chip says the color wasn’t confirmed applied, the gateway evaluated a color but the tower didn’t respond, check the USB cable and that the port shown on the Lights tab still matches where it’s plugged in.
Light shows amber and won’t clear, check the gateway’s Network tab for how long it’s been offline or on a degraded connection, amber-for-uncertainty means the light can’t confirm the andon state yet, it clears on its own once the connection is back and it’s heard the current state.
A bare relay light never lights up at all, that’s usually correct if the machine is running clean with no open calls, a relay light only lights for red. Kill the load briefly to confirm it lights (see wire the gateway’s panel I/O for the wiring check).